[Tux] Rakudo version 2020.06-16-gc7c18c214 - MoarVM version 2020.06-16-g82ebd0ed6
csv-ip5xs0.803 - 0.821
csv-ip5xs-207.864 - 8.138
csv-parser23.601 - 26.004
csv-test-xs-200.382 - 0.390
test7.835 - 7.926
test-t1.883 - 1.892
test-t --race0.835 - 0.922
test-t-2031.485 - 32.179
test-t-20 --race8.923 - 9.181
08:30
Geth rakudo/match-refactor: 33 commits pushed by (Elizabeth Mattijsen)++
review: github.com/rakudo/rakudo/compare/8...beece32602
10:36
lizmat important ones: efaa985eb76f4362a and 1fbeece326022bc3528 10:37
Altai-man_ JJMerelo, hi! How is your deadline? 10:49
JJMerelo Altai-man_ tight
But I guess we shouldn't delay it any more
Give me possible days and times 10:50
Altai-man_ JJMerelo, oki, let's see... 10:50
MasterDuke huh. looking at a profile of that read-one-byte example, every call to read() github.com/rakudo/rakudo/blob/mast...#L524-L531 causes a call to accepts_type() github.com/rakudo/rakudo/blob/mast...#L116-L124 11:19
MasterDuke i tried putting something like `my $buf8 := nqp::create(buf8.^pun)` outside the method and then using `$buf8` in the method, but it doesn't change anything 12:19
lizmat MasterDuke: have you tried to create a buf8 pun in the mainline, and then nqp::clone that everywhere ? 12:20
MasterDuke i just used it directly 12:21
i.e., created it in the mainline and used it without the nqp::clone
lizmat afk for a few hours& 12:46
jnthn So far, the startup time improvement running with RAKUDO_RAKUAST=1 is holding. 13:29
However, grammar is still to grow some amount.
(-e '' is in around 70% of the current time) 13:30
MasterDuke very cool 13:36
moritz TBH I was a bit worried that more "meaty" AST objects meant stuff was slower at the start, and we'd need some more optimizations later to make it faster again 13:44
Geth rakudo/rakuast: 9fcba6a1b2 | (Jonathan Worthington)++ | 2 files
Some more quoting stuff for the RakuAST grammar

We can handle these already at the AST level, so add them back into the grammar also. A few commented about bits point at things that still need to be considered.
13:46
jnthn moritz: The big win is that the previous design required us to walk through all top-level setting symbols before parsing, whereas the current design just looks them up on demand, so an O(n) became an O(1). 13:47
I'd noticed the opportunity before, but could never quite bring myself to go through the pain of doing it with the current architecture. :) 13:48
However, the win I expected from it was about 10%-15%, not 30% 13:49
MasterDuke jnthn: i haven't bothered to look myself, but you would know off-hand. have you been copy/pasting the current grammar and mostly changing the actions? or is the actual grammar for the individual pieces also getting changed? 13:52
jnthn Copy-paste-twiddle
Though only some things involve a twiddle 13:53
Anything mentioning $*W for example
Some error reproting in the current grammar goes away
Because it can't be done there
(Because it's possible to make those errors in a synthetic AST also)
MasterDuke nice, doesn't sound too bad 13:54
vrurg jnthn: I wonder why can't RakuAST be translated directly into VM's AST? 14:13
jnthn It's possible, of course, but the semantic gap is rather large 14:15
And you'd have to cross it for every backend
So the answer is it can be, but just because you can do something doesn't make it an ideal factoring 14:16
Also, there is no VM AST any more on the MoarVM backend 14:17
We do QAST -> bytecode
nine Also QAST isn't that bad to generate bytecode from 14:18
vrurg So, I guessed it right. Except for MAST. Is it actual AST or just an alias for bytecode? 14:19
jnthn There used to be something called MAST
Which really was an object graph
Then nine++ eliminated it in favor of going directly from QAST to bytecode
I think maybe there are still some pieces of it around
Modeling pieces like frames
tbh, I've only modified it in small ways since nine's work, so I don't really know exactly :) 14:20
jnthn I'm hopeful that we'll be able to find ways to produce and assemble stuff a bit at a time, however 14:20
So the initial strategy will be "produce a whole QAST tree, then throw it into the current QAST bytecode compiler" 14:21
But later on we might be able to find ways to do it a bit of the tree at a time
nine Yes, MAST::CompUnit, MAST::Frame, MAST::Handler, MAST::Lexical and MAST::Label are the ones that still get used as actual objects. The others really just write bytecode in their 'new' methods instead of creating actual nodes for a tree
jnthn Which would reduce memory use.
I did wonder "hm, could we parallelize it", but I don't actually know we can and get a win, because things like the strings table would need a lock on it 14:22
Or at least, we'd need care
vrurg I think parallelization would make sense in any case. Even if locking would make things much slower, I'd expect some gains anyway. But for any big enough project the biggest problem is not a single compunit but all the modules involved. 14:26
jnthn True, and I guess in-process precomp => multi-threaded precomp might be the bigger value here 14:27
Geth rakudo/rakuast: b93f28a527 | (Jonathan Worthington)++ | 5 files
Basic setup for RakuAST regex support

For now, just enough to make `"abc" ~~ /b/` work, but has done a lot of the groundwork needed to easily add quite a lot more.
17:06
jnthn That was some heavy lifting for a Friday afternoon :) 17:09
home time &
Xliff Is anyone here using Comma to debug rakudo? 18:17
Altai-man_ Xliff, I doubt this is possible now.
Xliff Ah. OK. 18:18
Altai-man_ I mean, if it works cool, but I would be truly impressed if so...
Geth rakudo/match-refactor: ad4dfcbb37 | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Match.iterator should only produce values

It was producing pairs. This was oddly enough, *not* caught by make test or make spectest. It *was* breaking the ANTLR4::Grammar distribution. It no longer does.
19:20
lizmat sadly, Inline::Perl5 still borked 19:21
Altai-man_ : could I ask you for another Blin run?
afk for a few hours&
dogbert17 lizmat: DOM::Tiny and Jupyter::Kernel are two modules which still have failing tests 19:29