[00:10] <[Coke]> c: eb6d4be9ff e

[00:10] <committable6> [Coke], ¦eb6d4be: «»

[00:46] <[Coke]> ⏳ 227 out of 2536 modules processed (8.95%)

[02:02] <Geth> ¦ rakudo: ugexe++ created pull request #6727: RakuAST: optimize a WhateverCode formed for a type argument

[02:02] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6727

[02:03] <ugexe> that fixes the last egregious performance difference, although i'll look at cutting down the others as well

[02:04] <ugexe> from https://github.com/rakudo/rakudo/issues/6712 that is

[02:29] *** nine left
[02:29] *** camelia left
[02:31] *** camelia joined
[02:35] *** nine joined
[02:46] <Geth> ¦ rakudo/main: 0b403f9cd9 | (Nick Logan)++ | 5 files

[02:46] <Geth> ¦ rakudo/main: RakuAST: optimize a WhateverCode formed for a type argument

[02:46] <Geth> ¦ rakudo/main: 

[02:46] <Geth> ¦ rakudo/main: Previously a WhateverCode passed to a role a class does, as in

[02:46] <Geth> ¦ rakudo/main: `class C does R[* cmp * == More]`, written in a subset's where

[02:46] <Geth> ¦ rakudo/main: clause, or handed to a trait, had its block formed at BEGIN time so

[02:46] <Geth> ¦ rakudo/main: the parameterization could take the code object, and that block was

[02:46] <Geth> ¦ rakudo/main: cached before the unit's optimize walk and lowering analysis had run.

[02:46] <Geth> ¦ rakudo/main: <…commit message has 27 more lines…>

[02:46] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/0b403f9cd9

[02:46] <Geth> ¦ rakudo/main: a72da8833b | (Nick Logan)++ | src/Raku/ast/code.rakumod

[02:46] <Geth> ¦ rakudo/main: RakuAST: honor --optimize=off for code compiled ahead of the unit

[02:46] <Geth> ¦ rakudo/main: 

[02:46] <Geth> ¦ rakudo/main: Previously a routine invoked at BEGIN time, a role body, and a

[02:46] <Geth> ¦ rakudo/main: WhateverCode formed for a type argument took the optimize walk and the

[02:46] <Geth> ¦ rakudo/main: lowering analysis before their blocks were cached, whatever the

[02:46] <Geth> ¦ rakudo/main: optimize option said, since only the unit's own optimize phase read

[02:46] <Geth> ¦ rakudo/main: it. Under --optimize=off such code still ran with static callee

[02:46] <Geth> ¦ rakudo/main: <…commit message has 7 more lines…>

[02:46] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/a72da8833b

[02:46] <Geth> ¦ rakudo/main: bc23c1a18d | (Nick Logan)++ (committed using GitHub Web editor) | 5 files

[02:46] <Geth> ¦ rakudo/main: Merge pull request #6727 from ugexe/ugexe/rakuast-primed-arg-optimize

[02:46] <Geth> ¦ rakudo/main: 

[02:46] <Geth> ¦ rakudo/main: RakuAST: optimize a WhateverCode formed for a type argument

[02:46] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/bc23c1a18d

[03:00] <releasable6> Next release in ≈1 day and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: https://github.com/rakudo/rakudo/wiki/ChangeLog-Draft

[03:11] <ugexe> the rest of the optimization PRs that will follow can wait until after the release

[03:13] <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] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6728

[04:10] <Geth> ¦ rakudo: ugexe++ created pull request #6729: RakuAST: call AT-POS itself for an array subscripted by a native int

[04:10] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6729

[09:27] *** finanalyst joined
[09:55] <Geth> ¦ rakudo/main: 4 commits pushed by (Nick Logan)++, (Elizabeth Mattijsen)++

[09:55] <Geth> ¦ rakudo/main: 162630596e | RakuAST: lower the lexicals of a block given as a type argument

[09:55] <Geth> ¦ rakudo/main: 0fb5cac33c | RakuAST: inline the operator of a native compound assignment

[09:55] <Geth> ¦ rakudo/main: 0f336b2454 | Remove unnecessary ternary

[09:55] <Geth> ¦ rakudo/main: bfdc9d3458 | Merge pull request #6728 from ugexe/ugexe/rakuast-type-arg-block-lowering

[09:55] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/compare/bc23c1a18d04...bfdc9d34583d

[10:11] *** finanalyst left
[10:26] *** [Coke] left
[10:26] *** [Coke] joined
[11:12] <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:13] <lizmat> rakkable: eco-provides foo

[11:13] <rakkable> lizmat, Running: eco-provides foo, please be patient!

[11:13] *** rakkable left
[11:13] <lizmat> meh

[11:13] *** rakkable joined
[11:13] <lizmat> rakkable: eco-provides foo

[11:13] <rakkable> lizmat, Running: eco-provides foo, please be patient!

[11:13] <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
[11:15] <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:16] <lizmat> use a local copy of rak and Ecosystem::Cache, I only see "quartenary" mentioned in the L10N modules, and Rainbow

