Geth rakudo: ugexe++ created pull request #6700:
RakuAST: compile a recursive sub call with a static callee lookup
00:17
rakudo/main: be8107f365 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
RakuAST: compile a recursive sub call with a static callee lookup (#6700)

Previously a call to a sub from inside its own body kept the plain callee lookup, while every other call to the same sub compiled to a static one. A routine's own scope finds the routine under its own name, so the bound once check saw the name declared in a scope nested inside the outermost one and declined. The routine is never declared in its ... (10 more lines)
00:57
rakudo: ugexe++ created pull request #6701:
RakuAST: lower sigilless term declarations to locals
01:44
[Coke] nearly done with changelog. 02:15
releasable6: info
releasable6 [Coke], Next release in ≈6 days and ≈16 hours. There are no known blockers. 442 out of 468 commits logged
[Coke], Details: gist.github.com/431fc57602feb82c55...a3ff5b507d
[Coke] anyone wants to get those last few, have fun. :) 02:16
ugexe we'll want to do a rakuast blin run tomorrow 02:21
none of the stuff from the last run will have been fixed yet, but the PR from earlier this morning was pretty big, and we might as well wait for me to get these last couple of optimizations out tonight before running it again 02:23
we also probably want to get github.com/MoarVM/MoarVM/pull/2044 in 02:27
Geth rakudo/main: a2465acccf | (Nick Logan)++ | 5 files
RakuAST: lower sigilless term declarations to locals

Previously the lexical to local lowering only considered sigiled declarations, term parameters and self, so `my \x := ...` always stayed a by-name lexical. The setting declares most of its temporaries this way, which left routines like DIVIDE_NUMBERS doing a lexical bind and several lexical reads per call where the legacy optimizer used ... (8 more lines)
02:33
rakudo/main: febf0e76c4 | (Nick Logan)++ | 2 files
Keep the Rat overflow lookup out of CREATE_RATIONAL_FROM_INTS

Previously the candidate that builds a Rat read $*RAT-OVERFLOW in its overflow arm. RakuAST compiles a dynamic variable to an inline lookup op, and MoarVM does not inline a frame that contains one, so every Rat operation paid a real call to create its result even though the overflow arm almost never runs.
This moves the lookup to a Rakudo::Internals method. The candidate is inlined into DIVIDE_NUMBERS again when CORE is compiled by RakuAST, and nothing changes for the legacy frontend, which calls DYNAMIC instead.
rakudo/main: 153cfad5aa | (Nick Logan)++ (committed using GitHub Web editor) | 7 files
Merge pull request #6701 from ugexe/ugexe/rakuast-lower-term-declarations

RakuAST: lower sigilless term declarations to locals
releasable6 Next release in ≈6 days and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
Geth rakudo: ugexe++ created pull request #6702:
RakuAST: don't allocate a container for a lowered parameter
03:15
rakudo/main: 4 commits pushed by (Nick Logan)++ 04:09
rakudo: ugexe++ created pull request #6703:
Assign to a new Array or Hash element from its own callsite
04:33
09:02 apogee_ntv left 09:08 finanalyst joined 10:18 apogee_ntv joined, shareable6 left 10:19 shareable6 joined 10:26 finanalyst left
Geth rakudo/RAKUDO_LEGACY: 54d92415f8 | (Elizabeth Mattijsen)++ | 25 files
Make RakuAST default for compilation of programs

This commit makes the new Raku grammar / actions to be the default for running Raku programs with Rakudo.
Over the past years, and especially the last months, great effort has been made to make this change as seamless as possible. So ideally ... (21 more lines)
11:22
rakudo: lizmat++ created pull request #6704:
Make RakuAST default for compilation of programs
11:23
lizmat with this change, we would need to get Inline::Perl5 also fixed to get Inline::Perl5 testing to work again in spectest 11:35
Geth nqp/main: f681164c58 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for serialization context fix

Which should make running under RakuAST faster because it wouldn't discard many runtime optimization options.
11:40
rakudo/main: ccbd569f4f | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for serialization context fix

