[Coke] NEW=59eafee5f3 - clear except for Injector 00:40
c: 501af82c50 e 00:57
committable6 [Coke], ¦501af82: «»
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:36
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:37
(This came from the rubble after a build-everything run.) 01:38
01:53 lizmat left
Geth rakudo: ugexe++ created pull request #6799:
RakuAST: recognize types from the outer context in term position		 03:06
rakudo/main: ed2d96829a | (Nick Logan)++ (committed using GitHub Web editor) | 7 files
RakuAST: recognize types from the outer context in term position (#6799)

Previously a type declared outside an EVAL, or on an earlier REPL line, was not recognized as a type by `is-name-type`. A lexical from that outer context resolves to a `RakuAST::Declaration::External`, which is not a
  `RakuAST::CompileTimeValue`. As such `A[Str]` parsed as a postcircumfix
on `A`, `C(Int)` as a call to an undeclared routine, and `C:D` silently ... (15 more lines)		 03:57
rakudo: ugexe++ created pull request #6800:
Ugexe/rakuast eval begin outer context		 04:00
07:36 lizmat_ left 07:37 lizmat joined 08:45 rnddim joined 08:46 rnddim left, ShimmerFairy left, rnddim joined 08:49 rnddim left 08:50 rnddim joined, rnddim left 08:51 rnddim joined
Geth rakudo/main: d3c07b2578 | (Elizabeth Mattijsen)++ | 2 files
RakuAST: tweak ::Type::Capture.from-identifier interface

Decided to only have positional arguments to .from-identifier methods. They are for convenience, so should be simple. So the :smiley optional named argument has become an optional second positional argument.
Since this API was introduced yesterday, it felt safe to do this change now.		 09:30
09:52 rnddim is now known as ShimmerFairy
Geth rakudo/main: 0a83ba536e | (Elizabeth Mattijsen)++ | 2 files
RakuAST: in NQP, my @a := nqp::list is unnecessary

Because a lexical array definition already allocates an nqp::list. So remove this essentially dead code.		 11:37
lizmat notable6: weekly 12:20
notable6 lizmat, 3 notes: gist.github.com/b6ca5a6da7d2c3c61b...b7e4707eb0
lizmat notable6: weekly reset 12:21
notable6 lizmat, Moved existing notes to “weekly_2026-10-05T12:21:03Z”
[Coke] huh. 49 bisect fails on last blin run to 40fca14d2657846c9bec388f8101bc04f99657f2 - doing a redo run... 13:17
linkable6 (2026-10-03) github.com/rakudo/rakudo/commit/40fca14d26 RakuAST: declare thunked code by the block it closes over
13:24 japhb left
[Coke] (Weird, we haven't had this many false negatives in a while) 13:30
Need to make a module that when testing, dies once, then works on subsequent tests. 13:31
13:32 Guest19 joined
Guest19 Hello.  Will a precompiled rakudo with the fix for the "constant MAIN" ticket be made available before the next monthly release? 13:34
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:35
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
Guest19 Ah, okay - noted.  Thank you.
lizmat if there is a really big problem, then a point release would happen
and that would become available in precompiled installs 13:37
your problem wasn't caught in spectest, or in the ecosystem, and you were the only one reporting
so it feels not urgent enough, I'm afraid
Guest19 Understood 13:38
lizmat The first Raku Weekly News hits the Net: rakuweekly.blog/2026/10/05/2026-40-pythonesque/ 13:49
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:55
lizmat ugexe: understood, expect to be making PRs again :-) 13:57
ugexe it seems like 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?
ah, it fails in building rakudo ?? 14:02
Frame has no lexical with name '&INDIRECT_NAME_LOOKUP' at src/Raku/ast/resolver.rakumod:637 14:03
ugexe ah right, im pretty sure the CI would have switched off x86 apple awhile ago 14:09
[Coke] redo run is 87.44% done, only 7 failures at 40fca now 14:20
(lots of locking going on as we're doing a lot of bisecting, apparently) 14:21
ah, that number is creeping back up. :( 14:39
back up to 19, with 19 left to test. 14:41
14:47 Guest19 left 15:09 japhb joined
[Coke] git@github.com:coke/raku-blin-release-results.git updated - injector + 38 failures on 40fca14d 15:25
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:43
[Coke] Thanks, no worries. 15:46
I just keep calling it out so you didn't think *I* forgot it was already reported. :)
many Serialization Error: missing static code ref for closure '' 15:51
ugexe yeah every subset ... where <expression> leaks AST into the precomp via Nil but Suggestion[$node] 15:52
which reminds me... we need the "Did you mean" message to not mention IMPL- methods
[Coke] mmm 15:59
lizmat ugexe: maybe that should be more general as in having them marked implementation-detail 16:00
[Coke] Ping me when it makes sense to do another blin 16:12
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" 16:13
Geth rakudo: ugexe++ created pull request #6801:
RakuAST: don't call Mu.WHY on the where expression of a subset		 17:09
ugexe oh our macOS CI job is x86 17:18
lizmat ok, that would explain the failure there then :-)
ugexe we should probably change that to arm64 at this point, but yeah seems like it hits a JIT issue
lizmat I just found a very weird anomaly in NQP performance 17:43
% time nqp -e 'my int $i := 100000000; my str $a := "e"; while --$i { my int $b := $a eq "a" }'
real0.29s
% time nqp -e 'my int $i := 100000000; my str $a := "e"; while --$i { my int $b := $a eq "a" || $a eq "b" }'
real1.54s
so the addition of: || $a eq "b" makes this 5x as slow ? 17:44
% 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" }'
real2.11s
compare this to a lookup hash with 2 elements: 17:46
% 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) }
real0.30s
ugexe i mean if you look at them from an optimization view point its kind of obvious 17:47
$b is never used 17:48
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)'
0
nqp -e 1.10s user 0.01s system 100% cpu 1.104 total
➜ ~ 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)'
0
nqp -e 2.01s user 0.02s system 100% cpu 2.022 total
linear
lizmat ah, indeed 17:51
TIL :-) 17:52
ok, with some more benchmarks, it looks like even a simple $a eq "a" || $a eq "b" would benefit from a lookup hash 17:55
if there's an unlikely hit 17:56
ugexe but doesnt that just make the unlikely hit faster and slow down the likely hit? 17:57
[Coke]: just merged the fix for most (all?) the blin failures 17:58
lizmat didn't see Geth say anything here? 17:59
Geth rakudo/main: 88626a34b8 | (Nick Logan)++ (committed using GitHub Web editor) | 4 files
RakuAST: don't call Mu.WHY on the where expression of a subset (#6801)

