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.
Nicholas good *, #moarvm 08:26
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
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
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
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
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.
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
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