ugexe maybe it isn't the modules fault... it doesnt use macros anywhere 00:10
Geth rakudo: ugexe++ created pull request #6412:
RakuAST: honor a version/auth constraint on `require`		 00:13
ugexe "JSON::Class trips it because its roles are use v6.e.PREVIEW; use experimental :will-complain, precompiled, then loaded together with the core experimental module by a default-6.d test snippet." 00:14
quite a prerequisite 00:15
japhb That's ... yeah 00:16
Geth rakudo: ugexe++ created pull request #6413:
Give the experimental macros flag a load-independent value		 00:31
ugexe that fixes JSON::Class 00:40
Geth rakudo: ugexe++ created pull request #6414:
RakuAST: iterate a sunk `xx` result so its thunk runs		 02:07
ugexe i think i have fixed just about everything in the latest Blin run that can be fixed in rakuast. the things that are left are 1) uses $*W 2) relies on legacy slangs 3) use NativeHelpers::Blob (although I did open a PR to ""fix"" it) 4) moarvm serialization errors 5) uses Perl5 regex 6) relies on e.g. $?FILE not returning an absolute path (i didn't write this change, but i seem to recall it was for 02:12
patrickb debugger work so presumably we want to keep the new behavior)
i think the next Blin run we'll be at 50-100 failures, probably closer to 100 02:15
since like 50 are moarvm serialization errors
japhb Do you have a link to the description of that? I'm curious about that problem. 02:29
02:35 ShimmerFairy left
ugexe gist.github.com/ugexe/8850ae245f4d...fca69e3b67 02:41
gist.github.com/ugexe/4a45378fc45c...634cdc7acf
those are the reproductions with some description of what is potentially going on
02:43 ShimmerFairy joined
ugexe github.com/ugexe/MoarVM/commits/ug...ed-recipe/ you can look at the two latest commits on my moarvm fork from a couple months back that have more details 02:43
03:11 guifa_ left
japhb Any particular reason github.com/raku-community-modules/...lob/pull/1 can't be merged? 03:29
Nice repro scripts in your gists. I'm guessing based on style these are Claude-assisted? 03:43
Have you been using the MoarVM fork with cross-sc-parameterized-recipe for all of your work? If so, I'd say it's about as well tested as anything can be right now. :-) 04:05
patrickb ugexe: The debugger only looks at the basename in $?FILE. 05:11
ugexe: So I'm pretty neutral wrt rel or abs. 05:12
Is this possibly about reproducibility?
05:16 guifa left 05:19 guifa joined
patrickb lizmat: Do you know more about this? Does $?FILE end up in the byte code? 10:19
lizmat it codegens as a WVal afaik, so yes 10:20
patrickb OK. I'd say that's enough reason to make it not be a full path. 10:21
lizmat raku -e '$?FILE' qasts to: 10:22
- QAST::Stmt <sunk final> $?FILE
ā”‚ ā”‚ - QAST::Want <sunk> :statement_id<1>
ā”‚ ā”‚ - QAST::WVal(Str) <sunk>
ā”‚ ā”‚ - Ss
ā”‚ ā”‚ - QAST::SVal(-e) <sunk>
patrickb From the debugger's perspective it'd be fine for it to only be a basename, so with no path at all.
lizmat well, pretty sure that would break some code, so changing that would have to be a language level change 10:24
rakkable: eco-provides $?FILE 10:25
rakkable lizmat, Running: eco-provides $?FILE, please be patient!
lizmat, Found 33 lines in 24 files (20 distributions):
lizmat, gist.github.com/3afb26648b2f28c93e...8b0009e7cd
10:33 apogee_ntv joined 10:52 guifa_ joined 11:23 guifa_ left
ugexe Whatever is broken is presumably fine in rakuast so I donā€™t know why weā€™d need a language level change 12:46
Er, fine in legacy
patrickb I guess it's an unrelated finding. 13:21
FILE is trimmed by CWD. Will that always be reproducible? 13:22
If not we'll need to find a different solution.
ugexe github.com/coke/raku-ast-blin-resu...ink_0.0.10 13:49
github.com/coke/raku-ast-blin-resu...ogP6_1.6.4
those are two examples that are currently broken in rakuast
github.com/rakudo/rakudo/commit/840e3eaf5 14:17
that is what changed the behavior
in rakuast only
14:43 finanalyst joined
Geth rakudo: ugexe++ created pull request #6415:
RakuAST: resolve `$?FILE` at parse time so it matches legacy		 16:10
ugexe i *think* that solves the problem i described while still addressing what github.com/rakudo/rakudo/commit/840e3eaf5 and github.com/rakudo/rakudo/commit/31...d8051d8957 meant to fix 16:11
japhb: i don't think there is technically anything stopping it. there is a failing windows ci although i haven't looked at it but assume its unrelated to the change itself (im guessing something in the CI yaml needs to be updated, such as windows version). my only concern is the changes themselves seem fragile, but theoretically this should be less fragile than what it replaces. 16:25
i was using my moarvm fork for awhile, but stopped at some point awhile ago so i could reproduce issues from blin more accurately. i probably used it for 10% of my working/testing at this point, although thats likely 100+ core rebuilds and at least 50 spectest runs 16:28
japhb Yeah, I checked the NH-B CI, and the Windows CI has been failing since it was added in the first place. 16:47
So probably worth merging the NH-B PR. 16:48
And it sounds like your MoarVM fork should be merged back as well, because that's a lot of testing right there.
With those in, plus your latest Rakudo pull, that should leave only #1, #2, and #5 from your list of remaining issues posted last night. 16:51
Er ... that was meant to be a question, as in, is there anything other than 1,2,5 left causing problems?
ugexe the short answer is i dont think so. the longer answer is it depends what gets exposed after the open fixes since some things may have other issues that aren't reachable yet. in many cases i did fix such issues but i haven't personally tried all 50 distributions failing due to serialization 16:53
i suspect we'd also want to go through the list of modules Blin tests and look at the ones it ignores that we would still want to work 16:54
for example Red is marked as always failure, but i think we'd want that to work
17:06 guifa left, guifa_ joined
[Coke] Many of those (including red) are because blin can't tell the difference between JSON::Class and JSON::Class 17:22
Would be nice if the startup time wasn't nearly 10m, would make it easier to fix and test. I'll move that back to the top of the queue. 17:23
(for just-regular-blin, not ast-check-blin)
ugexe any idea what its doing those first 10m? 17:34
[Coke] Haven't dug back in in a while, no. 18:00
it's right after "downloading the ecosystem lists" 18:01
Geth rakudo: ugexe++ created pull request #6416:
RakuAST: give an attributive parameter its declaring package for the full binder
ugexe also worth mentioning that i will be out of the country from july 26 to aug 1 so i wont be available during that time to fix any blin failures for the next release 18:22
19:05 finanalyst left 20:04 jdv left
[Coke] Roger. 20:55
Ugh, need to make blin faster so it chews less azure.
21:02 Pixi` joined 21:06 Pixi left
japhb Are you optimizing for wall clock or core-seconds? 21:17
21:18 guifa joined
[Coke] ah. the slowness is in the zef update command itself. 21:18
japhb: dollars spent at end of month
/home/azureuser/raku/bin/rakudo -I data/zef data/zef/bin/zef --config-path=data/zef-config.json update 21:19
that immediately outputs updating fez, rea mirrors, updated rea/fez mirrors... then hangs. 21:20
21:23 finanalyst joined
[Coke] well, maybe not hang, but doesn't output anything else. 21:26
21:27 finanalyst left
[Coke] still waiting. have a before and after time will paste it here when the command completes. 21:28
21:29 shareable6 left
[Coke] almost 10m exactly 21:30
2026-07-10T21:19:38.003909 to mirror: 360.zef.pm/
2026-07-10T21:29:35.513747Z
21:32 shareable6 joined
[Coke] running on Rakudoā„¢ v2025.05-42-gab0231a00. 21:36
ugexe given the default fetch timeout in zef is 10 minutes i'm not surprised 21:39
21:41 guifa left
[Coke] timing out fetching rea maybr? 21:52
adding --verbose doesn't show me anything. 21:55
er, nor rea. I see: 21:57
===> Updating fez mirror: 360.zef.pm/
===> Updating rea mirror: raw.githubusercontent.com/Raku/REA.../META.json
===> Updated rea mirror: raw.githubusercontent.com/Raku/REA.../META.json
===> Updated fez mirror: 360.zef.pm/
nothing with --debug... 22:00
ugexe --debug does take a bit longer because it calculates totals at the end
but we're talking like 10 seconds maybe? not even
[Coke] gist.github.com/coke/c2bf000894b87...8176dd1161 is blin's zef config 22:09
ugexe looks fine. `zef update` doesn't actually do too much, especially after its already printed "===> Updated ..." 23:29
github.com/ugexe/zef/blob/0aa54f53...#L123-L143 23:30
thats the work loop, and you can see the message is emited with KEEP so the loop has finished
github.com/ugexe/zef/blob/main/lib...1013-L1014 -> github.com/ugexe/zef/blob/0aa54f53...#L196-L206 -> github.com/ugexe/zef/blob/main/lib...#L101-L115 23:32
thats the call stack roughly
could put a few debug prints in there to get an idea of where its getting hung up
you could also try like 23:33
`zef update rea` to do a single ecosystem to see if that has any effect for some reason 23:34
Geth rakudo/main: 1dac18181e | (Nick Logan)++ | src/Raku/ast/scoping.rakumod
RakuAST: bind package symbols via the stash, not its storage hash

Previously IMPL-INSTALL-PACKAGE bound package symbols directly into the underlying storage hash of the target stash. The serialization write barrier only marks the object named in the write, and a stash's storage hash may be a fresh clone belonging to no serialization context, since Stash.merge-symbols clones and swaps the storage on every import merge. ... (6 more lines)		 23:36
rakudo/main: 51ac0d7600 | (Nick Logan)++ | 3 files
RakuAST: adopt an imported stub package's WHO when declaring the package

Previously a package declaration whose name an import had already brought in as a stub (e.g. `use Cro::Message; class Cro { }`, where compiling Cro::Message auto-vivified a stub Cro) merged the stub's symbols into the declaration's own fresh WHO instead of adopting the stub's WHO. The stash upgrade in IMPL-INSTALL-PACKAGE intended to ... (16 more lines)
rakudo/main: e398c4eb9e | (Nick Logan)++ (committed using GitHub Web editor) | 3 files
Merge pull request #6411 from ugexe/ugexe/rakuast-adopt-imported-stub-who

RakuAST: adopt an imported stub package's WHO when declaring the package

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!