00:01 shareable6 joined 00:02 shareable6__ joined 00:03 unicodable6 left 00:05 notable6 left, quotable6 left, nativecallable6 left, bisectable6 left, releasable6 left, sourceable6 left 00:06 shareable6 left, quotable6 joined, nativecallable6 joined, bisectable6 joined, unicodable6 joined, releasable6 joined, sourceable6 joined, notable6 joined 00:07 bloatable6 left 00:10 bloatable6 joined, shareable6__ left 00:11 shareable6 joined, shareable6__ joined 00:15 quotable6 left, nativecallable6 left, bisectable6 left, unicodable6 left, releasable6 left, sourceable6 left, notable6 left 00:16 shareable6 left, unicodable6 joined, bisectable6 joined, sourceable6 joined, releasable6 joined, notable6 joined, nativecallable6 joined, quotable6 joined 00:19 bloatable6 left, bloatable6 joined 00:21 shareable6__ left 00:24 shareable6 joined 00:25 unicodable6 left, bisectable6 left, sourceable6 left, releasable6 left, notable6 left, nativecallable6 left, quotable6 left 00:28 bloatable6 left, quotable6 joined, nativecallable6 joined, bisectable6 joined, releasable6 joined, sourceable6 joined, notable6 joined, unicodable6 joined 00:29 bloatable6 joined, bloatable6__ joined
Geth rakudo: ugexe++ created pull request #6682:
RakuAST: resolve declarator HOWs through the use statements of a tree		 00:30
00:32 shareable6 left 00:33 bloatable6 left, shareable6 joined 00:34 shareable6__ joined 00:36 bloatable6__ left 00:37 shareable6 left, quotable6 left, nativecallable6 left, bisectable6 left, releasable6 left, sourceable6 left, notable6 left, unicodable6 left 00:38 sourceable6 joined, notable6 joined, unicodable6 joined, nativecallable6 joined, bisectable6 joined, releasable6 joined, quotable6 joined 00:39 bloatable6 joined, bloatable6__ joined 00:41 shareable6__ left 00:44 bloatable6 left, shareable6 joined 00:46 unicodable6 left 00:48 sourceable6 left, notable6 left, nativecallable6 left, bisectable6 left, releasable6 left, quotable6 left
[Coke] github.com/coke/raku-blin-release-...ailures.md - 2 failures, one already known 00:48
that's through 00feb606ab
linkable6 (2026-09-11) github.com/rakudo/rakudo/commit/00feb606ab Measure a case-folded interpolation match against the target (#6652)
00:48 nativecallable6 joined, bisectable6 joined, quotable6 joined, releasable6 joined, sourceable6 joined, notable6 joined, bloatable6__ left 00:49 unicodable6 joined
[Coke] I did also run across: github.com/Raku/whateverable/issues/416 during these runs 00:49
00:51 bloatable6 joined 00:53 shareable6 left 00:54 shareable6 joined, shareable6__ joined 00:57 nativecallable6 left, bisectable6 left, quotable6 left, releasable6 left, sourceable6 left, notable6 left 00:58 shareable6 left, quotable6 joined, sourceable6 joined, bisectable6 joined, nativecallable6 joined, releasable6 joined, notable6 joined 01:01 djinni`_ left 01:05 djinni` joined 01:07 notable6 left 01:08 notable6 joined
Geth rakudo/main: 8464af23d7 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
RakuAST: check an attribute default against the base type of its meta-object (#6680)

Previously `class C { has Int $.a = 1; has Int $.b = $!a }` died "No such method 'IMPL-BASE-TYPE' for invocant of type 'Int'" under the RakuAST frontend. The attribute default check compares the return type of an initializer that has no compile time value with the declared type stripped of its definedness, and asked the meta-object of the declared ... (7 more lines)		 01:10
ugexe Proxy::Watched doesn't do any regex stuff at all and that test is a timing based promise test so i wonder if its just flakey 01:20
Geth rakudo/main: 9248851697 | (Nick Logan)++ | 3 files
RakuAST: evaluate a package colonpair of a hand built tree

Previously a package built from nodes, or rebuilt from the .raku of a parsed one, could not have a colonpair whose value needs evaluation. IMPL-BEGIN applies the block semantics of a package, which asks for its type, before it visits the name. So `class C:ver(1 + 1) { }` compiled the unresolved value and died "This element has not been resolved". ... (13 more lines)		 02:09
rakudo/main: 44a6111e0d | (Nick Logan)++ | 2 files
RakuAST: report a redeclaration in a tree EVAL

Previously compiling a tree built from nodes that declared an our package whose name was already taken died instead of reporting the redeclaration. `class C { }; class C { }` died "No such method 'panic' for invocant of type 'RakuAST::Resolver::EVAL'" and `class A::B { }; class A::B { }` died "No such method 'add-sorry'". Only ... (5 more lines)
rakudo/main: b88ac8f8f0 | (Nick Logan)++ (committed using GitHub Web editor) | 4 files
Merge pull request #6681 from ugexe/ugexe/rakuast-package-colonpair-begin

RakuAST: Evaluate package colonpairs of a hand built tree
[Coke] ugexe: opened github.com/spidererrol/perl6-Proxy...d/issues/1 02:21
another run through b88ac8f8f0 started 02:37
linkable6 (2026-09-13) github.com/rakudo/rakudo/commit/b88ac8f8f0 Merge pull request #6681 from ugexe/ugexe/rakuast-package-colonpair-begin
Geth rakudo/main: 5 commits pushed by (Nick Logan)++ 03:10
07:49 [Coke]_ joined 07:52 [Coke] left
lizmat just did some timing tests again: clean rakudo without any modules or zef installed: 0.06 startup 09:58
with 1 module (eigenstates) installed: 0.08 startup 09:59
hmmm... ok, I guess it's a false alarm... it's just that with a lot of modules installed, it's more likely to hit 0.08 startup 10:16
*much* more likely 10:17
(this on MacOS and Apple silicon)
11:28 finanalyst joined 13:03 finanalyst left
lizmat notable6: weekly 13:59
notable6 lizmat, 4 notes: gist.github.com/fd62a4c2842e0cb8a7...5373183d97
lizmat notable6: weekly reset 14:03
notable6 lizmat, Moved existing notes to “weekly_2026-09-14T14:03:58Z”
14:05 [Coke]_ is now known as [Coke]
[Coke] github.com/coke/raku-blin-release-results - run through b88ac8f, Text::Fortune is a new(?) one 14:05
Geth rakudo/main: 626e1ff96a | (Elizabeth Mattijsen)++ | src/core.c/Scheduler.rakumod
Allow anything that can coerce to an IO::Path in $*CWD

In a22cab8f9df9b8ad14bd5674cd089c3 the container in which $*CWD lives, was given an IO::Path constraint. This caused Text::Fortune to fail in the ecosystem.
Instead of an IO::Path constraint, coerce any given value to an IO::Path instead. If that turns out to be impossible, the assignment will fail.		 14:25
rakudo/e17a1d43b-but-ast-6.e: 6f00af5b84 | (Will Coleda)++ | src/main.nqp
Default to AST
 14:26
rakudo/e17a1d43b-but-ast-6.e: 1b72ad8806 | (Will Coleda)++ | src/main.nqp
Default to 6.e
rakudo: ugexe++ created pull request #6684:
RakuAST: give nodes complete and exact source spans		 14:39
[Coke] c: 1b72ad8806 e.put 14:41
committable6 [Coke], ¦1b72ad8: «2.718281828459045␤»
[Coke] kicking off a blin run on that one.
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2026/09/14/2026-...tiplicity/ 14:50
[Coke] 130 so far, 52 OK, 19 AlwaysFail
ugexe with github.com/rakudo/rakudo/pull/6684 the code in github.com/ugexe/Raku-rakufmt-prototype works. i dont plan on writing a full rakufmt, but i wanted a prototype to make sure i got rakuast itself in a position to maybe do it 14:52
Geth rakudo/main: 557d49482d | (Elizabeth Mattijsen)++ | src/core.c/Process.rakumod
Repeat 626e1ff96af849bbd82 for $*TMPDIR
rakudo/main: 58aab767ec | (Elizabeth Mattijsen)++ | src/core.c/Process.rakumod
Fix indentation snafu in dynvar initialization logic

No functional changes
ugexe github.com/ugexe/Raku-rakufmt-prot...n/examples has a before and after
[Coke] seems like when running under blin, the redo run is vital now for the various OOM kills. this makes sense. however, also getting a few "No candidates found matching identity" under load as well - these also seem fine on rerun. 15:13
e.g. Acme::BaseCJK just failed on this run. 15:14
ugexe++ for finding the very secret systemd-run option, and timo++ for helping me get it setup in the first place. 15:15
ugexe we'll probably need to have you run a customized zef to figure that one out 15:36
to see if its the index file contents, the json decoding, the identity comparison, or something else that is failing 15:37
this was happening with the rakuast runs too and it seemed to happen to stuff starting with A, i.e. distributions that are presumably at the start of the run 15:38
which feels like a race creating or reading the index file between the various zef runs
[Coke] (customized) sure 15:41
make sense if it's a race.
6f00af5b847948b0727de580fd2f7993c704c4dc 15:47
1b72ad88068e658c0c3ca021d297a72d5bd70af5
how to trigger the commit bot?
just wanted links to those commits - lizmat - first one has 10 failures bisected to it on the first run, second has 2 15:48
oh, those are my two commits. :)
so, some things breaking in AST (not a surprise) and a small number breaking only when 6.e 15:49
ah, nevermind. those 2 failures are No candidates found matching identity 15:50
so, I won't bother doing any reporting until I finish the run & the redos.
crap. pzstd error on one of the rakudo versions scrolled by before I could grab it. 17:21
now that I'm using Ghostty, my tmux scrolling doesn't work so I can't go back and get it 17:22
japhb: starting on a recent-ish macos laptop, ssh'd to ubuntu, running tmux - any idea how to make it page up ? As previously discussed, most of what I try ends up scrolling the input buffer, not the display. 17:23
If I remember, it's lost forever on this session
ah, thankfully the error recurred. 17:25
grabbed it this time
Geth rakudo: ugexe++ created pull request #6685:
Quote dependency specification matchers in .raku		 19:33
lizmat [Coke]: I just realized: is ParaSeq already skipped in blin ? 20:05
Geth rakudo: ugexe++ created pull request #6686:
RakuAST: report the composition error of a documented type		 20:08
lizmat ugexe: RakuAST::Expression.apply-sink takes a :$okifnil named argument, but RakuAST::Node does not 20:10
feels to me we should at least add a dummy :$okifnil to Node.apply-sink ? 20:12
20:18 finanalyst joined
ugexe if a callsite needs it sure, but why add it if nothing does? its existence would imply someone has thought if okifnil type behavior should work with that and to users that it actually does something 20:21
i also dont think i wrote either of those
lizmat not suggesting you did: it's just that you're much more involved with RakuAST lately :-) 20:22
I'll add it for compatibility with Expression.apply-sink and see if there's any testing fallout
meanwhile RAKU_LANGUAGE_VERSION=v6.e.PREVIEW found one useless use case in App::Rak that legacy / 6.d didn't find 20:23
so that's an improvement 20:24
re apply-sink: it broke RakuAST::Utils 20:25
that's how I found it
ugexe im not following how the non existence of a parameter to some node is being considered based on if adding it does anything or not 20:31
if you can prove its needed then that would be a good reason to add it. if you can't then i dont follow why it would be added 20:32
oh it broke RakuAST::Utils, i glossed over that. what does it break about it? if it is ast generated from valid raku code that sounds like a good reason to fix it. if by broken you mean some hand written ast isn't doing what you think it should i'm not so sure 20:33
lizmat Unexpected named argument 'okifnil' passed 20:34
in any apply-sink at src/Raku/ast/base.rakumod line 19
in any propagate-sink at src/Raku/ast/statements.rakumod line 1289
ugexe oh, well thats a great reason to lol
lizmat glad we agree :-)
I just found that Discogs::API fails reliably with: 20:35
Missing or wrong version of dependency 'core#sources/E26A2EAADD094CE6987C6663C4F1FBFEC9468476 (CompUnit::Repository::Staging)' (from '/Users/liz/Github/rakudo/install/share/perl6/site/sources/DAF2DD216931EA6FBC6203826A2C1E38F04DE958 (Cro::MessageWithBody)')
when under RAKU_LANGUAGE_VERSION=v6.e.PREVIEW 20:36
at site#sources/7A89B656FDF0A3160E0CA7474D27BD49571CD1CE (Cro::HTTP::Client::CookieJar):3 20:37
------> <BOL><HERE>use Cro::HTTP::Response;
I should probably remove Cro::HTTP::Client as a dependency in that module, but there you go
ugexe using that environment variable isn't going to make debugging precomp stuff simple 20:39
maybe you should just put use v6.e.PREVIEW in your code and see what happens 20:41
after clearing all existing precomp artifacts
lizmat yeah, it's on my list of failing modules already, will do so tomorrow 20:42
ugexe m: my $n = 100_000; my $blob = ("x" x $n).encode; my $bad = 0; for ^500 { $bad += (await (^8).map: { start $blob.decode.chars }).grep(* != $n).elems }; say "bad=$bad of 4000"; 20:44
camelia bad=1 of 4000
ugexe m: my $n = 100_000; my $blob = ("x" x $n).encode; my $bad = 0; for ^500 { $bad += (await (^8).map: { start $blob.decode.chars }).grep(* != $n).elems }; say "bad=$bad of 4000";
camelia bad=2 of 4000
ugexe that is supposedly the cause of the "No candidates found matching identity" bug [Coke] keeps seeing
lizmat ah, so a race condition :-( 20:45
ugexe a garbage collector race in MoarVM's utf8 decoder, added by MoarVM commit 7b802a101 ("When decoding over 10k bytes of utf8 or utf8-c8 data, mark thread blocked")
linkable6 (2026-05-29) github.com/MoarVM/MoarVM/commit/7b802a101f When decoding over 10k bytes of utf8 or utf8-c8 data, mark thread blocked
ugexe "Only the utf8 decoder. utf8-c8, ascii and iso-8859-1 all showed 0 failures." 20:46
m: say Blob.new(0x61, |(0xCC,0x81) xx 5000).decode 20:50
camelia (timeout)
ugexe that deadlock is also supposedly from the same commit
m: say Blob.new(0x61, |(0xCC,0x81) xx 4900).decode 20:51
camelia Too many codepoints (4900) in grapheme
in block <unit> at <tmp> line 1
ugexe with 4900 it returns instantly
that one affects both utf8 and utf8-c8 because neither decoder marks the thread active again before the normalization code throws 20:53
short term it might make sense to just revert that commit 21:16
guess it would also need to revert the follow up a3a507141 21:18
linkable6 (2026-06-30) github.com/MoarVM/MoarVM/commit/a3a5071413 utf8: Do not lock up when very long string has invalid utf8 in it.
21:20 finanalyst left
[Coke] lizmat: github.com/Raku/Blin/blob/main/res...skips.json - nope it's not skipped 21:29
in the current run, it's showing as 1665:ParaSeq – ZefFailure 21:37
the comments in the code say that means zef segfaulted, but I'm guessing maybe just "didn't return 0" 21:42
this may point to the same error we've been seeing more of lately ugexe was talking about
ugexe im working on the ParaSeq failures 22:12
right now there is a reduce hang that it blames on github.com/rakudo/rakudo/commit/9bcb01e96 22:15
lizmat interesting... 22:20
will look at it tomorrow 22:21

Powered by Cro and the Raku® Programming Language.

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

Thank you!