[11:16] <lizmat> not sure why rakkable segfaults  ;-(

[11:18] *** rakkable joined
[11:18] <lizmat> rakkable: eco-provides quaternary

[11:18] <rakkable> lizmat, Running: eco-provides quaternary, please be patient!

[11:18] <rakkable> lizmat, Found 11 lines in 11 files (6 distributions):

[11:18] <rakkable> lizmat, https://gist.github.com/a236f0b0189f4152c9c11f4b7bcfa935

[11:18] <lizmat> ShimmerFairy: ^^

[11:21] <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:25] <lizmat> that'd be cool

[11:51] <lizmat> 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 :-)

[13:05] <[Coke]> https://github.com/coke/raku-blin-release-results - through eb6d4be9ff

[13:05] <linkable6> (2026-09-24) https://github.com/rakudo/rakudo/commit/eb6d4be9ff Merge pull request #6726 from ugexe/ugexe/rakuast-eager-method-attach

[13:05] <[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,

[13:05] <[Coke]> some variety this time

[13:06] <[Coke]> 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] <[Coke]> c: bfdc9d3458 e

[13:06] <committable6> [Coke], ¦bfdc9d3: «»

[13:10] <lizmat> afaik all modules with auth:zef:slavenskoj are AI slop

[13:11] <lizmat> French, Portuguese

[13:13] <lizmat> Slang::Comments is victim of adding RakuAST bootstrap typechecking

[13:13] <lizmat> will make a PR for that

[13:22] <lizmat> https://github.com/bduggan/raku-slang-comments/pull/2

[13:22] <lizmat> Sustenance was given up on by the developer, afaik

[13:23] <lizmat> Inline::Perl5 just needs to merge a PR and/or release a new version

[13:23] * lizmat nudges nine

[13:23] <[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,.

[13:26] <lizmat> https://gist.github.com/lizmat/6a2e076bff3f4772e1737fe7be88c6c2

[13:28] <Geth> ¦ Blin/main: 7e55f9bb88 | (Will Coleda)++ | resources/skips.json

[13:28] <Geth> ¦ Blin/main: Note skips from RakuAST testing

[13:28] <Geth> ¦ Blin/main: review: https://github.com/Raku/Blin/commit/7e55f9bb88

[13:28] <[Coke]> ^^ there.

[13:36] <lizmat> looks like Algorithm::Evolutionary::Simple exposes a difference in WhateverCode handling

[13:36] <lizmat> m: dd (True, True, False, False, True, False).rotor(2).grep(so (*.all == True | False)).elems

[13:36] <camelia> rakudo-moar e17a1d43b: OUTPUT: «2␤»

[13:36] <lizmat> thats still legacy ^^

[13:36] <lizmat> m: Q|dd (True, True, False, False, True, False).rotor(2).grep(so (*.all == True | False)).elems|.AST.EVAL

[13:36] <camelia> rakudo-moar e17a1d43b: OUTPUT: «===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␤     …»

[13:37] <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

[13:37] <camelia> rakudo-moar e17a1d43b: OUTPUT: «3␤»

[13:38] <[Coke]> .seen nine

[13:38] <tellable6> [Coke], I saw nine 2026-07-18T19:35:26Z in #raku-dev: <nine> m: say "alive?"

[13:38] <ab5tract> lizmat: how'd you find that one? :)

[13:38] <lizmat> test in Algorithm::Evolutionary::Simple

[13:39] <ab5tract> ah, gotcha

[13:45] <lizmat> https://github.com/rakudo/rakudo/issues/6730

[13:46] <ugexe> there is already a fix PR to the repo

[13:46] <ugexe> please check the repos first

[13:47] <lizmat> good point

[13:49] <[Coke]> what are the odds of another moarvm fix before relase? non-zero?

[13:51] <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%

[13:51] <lizmat> *say

[13:52] <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:53] <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:54] <lizmat> ah... I see what you mean

[13:54] <lizmat> ok, keep testing the ones with PRs...   if they merged the PR, they will come out clean

[13:55] <lizmat> but I guess we would need to check whether the error is still the same, do we?

[13:57] <ugexe> i already fixed slang::comments

[13:57] <ugexe> https://github.com/bduggan/raku-slang-comments/pull/1#issuecomment-5833569206

[13:59] * lizmat stops looking at blin results until after the release

[14:07] *** [Coke] left
[14:19] <ugexe>  incoming PRs are for the next release

[14:20] <Geth> ¦ rakudo: ugexe++ created pull request #6731: RakuAST: type a native assignment as an argument by its variable

[14:20] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6731

[14:20] <Geth> ¦ rakudo: ugexe++ created pull request #6732: Keep the Array BIND-POS fast path small enough to inline

[14:20] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6732

[14:24] <Geth> ¦ rakudo: ugexe++ created pull request #6733: RakuAST: lower placeholder parameters to frame locals

[14:24] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6733

[14:26] <Geth> ¦ rakudo: ugexe++ created pull request #6734: RakuAST: call AT-POS itself for a native int operator result index

[14:26] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6734

