Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 01:03 reportable6 joined 02:01 squashable6 left 03:03 squashable6 joined 03:14 frost joined 04:38 evalable6 left, linkable6 left, evalable6 joined 05:40 linkable6 joined 06:02 reportable6 left 06:03 reportable6 joined 07:11 frost left 07:27 squashable6 left 08:03 timo left
Nicholas good *, #moarvm 08:26
09:25 linkable6 left, evalable6 left 09:28 linkable6 joined 09:29 squashable6 joined 10:27 evalable6 joined 10:45 frost joined 11:05 Altai-man joined 11:46 lizmat_ joined 11:47 TempIRCLogger left 11:48 nebuchad` joined, lizmat_ left, lizmat_ joined 11:50 TempIRCLogger joined 11:51 bartolin_ joined, Util_ joined, RakuIRCLogger joined 11:55 lizmat_ left, lizmat_ joined, lizmat left, gfldex left, bartolin left, JRaspass left 11:56 nebuchadnezzar left, Nicholas left, Util left, gfldex_ joined, lizmat_ left, lizmat joined, Nicholas joined 12:02 reportable6 left 12:03 JRaspass joined 12:06 frost left 13:05 reportable6 joined 13:56 squashable6 left 13:58 squashable6 joined 14:27 leonzh joined
nine Funny observation. That "expected Int but got Str" error disappears when I run with --ll-exception. Or rather, it still happens as normal part of trying to bind to a multi candidate. But it's not reported and instead we continue testing the next candidate (which then succeeds) 14:36
lizmat that *is* werid 14:39
*weird even
leonzh Hello, I plan to use MoarVM in a tiny indie game. If I plan to use only the interpreter, does the dynamic optimizer also optimize the bytecode for the interpreter? (like type specialization etc,) If so, that would be great. 14:42
nine Weird as it may be, it is the first clue that makes sense. This is after all about extremely fragmented call stacks. A call stack cleanup issue with regards to exceptions could explain this multi dispatch issue
leonzh: it does 14:43
leonzh =D  nice!
nine Oh the crucial difference is actually that we're calling bind_sig instead of try_bind_sig 15:03
vrurg nine: BTW, what's the semantic difference between the two? When try_bind_sig is used? 15:12
nine Well try_bind_sig should not throw an exception and just return success or failure instead 15:13
vrurg Ok, thanks! grep will tell where it's used. :) 15:14
nine Oh, wait a minute. The generated bytecode is identical. We first do a try_bind_sig, and only if that succeeds we're supposed to do a bind_sig. 15:18
15:19 Kaiepi left
lizmat wasn't the idea to only do that once ? 15:22
I mean, if the bind_sig succeeded, to use the result immediately ?
nine Maybe that's NYI for destructuring 15:23
jnthnwrthngtn It uses the slow-path binder, but it still doesn't repeat the work 15:29
Assuming we're talking about actual calls
nine This is weird....in the failing case we never call try_bind_sig 15:30
jnthnwrthngtn Capture to signature smart-matching always goes through the slow-path binder for example
15:31 leonzh left
nine Ah, got it! MVMCallStackRecord *under_frame = frame_rec->prev; 15:34
under_frame is a callstack region record, but we're looking for the bind control record
and fixed 15:36
(on the assumption that a region start record is the only thing that can get in between that bind control record and the frame record) 15:37
jnthnwrthngtn Yes, I don't think a continuation tag could get in there 15:40
Maybe we need to extract a "next_significant_record" or similar function
nine Well, this is already using the callstack iterator 15:42
jnthnwrthngtn ah, OK 15:55
16:08 Kaiepi joined
Nicholas Um, quiz question - I shouldn't be able to get to "MoarVM panic: Internal error: Unwound entire stack and missed handler 16:46
"
jnthnwrthngtn No, although I think some cases of native callbacks leaking exceptions can lead to that 16:49
Nicholas I will see if I can reduce it a bit
jnthnwrthngtn I thought we got a better error for it, but apparently not
Well, or we lost it somewhere along the way 16:50
Nicholas It's a return inside a Cro get handler
jnthnwrthngtn Oh.
Nicholas Yes. I thought roughly this too
jnthnwrthngtn Yeah, you'll need to use a sub, not a block
Nicholas at least, I added a few lines which I thought were innocent
jnthnwrthngtn Since `return` binds to the enclosing `sub` 16:51
Nicholas ah OK. But still, it shouldn't panic?
jnthnwrthngtn I suspect you have something like `sub routes() { route { get -> { return } } }` or similar
No, it should complain that the handler is not in dynamic scope 16:52
(The sub that the `return` binds to was already exited)
Nicholas Do I need to make a better test case?
jnthnwrthngtn m: sub foo() { -> { return 42 } }; foo()()
camelia Attempt to return outside of immediately-enclosing Routine (i.e. `return` execution is outside the dynamic scope of the Routine where `return` was used)
in block <unit> at <tmp> line 1
jnthnwrthngtn So there it works
But I wonder if this is because the `get` block runs on another thread
m: sub foo() { start { return 42 } }; foo(); sleep 1; 16:53
camelia Unhandled exception in code scheduled on thread 4
Attempt to return outside of immediately-enclosing Routine (i.e. `return` execution is outside the dynamic scope of the Routine where `return` was used)
in block at <tmp> line 1
jnthnwrthngtn Nope
Yes, I think we'll need it golfed
Since the basic cases work fine
Nicholas OK. I'm going to eat first. And possibly other 16:54
but I do have 2 crates of beer in stock, so I can take my time...
jnthnwrthngtn It's important to other enough.
Especially on a Friday.
jnthnwrthngtn has plenty of other in the beer fridge too :) 16:55
17:47 Colt left, Colt joined 17:56 Colt left 17:59 Colt joined 18:02 reportable6 left 18:07 Colt left, Colt joined 18:38 [Coke] left
Nicholas jnthnwrthngtn: sub MAIN() { ... } is important to the panic. I can golf it to this: paste.scsys.co.uk/596213 18:42
I don
I don't know how to golf the Cro out of that.
18:43 Altai-man left
Nicholas In that, I suspect it's what Cro is doing with threads and supplies, but I don't know what the important shape is that triggers the panic 18:43
One gets the panic when the route is run - ie GET localhost:10000/notifications
18:45 [Coke] joined
Nicholas doesn't need to be the implicitly called MAIN - having the code in a sub foo and then calling that does the trick too 18:58
jnthnwrthngtn ohh 19:17
m: sub { await start return }()
camelia MoarVM panic: Internal error: Unwound entire stack and missed handler
jnthnwrthngtn So it's important the sub is in dynamic scope on a *different* thread 19:18
And that's why the simpler golf didn't nail it 19:19
Nicholas wow, your golf is so much shorter than mine. But I would never have got to it 19:22
20:57 colemanx left 21:01 colemanx joined 21:03 reportable6 joined 22:03 evalable6 left 22:11 [Coke] left 22:13 [Coke] joined 22:34 kjp joined 22:45 squashable6 left 23:31 dogbert11 left, dogbert11 joined 23:53 lizmat_ joined, RakuIRCLogger left, TempIRCLogger left 23:54 Geth left, lizmat left

Powered by Cro and the Raku® Programming Language.

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

Thank you!