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
01:10 lizmat left 01:12 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 01:37 lizmat joined, p6bannerbot sets mode: +v lizmat 01:41 lizmat left 03:22 sivoais_ left 03:23 sivoais joined, p6bannerbot sets mode: +v sivoais
samcv someone is getting a Internal error: Unwound entire stack and missed handler message with their code anyone here who can help? 05:24
05:40 avar left 05:41 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 05:42 p6bannerbot sets mode: +v avar 07:23 domidumont joined 07:24 p6bannerbot sets mode: +v domidumont 07:38 domidumont left 07:57 zakharyas joined 07:58 p6bannerbot sets mode: +v zakharyas 07:59 domidumont joined 08:00 p6bannerbot sets mode: +v domidumont 08:02 robertle joined 08:03 p6bannerbot sets mode: +v robertle 09:01 lizmat joined, p6bannerbot sets mode: +v lizmat
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
12:09 zakharyas left
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
13:34 zakharyas joined 13:35 p6bannerbot sets mode: +v zakharyas 14:19 lizmat left 14:45 Merfont left 15:09 MasterDuke left 15:25 ZofBot left, huggable left, ZofBot joined, p6bannerbot sets mode: +v ZofBot, buggable left 15:26 ZofBot_ joined, p6bannerbot sets mode: +v ZofBot_, ZofBot__ joined, ZofBot__ left, ZofBot_ left, ZofBot left, ZofBot joined, p6bannerbot sets mode: +v ZofBot 16:13 Kaiepi joined 16:14 p6bannerbot sets mode: +v Kaiepi 16:25 domidumont left 16:35 robertle left 17:07 robertle joined
samcv jnthn, afaik they aren't using any nativecall code 17:07
17:08 p6bannerbot sets mode: +v robertle
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
17:38 Ven`` joined 17:39 p6bannerbot sets mode: +v Ven`` 18:16 Ven`` left 18:19 Ven`` joined 18:20 p6bannerbot sets mode: +v Ven`` 18:33 Ven`` left 18:48 Ven`` joined 18:49 p6bannerbot sets mode: +v Ven`` 19:00 zakharyas left 19:35 lizmat joined, p6bannerbot sets mode: +v lizmat
jnthn Oh...yeah, doing `return` in a `react` isn't going to end well unless we very magically handle it :) 20:13
20:25 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
lizmat jnthn: a strategically placed CONTROL block ? 20:27
20:40 zakharyas joined 20:41 p6bannerbot sets mode: +v zakharyas 20:51 lizmat left 20:53 lizmat joined, p6bannerbot sets mode: +v lizmat 20:57 lizmat_ joined, p6bannerbot sets mode: +v lizmat_ 20:59 lizmat left
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
21:26 zakharyas left 21:28 lizmat_ left
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
22:22 Ven`` left 23:07 lizmat joined, p6bannerbot sets mode: +v lizmat