Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
MasterDuke this is annoying. i got the first part of a new jvm bootstrap, but when i go to remove the old nqp::getstrfromname and build i keep getting `java.lang.RuntimeException: No such attribute '$!do' for this object in clone (gen/jvm/stage2/NQPCORE.setting:374) ...` 01:46
Geth nqp: 0003b32bdb | 陈梓立++ (committed using GitHub Web editor) | src/NQP/Grammar.nqp
whitespace
 02:37
travis-ci NQP build failed. 陈梓立 'whitespace' 02:40
travis-ci.org/perl6/nqp/builds/413872974 github.com/perl6/nqp/compare/59429...03b32bdbba
rkta Don't support freenode and their ICO scam, switch to a network that hasn't been co-opted by corporate interests. OFTC or efnet might be a good choice. Perhaps even matrix.org/ 03:23
lizmat good *. #perl6-dev! 06:49
Files=1248, Tests=75965, 364 wallclock secs (16.09 usr 5.79 sys + 2587.15 cusr 226.74 csys = 2835.77 CPU) 06:50
that's quite a bit less than the last time I did this!
[Tux] 2.290, but I'll run it again later today when I'm not using the desktop 07:31
lizmat jnthn: nowadays, is there a reason not to have infix:<~> *always* return a native str ? 09:13
lizmat since we have a str ~ str candidate that is inlined, it would seem to me it makes sense for strings with a lot of things interpolated 09:18
jnthn Str ~ Str will be inlined by spesh also, surely. 09:22
lizmat yeah, but that will still create a new Str object for each ~ 09:25
right ? 09:26
jnthn That'd still be the case if you just change the return type :)
lizmat it does do a nqp::p6box_s on return
jnthn But actually spesh is in the middle of learning how to spot box/unbox pairs and eliminate the boxing where that's all that happens.
lizmat FWIW, always return str for the infix ~ candidates spectests clean 09:27
jnthn Yeah, but it's wrong
Design wise
lizmat not sure I follow 09:28
you mean, people would need to be able to override infix:<~> ? 09:29
jnthn We consistently have the return types of operators taking boxed inputs as giving boxed outputs. Introducing a discontinuity just because it might be a win that we'll have out of more general optimizations anyway seems odd. 09:30
lizmat the reason I'm looking into this, is trying to optimize nested infix:<~> calls (which are the result of interpolation) and try to turn them into a nqp::join on a list_s 09:31
that should speed up a common case very much 09:32
then I realized that maybe I didn't have to do that, if infix:<~> would always return str rather than Str:D
jnthn No, because str is still immutable, so you'd still have a lot of the costs that join might save 09:33
lizmat BTW, inspired by the cause of one of the speed increases of Perl 5.28: optimizing multiple concats into a specific op
I fugured we wouldn't need the specific op
jnthn I thought the original idea for doing this was making infix:<~> list associative, but I think doing so introduced other issues 09:34
lizmat well, there *is* a candidate for it, which takes a slurpy
which is a big slowdown, I think 09:35
but I don't get your point about immutability of str
I mean, under the hood in the end it all turns into nqp::concat 09:36
so why would we knowingly do all of the boxing ?
I understand your general point: this is about only infix:<~>
jnthn The boxing doesn't matter much in that we'll soon be able to optimize it out anyway 09:37
Of course, there's no reason we can't for now do this by using nqp::concat ops on the pieces and then boxing the final thing 09:38
(After checking we have the CORE.setting version of infix:<~> in scope) 09:39
lizmat yeah, obviously :-)
jnthn But if doing such a transformation anyway, it might be better to go straight for turning it into an nqp::join
lizmat actually, that was my plan 09:40
push to an nqp::list_s, and then join and box at the end
jnthn Because nqp::join can assemble a single result buffer and copy all the pieces in to it
jnthn But nqp::concat even on native things can't do that 09:40
lizmat ok, so this is the plan then: 09:41
1. drop the idea of infix:<~> returning str always
lizmat 2. look into optimizing nested nqp::concats of significant depth into nqp::push_s on a list_s with an nqp::join at the end 09:42
with the core infix:<~> in scope
Geth nqp: 261276cb00 | 陈梓立++ | t/nqp/019-file-ops.t
update test
 09:45