Which should make running under RakuAST faster because it wouldn't discard many runtime optimization options.
11:57
lizmat fwiw, this looks like it makes "make spectest" about 9% faster (109 -> 100 seconds on Apple Slicion M4 Max with 32 cores) 11:59
argh, maybe not... may have mixed versions and branches :-( 12:02
ugexe: I guess now it's also time to create a MoarVM PR for the fix to make Array::xx modules install ok under RakuAST ? 12:21
Geth roast: c5d48505f7 | (Elizabeth Mattijsen)++ | test_summary
Add support for RAKUDO_LEGACY environment variable
12:28
roast/6.c-errata: 9b454315cd | (Elizabeth Mattijsen)++ | 13 files
Remove all macro tests

The experimental "macros" functionality will not be supported in any language level for now.
12:52
roast/6.d-errata: beee63c8d5 | (Elizabeth Mattijsen)++ | 13 files
Remove all macro tests

The experimental "macros" functionality will not be supported in any language level for now.
13:00
roast/6.d-errata: 0497094891 | (Elizabeth Mattijsen)++ | 16 files
Remove all tests for :P5/Perl5 regex adverb

This will not be supported in any language level for now.
13:38
lizmat so what should we do with test files that are in 6.c/d-errata that are *not* in spectest.data and thus are *not* checked during a "make spectest" 13:39
most of them are failing BTW
iow: do we assume any test file in roast to be specification of a Raku language level, or only the ones that are in "spectest.data" ? 13:40
Geth roast/6.c-errata: f50709bc88 | (Elizabeth Mattijsen)++ | 18 files
Remove all tests for :P5/Perl5 regex adverb

This will not be supported in any language level for now.
13:51
13:59 rakkable left 14:00 rakkable joined
Geth roast: 41679797af | (Elizabeth Mattijsen)++ | 12 files
Remove all tests for :P5/Perl5 regex adverb

This will not be supported in any language level for now.
14:03
lizmat ok, did two more spectest runs: one with RakuAST and one not: 98 (legacy) -> 100 seconds (RakuAST) 14:04
it's coming closer to noise difference :-)
Geth roast/6.c-errata: 83003118fc | (Elizabeth Mattijsen)++ | S06-multi/by-trait.t
Cannot reproduce dispatch failure outside of test file

So mark that test as todo
14:16
roast/6.d-errata: c70bf3305e | (Elizabeth Mattijsen)++ | S06-multi/by-trait.t
Cannot reproduce dispatch failure outside of test file

So mark that test as todo
14:17
lizmat m: multi x(int $a) { dd }; multi x(Str $a) { dd }; x 1 # sure would be nice if we could fix this in RakuAST 14:22
camelia Cannot resolve caller x(Int:D); none of these signatures matches:
(int $a)
(Str $a)
in block <unit> at <tmp> line 1
Geth roast/6.c-errata: 5544476d9d | (Elizabeth Mattijsen)++ | S06-multi/type-based.t
Todo a dispatch test

Feels that this should actually work in the future, but it doesn't now, not in legacy and not in RakuAST
14:24
14:37 Geth__ joined
Geth__ roast/6.c-errata: 58d66aa2fc | (Elizabeth Mattijsen)++ | S05-substitution/subst.t
Correct samemark test

The outcome of the test assumed :mm (aka :samemark) but only specified
  :m (single m). Apparently this was also acceptable in earlier versions
of Rakudo. RakuAST requires that it is actually ":mm".
14:38
lizmat [Coke]: this makes the 6.c-errata branch in roast clean on RakuAST 14:39
afaik
[Coke] lizmat++
14:40 Geth left
[Coke] blin fialure through be8107f365: Stomp CSS::Properties Polyglot::Regexen Terminal::UI GIO GLib JSON::GLib::Node 14:41
lizmat now only gist.github.com/lizmat/eff68b7fef7...2e01f80e49 left to look at
[Coke] c: ccbd569f4f e.say 14:45
committable6 [Coke], ¦ccbd569: «2.718281828459045␤»
[Coke] starting run through that
lizmat m: i.say 14:48
camelia 0+1i
lizmat :-)
[Coke] we can probably close all the fixed in ast bugs aftger this weekend. 15:08
do we need a final run on "bug in ast" tix?
only 9 of those: github.com/rakudo/rakudo/issues?q=...AKUAST%3D1 15:09
since we're close to release, blin stuff now in github.com/rakudo/rakudo/issues/6705 15:12
(full files will be in the coke/ repo, need smaller failures.md to fit in issue) 15:13
ugexe You’ll have to figure out how to do legacy built core with rakuast runtime for blin since that’s never been done 15:32
gist.github.com/ugexe/54f777a2fa41...dd73d7c744 here are the benchmarks 15:52
also, again, i have like 6+ roast PRs to erratta branchs open that fix at least one of the remaining erratta issues 16:00
i cant merge those
sigh, there are conflicts now on that one 16:01
lizmat: your samemark fix needs to be reverted and we need to use the one from my PR which is synced from the primary roast 16:02
there are probably a bunch of fixes on the primary branch that haven't been backporte 16:05
and hopefully any fixes to eratta branches are applying those exact fixes if they do exist 16:06
Geth__ roast/6.c-errata: f6d6dd2ce6 | (Elizabeth Mattijsen)++ | S05-substitution/subst.t
Revert "Correct samemark test"

