[00:40] <[Coke]> NEW=59eafee5f3 - clear except for Injector

[00:57] <[Coke]> c: 501af82c50 e

[00:57] <committable6> [Coke], ¦501af82: «»

[01:36] <japhb> I get this trying to `zef install App::Prove6`: Serialization Error: missing static code ref for closure '' (src/Raku/ast/signature.rakumod:1312)

[01:37] <japhb> Because it has several dependencies, I'm not sure which one is actually making it fail.  Trying to read the tea leaves, it *might* be sigpipe (sigpipe:ver<0.0.3>:auth<zef:leont>) but I'm not positive.

[01:38] <japhb> (This came from the rubble after a build-everything run.)

[01:53] *** lizmat left
[03:06] <Geth> ¦ rakudo: ugexe++ created pull request #6799: RakuAST: recognize types from the outer context in term position

[03:06] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6799

[03:57] <Geth> ¦ rakudo/main: ed2d96829a | (Nick Logan)++ (committed using GitHub Web editor) | 7 files

[03:57] <Geth> ¦ rakudo/main: RakuAST: recognize types from the outer context in term position (#6799)

[03:57] <Geth> ¦ rakudo/main: 

[03:57] <Geth> ¦ rakudo/main: Previously a type declared outside an EVAL, or on an earlier REPL line,

[03:57] <Geth> ¦ rakudo/main: was not recognized as a type by `is-name-type`. A lexical from that outer

[03:57] <Geth> ¦ rakudo/main: context resolves to a `RakuAST::Declaration::External`, which is not a

[03:57] <Geth> ¦ rakudo/main: `RakuAST::CompileTimeValue`. As such `A[Str]` parsed as a postcircumfix

[03:57] <Geth> ¦ rakudo/main: on `A`, `C(Int)` as a call to an undeclared routine, and `C:D` silently

[03:57] <Geth> ¦ rakudo/main: <…commit message has 15 more lines…>

[03:57] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/ed2d96829a

[04:00] <Geth> ¦ rakudo: ugexe++ created pull request #6800: Ugexe/rakuast eval begin outer context

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

[07:36] *** lizmat_ left
[07:37] *** lizmat joined
[08:45] *** rnddim joined
[08:46] *** rnddim left
[08:46] *** ShimmerFairy left
[08:46] *** rnddim joined
[08:49] *** rnddim left
[08:50] *** rnddim joined
[08:50] *** rnddim left
[08:51] *** rnddim joined
[09:30] <Geth> ¦ rakudo/main: d3c07b2578 | (Elizabeth Mattijsen)++ | 2 files

[09:30] <Geth> ¦ rakudo/main: RakuAST: tweak ::Type::Capture.from-identifier interface

[09:30] <Geth> ¦ rakudo/main: 

[09:30] <Geth> ¦ rakudo/main: Decided to only have positional arguments to .from-identifier

[09:30] <Geth> ¦ rakudo/main: methods.  They are for convenience, so should be simple.  So

[09:30] <Geth> ¦ rakudo/main: the :smiley optional named argument has become an optional

[09:30] <Geth> ¦ rakudo/main: second positional argument.

[09:30] <Geth> ¦ rakudo/main: 

[09:30] <Geth> ¦ rakudo/main: Since this API was introduced yesterday, it felt safe to do

[09:30] <Geth> ¦ rakudo/main: this change now.

[09:30] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/d3c07b2578

[09:52] *** rnddim is now known as ShimmerFairy

[11:37] <Geth> ¦ rakudo/main: 0a83ba536e | (Elizabeth Mattijsen)++ | 2 files

[11:37] <Geth> ¦ rakudo/main: RakuAST: in NQP, my @a := nqp::list is unnecessary

[11:37] <Geth> ¦ rakudo/main: 

[11:37] <Geth> ¦ rakudo/main: Because a lexical array definition already allocates an nqp::list.

[11:37] <Geth> ¦ rakudo/main: So remove this essentially dead code.

[11:37] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/0a83ba536e

[12:20] <lizmat> notable6: weekly

[12:20] <notable6> lizmat, 3 notes: https://gist.github.com/b6ca5a6da7d2c3c61be285b7e4707eb0

[12:21] <lizmat> notable6: weekly reset

[12:21] <notable6> lizmat, Moved existing notes to “weekly_2026-10-05T12:21:03Z”

[13:17] <[Coke]> huh. 49 bisect fails on last blin run to 40fca14d2657846c9bec388f8101bc04f99657f2 - doing a redo run...

[13:17] <linkable6> (2026-10-03) https://github.com/rakudo/rakudo/commit/40fca14d26 RakuAST: declare thunked code by the block it closes over

[13:24] *** japhb left
[13:30] <[Coke]> (Weird, we haven't had this many false negatives in a while)

[13:31] <[Coke]> Need to make a module that when testing, dies once, then works on subsequent tests.

[13:32] *** Guest19 joined
[13:34] <Guest19> Hello.  Will a precompiled rakudo with the fix for the "constant MAIN" ticket be made available before the next monthly release?

[13:35] <lizmat> Guest19: I doubt it.    The workaround would be to just replace the "constant" by "my", which afaics should not make running the script noticeable slower

[13:36] <Guest19> Okay.  In general, what is the policy for making precompiled installs available before monthly releases?

[13:36] <lizmat> afaik it's never happened before

[13:36] <Guest19> Ah, okay - noted.  Thank you.

[13:36] <lizmat> if there is a really big problem, then a point release would happen

[13:37] <lizmat> and that would become available in precompiled installs

[13:37] <lizmat> your problem wasn't caught in spectest, or in the ecosystem, and you were the only one reporting

[13:37] <lizmat> so it feels not urgent enough, I'm afraid

[13:38] <Guest19> Understood

[13:49] <lizmat> The first Raku Weekly News hits the Net: https://rakuweekly.blog/2026/10/05/2026-40-pythonesque/

[13:55] <ugexe> hmm yeah thats a lot of failures. we should refrain from refactoring / modifying any of the code from those commits until we figure out what the failures are from. otherwise its going to be difficult to revert them should the need arise

[13:57] <lizmat> ugexe: understood, expect to be making PRs again :-)

[14:01] <ugexe> it seems like https://github.com/rakudo/rakudo/pull/6800 might be exposing a JIT issue since it builds fine locally but all the variants fail CI

[14:01] <lizmat> but the Mac version also failed, and that runs on Apple silicon, does it not?

[14:02] <lizmat> ah, it fails in building rakudo ??

[14:03] <lizmat> Frame has no lexical with name '&INDIRECT_NAME_LOOKUP'  at src/Raku/ast/resolver.rakumod:637

[14:09] <ugexe> ah right, im pretty sure the CI would have switched off x86 apple awhile ago

[14:20] <[Coke]> redo run is 87.44% done, only 7 failures at 40fca now

[14:21] <[Coke]> (lots of locking going on as we're doing a lot of bisecting, apparently)

[14:39] <[Coke]> ah, that number is creeping back up. :(

[14:41] <[Coke]> back up to 19, with 19 left to test.

[14:47] *** Guest19 left
[15:09] *** japhb joined
[15:25] <[Coke]> git@github.com:coke/raku-blin-release-results.git updated - injector + 38 failures on 40fca14d

[15:43] <ugexe> for injector i have a local branch that implements type constraints on shaped hashes, but i haven't had time to finish reviewing it. and i probably wont have time to review it before looking at all these new failures. just mentioning to make it clear Injector isn't being ignored

[15:46] <[Coke]> Thanks, no worries.

[15:46] <[Coke]> I just keep calling it out so you didn't think *I* forgot it was already reported. :)

[15:51] <[Coke]> many Serialization Error: missing static code ref for closure ''

[15:52] <ugexe> yeah every subset ... where <expression> leaks AST into the precomp via Nil but Suggestion[$node]

[15:52] <ugexe> which reminds me... we need the "Did you mean" message to not mention IMPL- methods

[15:59] <[Coke]> mmm

[16:00] <lizmat> ugexe: maybe that should be more general as in having them marked implementation-detail

[16:12] <[Coke]> Ping me when it makes sense to do another blin

[16:13] <lizmat> wrt implementation detail: I've come to the conclusion that either RakuAST typegraphs will need to be made by hand, or many classes / roles will need to be marked "implementation-detail"

[17:09] <Geth> ¦ rakudo: ugexe++ created pull request #6801: RakuAST: don't call Mu.WHY on the where expression of a subset

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

[17:18] <ugexe> oh our macOS CI job is x86

[17:18] <lizmat> ok, that would explain the failure there then  :-)

[17:18] <ugexe> we should probably change that to arm64 at this point, but yeah seems like it hits a JIT issue

[17:43] <lizmat> I just found a very weird anomaly in NQP performance

[17:43] <lizmat> % time nqp -e 'my int $i := 100000000; my str $a := "e"; while --$i { my int $b := $a eq "a" }'

[17:43] <lizmat> real	0.29s

[17:43] <lizmat> % time nqp -e 'my int $i := 100000000; my str $a := "e"; while --$i { my int $b := $a eq "a" || $a eq "b" }'

[17:43] <lizmat> real	1.54s

[17:44] <lizmat> so the addition of:   || $a eq "b"    makes this 5x as slow ?

[17:44] <lizmat> % time nqp -e 'my int $i := 100000000; my str $a := "e"; while --$i { my int $b := $a eq "a" || $a eq "b" || $a eq "c" }'

[17:44] <lizmat> real	2.11s

[17:46] <lizmat> compare this to a lookup hash with 2 elements:

[17:46] <lizmat> % time nqp -e 'my constant A := nqp::hash("a",1,"b",1); my int $i := 100000000; my str $a := "e"; while --$i { my int $b := nqp::existskey(A,$a) }

[17:46] <lizmat> real	0.30s

[17:47] <ugexe> i mean if you look at them from an optimization view point its kind of obvious

[17:48] <ugexe> $b is never used

[17:50] <lizmat> I get the same numbers if I move "my int $b" out of the while loop

[17:50] <ugexe> ➜  ~ time nqp -e 'my int $i := 100000000; my str $a := "e"; my int $c := 0; while --$i { my int $b := $a eq "a"; $c := $c + $b }; nqp::say($c)'

[17:50] <ugexe> 0

[17:50] <ugexe> nqp -e   1.10s user 0.01s system 100% cpu 1.104 total

[17:50] <ugexe> ➜  ~ time nqp -e 'my int $i := 100000000; my str $a := "e"; my int $c := 0; while --$i { my int $b := $a eq "a" || $a eq "b"; $c := $c + $b }; nqp::say($c)'

[17:50] <ugexe> 0

[17:50] <ugexe> nqp -e   2.01s user 0.02s system 100% cpu 2.022 total

[17:50] <ugexe> linear

[17:51] <lizmat> ah, indeed

[17:52] <lizmat> TIL  :-)

[17:55] <lizmat> ok, with some more benchmarks, it looks like even a simple $a eq "a" || $a eq "b" would benefit from a lookup hash

[17:56] <lizmat> if there's an unlikely hit

[17:57] <ugexe> but doesnt that just make the unlikely hit faster and slow down the likely hit?

[17:58] <ugexe> [Coke]: just merged the fix for most (all?) the blin failures

[17:59] <lizmat> didn't see Geth say anything here?

[17:59] <Geth> ¦ rakudo/main: 88626a34b8 | (Nick Logan)++ (committed using GitHub Web editor) | 4 files

[17:59] <Geth> ¦ rakudo/main: RakuAST: don't call Mu.WHY on the where expression of a subset (#6801)

[17:59] <Geth> ¦ rakudo/main: 

[17:59] <Geth> ¦ rakudo/main: Previously the check for a leading doc on the where block of a subset,

[17:59] <Geth> ¦ rakudo/main: added in 9c75134daa, called `.WHY` on any where. `nqp::can` finds a

[17:59] <Geth> ¦ rakudo/main: `WHY` on every node since `Mu` has one, so a where that is an expression

[17:59] <Geth> ¦ rakudo/main: rather than a block got `Mu.WHY`, which returns

[17:59] <Geth> ¦ rakudo/main: `Nil but Suggestion[$node]`. Parameterizing that role runs its body, and

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

[17:59] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/88626a34b8

[18:00] <lizmat> ok, Github flubbed that one

[18:01] *** ugexe left
[18:04] *** ugexe joined
[18:47] <[Coke]> c: 88626a34b8 e

[18:47] <committable6> [Coke], ¦88626a3: «»

[18:48] <[Coke]> kicking off a run

[20:07] *** hurufu joined
[21:02] *** rnddim joined
[21:02] *** notable6__ joined
[21:04] *** lucs_ joined
[21:05] *** jdv_ joined
[21:07] *** camelia left
[21:07] *** notable6 left
[21:07] *** ShimmerFairy left
[21:07] *** lucs left
[21:07] *** jdv left
[21:22] *** camelia joined
[21:38] *** hurufu left
[22:09] <[Coke]> aff385f36fd229a

[22:09] <linkable6> (2026-10-02) https://github.com/rakudo/rakudo/commit/aff385f36f RakuAST: some fixes / streamlining in ::Name

[22:10] <[Coke]> DateTime::React – Fail, Bisected: aff385f36fd229a0078b46c5d3bdc06062bdd902

[22:10] <[Coke]> (still mid run)

[22:21] <Geth> ¦ rakudo: ugexe++ created pull request #6802: Implement multidimensional shaped hashes

[22:21] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6802

[22:57] <[Coke]> do our current core devs agree with niner's thoughts on https://github.com/rakudo/rakudo/pull/5869? (that we would rather do more at the HLL and improve optimisations?)