jnthn ++lizmat 09:45
travis-ci NQP build failed. 陈梓立 'update test' 09:51
travis-ci.org/perl6/nqp/builds/413976331 github.com/perl6/nqp/compare/0003b...1276cb00ed
lizmat jnthn: is there a reason that " $a" gets codegenned as "infix:<~>( " ", $a.Stringy )" instead of having MMD take care of stringification? 10:03
or is that some leftover from before MMD was fully functional ? 10:04
jnthn To make it easier for you to turn it into a join without having to worry about things MMD would take care of? :D
lizmat he
jnthn It's probably faster this way, though 10:05
lizmat but seriously, why ?
jnthn Oh, also
We had a fun bug once
my $i = 42; say "$i".WHAT # returned Int :P
evalable6 (Str)
jnthn I think the current factoring meant that bug just wouldn't happen by design. I suspect it's faster to do it this way because it avoids a redispatch and the callsite to .Stringy is potentially monomorphic rather than being a polymorphic one burried in the general coercing infix:<~> candidate. 10:07
lizmat well, I was thinking of adding Cool:D candidates that would directly call .Str
because that's also a common case
the path through Stringy nowadays typically takes 10% 10:08
for Cools
jnthn Measured through --profile, or timings? 10:09
(The profiler distorts very small inlines, thus the question)
lizmat through --profile
|Tux| Rakudo version 2018.06-369-gfa73bb48d - MoarVM version 2018.06-395-g0c5f6e52e
csv-ip5xs0.958 - 0.977
csv-ip5xs-207.880 - 7.955
csv-parser24.064 - 24.399
csv-test-xs-200.437 - 0.439
test7.790 - 8.203
test-t2.184 - 2.218
test-t --race0.935 - 0.948
test-t-2038.395 - 38.856
test-t-20 --race12.565 - 12.669
 11:30
jnthn Umm...oh no 12:23
Can somebody give me a sanity check?
We have this:
method d(IO::Path:D: --> Bool:D) {
$.e 12:24
?? ?Rakudo::Internals.FILETEST-D($!abspath)
!! Failure.new(X::IO::DoesNotExist.new(:path($!abspath),:trying<d>))
}
Bool:D. Failure return type.
m: class C { method m(--> Bool:D) { Failure.new(X::AdHoc.new) } }; C.m 12:25
camelia Unexplained error
in block <unit> at <tmp> line 1
jnthn m: class C { method m(--> Bool:D) { Failure.new(X::AdHoc.new) } }; my $x = C.m
camelia ( no output )
jnthn I thought :D didn't yet through Failure and Nil?
m: class C { method m(--> Bool:D) { Nil } }; my $x = C.m
camelia ( no output )
jnthn m: class C { method m(--> Bool) { Nil } }; my $x = C.m
camelia ( no output )
lizmat is unsure 12:26
afk for a bit to look at the rain
jnthn I'll just retain current behavior for now 12:30
(Looking into the last spectest failures of my p6decontrv plugin)
Zoffix jnthn: I thought Nil and Failure bypassed return typecheck entirely 12:44
jnthn: also, is your p6decontrv plugin "large" work? Like, I just fired off toaster. Should I kill it and wait for you to merge that work? 12:45
Geth rakudo/return-type-check-plugin: db96cab335 | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
Discard p6decontrv when returning a known constant
 12:45
rakudo/return-type-check-plugin: 09f5d0b68b | (Jonathan Worthington)++ | src/vm/moar/spesh-plugins.nqp
One identity sub shall suffice
rakudo/return-type-check-plugin: f8be2a2d64 | (Jonathan Worthington)++ | src/vm/moar/spesh-plugins.nqp
Enforce definiteness checks on return values
Zoffix (well, just Nil, I guess, since Failure is Nil)
jnthn Zoffix: Well, it's large in so far as return value type checks are widely used goes 12:46
Zoffix k, I'll wait for merge :)
jnthn On the other hand, it's also quite isolated (that is, I'm not doing code changes all over the place, just in one or two places)
So it's nothing like so risky as the Scalar changes :-)
I've got one spectest change I need to look at
*regression 12:47
"Type check failed for return value; expected num but got Bool (Bool::True)" 12:49
Huh, we ain't even meant to use this logic if it's a native return type...
jnthn Hurrah, a happy spectest 13:27
timotimo \o/
Geth rakudo/return-type-check-plugin: bf9ab42e0f | (Jonathan Worthington)++ | 2 files
Pass type into the spesh type check plugin

