[00:10] <ugexe> maybe it isn't the modules fault... it doesnt use macros anywhere

[00:13] <Geth> ¦ rakudo: ugexe++ created pull request #6412: RakuAST: honor a version/auth constraint on `require`

[00:13] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6412

[00:14] <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:15] <ugexe> quite a prerequisite 

[00:16] <japhb> That's ... yeah

[00:31] <Geth> ¦ rakudo: ugexe++ created pull request #6413: Give the experimental macros flag a load-independent value

[00:31] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6413

[00:40] <ugexe> that fixes JSON::Class

[02:07] <Geth> ¦ rakudo: ugexe++ created pull request #6414: RakuAST: iterate a sunk `xx` result so its thunk runs

[02:07] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6414

[02:12] <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] <ugexe> patrickb debugger work so presumably we want to keep the new behavior)

[02:15] <ugexe> i think the next Blin run we'll be at 50-100 failures, probably closer to 100

[02:15] <ugexe> since like 50 are moarvm serialization errors

[02:29] <japhb> Do you have a link to the description of that?  I'm curious about that problem.

[02:35] *** ShimmerFairy left
[02:41] <ugexe> https://gist.github.com/ugexe/8850ae245f4d3803771e04fca69e3b67

[02:41] <ugexe> https://gist.github.com/ugexe/4a45378fc45c91a7a79aa1634cdc7acf

[02:41] <ugexe> those are the reproductions with some description of what is potentially going on

[02:43] *** ShimmerFairy joined
[02:43] <ugexe> https://github.com/ugexe/MoarVM/commits/ugexe/cross-sc-parameterized-recipe/ you can look at the two latest commits on my moarvm fork from a couple months back that have more details

[03:11] *** guifa_ left
[03:29] <japhb> Any particular reason https://github.com/raku-community-modules/NativeHelpers-Blob/pull/1 can't be merged?

[03:43] <japhb> Nice repro scripts in your gists.  I'm guessing based on style these are Claude-assisted?

[04:05] <japhb> 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.  :-)

[05:11] <patrickb> ugexe: The debugger only looks at the basename in $?FILE.

[05:12] <patrickb> ugexe: So I'm pretty neutral wrt rel or abs.

[05:12] <patrickb> Is this possibly about reproducibility?

[05:16] *** guifa left
[05:19] *** guifa joined
[10:19] <patrickb> lizmat: Do you know more about this? Does $?FILE end up in the byte code?

[10:20] <lizmat> it codegens as a WVal afaik, so yes

[10:21] <patrickb> OK. I'd say that's enough reason to make it not be a full path.

[10:22] <lizmat> raku -e '$?FILE' qasts to:

[10:22] <lizmat> - QAST::Stmt <sunk final> $?FILE

[10:22] <lizmat>     │   │       - QAST::Want <sunk> :statement_id<1>

[10:22] <lizmat>     │   │         - QAST::WVal(Str) <sunk>

[10:22] <lizmat>     │   │         - Ss

[10:22] <lizmat>     │   │         - QAST::SVal(-e) <sunk>

[10:22] <patrickb> From the debugger's perspective it'd be fine for it to only be a basename, so with no path at all.

[10:24] <lizmat> well, pretty sure that would break some code, so changing that would have to be a language level change

[10:25] <lizmat> rakkable: eco-provides $?FILE

[10:25] <rakkable> lizmat, Running: eco-provides $?FILE, please be patient!

[10:25] <rakkable> lizmat, Found 33 lines in 24 files (20 distributions):

[10:25] <rakkable> lizmat, https://gist.github.com/3afb26648b2f28c93efa128b0009e7cd

[10:33] *** apogee_ntv joined
[10:52] *** guifa_ joined
[11:23] *** guifa_ left
[12:46] <ugexe> Whatever is broken is presumably fine in rakuast so I don’t know why we’d need a language level change 

[12:46] <ugexe> Er, fine in legacy 

[13:21] <patrickb> I guess it's an unrelated finding.

[13:22] <patrickb> FILE is trimmed by CWD. Will that always be reproducible?

[13:22] <patrickb> If not we'll need to find a different solution.

