[00:31] *** apogee_ntv left
[00:33] *** apogee_ntv joined
[01:12] *** apogee_ntv left
[01:14] *** apogee_ntv joined
[01:58] *** apogee_ntv left
[03:09] *** hurufu joined
[04:04] *** hurufu left
[04:27] *** hurufu joined
[08:33] <Geth> ¦ rakudo/main: abf53a6061 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files

[08:33] <Geth> ¦ rakudo/main: RakuAST: streamline Nodify lookup (#6209)

[08:33] <Geth> ¦ rakudo/main: 

[08:33] <Geth> ¦ rakudo/main: Instead of calling .Nodify with name parts, always call it with a

[08:33] <Geth> ¦ rakudo/main: fully qualified class name as a string (minus the RakuAST:: part).

[08:33] <Geth> ¦ rakudo/main: This allows a simple cache to be built for these class lookups.

[08:33] <Geth> ¦ rakudo/main: 

[08:33] <Geth> ¦ rakudo/main: Also introduce a .Nodify method in the Grammar to more easily (and

[08:33] <Geth> ¦ rakudo/main: recognizable) places where class lookups are done.

[08:33] <Geth> ¦ rakudo/main: 

[08:33] <Geth> ¦ rakudo/main: This appears to take off about 1 second from stage parse of the

[08:33] <Geth> ¦ rakudo/main: c setting in RakuAST (33 -> 32 seconds), at least for me.

[08:33] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/abf53a6061

[09:18] <Geth> ¦ rakudo/lizmat-my-constant: 261 commits pushed by 7 authors

[09:18] <Geth> ¦ rakudo/lizmat-my-constant: review: https://github.com/rakudo/rakudo/compare/25f3f368975b...7ecd4f3930e5

[09:33] *** apogee_ntv joined
[09:46] *** apogee_ntv left
[09:47] *** apogee_ntv joined
[11:41] *** finanalyst joined
[12:08] *** apogee_ntv left
[12:09] *** apogee_ntv joined
[12:21] *** apogee_ntv left
[12:22] *** apogee_ntv joined
[13:55] <Geth> ¦ nqp/main: 7b4689531a | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION

[13:55] <Geth> ¦ nqp/main: Bump MoarVM to get mod fix

[13:55] <Geth> ¦ nqp/main: review: https://github.com/Raku/nqp/commit/7b4689531a

[14:04] <Geth> ¦ rakudo/main: 0870b473bb | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION

[14:04] <Geth> ¦ rakudo/main: Bump NQP to get mod fix

[14:04] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/0870b473bb

[14:10] <Geth> ¦ nqp/main: cd443ed8d8 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION

[14:10] <Geth> ¦ nqp/main: Bump MoarVM to get large string read fix, timo++

[14:10] <Geth> ¦ nqp/main: review: https://github.com/Raku/nqp/commit/cd443ed8d8

[14:13] <lizmat> I think this will help rak going through large files  :-)

[14:15] *** rakkable left
[14:15] *** rakkable joined
[14:18] <Geth> ¦ rakudo/main: 20b6c7456f | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION

[14:18] <Geth> ¦ rakudo/main: Bump NQP to get large string read fix, timo++

[14:18] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/20b6c7456f

[14:23] <[Coke]> I'll go ahead and pull the trigger on MoarVM 2026.05.1

[14:23] <[Coke]> er, press the button

[14:39] *** apogee_ntv left
[14:41] *** apogee_ntv joined
[14:49] <[Coke]> El_Che: you can probably try again in about 1m

[14:49] <[Coke]> er, 10m

[14:57] <[Coke]> MoarVM 2026.05.1 has been cut - its sole purpose is to let the older redhat OS release work, no need to update for anyone else.

[14:57] <[Coke]> The one commit in there is already on main.

[14:57] <[Coke]> El_Che: let me know if any issues.

[15:04] *** apogee_ntv left
[15:07] *** apogee_ntv joined
[15:13] *** apogee_ntv left
[15:14] *** apogee_ntv joined
[15:34] *** ntv joined
[15:35] *** apogee_ntv left
[15:45] *** ntv left
[15:46] *** apogee_ntv joined
[15:51] *** apogee_ntv left
[15:52] *** apogee_ntv joined
[16:01] <Geth> ¦ rakudo/lizmat-8: 4 commits pushed by (Elizabeth Mattijsen)++

