[00:00] <ugexe> i.e. a rakuast bug

[00:03] <ugexe> otherwise it works

[00:05] <Geth> ¦ rakudo: ugexe++ created pull request #6226: RakuAST: default object hash value type to Any when no explicit type is given

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

[00:34] <japhb> Ah, thanks for taking a look!

[00:35] <japhb> Looks like my problem with MUGS-Core and Red begins at: 5c37ccea1 - Initial completion of what became the Great QuantHash Refactor (4 weeks ago) <Elizabeth Mattijsen>

[00:35] <japhb> Actual error is:

[00:35] <japhb> Type check failed in binding to parameter 'key'; expected Attribute but got Str ("\%!___COLUMNS_DATA___")

[00:35] <japhb> at /home/geoff/foss/git/MUGS/MUGS-Core/site#sources/585CBDC6402A5D00B076838C1C3D4DE64EA5D5EC (MUGS::Server::Storage::Driver::Red::SQLite::IdentitySchema):25

[00:36] <japhb> I'm going to try against actual Rakudo HEAD (I'd been bisecting within the 2026.04 and 2026.05 range) to see if it's still there

[00:37] <Geth> ¦ rakudo: ugexe++ created pull request #6227: RakuAST: drop `:D` from the element type when parameterising a sigil role

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

[00:52] <japhb> Woah, HEAD fails relatively early in my stack trying to test Crane (which is a dependency of Config::TOML, the thing I was actually trying to install at that point in my script).

[00:52] <japhb> Going to retry to see if it's a flapper

[01:13] <japhb> Nope, not a flapper.  Failures in Crane's t/list.rakutest - looks like a couple variants of an extra itemization layer.  For example:

[01:13] <japhb> [Crane]     # expected: $({:path($[0]), :value("zero")}, {:path($[1]), :value("one")}, {:path($[2]), :value("two")})

[01:13] <japhb> [Crane]     #      got: $(${:path($[2]), :value("two")}, ${:path($[1]), :value("one")}, ${:path($[0]), :value("zero")})

[01:14] <japhb> Oh, and it appears to have reversed the elements as well, hmmm.

[01:15] <japhb> Exact same module list known to have worked at rakudo-moar-2026.04-60-gf2273bf17a (which was the last Rakudo commit that worked for *every* module in my stack)

[01:29] <Geth> ¦ rakudo: ugexe++ created pull request #6228: Default object hash value type to Mu under 6.e, Any otherwise

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

[01:32] <ugexe> re CBOR::Simple, you'll want to add use v6.d since in v6.e we'll switch to the behavior the was breaking CBOR::Simple with RAKUDO_RAKUAST=1 since the new behavior does actually make sense to switch to

[01:32] <ugexe> but for now it'll work after the above PR

[01:40] <ugexe> re Crane: one issue is https://github.com/rakudo/rakudo/commit/ee30c34ff

[01:40] <ugexe> Map/Hash also do Iterable, and their iteration order isn't deterministic, so Hash cmp Hash is now unstable

[01:59] <japhb> ugexe: Yeah, makes sense about Hash cmp Hash being unstable.  Did you see what commit caused the elements to be itemized?

[02:01] <japhb> As for CBOR::Simple, I'm not sure whether I prefer doing `use v6.d` to freeze it at the old semantics, or `use v6.e` and make necessary changes.  Probably the latter if I can use a syntax that works for all the `v6.e.PREVIEW` releases.

[02:04] <ugexe> it is probably a red herring

[02:05] <ugexe> like how .raku renders scalars

[02:06] <ugexe> yeah if you can make changes that work on both that could be more ideal. i didn't look into what actual changes you'd need to make, so i can't comment on how correct that might be

[02:10] <ugexe> i did see it mention something about making a distinction between Any and Mu, so it might not be easy

[02:18] <japhb> One of the things I like about CBOR is the care it takes with undefinedness and similar concepts, so I'll have to be careful, yeah.

[02:18] <japhb> (SO much closer to Raku's understanding of same than most other data formats)

[05:55] *** vrurg_ left
[06:10] *** vrurg joined
[07:50] *** lizmat_ left
[07:50] *** lizmat joined
[08:13] <Geth> ¦ rakudo/lizmat-10: a51dbdaa53 | (Elizabeth Mattijsen)++ | src/Raku/ast/package.rakumod

[08:13] <Geth> ¦ rakudo/lizmat-10: RakuAST: test whether some syntax issue is causing breakage

[08:13] <Geth> ¦ rakudo/lizmat-10: 

[08:13] <Geth> ¦ rakudo/lizmat-10: Mostly done to also force another CI run

[08:13] <Geth> ¦ rakudo/lizmat-10: review: https://github.com/rakudo/rakudo/commit/a51dbdaa53

[09:00] *** shareable6 left
[09:03] *** shareable6 joined
[09:06] <Geth> ¦ rakudo/lizmat-10: 03f7535d1f | (Elizabeth Mattijsen)++ | src/Raku/ast/package.rakumod

[09:06] <Geth> ¦ rakudo/lizmat-10: RakuAST: fix various issues in accessor generation

[09:06] <Geth> ¦ rakudo/lizmat-10: 

[09:06] <Geth> ¦ rakudo/lizmat-10: - [0] doesn't work, use .head

[09:06] <Geth> ¦ rakudo/lizmat-10: - $name.split("::") is too soo, use nqp::split("::",$name)

[09:06] <Geth> ¦ rakudo/lizmat-10: - remove check for unknown traits, they will be caught elsewhere

[09:06] <Geth> ¦ rakudo/lizmat-10: 

[09:06] <Geth> ¦ rakudo/lizmat-10: This brings the build already quite a bit further!

[09:06] <Geth> ¦ rakudo/lizmat-10: review: https://github.com/rakudo/rakudo/commit/03f7535d1f

[09:42] *** librasteve_ joined