00:03 sena_kun joined 00:04 Altai-man_ left 00:26 AlexDaniel left 01:18 Merfont left 02:01 Altai-man_ joined 02:04 sena_kun left 02:17 Xliff left 03:35 stoned75 left 03:37 stoned75 joined 03:59 Merfont joined 04:02 sena_kun joined 04:04 Altai-man_ left 05:36 softmoth left 06:01 Altai-man_ joined 06:04 stoned75 left, sena_kun left 06:19 go|dfish left 06:26 MasterDuke joined 06:33 go|dfish joined 08:02 sena_kun joined 08:04 Altai-man_ left
[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
09:50 MasterDuke left, stoned75 joined 09:59 lichtkind joined 10:01 Altai-man_ joined 10:04 sena_kun left 10:08 JJMerelo joined
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
10:50 MasterDuke joined
Altai-man_ JJMerelo, oki, let's see... 10:50
11:01 JJMerelo left
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
12:02 sena_kun joined 12:04 Altai-man_ left
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
14:01 Altai-man_ joined 14:04 sena_kun left
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
14:20 lichtkind left
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
14:30 lichtkind joined 14:37 lichtkind left 14:39 lichtkind joined 14:40 lichtkind left 14:42 lichtkind joined 14:44 lichtkind left 14:45 lichtkind joined 14:50 lichtkind left 16:03 sena_kun joined 16:05 Altai-man_ left 16:51 stoned75 left 16:52 stoned75 joined 16:55 AlexDaniel joined, AlexDaniel left, AlexDaniel joined
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 &
18:02 Altai-man_ joined 18:04 sena_kun left 18:06 Xliff joined 18:14 vrurg_ joined
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...
18:19 softmoth joined 18:54 lichtkind joined 19:03 go|dfish left 19:17 go|dfish joined
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
19:44 vrurg_ is now known as vrurg 20:02 sena_kun joined 20:05 Altai-man_ left 20:14 softmoth left, softmoth joined 21:16 leont_ left 22:02 Altai-man_ joined 22:04 softmoth left, sena_kun left 22:49 lichtkind left

Powered by Cro and the Raku® Programming Language.

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

Thank you!