[13:49] <ugexe> https://github.com/coke/raku-ast-blin-results/blob/main/output_P5readlink_0.0.10

[13:49] <ugexe> https://github.com/coke/raku-ast-blin-results/blob/main/output_LogP6_1.6.4

[13:49] <ugexe> those are two examples that are currently broken in rakuast

[14:17] <ugexe> https://github.com/rakudo/rakudo/commit/840e3eaf5

[14:17] <ugexe> that is what changed the behavior

[14:17] <ugexe> in rakuast only

[14:43] *** finanalyst joined
[16:10] <Geth> ¦ rakudo: ugexe++ created pull request #6415: RakuAST: resolve `$?FILE` at parse time so it matches legacy

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

[16:11] <ugexe> i *think* that solves the problem i described while still addressing what https://github.com/rakudo/rakudo/commit/840e3eaf5 and https://github.com/rakudo/rakudo/commit/313dfb7df0fdb3d527125f4642100dd8051d8957 meant to fix

[16:25] <ugexe> 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:28] <ugexe> 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:47] <japhb> Yeah, I checked the NH-B CI, and the Windows CI has been failing since it was added in the first place.

[16:48] <japhb> So probably worth merging the NH-B PR.

[16:48] <japhb> And it sounds like your MoarVM fork should be merged back as well, because that's a lot of testing right there.

[16:51] <japhb> 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] <japhb> Er ... that was meant to be a question, as in, is there anything other than 1,2,5 left causing problems?

[16:53] <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:54] <ugexe> 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] <ugexe> for example Red is marked as always failure, but i think we'd want that to work

[17:06] *** guifa left
[17:06] *** guifa_ joined
[17:22] <[Coke]> Many of those (including red) are because blin can't tell the difference between JSON::Class and JSON::Class

[17:23] <[Coke]> 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] <[Coke]> (for just-regular-blin, not ast-check-blin)

[17:34] <ugexe> any idea what its doing those first 10m?

[18:00] <[Coke]> Haven't dug back in in a while, no.

[18:01] <[Coke]> 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

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

[18:22] <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

[19:05] *** finanalyst left
[20:04] *** jdv left
[20:55] <[Coke]> Roger.

[20:55] <[Coke]> Ugh, need to make blin faster so it chews less azure.

