#raku-dev on 11 May 2026 - Raku Programming Language Log

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-ip5xs	0.271	-	0.272
csv-ip5xs-20	1.074	-	1.093
csv-parser	1.071	-	1.089
csv-test-xs-20	0.114	-	0.116
test	1.780	-	1.807
test-t	0.469	-	0.512
test-t --race	0.297	-	0.311
test-t-20	6.169	-	6.357
test-t-20 --race	1.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]

👍

12:01 disbot2 left 12:02 disbot3 joined

[Coke]

(nqp pr) it does highlight to me that we have PRs on NQP going back to 2018

13:04

ab5tract

:O

13:17

Geth

raku.org/snyk-upgrade-369f7a21bdcf...92f0b41f9: 03478ad0e8 | snyk-bot++ | 2 files
fix: upgrade @picocss/pico from 2.0.6 to 2.1.0

Snyk has created this PR to upgrade @picocss/pico from 2.0.6 to 2.1.0.
See this package in npm:
@picocss/pico
See this project in Snyk:
app.snyk.io/org/raku.org-default/p...upgrade-pr

13:42

raku.org: coke++ created pull request #317:
[Snyk] Upgrade @picocss/pico from 2.0.6 to 2.1.0

[Coke]

OHAI

13:56

Must have clicked some buttons in the snyk org this weekend.

no vulnerabilities here, just "hey, that's old"

13:58

removing scan for raku/rakudo-star, which appears to be archived. (should we delete it?)

16:31

ugexe

lizmat: re the optimizer what I'm struggling with are where non-optimizations have been applied, i.e. optmizations that change behavior

16:38

lizmat

well, there at least 8 locations in the spectest that have been TODOed by nine because they would only pass with the optimizer enabled

16:39

ugexe

i see

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"; my Int $v2 = 5; a($v2); say "v2=$v2"

16:43

evalable6

(exit code 1) b: 6
Internal error: inconsistent bind result
in sub a at /tmp/CfMd9M4ahu line 1
in block <unit> at /tmp/CfMd9M4ahu line 1

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"

16:45

evalable6

b: 6
v=6

ugexe

oh i see, the warning in my first one was inbetween the v:6 and v=6

error rather

16:46

i guess my question there is should Int $p work the same in that example?

or should int $p error like Int $p

lizmat

feels to me that ++$p is not a left value

16:49

m: my int $p; ++$p = 42

evalable6

(exit code 1) Cannot modify an immutable Int (1)
in block <unit> at /tmp/4bhMyfkbwL line 1

ugexe

yeah, but the problem then is that json::fast uses that. and json::fast is widely used and (presumably) widely pinned)

16:50

lizmat

then I guess we need to fix JSON::Fast

I doubt that many modules in the ecosystem would use similar hacks

16:51

ugexe

yeah, but any that pin json::fast needs to be updated

lizmat

rakkable: eco-provides="use JSON::Fast" --and="ver:"

16:59

rakkable

lizmat, Don't know how to handle 'eco-provides="use JSON::Fast" --and="ver:"'

lizmat

rakkable: eco-provides "use JSON::Fast" --and="ver:"

17:01

rakkable

lizmat, Running: eco-provides "use JSON::Fast" --and="ver:", please be patient!

lizmat, No occurrences found for: eco-provides "use JSON::Fast" --and="ver:"

lizmat

rakkable: eco-provides "use JSON::Fast" --and=":ver"

17:02

rakkable

lizmat, Running: eco-provides "use JSON::Fast" --and=":ver", please be patient!

lizmat, No occurrences found for: eco-provides "use JSON::Fast" --and=":ver"

lizmat

rakkable: eco-provides "use JSON::Fast" --and=:ver

rakkable

lizmat, Running: eco-provides "use JSON::Fast" --and=:ver, please be patient!

lizmat, No occurrences found for: eco-provides "use JSON::Fast" --and=:ver

lizmat

rakkable: eco-provides JSON::Fast --and=:ver

rakkable

lizmat, Running: eco-provides JSON::Fast --and=:ver, please be patient!

lizmat, Found 19 lines in 19 files (18 distributions):

lizmat, gist.github.com/a5cb8a39f68d7b85ef...a17fe0621b

lizmat

rakkable: eco-provides JSON::Fast --and=:ver --and-not=+>

17:03

rakkable

lizmat, '--and-not' argument not allowed / unknown: ignored

lizmat, Running: eco-provides JSON::Fast --and=:ver, please be patient!

lizmat, Found 19 lines in 19 files (18 distributions):

lizmat, gist.github.com/c0edef8e43dab967ae...6ab17924df

lizmat

rakkable: eco-provides JSON::Fast --and=:ver --andnot=+>

rakkable

lizmat, Running: eco-provides JSON::Fast --and=:ver --andnot=+>, please be patient!

