[01:18] *** vendethiel joined
[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
[01:50] *** colomon joined
[01:57] *** prammer joined
[02:12] <[Coke]> not able to build rakudo-j on my 4G laptop anymore.

[02:12] <[Coke]> (nqp-j, even)

[02:20] *** vendethiel joined
[02:51] *** vendethiel joined
[03:52] *** vendethiel joined
[04:34] *** ggoebel2 joined
[05:12] *** vendethiel joined
[05:42] *** vendethiel joined
[06:07] *** vendethiel joined
[06:58] *** FROGGS joined
[07:00] <FROGGS> o/

[07:20] <lizmat> [Coke]: I have no trouble building JVM rakudo HEAD on OS X

[07:32] *** TimToady joined
[07:46] *** vendethiel joined
[07:47] *** zakharyas joined
[08:52] *** vendethiel joined
[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
[10:13] *** vendethiel joined
[12:05] *** rurban joined
[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
[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
[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
[15:15] *** lizmat joined
[15:23] *** Ven joined
[16:20] *** hoelzro_trying_w joined
[16:20] *** retupmoca joined
[16:20] *** timotimo joined
[16:40] *** cognominal joined
[17:12] *** vendethiel joined
[17:34] *** vendethiel joined
[18:13] *** zakharyas joined
[19:41] *** Peter_R joined
[20:32] *** colomon joined
[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
[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
[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
[21:38] *** colomon joined
[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