Turns out that the static inliner likes to inline some things that use it.		 13:30
timotimo oh, interesting
lizmat hmmm.. t/spec/MISC/misc-6.d.t flaps for me # Zoffix 13:34
Geth rakudo/master: 6 commits pushed by (Jonathan Worthington)++ 13:35
lizmat whee!
jnthn Probably a good time to do some version bumps now too :) 13:35
grrr 13:38
Can NOT inline AT-KEY (6256) with bytecode size 440 into postcircumfix:<{ }> (2249): bytecode is too large to inline
I'm sure I tuned that to work out before :(
timotimo damn 13:39
jnthn oh, lemme make sure I've got that revert of the change to it...
timotimo oh, the AT-KEY-NO-CONTAINER or what it was
jnthn yeah
yay, that revert helped 13:41
timotimo hooray
jnthn With it reverted a hash reading benchmark takes 0.3758; the manual inline slowed it to 0.6178 :) 13:45
lizmat yeah... :-)
sorry about that one
jnthn No worries, glad I caught it going in 13:46
AT-POS also inlines quite nicely nowadays too
ASSIGN-POS doesn't
Maybe time for another crack at that 13:47
lizmat jnthn: so, time to bump versions, or not ? 13:51
jnthn Yeah, can do :)
lizmat ok, will do in a mo (after my last spectest)
timotimo what was it before the recent round of optimifications? 13:56
jnthn Closer to the 0.6 or so 13:57
Geth rakudo: 3ae97e5f38 | (Elizabeth Mattijsen)++ | 3 files
Optimize interpolation

Before, all interpolation was codegenned with a call to "Stringy". This has several disadvantages:
  - it created a more opcodes (this patch makes core setting 25K smaller)
  - it wouldn't allow for better optimized infix:<~> candidates
  - it didn't allow custom infix:<~> to be seen (as all became Str)
... (13 more lines)
lizmat jnthn: I have one test failing in nqp: t/nqp/019-file-ops.t 14:02
lizmat You planned 111 tests but ran 112. # ring a bell ? 14:02
Geth nqp: b9c0bfcfcb | (Zoffix Znet)++ | t/nqp/019-file-ops.t
Revert "update test"

This reverts commit 261276cb00ed62526050d2328667032888ffaaed.
The commit is unexplained and makes the test suit fail. I don't immediatelly see why the failure occurs.		 14:04
lizmat ok, that's solved then :-) 14:06
Geth nqp: d24856daf0 | (Zoffix Znet)++ | t/nqp/019-file-ops.t
Revert "Revert "update test""

This reverts commit b9c0bfcfcb043cd138e1a1d57233f90793a4914f.
  github.com/perl6/nqp/commit/261276...t-30020362		 14:07
lizmat ah, it's not ?
Zoffix: que?
Geth nqp: c05a3120f8 | (Zoffix Znet)++ | t/nqp/019-file-ops.t
Fix plan

  github.com/perl6/nqp/commit/261276...t-30020362
