[01:33] <Geth> ¦ rakudo/main: 13 commits pushed by (Nick Logan)++

[01:33] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/compare/c6fff750c2ac...fdb0d563742e

[01:34] <ugexe> [Coke]: that one is worth of a new run itself^

[01:34] <ugexe> worthy rather

[06:41] <[Tux]> 🐧 zef update Slang::Tuxic

[06:41] <[Tux]> 🐧 zef install Slang::Tuxic

[06:41] <[Tux]> All candidates are currently installed

[06:41] <[Tux]> No reason to proceed. Use --force-install to continue anyway

[06:41] <[Tux]> 🐧 raku --version

[06:41] <[Tux]> Welcome to Rakudo™ v2026.09-21-g69f2b375f4.

[06:41] <[Tux]> Implementing the Raku® Programming Language v6.d.

[06:41] <[Tux]> Built on MoarVM version 2026.09-2-g6e5144cb6.

[06:45] <[Tux]> `zef upgrade Slang::Tuxic` did the job. Still I see new warnings, but I will have to look at those later

[06:45] <[Tux]> Rakudo v2026.09-21-g69f2b375f4 (v6.d) on MoarVM 2026.09-2-g6e5144cb6

[06:45] <[Tux]> csv-test-xs         0.016 -  0.017

[06:45] <[Tux]> csv-test-xs-20      0.115 -  0.116

[06:45] <[Tux]> csv-ip5xs           0.299 -  0.306

[06:45] <[Tux]> test-t --race       0.345 -  0.351

[06:45] <[Tux]> test-t              0.553 -  0.573

[06:45] <[Tux]> csv-parser          0.989 -  1.018

[06:45] <[Tux]> csv-ip5xs-20        1.163 -  1.191

[06:45] <[Tux]> test-t-20 --race    1.682 -  1.704

[06:45] <[Tux]> test                2.088 -  2.126

[06:45] <[Tux]> test-t-20           7.345 -  7.420

[06:45] <[Tux]> https://tux.nl/Talks/CSV6/speed4-20.html / https://tux.nl/Talks/CSV6/speed4.html https://tux.nl/Talks/CSV6/speed.log

[07:03] <[Tux]> test-t              0.571 -  0.580

[07:03] <[Tux]> something slowed down

[11:17] *** finanalyst joined
[12:22] <[Coke]> so, it looks like tux had a new rakudo but an older module installed. If I install a new rakudo (esp. with rakubrew), none of the previously installed modules are available. Which one of those is the expected case?

[12:23] <[Coke]> ugexe:running

[12:30] <[Tux]> The laslines of my raku update/install script are

[12:30] <[Tux]> zef update || true

[12:30] <[Tux]> zef install --exclude=perl \

[12:30] <[Tux]>     Slang::Tuxic File::Temp CSV::Parser \

[12:30] <[Tux]>     Data::Dump Inline::Perl5 p6doc Bench || true

[12:30] <[Tux]> zef upgrade --exclude=perl \

[12:30] <[Tux]>     Slang::Tuxic File::Temp CSV::Parser \

[12:30] <[Tux]>     Data::Dump Inline::Perl5 p6doc Bench || true

[12:30] <[Tux]> Does that need more?

[12:30] <[Tux]> laslines → last lines

[12:34] <[Coke]> For me, those would be installing into a new repo tied to the new install, so I'd get whatever the latest was. if you're using the same repo somehow, I think the upgrade should have handled it. 

[12:37] <[Coke]> (I have something similar, a script that invoke zef for all my "always use" modules)

[12:37] <[Coke]> I only have 'zef install' though, as the zef install is new at that point as well, so nothing to update.

[12:38] <[Coke]> Just wanted to make sure you weren't doing something like "export list of old modules" -> "install this exact set of modules" - your script there looks reasonable to me!

[12:48] <[Coke]> suggestion: do blin runs a branches that turn deprecation warnings into failures so we can see what all the ecosystem fallout will be for, e.g. "Please use %?RESOURCES<key> directly instead."

[12:50] <[Coke]> ugexe: For the Cyclic Dependency errors in blin - it's at least partially an issue with how blin is processing things (but it seems to make sense) - e.g. Geo::Hash depends on Geo::Hash::CustomBuilder which in turn depends on Geo::Hash::CustomBuilder - but zef doesn't care, and installed Geo::Hash with no complaint. blin says "heyyyyy" and puts it on the naughty list.

[12:51] <[Coke]> I think maybe blin needs to realize that Geo::Hash::CustomBuilder is IN Geo::Hash and therefore that's not a cycle.

