github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: samcv++ created pull request #1004:
Attempt to fix MoarVM build on AIX
00:38
samcv someone is getting a Internal error: Unwound entire stack and missed handler message with their code anyone here who can help? 05:24
jnthn samcv: That one is most of the time because they got an exception in some native callback and didn't handle it, and due to the C stack wedged on the code inbetween we don't (can't, in some senses) handle that so well. 09:40
dogbert2_ m: CONTROL { }; warn "foo" 12:19
camelia foo
MoarVM panic: Trying to unwind over wrong handler
robertle R#1605 12:49
synopsebot_ R#1605 [open]: github.com/rakudo/rakudo/issues/1605 `CONTROL { }; warn "";` says Trying to unwind over wrong handler
samcv jnthn, afaik they aren't using any nativecall code 17:07
samcv yeah he's not 17:08
they say they had to move the return out of a react to fix it. otherwise that error comes up 17:10
jnthn Oh...yeah, doing `return` in a `react` isn't going to end well unless we very magically handle it :) 20:13
lizmat jnthn: a strategically placed CONTROL block ? 20:27
jnthn lizmat: You'd need to handle it a lot like `done` in the supply internals, I guess, but it's a bit tricky because most of those are shared between react/supply and we'd only want this for react. Then one'd need to marshall the exception from the thread that did the `return` back to the thread that was blocking on the `react`. 21:00
Do-able, but needs care
lizmat_ jnthn: ack
jnthn But probably worth doing, since folks are trying it, and I can't think of a reason to consider it harmful to make it work. 21:03
AlexDaniel squashable6: next 21:40
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 2 days and ≈12 hours (2018-12-03 UTC-12⌁UTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day