Previously the check for a leading doc on the where block of a subset, added in 9c75134daa, called `.WHY` on any where. `nqp::can` finds a
  `WHY` on every node since `Mu` has one, so a where that is an expression
rather than a block got `Mu.WHY`, which returns
  `Nil but Suggestion[$node]`. Parameterizing that role runs its body, and
... (14 more lines)
lizmat ok, Github flubbed that one 18:00
18:01 ugexe left 18:04 ugexe joined
[Coke] c: 88626a34b8 e 18:47
committable6 [Coke], ¦88626a3: «»
[Coke] kicking off a run 18:48
20:07 hurufu joined 21:02 rnddim joined, notable6__ joined 21:04 lucs_ joined 21:05 jdv_ joined 21:07 camelia left, notable6 left, ShimmerFairy left, lucs left, jdv left 21:22 camelia joined 21:38 hurufu left
[Coke] aff385f36fd229a 22:09
linkable6 (2026-10-02) github.com/rakudo/rakudo/commit/aff385f36f RakuAST: some fixes / streamlining in ::Name
[Coke] DateTime::React – Fail, Bisected: aff385f36fd229a0078b46c5d3bdc06062bdd902 22:10
(still mid run)
Geth rakudo: ugexe++ created pull request #6802:
Implement multidimensional shaped hashes		 22:21
[Coke] do our current core devs agree with niner's thoughts on github.com/rakudo/rakudo/pull/5869? (that we would rather do more at the HLL and improve optimisations?) 22:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!