[Coke] will kick off a regular blin run 00:19
Geth rakudo/main: 94ae304e51 | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Intern curried roles created by generic instantiation (#6567)

Previously CurriedRoleHOW.instantiate_generic built its instantiated curry with CurriedRoleHOW.new_type. Instantiating the Positional[TValue] that Array::Typed does thus produced a Positional[Int] distinct from the interned one that writing Positional[Int] in source returns. Type-check caches match on object identity, so a typed array never got a cache hit ... (12 more lines)		 00:40
rakudo: ugexe++ created pull request #6568:
Cache interpolated regex compilations by pattern source		 00:50
ugexe [Coke]: 👍
[Coke] missed that one, i think. 00:54
ugexe i'm still working on fixing one legacy regression i found so we'd need another legacy run in the near future anyway 01:00
[Coke] ok 01:04
blin runs are cheaper these days, no worries. ;)
releasable6: next
releasable6 [Coke], Next release in ≈8 days and ≈17 hours. There are no known blockers. 152 out of 152 commits logged (⚠ 1 warnings)
[Coke], Details: gist.github.com/dabe83d9eabd8c5c48...1c938a7c95
[Coke] ... again, why does it use a previous output from that command when I fixed the warning/did all the commits already
⏳ 641 out of 2509 modules processed (25.54%) 01:05
62% done, no new fails 02:15
ugexe nice 02:25
[Coke] output_Test::Selector_zef:lucs_0.4.1_0 02:59
"No unspace allowed in regex; if you meant to match the literal^M" 03:01
"Fail, Bisected: 1a08ca762010ff035c3ee106c842464a68d301e6": 1, 03:02
1a08ca762010ff035c3ee106c842464a68d301e6 ?
linkable6 (2026-08-03) github.com/rakudo/rakudo/commit/1a08ca7620 Do not apply unspace to whitespace inside regexes
japhb ugexe++ # 94ae304e51 -- Holy moly, 40x is *huge*! 03:04
linkable6 (2026-08-15) github.com/rakudo/rakudo/commit/94ae304e51 Intern curried roles created by generic instantiation (#6567)
ugexe [Coke]: does it say what line? 03:05
[Coke] [Test::Selector] # at /home/coke/sandbox/blin/data/zef-data/tmp/6d1ca6b4c6990bb293ba310faaca1e4400a6674b.tar.gz/lib/Test/Selector.rakumod (Test::Selector):614^M 03:06
I can post the whole file, one sec.
github.com/coke/raku-blin-release-...cs_0.4.1_0 03:08
ugexe ah, module needs to be updated to be like / ^ \s* ok ' ' / || 03:16
m: say "ok x" ~~ /ok\ x/ 03:21
camelia ===SORRY!=== Error while compiling <tmp>
No unspace allowed in regex; if you meant to match the literal
character, please enclose in single quotes (' ') or use a backslashed
form like \x20.
at <tmp>:1
------> say "ok x" ~~ /ok\ <HERE>x/
ugexe m: say "okx" ~~ /ok \ x/
camelia ===SORRY!=== Error while compiling <tmp>
No unspace allowed in regex; if you meant to match the literal
character, please enclose in single quotes (' ') or use a backslashed
form like \x20.
at <tmp>:1
------> say "okx" ~~ /ok \ <HERE>x/
ugexe ah must have that commit
raku -e 'say "okx" ~~ /ok \ x/'
｢okx｣
which shows that if there was a space before unspace it wasn't erroring before when it should have 03:22
[Coke] 3 more failures 03:48
ugexe 3 of them are the same thing from the same source 03:52
Cro::FCGI is different though
did it bisect?
[Coke] 2 more fails, ⏳ 2240 out of 2509 modules processed (89.27%) 04:03
"Fail, Bisected: 1a08ca762010ff035c3ee106c842464a68d301e6": 4, "Fail, Bisected: 2b05993c58a7884f262f61cb81340e5ed58381b3": 1, "Fail, Bisected: 4b4af55da39bb255f1e540b869e16d338073698b": 1,
it's one of those
oh, wait 04:04
435:Cro::FCGI – Fail, Bisected: 4b4af55da39bb255f1e540b869e16d338073698b
which is a rakuast commit. maybe a false fail 04:05
ugexe github.com/lucs/Test-Selector/pull/3 04:10
man git.sr.ht does not like me... just trying to view some source code and it hits me with multi second bot detection proof of work for every page hit 04:13
Geth rakudo: ugexe++ created pull request #6569:
Let a boxed value reach a native-only multi candidate by unboxing		 04:21
07:37 lizmat joined
Geth rakudo/main: 0561c5c333 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Fixups.rakumod
The Hashray class is also an implementation detail
 08:28
09:13 lizmat left 09:14 lizmat joined
Geth rakudo/main: 7d95b754a8 | (Elizabeth Mattijsen)++ | src/core.c/Hash/Ordered.rakumod
Make Hash::Ordered.raku produce pairs in correct order
 09:14
09:19 lizmat left 10:45 sivoais left 13:05 Pixi left 13:06 Pixi joined
[Coke] 9 failures total, pushed 13:44
oooh. 13:46
Nifty. github.com/coke/raku-blin-release-...ng_0.1.5_0 13:47
actually reports it was killed by the OOM killer
That might make some flappers explainable.
and I can specifically rerun the OOM tests (since blin is running things under more pressure than solo) 13:50
timo I think with a `systemctl status blablablablablabla.service` or `.scope` or whatever you can also get the maxrss of something you ran with systemd-run, and also things like the total used CPU time and what-not 13:54
[Coke] timo: it's in the output
timo oh, that's there
nice
[Coke] e.g. github.com/coke/raku-blin-release-...cs_0.4.1_0 shows Memory peak: 1.3G (swap: 277.9M)
(and that was a success!) 13:55
CSS::Stylesheet, IntlPromptYesNo, Resend had OOM issues if someone want to open tickets for those. 13:56
those 3 all retested fine. 14:26
I'll open a blin ticket with the rest.
timo if we record the memory peak for modules, we can try using them in a future run to be a bit smarter with how we schedule multiple things at the same time 14:28
alternatively and/or additionally, re-run things killed by OOM on their own at the end of the run 14:29
[Coke] We have flap protection, could make it smarter. 14:33
I had been thinking of flapper support as bad, because it encourages tests that fail sometimes, but wasn't thinking about issues on the host machine running the test as opposed to a bad test. 14:34
also retesting the two that weren't regex unspace related. 14:35
Cro::FCGI seems ok on rerun (noted on ticket) 14:54
Geth rakudo: coke assigned to ugexe Issue blin issue 2026.08 run github.com/rakudo/rakudo/issues/6570
coke assigned to MasterDuke17 Issue blin issue 2026.08 run github.com/rakudo/rakudo/issues/6570
 15:01
[Coke] Wonder if some of the random failures are due to a whateverable lock on a checked out rakudo. 15:02
not checked out literally, but in use. Maybe it's just timing out trying to run a bisect and then giving us the wrong answer.
a5c48846b310c4e79e785b473f32dc928776d47f is a broken archive, per Whateverable 15:08
linkable6 (2026-08-07) github.com/rakudo/rakudo/commit/a5c48846b3 Make cmp compare collections by their values (#6517)
ugexe The net bgp one points at a nqp bump 15:13
[Coke] yes, rerunning now to make sure that's real. 15:14
during that it said your cmp commit wasn't a real archive, so couldn't test it.
rerun brought it to the same commit (MasterDuke) 15:15
ugexe It does use that nativehelpers distribution I think l which does a bunch of hacky stuff that isn’t fully gc friendly 15:16
15:17 sjn left
[Coke] thought I had dialed down flap protection, but blin is still using 4 runs to check a flapper 15:20
| AlwaysFail | 728 | ⋯ | from the recent full run
15:24 sjn joined
[Coke] eventually want to go through that list and open tickets/skip those. 15:35
Maybe I can finally get to work on JSON::Class now that it doesn't take 13 hours to do a run) 15:36
15:38 sjn left 15:40 sjn joined
ugexe fwiw it installs fine for me 15:40
plan :skip-all("Non-Linux Host") unless $*KERNEL.name eq 'linux'; 15:49
guess that would explain why
"It's a latent double-close bug in TCP::LowLevel, not a rakudo regression — the nursery commit just moved GC timing enough to make it land inside a test."
it has two finalizers that try to close the same socket 15:50
15:52 guifa left 15:53 guifa joined 16:02 finanalyst joined
ugexe github.com/jmaslak/Raku-TCP-LowLevel/pull/2 16:04
16:32 Geth left, Geth joined 16:42 committable6 left 16:43 committable6 joined 16:44 evalable6 left, evalable6 joined 16:46 tellable6 left, tellable6 joined 17:43 bisectable6 left, bisectable6 joined
ugexe "IntlPromptYesNo's blin OOM isn't a rakudo bug — its test is just use Intl::Prompt::YesNo, which pulls in Intl::CLDR (122 modules) uncompiled, and rakudo precompiles each uncompiled dep by spawning a child rakudo that stays resident while its own deps spawn grandchildren, so you get ~12 nested rakudo procs at ~220MB each = 2.5G (I reproduced 2581MB locally, matching the log exactly). Same on 17:59
RakuAST (2605MB), and coke's REDO.md already notes it passes on a solo rerun."
18:10 donaldh left 18:15 finanalyst left
ugexe github.com/rakudo/rakudo/blob/94ae...#L367-L383 uses 12 procs with 2592 MB rss. if it does a topological sort it goes down to 6 procs and 1176 MB rss. however the topological sort is based on just grepping the code for use/need which is a bit naive... not sure how we'd do it The Right Way 18:19
The other thing is raku -e '' alone is 163 MB, and each level of the process chain is ~225 MB. So ~75% of every level is fixed CORE.setting + compiler baseline and not from the module being compiled. 18:20
18:37 lizmat joined 18:56 sjn left 18:57 sjn joined 18:59 finanalyst joined
timo at the very least some files are mmapped instead of read, so are eligible for being shared between processes 19:24
but of course we do deserialize stuff out of these files into live objects that live on the heap, those can not be shared 19:25
maybe it'd be worth looking at in-process precomp again; maybe processes that already got spawned in order to precompile dependencies should try to precompile without launching child processes? 19:28
ugexe i don't see how in-process precomp could ever work 19:29
compilation mutates process global state 19:30
timo anything in particular you think is problematic? we would have to work on making the state in question be correctly clearable / resettable 19:33
japhb ugexe: How much of that was improved by getting rid of $*W? 19:34
ugexe SC repossession 19:37
augmenting core types 19:38
japhb: how much of what was improved?
japhb ugexe: "compilation mutates process global state" -- my (admittedly very old) understanding is that $*W was a large chunk of that compilation-related global state, but I have no idea what fraction it was of the overall problem. 19:40
ugexe i think $*W would cause problems moreso because it touches global state. and $*W isn't exactly going away in rakuast... rakuast has $*R which also pokes at global state 19:45
19:48 sjn left 19:50 sjn joined
timo the thing in $*W is an instance of Perl6::World; we should be storing stuff only in its instance, not the class itself, so making a fresh World should give us some amount of freshness already 19:51
I guess we want an op that kicks compunits completely out of memory, as deeply as needed 19:52
could be complicated
I guess you can mixin to stuff relatively deep into the metamodel 19:53
though repossession should mean we actually have kind of a "record" of what has been changed in other SCs 19:54
ugexe the main reason I don't think it can work is repossession. `augment class Int` moves Int's STable out of CORE's SC into whatever compunit is compiling, 19:57
and if we do that in process that will ultimately end up with the wrong sc_id
20:00 lizmat left
20:48 finanalyst left 20:54 sivoais joined
ugexe we could get like 6mb if we didnt eager load the legacy frontend under rakuast 21:11
timo yeah I had a tentative patch for that for a moment 21:17
github.com/rakudo/rakudo/commit/82...26d17ec0be 21:19
21:50 kurahaupo left, kurahaupo joined
Geth rakudo/main: 050230cb27 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
RakuAST: intern the Callable mixin for constant return values (#6571)

Previously a routine with a constant return value such as `--> ''` mixed a Callable parameterized with the literal value itself into the routine. Parameterizations intern by argument identity, so every distinct literal produced its own curried Callable, mixin type, and mixin cache type. In the core setting this serialized several hundred ... (9 more lines)		 21:57
rakudo: ugexe++ created pull request #6572:
RakuAST: name stub packages without their container		 22:04
rakudo: ugexe++ created pull request #6573:
Share the revision gate mixin across gated routines		 22:16
[Coke] ok - one week out to release. Anything we're trying to get merged before then? 22:17
Need to test reverting the nursery size on a branch and see if that fixes Net::BGP 22:25
ugexe github.com/jmaslak/Raku-TCP-LowLevel/pull/2 22:27
that fixes it
changing the nursery size just tickled it out since it was relying on two different DESTROY methods to close a socket in a racey way 22:28
s/that fixes it/that fixes Net::BGP/ 22:29
if you reran it enough times it would presumably work 22:31
[Coke] 4 not enough. :) 22:38
OK - so patches for all impacted modules out there, so not a release blocker. 22:39
ugexe++

Powered by Cro and the Raku® Programming Language.

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

Thank you!