[14:23] <ugexe> i'm honestly not sure if it should be listing that in the build-depends if its included in the distribution

[14:23] <ugexe> its slightly different than typical modules in that its listed in the "builder" field so i might just be forgetting some detail

[14:24] <[Coke]> it's also under build-depends

[14:25] <[Coke]> which is where blin is seeing it, I think.

[14:25] <[Coke]> I agree that it shouldn't be there, but since zef allows it, blin probably should too

[14:26] <[Coke]> 57% done with blin, no failures yet compared to 2026.09

[14:48] <[Coke]> I also want to eventually go through the AlwaysFail list and see if any of these can be resurrected or skipped.

[15:05] <lizmat> afk for a bit for an update

[15:06] *** lizmat left
[15:11] *** finanalyst_ joined
[15:11] *** finanalyst left
[15:18] *** lizmat joined
[15:31] *** finanalyst_ left
[15:37] <Geth> ¦ rakudo: ugexe++ created pull request #6764: RakuAST: instantiate a generic array or hash where it is declared

[15:37] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6764

[15:53] *** finanalyst joined
[16:18] <Geth> ¦ rakudo: ugexe++ created pull request #6765: RakuAST: only leave the scope for a heredoc body after a closing brace

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

[16:31] <[Coke]> ugexe: IO::Directory::Watcher and Stomp (run still in progress) bisecting to fdb0d563742e1671bf84fe840e161ab89c72e662

[16:31] <linkable6> (2026-09-29) https://github.com/rakudo/rakudo/commit/fdb0d56374 Merge pull request #6754 from ugexe/ugexe/rakuast-short-circuit-no-curry

[16:31] <[Coke]> 87% doe

[16:31] <[Coke]> done

[17:13] <Geth> ¦ rakudo/main: a0433344aa | (Nick Logan)++ (committed using GitHub Web editor) | 3 files

[17:13] <Geth> ¦ rakudo/main: RakuAST: only leave the scope for a heredoc body after a closing brace

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

[17:13] <Geth> ¦ rakudo/main: The `cheat-heredoc` token parses the body of a heredoc right after the line

[17:13] <Geth> ¦ rakudo/main: that queued it, and it left the current scope while doing so. Leaving is

[17:13] <Geth> ¦ rakudo/main: correct after the closing brace of a block, since the body then lies outside

[17:13] <Geth> ¦ rakudo/main: that block. However the same token also runs after the semicolon that ends

[17:13] <Geth> ¦ rakudo/main: the statement of a statement prefix or phaser, a `constant` initializer, or a

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

[17:13] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/a0433344aa

[17:43] *** hankache joined
[18:03] *** ShimmerFairy left
[18:03] *** ShimmerFairy joined
[18:03] *** Pixi` joined
[18:06] *** Pixi left
[18:07] *** Pixi` is now known as Pixi

[18:29] <[Coke]> managed to kill blin with 3 modules remaining. rerunning with those 3 plus the failing 2...

[18:43] <[Coke]> ugexe: fdb0d56374 is clean on redo

[18:44] <Geth> ¦ problem-solving: hankache assigned to codesections Issue Decoupling Raku module requirements from Rakudo versions https://github.com/Raku/problem-solving/issues/531

[21:38] <Geth> ¦ problem-solving: lizmat unassigned from codesections Issue Decoupling Raku module requirements from Rakudo versions https://github.com/Raku/problem-solving/issues/531

[22:36] <Geth> ¦ rakudo/main: a61b582d7a | (Nick Logan)++ (committed using GitHub Web editor) | 4 files

[22:36] <Geth> ¦ rakudo/main: RakuAST: instantiate a generic array or hash where it is declared (#6764)

[22:36] <Geth> ¦ rakudo/main: 

[22:36] <Geth> ¦ rakudo/main: Previously `sub f(::T) { my %h{T} }` died with "No such method

[22:36] <Geth> ¦ rakudo/main: 'instantiate_generic' for invocant of type 'Hash[Any,T]'" when called.

[22:36] <Geth> ¦ rakudo/main: So did `my T @a` and `my T %h` in a sub with a type capture or in a

[22:36] <Geth> ¦ rakudo/main: method of a parametric role. The declaration instantiated its container

[22:36] <Geth> ¦ rakudo/main: in place, which a Scalar supports but an Array or Hash does not.

[22:36] <Geth> ¦ rakudo/main: <…commit message has 30 more lines…>

[22:36] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/a61b582d7a