[21:02] *** Pixi` joined
[21:06] *** Pixi left
[21:17] <japhb> Are you optimizing for wall clock or core-seconds?

[21:18] *** guifa joined
[21:18] <[Coke]> ah. the slowness is in the zef update command itself.

[21:18] <[Coke]> japhb: dollars spent at end of month

[21:19] <[Coke]> /home/azureuser/raku/bin/rakudo -I data/zef data/zef/bin/zef --config-path=data/zef-config.json update

[21:20] <[Coke]> that immediately outputs updating fez, rea mirrors, updated rea/fez mirrors... then hangs.

[21:23] *** finanalyst joined
[21:26] <[Coke]> well, maybe not hang, but doesn't output anything else. 

[21:27] *** finanalyst left
[21:28] <[Coke]> still waiting. have a before and after time will paste it here when the command completes.

[21:29] *** shareable6 left
[21:30] <[Coke]> almost 10m exactly

[21:30] <[Coke]> 2026-07-10T21:19:38.003909 to mirror: https://360.zef.pm/

[21:30] <[Coke]> 2026-07-10T21:29:35.513747Z

[21:32] *** shareable6 joined
[21:36] <[Coke]> running on Rakudo™ v2025.05-42-gab0231a00.

[21:39] <ugexe> given the default fetch timeout in zef is 10 minutes i'm not surprised

[21:41] *** guifa left
[21:52] <[Coke]> timing out fetching rea maybr?

[21:55] <[Coke]> adding --verbose doesn't show me anything.

[21:57] <[Coke]> er, nor rea. I see:

[21:57] <[Coke]> ===> Updating fez mirror: https://360.zef.pm/

[21:57] <[Coke]> ===> Updating rea mirror: https://raw.githubusercontent.com/Raku/REA/main/META.json

[21:57] <[Coke]> ===> Updated rea mirror: https://raw.githubusercontent.com/Raku/REA/main/META.json

[21:57] <[Coke]> ===> Updated fez mirror: https://360.zef.pm/

[22:00] <[Coke]> nothing with --debug...

[22:00] <ugexe> --debug does take a bit longer because it calculates totals at the end

[22:00] <ugexe> but we're talking like 10 seconds maybe? not even

[22:09] <[Coke]> https://gist.github.com/coke/c2bf000894b87dfb23c0468176dd1161 is blin's zef config

[23:29] <ugexe> looks fine. `zef update` doesn't actually do too much, especially after its already printed "===> Updated ..."

[23:30] <ugexe> https://github.com/ugexe/zef/blob/0aa54f53b55662d3a7a3b89981d34b9de97422f1/lib/Zef/Repository/Ecosystems.rakumod#L123-L143

[23:30] <ugexe> thats the work loop, and you can see the message is emited with KEEP so the loop has finished

[23:32] <ugexe> https://github.com/ugexe/zef/blob/main/lib/Zef/CLI.rakumod#L1013-L1014 -> https://github.com/ugexe/zef/blob/0aa54f53b55662d3a7a3b89981d34b9de97422f1/lib/Zef/Repository.rakumod#L196-L206 -> https://github.com/ugexe/zef/blob/main/lib/Zef/Repository/Ecosystems.rakumod#L101-L115

[23:32] <ugexe> thats the call stack roughly

[23:32] <ugexe> could put a few debug prints in there to get an idea of where its getting hung up

[23:33] <ugexe> you could also try like

[23:34] <ugexe> `zef update rea` to do a single ecosystem to see if that has any effect for some reason

[23:36] <Geth> ¦ rakudo/main: 1dac18181e | (Nick Logan)++ | src/Raku/ast/scoping.rakumod

[23:36] <Geth> ¦ rakudo/main: RakuAST: bind package symbols via the stash, not its storage hash

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

[23:36] <Geth> ¦ rakudo/main: Previously IMPL-INSTALL-PACKAGE bound package symbols directly into the

[23:36] <Geth> ¦ rakudo/main: underlying storage hash of the target stash. The serialization write

[23:36] <Geth> ¦ rakudo/main: barrier only marks the object named in the write, and a stash's storage

[23:36] <Geth> ¦ rakudo/main: hash may be a fresh clone belonging to no serialization context, since

[23:36] <Geth> ¦ rakudo/main: Stash.merge-symbols clones and swaps the storage on every import merge.

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

[23:37] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/1dac18181e

[23:37] <Geth> ¦ rakudo/main: 51ac0d7600 | (Nick Logan)++ | 3 files

[23:37] <Geth> ¦ rakudo/main: RakuAST: adopt an imported stub package's WHO when declaring the package

[23:37] <Geth> ¦ rakudo/main: 

[23:37] <Geth> ¦ rakudo/main: Previously a package declaration whose name an import had already

[23:37] <Geth> ¦ rakudo/main: brought in as a stub (e.g. `use Cro::Message; class Cro { }`, where

[23:37] <Geth> ¦ rakudo/main: compiling Cro::Message auto-vivified a stub Cro) merged the stub's

[23:37] <Geth> ¦ rakudo/main: symbols into the declaration's own fresh WHO instead of adopting the

[23:37] <Geth> ¦ rakudo/main: stub's WHO. The stash upgrade in IMPL-INSTALL-PACKAGE intended to

[23:37] <Geth> ¦ rakudo/main: <…commit message has 16 more lines…>

[23:37] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/51ac0d7600

[23:37] <Geth> ¦ rakudo/main: e398c4eb9e | (Nick Logan)++ (committed using GitHub Web editor) | 3 files

[23:37] <Geth> ¦ rakudo/main: Merge pull request #6411 from ugexe/ugexe/rakuast-adopt-imported-stub-who

[23:37] <Geth> ¦ rakudo/main: 

[23:37] <Geth> ¦ rakudo/main: RakuAST: adopt an imported stub package's WHO when declaring the package

[23:37] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/e398c4eb9e