samcv releasable6: status 01:24
releasable6 samcv, Next release in 4 days and ≈17 hours. Blockers: github.com/rakudo/rakudo/issues?q=...%9A%A0%22. Changelog for this release was not started yet
samcv, Details: gist.github.com/f921fe36733106bd17...a906b5f760
brrt good * #moarvm 07:07
nwc10 jnthn++ # cf523c89c06a0f480ec43a8adbc54d0ff453ebee 07:34
samcv good * br 07:52
timotimo i just checked and it looks like travis machines have 2 cores actually 12:45
we should be running our travis jobs with at least -j2 on the makefile
Geth MoarVM: c512dce8e9 | (Timo Paulssen)++ | .travis.yml
travis: use 2 cores for compilation and tests

it looks like travis virtual machines usually have 2 cores available.		 12:48
timotimo let's see how that helps
travis-ci MoarVM build failed. Timo Paulssen 'travis: use 2 cores for compilation and tests 13:02
travis-ci.org/MoarVM/MoarVM/builds/340930988 github.com/MoarVM/MoarVM/compare/a...12dce8e91c
dogbert2 jnthn: there's at least one GC related bug left in case you're interested: github.com/MoarVM/MoarVM/issues/620 13:39
timotimo oh, haha
the semaphore test case doesn't work if there's not enough cores i guess 13:40
it doesn't even seem to save that much time
Geth MoarVM: 1c79ca35d4 | (Timo Paulssen)++ | .travis.yml
set test jobs back to 1

the semaphore test in nqp seems to flap if only two cores are available but one of the cores is busy running other test files		 13:42
jnthn huh, that's odd 13:44
dogbert2 ?
jnthn I'd expect the semaphore test to work reliably 13:45
timotimo then perhaps that failure is actually legitimate?
jnthn Probably 13:46
travis-ci MoarVM build passed. Timo Paulssen 'set test jobs back to 1 13:57
travis-ci.org/MoarVM/MoarVM/builds/340951714 github.com/MoarVM/MoarVM/compare/c...79ca35d448
brrt i have ehm, debugged the bug a bit further 15:27
the JIT appears to stuff a small number into where the GC thinks it should find an object 15:28
dogbert2 that doesn't sound very good does it ? 15:35
jnthn Matches the stack traces pretty well
timotimo that'd often be a frame, right? because they don't actually have their header? 15:41
jnthn More likely just some junk 15:42
dogbert2 should Proc.kill return any file descriptors to the system or is that up to the GC? 15:54
dogbert2 I meant Proc::Async.kill ofc 15:57
brrt is back online 15:58
i wonder if there is a way in which a frame can be allocated, which does not respect the spesh_cand jitcodes' frame size 16:00
or, if i'm not computing that correctly
so this makes spilling quite suspicious 16:04
but, this frame, that's different from the one where the jit bisect script points us to 16:10
:-(
brrt correction, after MVM_SPESH_BLOCKING it isn't 20:04
Kaiepi thank you so much github.com/MoarVM/MoarVM/pull/801/files#diff-0 22:14
this has been driving me insuts for weeks
timotimo oh whoops :) 22:55
Kaiepi stack overflows 22:58
not... insut? what
oh nuts 22:59
geekosaur was trying to figure out what keyboard layout would lead to that keysmash
Kaiepi casual qwerty 23:00
unless you couunt tipsy as a keyboard
jnthn .tell brrt Don't suppose a data breakpoint on the thing we're overwriting could help at al? 23:09
yoleaux jnthn: I'll pass your message to brrt.
MasterDuke is this the sort of thing rr would be useful for? 23:14
jnthn Perhaps, yes 23:18
Especially if it does reverse data breakpoints 23:19
(I suspect it does)
Kaiepi ok 23:26
the callbacks are happening after its been faced to the c part 23:27
*crashing
jnthn Hm, it makes it back into MoarVM? 23:33
Kaiepi yep 23:46
gimme a second i'll get some more detail out of it 23:48
shit i forgot to compile moar with telemetry 23:49

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!