[14:34] <Geth> ¦ rakudo/main: 8dccf3acb1 | (Nick Logan)++ (committed using GitHub Web editor) | 4 files

[14:34] <Geth> ¦ rakudo/main: RakuAST: call AT-POS itself for an array subscripted by a native int

[14:34] <Geth> ¦ rakudo/main: 

[14:34] <Geth> ¦ rakudo/main: Previously `@a[$i]` with a native int `$i`, or an int literal, called

[14:34] <Geth> ¦ rakudo/main: the setting's `postcircumfix:<[ ]>`, whose candidate for an Int index

[14:34] <Geth> ¦ rakudo/main: does nothing but forward its two arguments to `SELF.AT-POS`, and the

[14:34] <Geth> ¦ rakudo/main: assignment form forwards to `SELF.ASSIGN-POS` the same way. That call

[14:34] <Geth> ¦ rakudo/main: cost a proto dispatch and a frame per subscript. In the BinaryHeap

[14:34] <Geth> ¦ rakudo/main: <…commit message has 20 more lines…>

[14:35] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/8dccf3acb1

[15:06] <ugexe> i see JSON::Class is causing some failures, so we'll have at least one more commit to fix that

[15:36] <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:37] <ab5tract> it would allow for a different lever for addressing LTA beyond the worry mechanism, which has its own drawbacks

[15:38] <ab5tract> 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:41] <ugexe> its junctions where 50% of what you can do probably isnt expected

[16:04] *** [Coke] joined
[16:23] <Geth> ¦ rakudo: ugexe++ created pull request #6735: Accept metamodel types as declared types and as roles to compose

[16:23] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6735

[16:42] <[Coke]> NEW=8dccf3acb1 #doing another run up to here.

[16:56] <ugexe> i'll have a few other fixes related to JSON::Class later

[17:03] <ugexe> which i guess isn't too surprising given its vrurg's version and thus flexes the metamodel quite a bit

[17:06] <ugexe> probably a good reason to push the release back till sunday though

[17:17] <ab5tract> re: junctions. all the more reason for a sanity-irizer ;)

[17:18] <ab5tract> use sanity; # remind me of dragons when I invite them to doorsteps

[17:19] <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?

[17:20] <ab5tract> ugexe: 😆

[17:20] <ugexe> i already took the sanity namespace :P https://github.com/ugexe/Raku-sanity

[17:22] <ab5tract> ah! seeing the examples reminds me that I have indeed  seen this before.

[17:23] <ab5tract> I'm glad somebody's got some and is willing to share. seems to be in short supply often these days

[17:24] <ab5tract> I wonder how much of junctions usage can be safely optimized away as `[&&] |$j`

[17:24] <ab5tract> etc

[17:24] <lizmat> the old optimizer did this up to 3 elements I think 

[17:24] <lizmat> timo might know that

[17:27] <ugexe> the optimizer changed the result of those, hence https://github.com/JJ/p6-algorithm-evolutionary-simple/pull/14

[17:29] <ab5tract> well I guess my argument is that we should consider re-formulating junctions as thin wrappers around reduce operations

[17:29] <ab5tract> s/argument/suggestion/

[17:29] <evalable6> ab5tract, rakudo-moar 8dccf3acb: OUTPUT: «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␤»

[17:30] <ugexe> oh that is affectign rakuast as well i guess

[17:31] <ugexe> (the optimization divergence)

[17:31] <ab5tract> essentially they could become the first customer of macros

[17:33] <ab5tract> and then we just abandon whatever junction semantics that can't be implemented as a macro

[17:34] <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> ugexe, rakudo-moar 8dccf3acb: OUTPUT: «False␤»

[17:34] <ab5tract> is the RakuAST optimizer off by default? 

[17:35] <lizmat> no, afaik

[17:35] <ugexe> no

[17:36] <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] <ab5tract> ticket=PR

[17:39] <ugexe> b.all == True|False

[17:39] <ugexe> → all(b1 == any(True,False), b2 == any(True,False), ...)

[17:39] <ugexe> → all(any(T,F), any(F,T), any(T,F), any(F,T))

[17:39] <ugexe> → True

[17:39] <ugexe> the unoptimized version is correct

[17:52] <ugexe> https://github.com/Raku/old-design-docs/blob/1c4e6039a116421c7dbd36c56c34d3f774dcaf8f/S09-data.pod#junctions see the bit starting with "If two or more arguments are junctive, then the argument that is chosen to be "autothreaded" is:"

[17:57] <Geth> ¦ rakudo: ugexe++ created pull request #6736: RakuAST: accept an invoked term as a feed stage

[17:57] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6736

[18:20] *** Pixi left
[18:25] *** Pixi joined
[18:41] * ugexe shakes fist at junctions

[19:12] <[Coke]> I may do the moarvm release tomorrow and the npq/rakudo release Sunday.

[19:12] <[Coke]> (can always do a moarvm point release if needed)

[19:13] <[Coke]> blin run through 8dccf3acb1 at about 60% now.

[19:13] <linkable6> (2026-09-25) https://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