Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-15

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:18 vendethiel joined #moarvm
01:29 [Coke] moar is failing 40+ tests on rakudo on os x.
01:29 [Coke] er.
01:29 [Coke] sorry, on hack.p6c.org
01:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:50 colomon joined #moarvm
01:57 prammer joined #moarvm
02:12 [Coke] not able to build rakudo-j on my 4G laptop anymore.
02:12 [Coke] (nqp-j, even)
02:20 vendethiel joined #moarvm
02:51 vendethiel joined #moarvm
03:52 vendethiel joined #moarvm
04:34 ggoebel2 joined #moarvm
05:12 vendethiel joined #moarvm
05:42 vendethiel joined #moarvm
06:07 vendethiel joined #moarvm
06:58 FROGGS joined #moarvm
07:00 FROGGS o/
07:20 lizmat [Coke]: I have no trouble building JVM rakudo HEAD on OS X
07:32 TimToady joined #moarvm
07:46 vendethiel joined #moarvm
07:47 zakharyas joined #moarvm
08:52 vendethiel joined #moarvm
08:52 * jnthn build nqp-j only a day or two ago 'cus he was working on adding the multidim stuff
09:40 vendethiel joined #moarvm
10:13 vendethiel joined #moarvm
12:05 rurban joined #moarvm
12:17 [Coke] lizmat, jnthn (whoops, wrong window on the jvm stuff). I remember the build being fiddly ages ago and needing to change how much memory we asked for during the build. I may have lost a local mod (this is an old laptop)
12:17 [Coke] will just hope he gets the 16G one back soon.
13:09 dalek MoarVM: f22142b | hoelzro++ | src/io/procops.c:
13:09 dalek MoarVM: uv_close a proc handle when we're done reading
13:09 dalek MoarVM:
13:09 dalek MoarVM: Fixes Rakudo RT #125616
13:09 dalek MoarVM:
13:09 dalek MoarVM: uv_read_stop prevents further reads from being scheduled on a handle,
13:09 dalek MoarVM: but apparently doesn't close the OS file descriptor.  This caused a
13:09 dalek MoarVM: runaway descriptor allocation when tapping standard output or error
13:09 dalek MoarVM: on Proc::Async
13:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f22142be9f
13:13 jnthn hoelzro++
13:14 timotimo good catch, hoelzro++
13:14 jnthn hoelzro: Don't suppose you could commit a test for that?
13:15 hoelzro jnthn: sure, in roast?
13:15 jnthn Please
13:15 hoelzro timotimo: it's only because I ran into it =)
13:15 timotimo well, you're apparently doing a better job at actually using our stuff than me ;)
13:15 timotimo recently my perl6 activities have been pretty limited
13:16 hoelzro I'm *really* trying lately to actually use Perl 6 instead of fixing every little problem I encounter
13:16 JimmyZ https://github.com/MoarVM/MoarVM/blob/f22142be9f058a2c2c4395fc3706ac0e2a2e9af5/src/io/procops.c#L715 # how about this one ?
13:16 hoelzro JimmyZ: that's a good question; I think that also should change
13:17 timotimo hoelzro: i hate to say you're still fixing problems in core :S
13:18 hoelzro timotimo: https://xkcd.com/597/
13:18 hoelzro also, this makes me sad: https://github.com/search?utf8=%E2%9C%93&q=abort+repo%3Alibuv%2Flibuv&type=Code&ref=searchresults
13:19 jnthn hoelzro: I'll bump MOAR_REVISION/NQP_REVISION also too
13:19 jnthn Think I'm about to fix another regex engine bug
13:19 timotimo abort is the thing that makes the process die with SIGABRT?
13:19 hoelzro jnthn: I might have another change coming
13:19 hoelzro timotimo: yes
13:19 jnthn hoelzro: ah, ok
13:19 hoelzro jnthn: I'm thinking of throwing an adhoc exception for https://github.com/MoarVM/MoarVM/issues/165
13:20 hoelzro just so people (ie. me) are not surprised when that bug happens
13:20 timotimo so libuv isn't very fault tolerant?
13:20 hoelzro timotimo: apparently not =/
13:20 timotimo yeah, that issue still boggles my mind
13:20 hoelzro be back shortly; have to see my wife off to work
13:22 jnthn hoelzro: We could do that for now, yes
13:22 jnthn hoelzro: I suspect this may be the issue that pushes us away from libuv for sync IO
13:40 hoelzro alright, I'll get on that then
13:49 zakharyas joined #moarvm
13:56 hoelzro jnthn: you can go ahead and bump MOAR_REVISION if you want; that bug is proving more interesting than I'd thought =/
13:56 jnthn ok :)
13:57 jnthn Current ongoing discussion on #perl6 may give me a second NQP change to do anyway
14:00 * timotimo first read up to "second NQP" and was like "another??"
14:13 jnthn hoelzro: Congrats, you win an MSVC warning!
14:13 jnthn compiling src\io\procops.obj
14:13 jnthn procops.c
14:13 jnthn src\io\procops.c(699) : warning C4133: 'function' : incompatible types - from 'uv_stream_t *' to 'uv_handle_t *'
14:13 hoelzro ah, crap
14:13 hoelzro I *did* see that with GCC; I just forgot to go back and fix it =/
14:14 jnthn ah, ok
14:15 timotimo uv kinda plays it fast and loose with those "types" :)
14:16 timotimo but to be fair, we also treat everything as an MVMCollectable at some points
14:16 timotimo i guess it's common practice
14:16 dalek MoarVM: d83ec82 | hoelzro++ | src/io/procops.c:
14:16 dalek MoarVM: Fix compiler warning when using uv_close
14:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d83ec82b3e
14:16 dalek MoarVM: 07daf04 | hoelzro++ | src/io/procops.c:
14:16 dalek MoarVM: Use uv_close in Proc::Async read error case as well
14:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/07daf04912
14:16 timotimo and a language like C++ also does it, it just hides the vtable a bit better?
14:17 hoelzro timotimo: I think C++ just has rules for when a pointer to type A can be treated as a pointer to type B
14:17 hoelzro commute &
14:20 FROGGS joined #moarvm
14:49 jnthn So, hunting concurrency bugs that are above VM level is getting tricky.
14:50 jnthn Thankfully, we have The Technology to instrument bytecode
14:50 jnthn I think I'm going to see if I can hack up some env-var-enabled overly-simplistic analysis tool to help
14:51 timotimo that'd be pretty interesting
14:51 timotimo anything particular you're going to model it after?
14:51 jnthn That will spot when a thread writes to something that it didn't allocate
14:52 jnthn Not really...I know about some of the good algorithms but I don't actually need that level of sophistication yet
14:53 jnthn (The good algos want you to do stuff like vector clocks, establish the happens-before relation, and so on)
14:53 jnthn But the bugs I've got seem to be where at some point we end up with supposedly shared-nothing code accidentally sharing
14:54 timotimo right
14:54 jnthn And while some were MoarVM's fault, many of them are code-gen bugs
14:54 timotimo that seems sorta-easy to spot, as we have an owner field in all objects already
14:54 jnthn Right
14:54 timotimo cool
14:56 JimmyZ_ joined #moarvm
15:15 lizmat joined #moarvm
15:23 Ven joined #moarvm
16:20 hoelzro_trying_w joined #moarvm
16:20 retupmoca joined #moarvm
16:20 timotimo joined #moarvm
16:40 cognominal joined #moarvm
17:12 vendethiel joined #moarvm
17:34 vendethiel joined #moarvm
18:13 zakharyas joined #moarvm
19:41 Peter_R joined #moarvm
20:32 colomon joined #moarvm
20:52 dalek MoarVM: 5227f5e | jnthn++ | / (15 files):
20:52 dalek MoarVM: Add cross-thread write debug logging.
20:52 dalek MoarVM:
20:52 dalek MoarVM: Enabled by setting MVM_CROSS_THREAD_WRITE_LOG in the environment. Uses
20:52 dalek MoarVM: bytecode instrumentation and squeals when one thread does a write to
20:52 dalek MoarVM: an object allocated by another thread, and isn't under lock. (You may
20:52 dalek MoarVM: set MVM_CROSS_THREAD_WRITE_LOG_INCLUDE_LOCKED in order to include the
20:52 dalek MoarVM: writes done while holding a lock also). Does not yet deal with binds
20:52 dalek MoarVM: to lexicals in a frame entered by another thread, but gets object,
20:52 dalek MoarVM: array, and hash mutations nailed.
20:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5227f5e33e
20:54 colomon joined #moarvm
20:59 jnthn Nicely shows up that something very odd is going on with RT #125161
21:00 hoelzro yaaaaaay
21:00 hoelzro jnthn++
21:01 synbot6 joined #moarvm
21:02 jnthn Of course, I've still to figure out what exactly, but it gives me stack traces showing where the unexpected cross-thread writes happen.
21:20 TEttinger joined #moarvm
21:38 colomon joined #moarvm
21:51 nwc10 jnthn: seems that Rakudo build fails becaose instrument/crossthreadwrite.h is not installed
21:51 nwc10 In file included from src/vm/moar/ops/perl6_ops.c:2:0:
21:51 nwc10 /home/nicholas/Sandpit/moar-san/include/moar/moar.h:179:41: fatal error: instrument/crossthreadwrite.h: No such file or directory
21:52 jnthn nwc10: interesting...
21:53 jnthn I didn't actually try one of those :)
21:53 jnthn Though, I didn't bump MOAR_REVISION either ;)
21:54 dalek MoarVM: 938098d | jnthn++ | build/Makefile.in:
21:54 dalek MoarVM: Fix "make install" to know about src/instrument.
21:54 dalek MoarVM:
21:54 dalek MoarVM: nwc10++ for reporting.
21:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/938098d1a9
21:54 jnthn That should do it.
21:56 jnthn .oO( If he calls it "moar san", does that mean he considers it his equal? :) )
21:57 nwc10 it has friends such as moar-O2, moar-g moar-32 and even moar-clang-O2
21:58 hoelzro why didn't Travis pick up that failure?
22:01 nwc10 not smoking the newest crack? Just the current versions?
22:01 nwc10 or only re-doing Rakudo if Rakudo changes?
22:02 hoelzro MoarVM has its own Travis config, doesn't it?
22:02 nwc10 either way, it's a good question, and it would be useful if there was a travis that could smoke master/master/nom for any change in all 3 (er 4, roast)
22:02 nwc10 but this isn't me volunteering to figure out how to do it :-)
22:02 hoelzro =)
22:03 hoelzro I wanted to hack a little Travis script that would verify my modules build against the latest Rakudo once a day, if they hadn't been built that day
22:03 * hoelzro .oO( Triple Travist? )
22:04 hoelzro now I need to set it up just for the name =)
22:04 hoelzro it's a shame that Rakudo doesn't spectest in Travis as well
22:05 jnthn Note that Rakudo was only affected if you're a HEAD-chaser
22:05 jnthn Most folks follow the recomended NQP/Moar revisions, and I suspect the Travis builds do too
22:06 hoelzro the Travis builds use both the NQP_REVISON and NQP master
22:06 hoelzro https://github.com/rakudo/rakudo/blob/nom/.travis.yml#L27
22:07 nwc10 to be clear (and I don't think anyone misunderstood me, but to be sure to be sure) I meant "would be useful in addition to what we have currently"
22:09 jnthn aha
22:09 jnthn hoelzro++ # knowing where to look up this stuff :)
22:10 hoelzro this sounds right up our alley: https://github.com/travis-ci/travis-ci/issues/249
22:12 jnthn cool :)
22:13 jnthn OK, enough for me today
22:13 jnthn 'night, y'all
22:13 hoelzro good night jnthn
23:16 nebuchadnezzar joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary