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.
nine jnthnwrthngtn: 329! 08:31
jnthnwrthngtn: github.com/rakudo/rakudo/commit/997c4f20b2 adds API and needs review
lizmat looks like we can't build on Windows since dev.azure.com/Rakudo/rakudo/_build...7ed1ecd095 ? 10:24
MasterDuke a quick google suggests atomic support wasn't added until visual studio 2022 10:30
but CI uses Visual Studio 2019
lizmat so: does that mean we have an issue with testing, or more generally with building ? 10:33
MasterDuke we could revert a3476e286967f33af50c6dad821db16bf347b5bc (which made C11 atomics the default), we could add the `--no-c11-atomics` MoarVM option to our Windows CI jobs, we could add a probe in Configure.pl to check whether C11 atomics are actually supported 10:36
lizmat feels like the last option would be best ?
nine indeed 10:37
nine method multi_declarator:sym<multi> 10:58
And suddenly the flexibility of routine names makes so much sense... 10:59
Surprisingly just parsing multi declarators (and still compiling them into plain normal only routines) gets us to 331 11:24
jnthnwrthngtn omg, I must have been sleepy when I did the Rat parsing stuff, it was doing it wrong 12:11
So Rat literals often got the wrong values
Fixing that is worth 32 extra passes, bringing us to 356 even before I pull nine++'s latest things :)
lizmat jnthnwrthngtn++ 12:14
jnthnwrthngtn nine: Mixed feelings about the signature "tell, don't ask" changes, in so far as I'm not sure if it will have a negative impact when folks manipulate the AST (for example, add extra parameters) 12:20
Plus now we have a mix of "some properties (like invocant type) are discovered through attachment, others are pushed down at BEGIN time" 12:21
nine It has the benefit of being a solution I could find. It had no competitors... 12:22
It's not clear whose responsibility it is to determine those types. I could argue it both ways. It'd certainly be easier (more magical) for parameters to do it. But then this magic may also be a bit surprising and get in the way. Arguably it's for the owner to decide these things. 12:25
We can of course go all the way and treat invocant type the same. At least that would make it consistent. Only reason I didn't do it is that I wanted to get by with as few changes as possible. 12:27
jnthnwrthngtn The attachment mechanism is meant to be the general way for handling situations where compilation and meta-object production depends on the surrounding context, although it's certainly the case that timing and similar around it is not fully fleshed out yet 12:30
nine BEGIN makes everything hard 12:31
jnthnwrthngtn Right, and I'm certainly not "done" in terms of exploring that territory in the RakuAST design
nine So I suggest leaving it as it is for now, so we continue to make progress and collect more use cases and re-visit that part later with a hopefully better design. 12:32
jnthnwrthngtn OK, hopefully the revisit won't be too painful. 12:38
Seems we're up to 375 passing tests 12:39
Blasting us well over the 25% mark (27.7%) 12:40
MasterDuke nice 12:41
jnthnwrthngtn In general, I want to try and avoid too many special-case interactions between AST nodes. So I hunt for generic things (like visiting, the attachment mechanism) that extract common "node interaction patterns" and solve many problems at once. 12:43
The expression thunk thing is another example of that
Timing *also* comes up there, though: when is the right time for an expression to get its whatever-code thunker attached? 12:44
(I don't know yet.)
BEGIN time execution also implies that we might need to push parts of the AST into later "stages" than we might naturally otherwise do 12:45
It may be that at the point you BEGIN-time evaluate something, the AST below that point is made immutable, for example. 12:46
Anyway, I guess there's some kind of lifetime model to come up with here. 12:47
That should also rationalize the difference between EVAL from parse-time and EVAL from synthetic AST 12:48
Or when synthetic AST appears in a parse-produced AST (for example, thanks to a macro) 12:49
(Effectively, in the case we're parsing, BEGIN-time effects can affect how we parse/interpret what follows. But in a synthetic AST, well, it's already decided what things are. A bit like how precedence is no longer a question in an AST.) 12:50
nine How would traits then work with a synthetic AST? 12:51
jnthnwrthngtn The BEGIN-time effects are performed, it's just that there's not a parsing triggering them "as soon as possible" 12:52
The question is what the rules are for triggering that 12:53
For example, should there be a rule like "my children must be in at least the compilation phase that I am"
We're going to have a nice headache in this area with quasi quoting too :) 12:55
Lunch, bbiab 12:56
lizmat MasterDuke: will you do the Rakudo bump ? 12:59
MasterDuke sure 13:04
lizmat well, I can do that also... just wanted to make sure we're not both doing it :-) 13:09
nine Out-of-sync package detected in LANG1 at age ~= "\n$indents# between tw (value in braid: RakuAST::Package, value in $*PACKAGE: RakuAST::Package) 13:45
I wonder if this is still a correct warning (issued by NQP) or if it's just obsolete.
nine (value in braid: RakuAST::Package (X::SubtestsSkipped), value in $*PACKAGE: RakuAST::Package (Test)) looks legit 16:30
lizmat is it correct that you cannot do an nqp::atkey on a lexpad, unless the key actually exists ? 19:09
if not, you get: Lexical with name 'Version' does not exist in this frame
s/Version/$name

Powered by Cro and the Raku® Programming Language.

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

Thank you!