brrt ohai #moarvm 05:55
nwc10 good *, brrt 05:56
brrt \o nwc10 05:57
i have another bug and i can be very short about it this time
i think the problem is the gc-moveable objects combined with 'dumb' spilling i talked about earlier 05:58
i.e. when I spill a value it doesn't end up as a GC root and hence is not updated when the GC runs 05:59
brrt so what i have to do, it seems, is record the 'objectness' (or 'collectableness') of values computed by nodes, then when I allocate a local for temporary storage, I mark that as a collectable in the local_types array 06:11
this seems to me, to be entirely doable 06:14
nwc10 I understand this enough to say that if your first part is a valid diagnosis of the cause, then the second part should be a solution, and should be doa-ble 06:20
and also, that the first part is going to be a bug, even if it's not the exact problem this time
brrt right :-) 06:22
the moral question i'm asking myself is, is it worth proving that this is the bug 06:23
because if it *isnt't* the bug, but another one, then fixing the above might 'hide' the real bug
nwc10 ["how easy is it to prove?" "won't know until it's finished"] ? 06:24
brrt i seem to recall jnthn had developed gc debugging macros 06:25
that should probably make proving easier
nwc10 await jnthn?
brrt probably best
nwc10 coffee bootstrapping near miss - was distracted by the fact that the coffee machine had run out of water 06:43
fixed that, but forgot that I'd not yet put a cup underneath it.
nwc10 Switched on, realised, grabbed cup from top of machine, avoided disaster 06:44
IIRC the only other time I made this mistake, I had to grab the cup from the cupboard
The IRC logs here will remember. They remember things like this. 06:45
nine Too much action for early morning
brrt :-D
nwc10 you know, one solution would be for programmers to work on site, in shifts, 24x7, so that the previous shift can bootstrap coffee for the new shift. 06:46
seems like an excellent idea. but I suspect that it will never catch on.
brrt seems reasonable
nine But not compatible with me starting out my day in my home office... 06:47
nwc10 clearly the home office will have to go!
nine I'm not sure I want to have coders around all night ;)
nwc10 "what could possibly go wrong?"
jnthn brrt: fwiw, the GC debug stuff is done by various macros, including redefining the register access ones in interp.c, which makes it a tad less useful for catching JIT bugs perhaps 12:40
brrt hmmm 12:41
well, yeah
i thought maybe reducing the nursery size makes it more reliable
jnthn Yeah, typically it does 12:42
brrt :-) 12:47
that makes it a pretty reliable crash indeed 13:00
(16k nursery size)
and, dependent on JIT, so that's even better 13:01
Geth MoarVM: zoffixznet++ created pull request #606:
Use more professional language in error message		 13:49
Geth MoarVM: 9097de15b5 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/strings/parse_num.c
Use more professional language in error message
 14:07
MoarVM: 636f2195db | lizmat++ (committed using GitHub Web editor) | src/strings/parse_num.c
Merge pull request #606 from zoffixznet/patch-1

Use more professional language in error message
Geth MoarVM/even-moar-jit: a407d54134 | (Bart Wiegmans)++ | docs/jit/todo.org
Document problem with spilling

JIT value spilling does not mark the spilled values as collectable, which means the GC will not update them, which would cause them to go stale, which is probably what causes a crash when I introduce sp_fastcreate as a template.		 14:51
lizmat And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/06/12/...ty-sorted/ 20:33
[Coke] lizmat++ 21:03
timotimo good weekly, aye 21:07
jnthn lizmat++ # keeping up with the weeklys :) 21:25

Powered by Cro and the Raku® Programming Language.

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

Thank you!