00:04 librasteve_ left
ugexe m: for 1 { $ = sub { say 1 }() R, sub { say 2 }() } 00:20
evalable6 2
1
ugexe just so im clear, should we consider the order of evaluation of that as what rakuast should do? it current prints 1 2 00:21
rakuast does reverse the values returned 00:22
it is just a matter of if we have a expected evaluation order 00:23
01:05 kjp left 01:23 kjp joined
ugexe m: sub b(int $p is rw) { say "b: $p" }; sub a(int $p is rw) { b(++$p) }; my int $v = 5; a($v); say "v=$v" 01:37
evalable6 b: 6
v=6
ugexe m: sub b(Int $p is rw) { say "b: $p" }; sub a(Int $p is rw) { b(++$p) }; my Int $v = 5; a($v); say "v=$v" 01:38
evalable6 (exit code 1) Parameter '$p' expects a writable…
ugexe, Full output: gist.github.com/864c4cc8a575ff3f1f...c2068a7afc
ugexe why do we optimize int to a writable container but not e.g. Int?
it seems like the e.g. ++ subs should all be marked is rw but then that breaks roast tests 01:40
json::fast relies on that behavior, and i'm not really sure how to implement these type of optimizations just to paper over implementation impediance 01:42
in rakuast
github.com/rakudo/rakudo/commit/04791bfcf 01:44
makes it seem like a hack that he hoped spesh might obviate 01:45
04:52 apogee_ntv left 04:53 apogee_ntv joined 05:57 librasteve_ joined
lizmat ugexe: I wouldn't worry about things in Perl6/Optimizer at this point 07:29
also: with the optimize switched off in legacy, it also says 1,2 so it's the optimizer changing the order? 07:41
Geth nqp/main: f7ada3f160 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get alloc check fix, MasterDuke++
08:22
lizmat looks like the optimizer optimizes that to a WVal Array 08:31
Geth rakudo/main: 12e6f4dfcc | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get alloc check fix, MasterDuke++
08:33
lizmat ah, no, that'd be a golf 08:36
[Tux] Rakudo v2026.04-104-g12e6f4dfc (v6.d) on MoarVM 2026.04-26-gf2e25d78d
csv-ip5xs0.271 - 0.272
csv-ip5xs-201.074 - 1.093
csv-parser1.071 - 1.089
csv-test-xs-200.114 - 0.116
test1.780 - 1.807
test-t0.469 - 0.512
test-t --race0.297 - 0.311
test-t-206.169 - 6.357
test-t-20 --race1.394 - 1.521
10:03
csv-test-xs 0.016 - 0.018
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
timo do we know if Text::CSV works with rakuast already? does the tuxic slang need any changes for that? 10:12
[Tux] I do ot know. I have been rather detached from Raku 10:28
Geth nqp/snyk-upgrade-def3d5b7ede9f6cfa22dcb6dddae6b3a: 4b71d0b8ef | snyk-bot++ | nqp-js-on-js/package.json
fix: upgrade nqp-runtime from 0.30.0 to 0.43.0

Snyk has created this PR to upgrade nqp-runtime from 0.30.0 to 0.43.0.
See this package in npm: nqp-runtime
See this project in Snyk:
  app.snyk.io/org/raku.org-default/p...upgrade-pr
10:46
nqp: coke++ created pull request #846:
[Snyk] Upgrade nqp-runtime from 0.30.0 to 0.43.0
lizmat timo: afaik Text::CSV uses Slang::Tuxic, which uses Slangify, and is thus ready fro RakuAST 10:53
timo [Tux] so that has been taken care of, at least at that level
if you know of a slang in the ecosystem that does not use Slangify yet, let me know :-) 10:54
[Tux] 👍