[16:01] <Geth> ¦ rakudo/lizmat-8: 34f7561aa2 | RakuAST: streamline Nodify lookup (#6209)

[16:01] <Geth> ¦ rakudo/lizmat-8: f02c3bf97e | Bump NQP to get mod fix

[16:01] <Geth> ¦ rakudo/lizmat-8: dac90a1c3f | Bump NQP to get large string read fix, timo++

[16:01] <Geth> ¦ rakudo/lizmat-8: 6e9b92d539 | RakuAST: step two for codegenning POPULATE in every class

[16:01] <Geth> ¦ rakudo/lizmat-8: review: https://github.com/rakudo/rakudo/compare/ca0d8d6e95ce...6e9b92d53958

[16:02] <lizmat> ugexe would appreciate some eyes on 6e9b92d53958e786af7

[16:02] <lizmat> https://github.com/rakudo/rakudo/commit/6e9b92d53958e786af7

[16:26] *** apogee_ntv left
[16:59] *** apogee_ntv joined
[18:00] *** finanalyst left
[18:50] *** hurufu left
[19:29] <Geth> ¦ rakudo/lizmat-8: edaaa8b388 | (Elizabeth Mattijsen)++ | src/Raku/ast/package.rakumod

[19:29] <Geth> ¦ rakudo/lizmat-8: RakuAST: some small changes to go further in setting compilation

[19:29] <Geth> ¦ rakudo/lizmat-8: 

[19:29] <Geth> ¦ rakudo/lizmat-8: For some reason, it can't find infix:<,>, but I don't see where

[19:29] <Geth> ¦ rakudo/lizmat-8: that would be needed :-(

[19:29] <Geth> ¦ rakudo/lizmat-8: review: https://github.com/rakudo/rakudo/commit/edaaa8b388

[22:00] <patrickb> there won't be a rakudo 2026.05.1, correct?

[22:01] <patrickb> I'm asking, because the release pipeline works off of the release rakudo files on rakudo.org.

[22:03] <patrickb> I can create a custom release that that pulls in moar 2026.05.1 instead, but that's a bit unclean. Any opinions on what's best to do?

[22:05] <lizmat> it was the idea that there would only be a moarvm point release

[22:05] <lizmat> as its fix was only for some close to EOL OSes ?

[22:06] <patrickb> correct.

[22:07] <patrickb> only concern is that the rakudo release files explicitly list the moar revision to use. I'll change that reference there but will not change the version number.

[22:08] <patrickb> I guess no one will care, I just think it's worth a mention that I'll be lying a bit there.

[22:09] <lizmat> well.. unless you're packaging for such old OSes, you can go by what Rakudo 2026.05 specifies as a NQP/Moar dependency

[22:09] <patrickb> unrelated question, is GitHub.com/Raku/geth the real thing? (Last updated 5 years ago.)

[22:10] * lizmat checks

[22:10] *** Geth left
[22:10] <patrickb> the prebuilt releases that end up on rakudo.org are always built with such old releases. That bug is the reason there is no binary for Linux for 2026.05 there yet.

[22:10] *** Geth joined
[22:10] <patrickb> s/releases/oses/

[22:11] <lizmat> yeah, that's where Geth lives

[22:11] *** Geth left
[22:11] *** Geth joined
[22:11] <lizmat> I have some minor local changes

[22:12] <patrickb> The reason the binary releases use such old oses is because glibc is backwards, but not forwards compatible

[22:12] <patrickb> i.e. always pick the oldest glibc you want to support when building.

[22:13] <patrickb> I upgrade rarely, and always try to support the oldest release of the major distros.

[22:38] <[Coke]> patrickb: if your previous binaries worked, do not use the new moar.

[22:38] <[Coke]> I thought only el_che reported issues with the binaries they were creating. (and only one of those)

[22:39] <[Coke]> You can just skip 2026.05.1 if 2026.05 worked for you

[22:39] <[Coke]> then everything will sync up with 2026.06 next month

[22:39] <[Coke]> (centos 8, I think was the problem OS)