nqp: e1929a4948 | (Elizabeth Mattijsen)++ | tools/build/MOAR_REVISION
Bump MoarVM for latest goodies
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...5-g0c5f6e5
travis-ci NQP build canceled. Zoffix Znet 'Fix plan 14:08
travis-ci.org/perl6/nqp/builds/414077835 github.com/perl6/nqp/compare/d2485...5a3120f8f2
travis-ci NQP build failed. Zoffix Znet 'Revert "update test" 14:09
travis-ci.org/perl6/nqp/builds/414076313 github.com/perl6/nqp/compare/26127...c0bfcfcb04
travis-ci NQP build failed. Zoffix Znet 'Revert "Revert "update test"" 14:11
travis-ci.org/perl6/nqp/builds/414077657 github.com/perl6/nqp/compare/b9c0b...4856daf079
Zoffix lizmat: yeah, it's solved. It was just a wrong plan after a recent change to that test file 14:13
(the travis failures are N#494) 14:14
synopsebot N#494 [open]: github.com/perl6/nqp/issues/494 Bootstrap for JVM backend
travis-ci NQP build failed. Elizabeth Mattijsen 'Bump MoarVM for latest goodies' 14:14
travis-ci.org/perl6/nqp/builds/414078139 github.com/perl6/nqp/compare/c05a3...929a494815
lizmat that's the JVM build failing with "nqp::strfromname(~$/)"), no registered operation handler" 14:17
Zoffix lizmat: which test flaps int/spec/MISC/misc-6.d.t ? I can't get any to flap 14:18
lizmat the "is native num initialized with 0e0" test
Zoffix 0_o 14:19
lizmat m: say 14051288 - 13956344 # reduction in .moarvm 14:20
camelia 94944
Zoffix lizmat: does this have any failures? gist.github.com/zoffixznet/82efbc2...087b457735 14:20
lizmat: I ran it with `prove -e ./perl6 ../z.p6` 14:21
Zoffix All tests successful. 14:21
Files=1, Tests=100000,
Geth rakudo: a41c37c89f | (Elizabeth Mattijsen)++ | tools/build/NQP_REVISION
Bump NQP to get the latest goodies
¦ rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....4-ge1929a4
lizmat Zoffix: that was ok for me as well 14:23
note: that was with the bumped MoarVm
notable6 lizmat, Noted!
lizmat oops
Zoffix I'm on master/master/master with 2018.06-376-g3ae97e5 built on MoarVM version 2018.06-395-g0c5f6e5
lizmat same here 14:24
[Tux]: looks like the latest bump will have a positive effect on test-t :-) 14:26
lizmat test-t < 1.9 on my machine for the first time 14:27
Zoffix :o
|Tux| it is running now … 14:27
Zoffix Yesterday, stage parse was 99s on this box, today it's 89. Dunno if it's just noise/less busy box, but might be a real improvement :) 14:28
diakopter O_O 14:30
Zoffix ?
diakopter that's fast
sometimes the highest-hanging fruit is heaviest 14:31
jnthn I saw a slight improvement :) 14:31
|Tux| 2.213 on first run
|Tux| Rakudo version 2018.06-377-ga41c37c89 - MoarVM version 2018.06-395-g0c5f6e52e
csv-ip5xs0.950 - 0.988
csv-ip5xs-207.225 - 7.744
csv-parser22.602 - 22.667
csv-test-xs-200.485 - 0.504
test7.841 - 8.863
test-t2.133 - 2.213
test-t --race0.906 - 0.939
test-t-2037.417 - 39.629
test-t-20 --race11.905 - 12.101
 14:37
2018-08-09 13:22:47 test-t 2.184
2018-08-07 19:22:21 test-t 2.178
2018-08-03 17:01:13 test-t 2.175
2018-08-07 16:28:38 test-t 2.159
2018-08-09 16:34:28 test-t 2.133
Zoffix
.oO( we need a new, more comprehensive bench )
 14:39
dogbert17 we need to get below 2 :-) 14:47
lizmat dogbert17: on my machine, test-t is now below 1.9 :-) 14:50
|Tux| my test box: Linux 4.4.140-62-default [openSUSE Leap 42.3] HP Z220CMT Xeon(R) CPU E3-1245 V2 @ 3.40GHz/3271(8 cores) x86_64 11888 Mb 14:51
lizmat 2.9GHz I7 with turbo boost up to 3.6GHz I believe 14:55
afk for a few hours& 14:56
dogbert17 lizmat: cool 14:59
dogbert17 ZOFFLOP: /spec/S09-typed-arrays/native-int.t 15:05
valgrind doesn't like that file 15:06
==8553== Conditional jump or move depends on uninitialised value(s)
==8553== at 0x502B97A: MVM_validate_static_frame (validation.c:696) 15:07
jnthn Studying some of the code we produce shows up quite a few little things for improvement... 15:16
|Tux| 2.129 15:18
Zoffix nm on toaster... Google keeps killing my VM after several minutes and I don't see an option to turn off pre-emptability without re-creating the VM from scratch, which I'm too lazy to do 15:20
jnthn CORE.setting compilation does also seem reliably a little faster for me, fwiw 15:21
48.273 is the lowest I remember seeing 15:22
hmpf, one of my code-gen improvements regressed my hash store benchmark... 15:24
jnthn huh, or pulling latest did 15:26
oh yes, ASSIGN-KEY now fails to inline 15:27
Heh, 48.014 certainly is 15:34
(Not because of another improvement, just a lucky run) 15:35
wat, I just got 47.734 on my latest one o.O
diakopter jnthn: mebbe that was VERY fortuitous cosmic rays optimizing your program for you 15:39
timotimo it just keeps getting faster and faster 15:44
Geth nqp: 2bb945df83 | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Improve getattr/bindattr code gen quality