ugexe

looks like it doesn't search meta files?

rakkable

lizmat, Found 5 lines in 5 files (5 distributions):

lizmat, gist.github.com/d5c851113e6f77e37e...9246fd6852

lizmat

looks like there are 5 modules in the ecosystem that have a pinned version of JSON::Fast

17:04

ugexe

im skeptical, i see no references from meta6.json files

lizmat

one of which is a false positive, as it is JSON::Fast itself

well... the META6.json file is only an indication, the actual code will make or break execution

17:05

ugexe

no the module installation process will break executio when it runs json::fast test

lizmat

yeah, but you can install without running the tests

ugexe

does it make sense to run blin without running tests?

17:06

lizmat

no, it does not :-)

.oO( note to self: the rakkable interface needs work)

in any case, I think JSON::Fast being pinned in the ecosystem, is something that can be fixed

17:08

[Coke]

note that blin deals not at all with pinned versions.

right now if someone pins a version that is not also coincidentally the latest version, it doesn't get blinned.

17:09

lizmat

even if that pinning has a + in it ?

[Coke]

github.com/Raku/Blin/issues/48 for an example of one

if it's "version x or later", blin works, because it's always testing the latest version

lizmat

but but, Hash::Ordered is not pinned to a specific version of Hash::Agnostic: use Hash::Agnostic:ver<0.0.17+>:auth<zef:lizmat>;

17:10

and Hash::Agnostic is at 0.0.19

17:11

so how is that a problem now?

[Coke]

ah, then I retract my "it happens to work" statement.

17:12

so any pinned version is problematic, likely.

this particular example doesn't work in blin.

lizmat

ah, perhaps another module is pinning Hash::Agnostic at an earlier version

17:13

[Coke]

no, it fails with just testing Hash::Ordered.

which tries to pull in H::A and that arrangement fails to work.

17:14

I'll update the bug desc.

Thanks.

17:15

lizmat

hmmm.. I guess I didn't update H::O yet... the ecosystem version indeed has a hard-pinned version

*sigh*

17:17

[Coke]

ah.

17:47

I suspect I'm going to have to create some blin-testing modules to highlight the particular issues and then skip them once I have the skiplist working.

17:48

so don't worry about fixing these in the ecosystem

(that is, it's fine to fix them)

librasteve_

rakudoweekly.blog/2026/05/11/2026-...f-failure/

18:35

lizmat

librasteve_++

18:37

timo

[Coke]: it feels like this was probably by mistake? raku.land/zef:coke/Slang:Date

18:42

lizmat

timo: ??

18:43

timo

there's only one : in the name

lizmat

aah... yes...

that *was* a mistake that is now immortalized ;-(

18:44

timo

oh, we don't allow removing stuff, right?

lizmat

indeed... although I guess an exception could be made for this one...

or at least blacklist it at raku.land

[Coke]

I am the perfect example of why we need to be able to delete modules.

19:02

also: Imagine a security vulnerability is discovered - how do we prevent people from installing it?

lizmat

well, I guess I could at least remove it from the REA

19:03

thing is, the next run it would find it in zef, and put it back

[Coke]

Yup. need a comprehensive solution.

19:04

Sorry. :|

timo

it's not like it's your fault? haha

19:25

[Coke]

I mean... that one was, right?

19:26

timo

well, this one, but i don't think it has much of an impact unless you're specifically searching for "Slang" and then get surprised to see one with : instead of :: in the name?

19:33

Geth

roast: b7f0908a92 | (Elizabeth Mattijsen)++ | S32-str/sprintf-c.t
Add line informaton to test

Because these are table driven, a failure is often hard to trace back to where in the table the data is from. By adding the line number to the test data, looking up where the source of the error is, is suddenly a *lot* easier!

19:49

roast: b7f0908a92 | (Elizabeth Mattijsen)++ | S32-str/sprintf-c.t
Add line informaton to test

Because these are table driven, a failure is often hard to trace back to where in the table the data is from. By adding the line number to the test data, looking up where the source of the error is, is suddenly a *lot* easier!

lizmat

that's a weird Github hickup :)

ab5tract

.seen avuserow

20:14

tellable6

ab5tract, I saw avuserow 2026-05-10T16:29:49Z in #raku: <avuserow> lizmat: just searched, is that a reference to PLATO? If so that's before my time but PLATO is from my alma mater so that's another connection for me

ab5tract

avuserow: how did you get Raku syntax highlighting to work on bearblog? So cool

20:15

tellable6

ab5tract, I'll pass your message to avuserow

21:18 ShimmerFairy left 21:19 ShimmerFairy joined 21:38 vrurg_ left 21:54 vrurg joined 22:02 vrurg_ joined 22:05 vrurg left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!