[00:40] *** librasteve_ left
[09:27] *** librasteve_ joined
[11:29] <lizmat> now that default RakuAST is drawing near, I was wondering about a (subroutine) trait that would specify code to be run at CHECK time to optimize a call site for that subroutine

[11:30] <lizmat> case in point:  a call to sprintf("--%s--", "foo")   change to the WVal  "--foo--"

[13:22] <Geth> ¦ Blin/rc: 463102727d | (Will Coleda)++ | docker/README.md

[13:22] <Geth> ¦ Blin/rc: build an rc image?

[13:22] <Geth> ¦ Blin/rc: review: https://github.com/Raku/Blin/commit/463102727d

[13:30] <[Coke]> Anyone know "Claudio Ramirez" ?

[13:32] <[Coke]> Looks like he added a .travis.yml file to blin in 2019 which isn't doing anything, presumably because the repo got moved to raku/ org at some point.

[13:36] <[Coke]> guessing we should switch to using a builtin github action for that.

[13:38] <lizmat> [Coke]: that's El_Che

[13:41] <[Coke]> ahhhhhh

[16:28] *** MasterDuke joined
[16:29] <MasterDuke> lizmat: how would that be different than the not-yet-existing `--stage=optimize` for RakuAST?

[16:29] <tellable6> 2026-05-09T04:32:24Z #raku-dev <ugexe> MasterDuke: nah i've just been focused on getting things to work, although i do look at optimization stuff if it is blocking me, e.g. https://github.com/rakudo/rakudo/pull/6125

[16:29] <tellable6> 2026-05-09T19:24:44Z #raku-dev <ugexe> MasterDuke: it looks like the begin and end phasers are getting wrapped by the loop

[18:20] <Geth> ¦ nqp/main: 44edcdb298 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION

[18:20] <Geth> ¦ nqp/main: Bump MoarVM to get getenv fix, MasterDuke++

[18:20] <Geth> ¦ nqp/main: review: https://github.com/Raku/nqp/commit/44edcdb298

[18:29] <lizmat> MasterDuke: I guess it would allow stage optimize to work better, because it can then depend on "local" knowledge

[18:30] <Geth> ¦ rakudo/main: af66caff12 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION

[18:30] <Geth> ¦ rakudo/main: Bump NQP to get getenv fix, MasterDuke++

[18:30] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/af66caff12

[19:56] <Geth> ¦ nqp/main: 63b8898a0b | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION

[19:56] <Geth> ¦ nqp/main: Bump MoarVM to restore mod_I optimization, MasterDuke++

[19:56] <Geth> ¦ nqp/main: review: https://github.com/Raku/nqp/commit/63b8898a0b

[20:03] <Geth> ¦ rakudo/main: 9e649f705f | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION

[20:03] <Geth> ¦ rakudo/main: Bump NQP to restore nqp::mod_I optimization, MasterDuke++

[20:03] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/9e649f705f

[20:04] <Geth> ¦ rakudo/main: df18dda438 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files

[20:04] <Geth> ¦ rakudo/main: EVAL: bridge AST EVAL to outer Perl6::World during legacy precomp (#6176)

[20:04] <Geth> ¦ rakudo/main: 

[20:04] <Geth> ¦ rakudo/main: When a runtime RakuAST::Node.EVAL fires from inside a precompiling

[20:04] <Geth> ¦ rakudo/main: module's mainline whose outer compile uses the legacy frontend (the

[20:04] <Geth> ¦ rakudo/main: default when RAKUDO_RAKUAST is unset), the AST EVAL mints a fresh

[20:04] <Geth> ¦ rakudo/main: ephemeral SC named EVAL_<n>. The consumer's serializer captures

[20:04] <Geth> ¦ rakudo/main: references to the EVAL'd Sub via the producer's stash, records EVAL_<n>

[20:04] <Geth> ¦ rakudo/main: <…commit message has 27 more lines…>

[20:04] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/df18dda438

[20:05] <lizmat> and Astro::Utils passes!

[20:06] <lizmat> it feels to me that we could make RakuAST the default *after* the 2026.05 release

[20:07] <MasterDuke> i think we need to get its performance at least on par with legacy

[20:08] <lizmat> so you're saying we should get static optimizations in place already before making it the default ?

[20:08] <lizmat> could we at least make it the default if a build option was set ?

[20:09] <lizmat> anyways, thoughts, thoughts   after a long day...     going afk for some R&R

[20:10] <MasterDuke> i just think if someone follows the default build instructions and gets a rakudo that's ~25% slower than they are used to they'll complain

[20:11] <MasterDuke> but i have no objection to making it easy to opt in to build with it

[20:15] <Geth> ¦ rakudo: MasterDuke17++ created pull request #6177: Simplify Int multi for infix:<%>

[20:15] <Geth> ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/6177

[20:21] <MasterDuke> [Coke]: btw, i wouldn't mind access to those snyk reports

[21:33] *** MasterDuke left
[21:55] <Geth> ¦ rakudo/main: 13fcc50e71 | MasterDuke17++ (committed using GitHub Web editor) | src/core.c/Int.rakumod

[21:55] <Geth> ¦ rakudo/main: Simplify Int multi for infix:<%> (#6177)

[21:55] <Geth> ¦ rakudo/main: 

[21:55] <Geth> ¦ rakudo/main: Now that Rakudo and NQP have been bumped to pick up

[21:55] <Geth> ¦ rakudo/main: https://github.com/MoarVM/MoarVM/pull/1989, the "manual"

[21:55] <Geth> ¦ rakudo/main: optimization/fix for actually-small Ints is no longer needed.

[21:55] <Geth> ¦ rakudo/main: review: https://github.com/rakudo/rakudo/commit/13fcc50e71

[23:36] <[Coke]> .tell masterduke snyk invite sent

[23:36] <tellable6> [Coke], I'll pass your message to MasterDuke