[Coke] c: eb6d4be9ff e 00:10
committable6 [Coke], ¦eb6d4be: «»
[Coke] ⏳ 227 out of 2536 modules processed (8.95%) 00:46
Geth rakudo: ugexe++ created pull request #6727:
RakuAST: optimize a WhateverCode formed for a type argument		 02:02
ugexe that fixes the last egregious performance difference, although i'll look at cutting down the others as well 02:03
from github.com/rakudo/rakudo/issues/6712 that is 02:04
02:29 nine left, camelia left 02:31 camelia joined 02:35 nine joined
Geth rakudo/main: 0b403f9cd9 | (Nick Logan)++ | 5 files
RakuAST: optimize a WhateverCode formed for a type argument

Previously a WhateverCode passed to a role a class does, as in
  `class C does R[* cmp * == More]`, written in a subset's where
clause, or handed to a trait, had its block formed at BEGIN time so the parameterization could take the code object, and that block was cached before the unit's optimize walk and lowering analysis had run. ... (27 more lines)		 02:46
rakudo/main: a72da8833b | (Nick Logan)++ | src/Raku/ast/code.rakumod
RakuAST: honor --optimize=off for code compiled ahead of the unit

Previously a routine invoked at BEGIN time, a role body, and a WhateverCode formed for a type argument took the optimize walk and the lowering analysis before their blocks were cached, whatever the optimize option said, since only the unit's own optimize phase read it. Under --optimize=off such code still ran with static callee ... (7 more lines)
rakudo/main: bc23c1a18d | (Nick Logan)++ (committed using GitHub Web editor) | 5 files
Merge pull request #6727 from ugexe/ugexe/rakuast-primed-arg-optimize

