github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth_ MoarVM: e224567df8 | (Stefan Seifert)++ | docs/ChangeLog
Update ChangeLog for 2019.12 release
 13:21
nine I went through the release guide and finished all steps except for the ones about signing and tags. Looks like everything's fine 13:29
sena_kun nine++ 13:32
sena_kun we do need to finish the process properly, though. as for github.com/rakudo/rakudo/issues/3311 I am not really sure. one thing it can be reproduces on macos, another one it reproduces on some macos setups, excluding MBP in question. 13:45
nine Apparently the test in question has long been troublesome: rt.perl.org/Public/Bug/Display.html?id=130042 14:43
But this commit actually gives a hint about what may be the issue again: github.com/rakudo/rakudo/commit/49fd82517f 14:45
And indeed, I can reproduce it by adding a sleep 1; after the nqp::buildnativecall! 14:46
nine Apparently there is still one more side effect of my callback deopt fix: exceptions (even control exceptions like return) don't find a handler. 17:32
dogbert2 m: sub { await start { return } }() 17:48
camelia MoarVM panic: Internal error: Unwound entire stack and missed handler
nine It's....gone? Cannot reproduce it anymore 18:32
Could on my desktop. Then wanted to repro on my laptop for rr but there it worked just fine. Then I noticed that I actually had a local change to Inline::Perl5 that could explain perfectly why I didn't see the missed handler message: I removed the return from the exact callback that I saw failing on the desktop 18:34
But, reverting that change didn't bring on the failure and after trying the same change on my desktop, the failure is gone there, too. Even after I reverted it again!
So maybe the recompile fixed it 18:38
Geth_ MoarVM: 2ac1fa27f5 | (Stefan Seifert)++ | src/core/nativecall.c
Fix race condition with multi threaded NativeCall users

A NativeCall site is considered set up as soon as its body->lib_handle is non-NULL. If we initialize lib_handle too early, a different thread might think everyting's already set up and run into strange issues. So instead, initialize it last, after everything else is done.		 18:44
nine This is just an extension of the fix for github.com/rakudo/rakudo/issues/3311
lizmat nine++ 18:45
dogbert2 nine++, soon there won't be any bugs left :) 18:46

Powered by Cro and the Raku® Programming Language.

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

Thank you!