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:05 reportable6 left 00:06 reportable6 joined 01:06 evalable6 left, committable6 left, reportable6 left, notable6 left, linkable6 left, statisfiable6 left, coverable6 left, releasable6 left, nativecallable6 left, shareable6 left, bisectable6 left, benchable6 left, bloatable6 left, unicodable6 left, greppable6 left, sourceable6 left, quotable6 left 01:07 benchable6 joined, notable6 joined, linkable6 joined, sourceable6 joined, statisfiable6 joined, coverable6 joined 01:08 evalable6 joined, reportable6 joined, shareable6 joined, committable6 joined, bisectable6 joined, greppable6 joined, quotable6 joined, nativecallable6 joined 01:09 bloatable6 joined, releasable6 joined, unicodable6 joined 01:20 japhb left 01:23 japhb joined 03:19 linkable6 left, evalable6 left 03:22 evalable6 joined, linkable6 joined 04:22 benchable6 left, coverable6 left, sourceable6 left, notable6 left, releasable6 left, greppable6 left, committable6 left, statisfiable6 left, linkable6 left, unicodable6 left, shareable6 left, evalable6 left, nativecallable6 left, bisectable6 left, reportable6 left, bloatable6 left, quotable6 left, greppable6 joined 04:23 quotable6 joined, nativecallable6 joined, bloatable6 joined, sourceable6 joined, notable6 joined, unicodable6 joined, benchable6 joined, reportable6 joined, committable6 joined 04:24 linkable6 joined, bisectable6 joined, statisfiable6 joined 04:25 releasable6 joined, coverable6 joined, evalable6 joined, shareable6 joined 05:27 frost joined, frost left 05:51 frost joined 06:07 reportable6 left, reportable6 joined
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 ?
10:36 linkable6 left
nine indeed 10:37
10:39 linkable6 joined
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
11:38 sena_kun left 11:39 sena_kun joined 12:06 reportable6 left 12:08 reportable6 joined
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.
14:52 dogbert17 joined 15:09 frost left 15:45 sena_kun left 15:46 sena_kun joined
nine (value in braid: RakuAST::Package (X::SubtestsSkipped), value in $*PACKAGE: RakuAST::Package (Test)) looks legit 16:30
16:57 sena_kun left 16:58 sena_kun joined 18:04 discord-raku-bot left 18:05 discord-raku-bot joined 18:07 reportable6 left 18:08 reportable6 joined
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
19:11 linkable6 left 19:13 linkable6 joined 20:20 Geth left, Geth joined 22:05 discord-raku-bot left 22:06 discord-raku-bot joined 23:54 reportable6 left, committable6 left, bloatable6 left, nativecallable6 left, linkable6 left, releasable6 left, benchable6 left, quotable6 left, shareable6 left, sourceable6 left, statisfiable6 left, bisectable6 left, coverable6 left, evalable6 left, greppable6 left, unicodable6 left, notable6 left, reportable6 joined 23:55 linkable6 joined, greppable6 joined, bloatable6 joined 23:56 coverable6 joined, bisectable6 joined, quotable6 joined, releasable6 joined, benchable6 joined, nativecallable6 joined, committable6 joined, Techcable left, sourceable6 joined 23:57 notable6 joined, statisfiable6 joined, evalable6 joined, unicodable6 joined, shareable6 joined 23:58 Techcable joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!