github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
jeffythedragonsl hello! 06:30
nwc10 Hello 06:31
jeffythedragonsl can someone recommend an easy open issue? 06:51
nwc10 sorry I can't, as I've not been actively working on MoarVM. Hopefully someone else can, although I suspect most folks are asleep currently. 06:53
jeffythedragonsl haha true 06:54
lizmat nine: would a Moar bump be ok ? 13:14
nine sure 13:15
lizmat oki 13:18
brrt \o 14:14
nwc10 o/
brrt happy new year #moarvm 14:16
jnthn Happy New Year :) 16:35
nine jnthn: what optimizer talk did you mean with this comment? github.com/rakudo/rakudo/blob/mast...y.pm6#L452 18:21
nine The Supply stuff is a really confusing maze of exceptions and handlers 18:52
What's making this harder is that I have no idea when getting or returning an actual NULL in a register is OK and when it is not
Well I guess the answer is "rarely" 19:10
nine OMG the solution is so simple! 21:19
The JITed version of takehandlerresult simply doesn't match the interpreted one wrt NULL handling 21:20
Which...is not that surprising. The code matches 100 % the version introduced in the commit "WIP on Handler support." 21:21
MasterDuke nine++ is on a roll recently
moritz don't we have some kind JIT validation mode that runs both versions, and throws an exception when they disagree? 21:38
nine moritz: that would be seriously hard to implement 21:39
moritz :-( 21:40
Geth MoarVM: e35bd5f0ea | (Stefan Seifert)++ | src/jit/x64/emit.dasc
Fix segfaults caused by JITed takehandlerresult returning NULL

The interpreter implementation of takehandlerresult returns VMNull if last_handler_result is NULL. The JITed version didn't and instead put the NULL into the result register, which caused segfaults later on. Fix by having the JITed implementation match the interpreter's.		 21:46
nine The sad part is that despite being able to fix this, I do not have the slightest idea how to write a test for this issue 21:47
I'm really surprised, this didn't show up much more often 21:48
japhb nine: I can remember a lot of bugs over the years that have been of the "I can't believe this didn't explode *all the time*" variety. 22:39
It's kindof amazing how "mostly working" does in fact mostly work. 22:40
nine japhb: yeah, I've fixed a few of those my self. Still amazes me every time 22:43
jnthn nine: I think probably it's because handlers in nqp::handle imply a block being generated, and lexical to local lowering fails to grok that and so thinks it can lower away...probably one or both of $state and &code 23:48

Powered by Cro and the Raku® Programming Language.

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

Thank you!