RakuAST: optimize a WhateverCode formed for a type argument
releasable6 Next release in ≈1 day and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
ugexe the rest of the optimization PRs that will follow can wait until after the release 03:11
Geth rakudo: ugexe++ created pull request #6728:
RakuAST: lower a block given as a type argument and inline a native compound assignment's operator		 03:13
rakudo: ugexe++ created pull request #6729:
RakuAST: call AT-POS itself for an array subscripted by a native int		 04:10
09:27 finanalyst joined
Geth rakudo/main: 4 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++ 09:55
10:11 finanalyst left 10:26 [Coke] left, [Coke] joined
ShimmerFairy I've been looking into improving collation support in raku (though it's looking to be a big enough project to put off for the time being), and I was wondering if there was an easy way to search the ecosystem to see if certain language features are being used. 11:12
lizmat rakkable: eco-provides foo 11:13
rakkable lizmat, Running: eco-provides foo, please be patient!
11:13 rakkable left
lizmat meh 11:13
11:13 rakkable joined
lizmat rakkable: eco-provides foo 11:13
rakkable lizmat, Running: eco-provides foo, please be patient!
ShimmerFairy Specifically, the Collation class's "quaternary" level appears to be mislabeled. The quaternary level in the UCA is just a fourth level of weights that gets used in certain modes, and is defined for certain CLDR locales. But in raku, the term is currently used for the codepoint tie-breaker, which the UCA labels the "identical" level.
11:13 rakkable left
ShimmerFairy So for improved collation support, I think we'd have to change the name of the current "quaternary" level whenever we get to supporting the bits of the algorithm that make use of the actual 4th level, and I'm worried about how much damage that change could cause. Like I said though, I'm not doing anything any time soon. 11:15
lizmat use a local copy of rak and Ecosystem::Cache, I only see "quartenary" mentioned in the L10N modules, and Rainbow 11:16
not sure why rakkable segfaults ;-(
11:18 rakkable joined
lizmat rakkable: eco-provides quaternary 11:18
rakkable lizmat, Running: eco-provides quaternary, please be patient!
lizmat, Found 11 lines in 11 files (6 distributions):
lizmat, gist.github.com/a236f0b0189f4152c9...4b7bcfa935
lizmat ShimmerFairy: ^^
ShimmerFairy Well that's good, nobody in the ecosystem is depending on Collation.quaternary to control codepoint tiebreaking. Since there would still be a "quaternary" in the hypothetical improved future, just with a different meaning, all those L10N modules localizing the name ought to not need changing even. 11:21
lizmat that'd be cool 11:25
ugexe: looks like the addition of type-checking in ast/* broke something in the L10N AST building logic, investigating, probably *not* a blocker but victim of API changes :-) 11:51
[Coke] github.com/coke/raku-blin-release-results - through eb6d4be9ff 13:05
linkable6 (2026-09-24) github.com/rakudo/rakudo/commit/eb6d4be9ff Merge pull request #6726 from ugexe/ugexe/rakuast-eager-method-attach
[Coke] "Fail, Bisected: 2149157600df3a8114e15af8dd8de78e81e47b18": 1, "Fail, Bisected: 6357ccf97f2c4b1dd1067bf4f50b6cdcfdb78373": 3, "Fail, Bisected: a0a60ed3ce28e6e014bf287101a6d454e364aeaa": 1, "Fail, Bisected: aab0778725da5848824f07514c0ae355d972926a": 1, "Fail, Bisected: eb6d4be9ff53107461c1e22112833bc34e95a208": 3, "Fail, Bisected: f0a24041462ebd6979a8648ccb2954b3348dbcb0": 39,
some variety this time
Looks like I have several more commits since that started. Let me know when it's safe to run those. Definitely thinking we should push the release out slightly 13:06
c: bfdc9d3458 e
committable6 [Coke], ¦bfdc9d3: «»
lizmat afaik all modules with auth:zef:slavenskoj are AI slop 13:10
French, Portuguese 13:11
Slang::Comments is victim of adding RakuAST bootstrap typechecking 13:13
will make a PR for that
github.com/bduggan/raku-slang-comments/pull/2 13:22
Sustenance was given up on by the developer, afaik
Inline::Perl5 just needs to merge a PR and/or release a new version 13:23
lizmat nudges nine
[Coke] If there are modules I should skip going forward, please throw them in a gist or something, and I'll patch the skips.json in blin to stop testing them,.
lizmat gist.github.com/lizmat/6a2e076bff3...e7be88c6c2 13:26
Geth Blin/main: 7e55f9bb88 | (Will Coleda)++ | resources/skips.json
Note skips from RakuAST testing
 13:28
[Coke] ^^ there.
lizmat looks like Algorithm::Evolutionary::Simple exposes a difference in WhateverCode handling 13:36
m: dd (True, True, False, False, True, False).rotor(2).grep(so (*.all == True | False)).elems
camelia 2
lizmat thats still legacy ^^
m: Q|dd (True, True, False, False, True, False).rotor(2).grep(so (*.all == True | False)).elems|.AST.EVAL
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> False).rotor(2).grep(so (*.all == True |<HERE> False)).elems|.AST.EVAL
expecting any of:
infix
infix stopper
statement end
…
ab5tract if Inline::Perl5 is going to break with the defaults on the new release, we need that merge/release pressed ASAP 13:37
lizmat m: Q/dd (True, True, False, False, True, False).rotor(2).grep(so (*.all == True | False)).elems/.AST.EVAL
camelia 3
[Coke] .seen nine 13:38
tellable6 [Coke], I saw nine 2026-07-18T19:35:26Z in #raku-dev: <nine> m: say "alive?"
ab5tract lizmat: how'd you find that one? :)
lizmat test in Algorithm::Evolutionary::Simple
ab5tract ah, gotcha 13:39
lizmat github.com/rakudo/rakudo/issues/6730 13:45
ugexe there is already a fix PR to the repo 13:46
please check the repos first
lizmat good point 13:47
[Coke] what are the odds of another moarvm fix before relase? non-zero? 13:49
ugexe [Coke]: scanning the output of that last blin run it look slike the only new thing is FastCGI::NativeCall and that isnt showing what the failure was (so maybe a flake) 13:51
lizmat [Coke]: judging from the PRs that are there now, I'd so 0%
*say
ugexe pretty much everything else in that list either we wont fix or has a PR... although that does make it kind of difficult to make a decent skip list since we only want to skip the ones with a PR until their PR is merged 13:52
lizmat I think it's fine to skip the ones with a PR, it's the author's responsibility to act: if they don't, there's no point in testing anyway 13:53
ah... I see what you mean 13:54
ok, keep testing the ones with PRs... if they merged the PR, they will come out clean
but I guess we would need to check whether the error is still the same, do we? 13:55
ugexe i already fixed slang::comments 13:57
github.com/bduggan/raku-slang-comm...5833569206
lizmat stops looking at blin results until after the release 13:59
14:07 [Coke] left
ugexe incoming PRs are for the next release 14:19
Geth rakudo: ugexe++ created pull request #6731:
RakuAST: type a native assignment as an argument by its variable		 14:20
rakudo: ugexe++ created pull request #6732:
Keep the Array BIND-POS fast path small enough to inline
rakudo: ugexe++ created pull request #6733:
RakuAST: lower placeholder parameters to frame locals		 14:24
rakudo: ugexe++ created pull request #6734:
RakuAST: call AT-POS itself for a native int operator result index		 14:26
rakudo/main: 8dccf3acb1 | (Nick Logan)++ (committed using GitHub Web editor) | 4 files
RakuAST: call AT-POS itself for an array subscripted by a native int

Previously `@a[$i]` with a native int `$i`, or an int literal, called the setting's `postcircumfix:<[ ]>`, whose candidate for an Int index does nothing but forward its two arguments to `SELF.AT-POS`, and the assignment form forwards to `SELF.ASSIGN-POS` the same way. That call cost a proto dispatch and a frame per subscript. In the BinaryHeap ... (20 more lines)		 14:34
ugexe i see JSON::Class is causing some failures, so we'll have at least one more commit to fix that 15:06
ab5tract re: that junction stuff from before, this is not the first time I've thought it would be helpful to have an opt-in `guides` pragma 15:36
it would allow for a different lever for addressing LTA beyond the worry mechanism, which has its own drawbacks 15:37
if we were to have such, it would be useful to users to know that the syntax is valid but the effect (probably) unexpected 15:38
ugexe its junctions where 50% of what you can do probably isnt expected 15:41
16:04 [Coke] joined
Geth rakudo: ugexe++ created pull request #6735:
Accept metamodel types as declared types and as roles to compose		 16:23
[Coke] NEW=8dccf3acb1 #doing another run up to here. 16:42
ugexe i'll have a few other fixes related to JSON::Class later 16:56
which i guess isn't too surprising given its vrurg's version and thus flexes the metamodel quite a bit 17:03
probably a good reason to push the release back till sunday though 17:06
ab5tract re: junctions. all the more reason for a sanity-irizer ;) 17:17
use sanity; # remind me of dragons when I invite them to doorsteps 17:18
ugexe just emit a warning anytime junctions are used period, which has the advantage of not needing to do additional work to figure out the if and what :) 17:19
ab5tract maybe not the best from a marketing standpoint? or maybe just the right amount of self-deprecation?
ugexe: 😆 17:20
ugexe i already took the sanity namespace :P github.com/ugexe/Raku-sanity
ab5tract ah! seeing the examples reminds me that I have indeed seen this before. 17:22
I'm glad somebody's got some and is willing to share. seems to be in short supply often these days 17:23
I wonder how much of junctions usage can be safely optimized away as `[&&] |$j` 17:24
etc
lizmat the old optimizer did this up to 3 elements I think
timo might know that
ugexe the optimizer changed the result of those, hence github.com/JJ/p6-algorithm-evoluti...le/pull/14 17:27
ab5tract well I guess my argument is that we should consider re-formulating junctions as thin wrappers around reduce operations 17:29
s/argument/suggestion/
evalable6 Use of uninitialized value $_ of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in block <unit> at /tmp/cYb8rc2c4u line 1
ugexe oh that is affectign rakuast as well i guess 17:30
(the optimization divergence) 17:31
ab5tract essentially they could become the first customer of macros
and then we just abandon whatever junction semantics that can't be implemented as a macro 17:33
ugexe my $b = (True,False,True,False); say so $b.all == True|False #gives a different result with optimize off vs on for both legacy and rakuast 17:34
evalable6 False
ab5tract is the RakuAST optimizer off by default?
lizmat no, afaik 17:35
ugexe no
ab5tract then is the expression above returning the right or the wrong answer? from the ticket I understand it as the right answer 17:36
ticket=PR
ugexe b.all == True|False 17:39
→ all(b1 == any(True,False), b2 == any(True,False), ...)
→ all(any(T,F), any(F,T), any(T,F), any(F,T))
→ True
the unoptimized version is correct
github.com/Raku/old-design-docs/bl...#junctions see the bit starting with "If two or more arguments are junctive, then the argument that is chosen to be "autothreaded" is:" 17:52
Geth rakudo: ugexe++ created pull request #6736:
RakuAST: accept an invoked term as a feed stage		 17:57
18:20 Pixi left 18:25 Pixi joined
ugexe shakes fist at junctions 18:41
[Coke] I may do the moarvm release tomorrow and the npq/rakudo release Sunday. 19:12
(can always do a moarvm point release if needed)
blin run through 8dccf3acb1 at about 60% now. 19:13
linkable6 (2026-09-25) github.com/rakudo/rakudo/commit/8dccf3acb1 RakuAST: call AT-POS itself for an array subscripted by a native int
20:27 finanalyst joined 22:14 finanalyst 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!