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 *, * 06:09
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/04/04/2022-...completer/ 12:45
nine jnthnwrthngtn: I'm not sure the !eval test in t/12-rakuast/var.t makes sense as it is. It's still using EVAL to run the code, but EVAL uses a RakuAST::Resolver::EVAL which will e.g. find the outer package. 20:08
jnthnwrthngtn nine: I think the point was that it declares a fresh GLOBALish and the $y lives in that, rather than taking the surrounding package 20:27
I don't see how it can find the outer package; the `outer` of a :!eval is meant to be the setting 20:30
So it can't find the $?PACKAGE of module M lexically either
Or at least, that's how it's meant to be :) 20:31
nine jnthnwrthngtn: but the RakuAST::Resolver::EVAL doesn't know that in this case it isn't supposed to know about the outer package and finds it anyway: github.com/rakudo/rakudo/blob/raku...kumod#L438 20:34
Or arguably it's EVAL itself which still passes the caller's context in this case: github.com/rakudo/rakudo/blob/raku...de.pm6#L87 20:38
jnthnwrthngtn Yeah, it's possible some things are on the resolver hook that should be hanging off CompUnit instead. 20:52
(RakuAST::Resolver::EVAL pre-dates what's been figured out of RakuAST::CompUnit 20:53
Probably the EVAL resolver is also mis-named, since it's really the "we're starting out with an AST" resolver 20:54
An EVAL with source code would be using the Compiler resolver
MasterDuke might be of interest github.com/dyu/ffi-overhead 20:58