Recognize when we have a literal wrapped up in a QAST::Want, and emit a more efficient getattr_* instead of a const_s and getattrs_*.		 15:49
jnthn Not quite sure who and what is to thank for it, but CORE.setting here is now under the 14 MB mark 15:52
timotimo \o/ 15:56
i expect all of this to also decrease memory usage during core setting compilation by a tiny amount 15:57
statisfiable6: core 15:58
statisfiable6 timotimo, OK! Working on it…
timotimo, gist.github.com/605db5c0b63cf1a56f...93e7dc56d3 16:00
timotimo 3ae97e5f38e85a5db76053ed2c7757c59a22f73d 14.00476 16:02
a41c37c89f45327c91c024b72ed1d59693cfa832 13.956392
Geth nqp: b23941d2ee | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Often do a decont less in getattr/bindattr codegen

In the case that we have a QAST::WVal for the class handle, then we know that we don't need to generate one.		 16:10
jnthn m: my @a; dd (@a = 42) 16:11
camelia Array @a = [42]
jnthn m: my @a; dd (@a[1] = 42)
camelia 42
jnthn m: my @a; (@a[1] = 42) = 101
camelia Cannot modify an immutable Int (42)
in block <unit> at <tmp> line 1
Geth rakudo: fd6164a106 | (Jonathan Worthington)++ | src/vm/moar/Perl6/Ops.nqp
Improve p6bindattrinvres code-gen quality

  * Generate simpler bindattr_o where possible instead of bindattrs_o
   and a const_s
  * Don't decont the class handle if it's a QAST::WVal type object		 16:13
rakudo: 9a5c538fa2 | (Jonathan Worthington)++ | src/Perl6/World.nqp
Ensure Scalar type objects compiles to QAST::WVal

It previously would compile into a `getlex`. Amusingly enough, spesh did try and make the best of a bad situation by sticking in a guard so things like `nqp::create(Scalar)` and attribute lookups using `Scalar` would be lowered anyway, which is cute, but still wasteful.
rakudo: c60a347f61 | (Jonathan Worthington)++ | src/core/Hash.pm6
Further code shrinkage of Hash.ASSIGN-KEY

To really make sure it's getting reliably inlined.
travis-ci NQP build failed. Jonathan Worthington 'Often do a decont less in getattr/bindattr codegen 16:14
travis-ci.org/perl6/nqp/builds/414136113 github.com/perl6/nqp/compare/2bb94...3941d2ee96
Zoffix New blog post: "The 100 Day Plan: The Update on Perl 6.d Preparations": rakudo.party/post/The-100-Day-Plan...6-d-Update 16:48
Ulti yay Im going to share a birthday with Perl 6.d 16:54
or at least Diwali this year 16:55
Ulti which is convenient since in the UK we will be setting the place on fire around that time anyway 16:55
diakopter <sideways laughter crying emoji> 16:57
Zoffix Toast results for HEAD: aborted because zef failed to run "flattening of other hash reprs NYI." 17:04
actually, no it's the step after zef 17:05
Zoffix tries to golf
Actually, g2g ATM... Here's the tail of toaster session with the error: gist.github.com/zoffixznet/c0f9d9e...5d09f9c80b and toaster code is here: github.com/zoffixznet/perl6-Toaster 17:07
Ulti m: say "\c[ROLLING ON THE FLOOR LAUGHING]" 17:08
camelia 🤣
Ulti naw
diakopter I think thats what you wanted :P
Zoffix Actually yeah, it is zef. I can repro by just cloning zef and running `perl6 -Ilib bin/zef info Test` 17:28
on 2018.06-377-ga41c37c built on MoarVM version 2018.06-395-g0c5f6e5
and the "flattening of other hash reprs NYI." crash is on " $!recommendation-manager.search(@identities, :$strict, |%fields);", but I'm failing to repro it outside the code 17:30
Zoffix .tell jnthn FYI: R#2195 github.com/rakudo/rakudo/issues/2195 17:48
yoleaux Zoffix: I'll pass your message to jnthn.
synopsebot R#2195 [open]: github.com/rakudo/rakudo/issues/2195 [⚠ blocker ⚠] False positive throwage of "flattening of other hash reprs NYI"
Geth rakudo: 5559f4c99f | (Jonathan Worthington)++ | src/core/Array.pm6
Tune up Array.ASSIGN-POS

