00:40 librasteve_ left 09:27 librasteve_ joined
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:29
case in point: a call to sprintf("--%s--", "foo") change to the WVal "--foo--" 11:30
Geth Blin/rc: 463102727d | (Will Coleda)++ | docker/README.md
build an rc image?
13:22
[Coke] Anyone know "Claudio Ramirez" ? 13:30
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:32
guessing we should switch to using a builtin github action for that. 13:36
lizmat [Coke]: that's El_Che 13:38
[Coke] ahhhhhh 13:41
16:28 MasterDuke joined
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. github.com/rakudo/rakudo/pull/6125
2026-05-09T19:24:44Z #raku-dev <ugexe> MasterDuke: it looks like the begin and end phasers are getting wrapped by the loop
Geth nqp/main: 44edcdb298 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get getenv fix, MasterDuke++
18:20
lizmat MasterDuke: I guess it would allow stage optimize to work better, because it can then depend on "local" knowledge 18:29
Geth rakudo/main: af66caff12 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get getenv fix, MasterDuke++
18:30
nqp/main: 63b8898a0b | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to restore mod_I optimization, MasterDuke++
19:56
rakudo/main: 9e649f705f | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to restore nqp::mod_I optimization, MasterDuke++
20:03
rakudo/main: df18dda438 | (Nick Logan)++ (committed using GitHub Web editor) | 2 files
EVAL: bridge AST EVAL to outer Perl6::World during legacy precomp (#6176)

When a runtime RakuAST::Node.EVAL fires from inside a precompiling module's mainline whose outer compile uses the legacy frontend (the default when RAKUDO_RAKUAST is unset), the AST EVAL mints a fresh ephemeral SC named EVAL_<n>. The consumer's serializer captures references to the EVAL'd Sub via the producer's stash, records EVAL_<n> ... (27 more lines)
20:04
lizmat and Astro::Utils passes! 20:05
it feels to me that we could make RakuAST the default *after* the 2026.05 release 20:06
MasterDuke i think we need to get its performance at least on par with legacy 20:07
lizmat so you're saying we should get static optimizations in place already before making it the default ? 20:08
could we at least make it the default if a build option was set ?
anyways, thoughts, thoughts after a long day... going afk for some R&R 20:09
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:10
but i have no objection to making it easy to opt in to build with it 20:11
Geth rakudo: MasterDuke17++ created pull request #6177:
Simplify Int multi for infix:<%>
20:15
MasterDuke [Coke]: btw, i wouldn't mind access to those snyk reports 20:21
21:33 MasterDuke left
Geth rakudo/main: 13fcc50e71 | MasterDuke17++ (committed using GitHub Web editor) | src/core.c/Int.rakumod
Simplify Int multi for infix:<%> (#6177)

Now that Rakudo and NQP have been bumped to pick up
  github.com/MoarVM/MoarVM/pull/1989, the "manual"
optimization/fix for actually-small Ints is no longer needed.
21:55
[Coke] .tell masterduke snyk invite sent 23:36
tellable6 [Coke], I'll pass your message to MasterDuke