This reverts commit 58d66aa2fc8ab85378633fc00ddc3ee4493e8ee8.
A better fix is coming along!
16:08
roast/6.c-errata: d3e34ef58d | (Nick Logan)++ (committed using GitHub Web editor) | 4 files
Sync recent roast adjustments to 6.c-errata (#903)

  * Reach the run time type check with a value the compiler cannot judge
Rakudo is learning to report a store of a value a variable's type can never accept while it compiles, instead of leaving it to the run time check. A test written as `dies-ok { my Int $x = "str" }` names a literal ... (25 more lines)
16:11
roast/6.d-errata: fc792f565a | (Nick Logan)++ (committed using GitHub Web editor) | 6 files
Sync recent roast adjustments to 6.d-errata (#904)

  * Reach the run time type check with a value the compiler cannot judge
Rakudo is learning to report a store of a value a variable's type can never accept while it compiles, instead of leaving it to the run time check. A test written as `dies-ok { my Int $x = "str" }` names a literal ... (46 more lines)
roast/6.c-errata: 020a3c063c | (Nick Logan)++ (committed using GitHub Web editor) | S05-substitution/subst.t
Keep the ss:i:m test free of samemark (#910)

The test substitutes marked, mixed case input with ss:i:m and checks that the whitespace of the matched text survives in the replacement. The :i and :m adverbs are only there so the pattern matches that input at all, and the marks in the input only gave :m something to ignore.
... (15 more lines)
roast/6.d-errata: c3f14ac87e | (Nick Logan)++ (committed using GitHub Web editor) | S05-substitution/subst.t
Keep the ss:i:m test free of samemark (#911)

The test substitutes marked, mixed case input with ss:i:m and checks that the whitespace of the matched text survives in the replacement. The :i and :m adverbs are only there so the pattern matches that input at all, and the marks in the input only gave :m something to ignore.
... (15 more lines)
16:12
roast: daeff58a3e | (Nick Logan)++ (committed using GitHub Web editor) | S05-metasyntax/longest-alternative.t
Test that character class methods take part in longest token matching (#912)

Previously a branch calling <alnum>, <digit> or another character class method contributed nothing to longest token matching, so a shorter branch listed earlier won and a ratcheting group failed.
linkable6 ROAST#912 [closed]: github.com/Raku/roast/pull/912 Test that character class methods take part in longest token matching
Geth__ roast/6.c-errata: e749867e57 | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Put a leading declarator doc before the routine it documents (#914) (#915)

A leading doc attaches to the declarator immediately after it, which for
  `#| doc` above `my $anon-sub = anon Str sub {}` is the variable, not
the sub in its initializer. These tests document the sub and the block, so the doc now precedes them inside the initializer.
16:13
roast/6.d-errata: 1f8aa0f3e7 | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Put a leading declarator doc before the routine it documents (#914) (#916)

A leading doc attaches to the declarator immediately after it, which for
  `#| doc` above `my $anon-sub = anon Str sub {}` is the variable, not
the sub in its initializer. These tests document the sub and the block, so the doc now precedes them inside the initializer.
16:13 Geth__ left 16:14 Geth joined
lizmat 6.c-errata still clean 16:19
. 16:20
16:21 Geth left, Geth joined
lizmat 6.d clean for me, except: 16:23
S16-io/eof.t
S32-io/out-buffering.t
S32-str/utf8-c8.t 16:24
will check master now for backportable fixes
Geth roast/6.d-errata: 62a5c51e04 | (Elizabeth Mattijsen)++ | S16-io/eof.t
Backport eof test fix from master
16:30
roast/6.d-errata: b4df81152f | (Elizabeth Mattijsen)++ | S32-io/out-buffering.t
Backport buffering test from master
16:34
roast/6.d-errata: 5b48004b40 | (Elizabeth Mattijsen)++ | S32-str/utf8-c8.t
Backport utf8-c8 fix from master
16:38
lizmat which now makes 6.d-errata also clean for me 16:39
can someone with access to a Windows machine and the ability to build Rakudo, check why github.com/rakudo/rakudo/pull/6704 is failing on Windows 16:41
the Azure error reporting is complete gobbledegook for me 16:42
ugexe m-flag-module-spec.t test 13, empty -M. argvQuote in src/runner/runner.c writes an empty arg as nothing rather than "", so on windows the empty string is dropped and -M takes the script path instead. 17:13
not sure if that explanation is correct though 17:14
oh i guess it is correct, its just a newish test that is rakuast only 17:18
(hence why we didnt see that windows runner issue before despite it having nothing to do with rakuast) 17:19
a good reminder though that we havnt really done any windows testing with rakuast 17:21
Geth rakudo/RAKUDO_LEGACY: cf9c424617 | (Elizabeth Mattijsen)++ | t/02-rakudo/m-flag-module-spec.t
Todo a test on Windows that fails, at least for now
17:30
ugexe i forget, what is the purpose of keeping the core legacy if we're making runtime rakuast? 18:29
i guess at the meeting i glossed over that, thinking it was the other way around 18:32
presumably all these test changes are going to break the CI as well 18:36
silently break them 18:37
my skepticism on this is growing 18:38
[Coke] I thought switching it in src/main.nqp was a global thing, didn't realize it wasn't impacting core. 19:05
ugexe Yeah, non ast core with rakuas
[Coke] I also didn't realize until the notes that we were talking about core compilation separately
lizmat the purpose of keeping the legacy core around now, is to allow for an escape hatch 19:57
and that's because we found some problems running 6.c/d on the core built with RakuAST in blin I believe? 19:58
so that would allow us to fix this for the 2026.10 release?
SmokeMachine I think I found a bug on RakuAST: github.com/FCO/Red/pull/601 20:06
Sorry, wrong paste
usercontent.irccloud-cdn.com/file/.../image.png
lizmat please make an issue 20:07
SmokeMachine but for class that works... 20:08
ugexe the reasons problems would ahve been found with a core built with rakuast is because its been actually getting used
SmokeMachine m: class B {...}; class A { has B $.b }; class B { has A $.a }
camelia ( no output )
ugexe no one has been building legacy core and doing extensive testing with rakuast runtime
that is the least tested of any option we could do
lizmat I thought it was what all the RakuAST testing with blin was about ? 20:11
ugexe no
when blin has been testing rakuast it has been rakuast core with rakuast runtime
and with legacy it is legacy core with legacy runtime 20:12
lizmat ok, for clarity: with a RakuAST built core, we would still be at 6.d by default, right ? 20:13
ugexe yes
lizmat TIL, I really thought that all blin testing was done with legacy core and RAKUDO_RAKUAST=1 set for testing 20:14
SmokeMachine it's not only for Red: usercontent.irccloud-cdn.com/file/.../image.png 20:15
ugexe use a newer rakudo then 20:16
lizmat SmokeMachine: I just the same thing with OO::Monitors, and it worked ok
*did
Geth rakudo/main: a107b0ce34 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 26 files
Make RakuAST default for compilation of programs (#6704)

This commit makes the new Raku grammar / actions to be the default for running Raku programs with Rakudo.
Over the past years, and especially the last months, great effort has been made to make this change as seamless as possible. So ideally ... (21 more lines)
ugexe ... 20:17
did you update the CI?
lizmat ugexe: that changes my preference and my proppsal (I'm really sorry that didn't become clear to me yesterday :-( )
SmokeMachine usercontent.irccloud-cdn.com/file/.../image.png
lizmat the CI was clean
ugexe that doesnt mean its fine
i mentioned this above. we really need to think about these type of changes first
how is the CI that builds core with rakuast supposed to work now?
sort of another reason why not mixing the frontends is a good idea as well 20:18
lizmat ok, I'm thoroughly confused now: how would a change in src/main.nqp affect building the core ? 20:19
[Coke] Been stuck on [2026-09-20T16:18:58-04:00] ⏳ 2530 out of 2532 modules processed (99.92%) (left: GIO JSON::GLib::Node)
for like an hour
SmokeMachine lizmat: for me OO::Monitors had the same problem... maybe my environment? 20:20
ugexe how does removing the RAKUDO_RAKUAST=1 environment variable not affect building the core?
this is what i mean we need to think harder about this
lizmat SmokeMachine: are you running 2026.08 ?
SmokeMachine yes
lizmat SmokeMachine: try running HEAD, please
ugexe: so you're saying that someone specifying RAKUDO_RAKUAST=1 should get the RakuAST grammar for parsing as well? 20:21
[Coke] (just had to complain now down to just JSON::GLib::Node)
SmokeMachine I have a HEAD from yesterday... is it enough or should I build a new HEAD?
ugexe im saying at a minimum the CI expects that, and removing it just means all the CI tests are potentially backwards and not at all what they say they are testing 20:22
lizmat SmokeMachine: that should be enough
because the CI is not using HEAD ?
ugexe previously we would know if the core stopped compiling under rakuast. now we do not
the CI is literally every commit of rakudo
lizmat I still don't understand how the change in src/main.nqp would affect core building ? 20:23
SmokeMachine I just remembered why I went back to stable... any code I run on main is being killed... that must be my env... usercontent.irccloud-cdn.com/file/.../image.png
ugexe are you suggesting that one can build a rakuast core with RAKUDO_RAKUAST=1?
still 20:24
lizmat yes, I think you can ?
lizmat tests
ugexe if we really wanted to do legacy core with rakuast runtime i would have suggested RAKUDO_RAKUAST=0 instead of a new environment variable 20:25
because all the existing uses would still work right
lizmat hmmm... I just *did* notice something: core compilation time is way up 20:28
my reasoning for creating a new env var, is that it would be intended for people who previously never had to deal with RAKUDO_RAKUAST=1 20:31
ugexe i dont think thats a good reason given what i've pointed out
those same people will never have had to deal with whatever new env variable
lizmat ok, it looks like core building for me was 25 seconds before the MoarVM bump, it's now at 37 for me 20:32
ugexe for a legacy built core i guess that isnt too surprising given GLOBAL was always in slot 0
lizmat but the bump was supposed to make it faster, no? now it made it about 50% slower ? 20:33
double checking now
ugexe it does make code faster
significantly
but you're talking about compiling the legacy core presumably
the optimization can never have any benefit to legacy 20:34
lizmat but it shouldn't slow it down by 50% now either, does ?
ugexe for legacy? i dont know, again no one has really been testing legacy core with rakuast stuff 20:35
lizmat ok, confirmed it was not the MoarVM bump 20:36
Geth rakudo/main: a456c3a35f | (Elizabeth Mattijsen)++ | 26 files
Revert "Make RakuAST default for compilation of programs (#6704)"

This reverts commit a107b0ce342aaea278202f6b7110d3a25e9ed4d6.
Need to understand why this change makes core setting building go from 25 to 38 seconds.
20:38
lizmat ok, looks like a107b0ce34 also made the core setting build with RakuAST 20:42
linkable6 (2026-09-20) github.com/rakudo/rakudo/commit/a107b0ce34 Make RakuAST default for compilation of programs (#6704)
lizmat (judging from the core setting parse time) 20:43
[Coke] # of blin failures reduced in latest run 20:46
ccbd569f4f down to Polyglot::Regexen GIO GLib JSON::GLib::Node
linkable6 (2026-09-20) github.com/rakudo/rakudo/commit/ccbd569f4f Bump NQP for serialization context fix
[Coke] Let me know when y'all are ready for another Blin run. 20:49
lizmat aha, TIL that core setting compilation *also* calls src/main.nqp
so that the core was also built with RakuAST
[Coke] (the 2 commits after ccbd569f4f combine to 0) 20:50
linkable6 (2026-09-20) github.com/rakudo/rakudo/commit/ccbd569f4f Bump NQP for serialization context fix
lizmat yeah...
ugexe: so it looks like my change actually did what you wanted it to: make both core setting and running programs run on RakuAST 20:51
ugexe: so, if I prepare a new PR to activate RakuAST both for the core and programs, and use RAKUDO_RAKUAST=0 to indicate legacy 20:56
what would be the changes needed in CI to make it all make sense ?
21:11 finanalyst joined 22:10 finanalyst left
releasable6 Next release in ≈5 days and ≈19 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
ugexe anywhere RAKUDO_RAKUAST=1 is set in github.com/rakudo/rakudo/blob/main...elines.yml it needs to be changed to 0. then anywhere else that rakuast / Rakuast is referenced in that file should be changed to some name referencing legacy (those remaining instances are basically just labels to know which jobs they are) 23:15
[Coke]: just in case you missed it from a few days ago: GIO, GLib, and JSON::GLib::Node all have the same root cause originating from GLib::Raw::Exceptions using `:` as an invocation marker in a way that is just wrong but legacy seemingly ignored 23:23
if someone cloned whatever distribution GLib::Raw::Exceptions is in and removed that : and made a release it would presumably fix everything though 23:24
gist.github.com/ugexe/54f777a2fa41...dd73d7c744 just want to repost the benchmarks as well, which show rakuast should be, generally speaking, faster than legacy. 23:31
compile times are inherently longer though... legacy can just emit qast inline with the parse but rakuast has to make nodes during the parse, then traverse that tree to optimize the ast and again to turn the tree into qast 23:34
or in other words: legacy doesn't have to generate the ast that rakuast does so it compiles faster