This gets the code size to be quite significantly smaller. It's not quite at the point where it will inline yet, but a great deal closer. There's still some suboptimality in the code produced after specialization, so this will need more attention. Even with these outstanding tasks, this is still a quite measurable speedup.		 18:14
lizmat jnthn: from c60a347f615400b41b6d I gather that nowadays we don't want to do 2 getattrs, but preferably do a single one, bind to that and use the alias? 18:45
jnthn lizmat: Yes. Sigilless vars (provided not closed over) just become a VM register and the "assignment" into them a `set` instruction 19:57
lizmat: Then the references to it are immediate (e.g. no lookup instruction)
lizmat ok, I think I know a few other places then that could use that change :-)
jnthn lizmat: Further to that, each getattr means a guard, and it's better to have less of those :) 19:58
lizmat gotcha
it used to be that having extra locals would be overhead
I guess that's no longer the case then :)
jnthn Well, it also used to be they were *not* locals, they were lexicals :) 20:00
lizmat ah, that... ok 20:01
argh, I just found out that sprintf/fmt use a grammar under the hood
which makes them really slow :-(
jnthn Well, it's fast if you keep a hash mapping format string into code that does the job, but yeah, if you parse it every time... :) 20:02
lizmat how would you keep that ? 20:03
diakopter sprintf/fmt used to be non-grammar based :o
lizmat jnthn: how can you *not* parse that every time ?
jnthn lizmat: Parse it once, turn it into a closure tree (or compile it into QAST) that - given the arguments - applies the format 20:10
lizmat I'm afraid I don't follow :-( 20:11
jnthn lizmat: Compile formats into code that, keep a hash of format string to code, run the cdoe each time 20:18
lizmat ok, so you're suggesting I implement that in the core? Is that what you're saying ? 20:19
jnthn Well, it's probably an amount of work, but yes, it's probably the right direction to go 20:21
If we're parsing the string with a grammar every time, that ain't going to be so fast... 20:22
lizmat ok 20:29
gotcha
pmurias Dynamicaly created sprintf formats are super rare, right? 20:49
timotimo i would expect that 20:52
jnthn I figure so. We can always put a size limit on the cache. 21:04
AlexDaniel Zoffix++ # v6.d work 21:06
Geth rakudo: 45df171ae5 | (Elizabeth Mattijsen)++ | 2 files
Move the Any ~ Any candidate to Str.pm6

And reduce a level of indirection in that case.		 21:36
rakudo: 327cae7c93 | (Elizabeth Mattijsen)++ | src/core/Hash.pm6
Reduce the number of nqp::getattr calls

According to jnthn:
   colabti.org/irclogger/irclogger_log...08-09#l623
Reduces the .moarvm file by 760 bytes. All little things help :-)
lizmat_ jnthn: is nqp::getattr(self,List,'$!todo') also auto-magically vivifying ? 21:41
jnthn lizmat_: To something, maybe to Mu; I forget :) 21:46
Geth rakudo/master: 7 commits pushed by (Elizabeth Mattijsen)++ 22:48
lizmat this shaves 1856 bytes from .moarvm file 22:50
jnthn :) 23:06
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Reduction spree in set_subset' 23:09
travis-ci.org/rakudo/rakudo/builds/414293399 github.com/rakudo/rakudo/compare/3...a1536d57a6
MasterDuke woohoo, and my parse time is the lowest it's been in a while. 72s 23:09
jnthn :) 23:10
timotimo sweet 23:20
same here fwiw

Powered by Cro and the Raku® Programming Language.

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

Thank you!