#raku-dev on 15 February 2026 - Raku Programming Language Log

09:33 finanalyst_ joined 09:34 finanalyst joined 09:44 [Tux] left 09:47 [Tux] joined 10:01 finanalyst_ left

[Tux]

I see deprecation messages. Should all `.perl` methods be replaced with `.raku`?

10:26

librasteve_

[Tux] yes, please

10:28

[Tux]

Rakudo v2026.01-16-g6acaa900d (v6.d) on MoarVM 2026.01-4-g0742ba286

csv-ip5xs	0.255	-	0.263
csv-ip5xs-20	1.053	-	1.059
csv-parser	1.072	-	1.076
csv-test-xs-20	0.118	-	0.122
test	1.808	-	1.835
test-t	0.447	-	0.456
test-t --race	0.282	-	0.301
test-t-20	5.754	-	5.832
test-t-20 --race	1.427	-	1.589

10:30

csv-test-xs 0.017 - 0.017

tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log

lizmat

yeah, it's about time, 6+ years later

10:35

11:31 finanalyst_ joined 12:07 finanalyst left 12:11 finanalyst_ left

timo

snitch can still be changed as it's experimental right?

12:22

i'd like to be able to give context to different invocations of .snitch, like foo().snitch("foo value").map(...).grep(...).snitch("grepped transformed value").etc().etc()

12:23

i know i can supply a block but that's a little wordy since then i'll also have to put note or dd or say or whatever i want in there as well

ab5tract

that does sound kind of handy

12:25

I believe it's technically "unreleased" and intended to land in v6.e

12:26

Whether it is officially marked as experimental, I don't know

timo

so .snitch({ "foo val: $_".note }) could become .snitch(:as("foo val")) or so

i have to `use v6.e.PREVIEW` for it to show up

ab5tract

then as far as I'm aware, it's free for alterations and tune-up

12:27

lizmat

indeed

++timo

12:28 ChanServ sets mode: -o lizmat

timo

the "as" name should be bikeshed first

12:28

lizmat

:comment ?

timo

tag? label?

lizmat

:desc ?

timo

desc isn't bad

how about an adverb to also put filename and line number where the snitch lives :D

12:29

lizmat

also, keeping Test's subtest in mind

"description" => { ... }

aka, a Pair:D candidate could use the key as the description

Zoffix++ for that idea in the past

timo

but with snitch, what would go in the other bit of the pair?

lizmat

the block?

12:30

hmmm...

12:31

Str:D would just be the decsription, with the default &note as the snitcher

Pair:D would be the description as the key, and the block as the snitcher ?

12:32

just a block would be the snitcher without description ?

timo

not sure if it's really useful to have the description text and then the snitcher as a Pair, then it's almost shorter to write out the whole thing?

12:33

`"foo val" => &note` vs `{ "foo val $_".note }`

lizmat

but by default .snitch would just note the invocant, no ?

12:34

timo

"by default" meaning without any arguments at all?

lizmat

m: use v6.*; (1,2,3).snitc

camelia

No such method 'snitc' for invocant of type 'List'
in block <unit> at <tmp> line 1

lizmat

m: use v6.*; (1,2,3).snitch

camelia

(1 2 3)

ab5tract

okay, it's kind of cheeky but what about .snitch(:ing("this") :)

12:35

not really a serious suggestion

lizmat

m: use v6.*; note (1,2,3).snitch.map(*+2).snitch.map(*-7)

12:40

camelia

(1 2 3)
(3 4 5)
(-4 -3 -2)

timo

in order to pun it, have "snitches" as well as "stitches"

12:43

stitches is obviously how multiple snitches get connected together

12:44

one thing with a description is that we will now have to decide on if .Str or .gist or .raku get used for the stringification process

12:46

whereas until now, we just pass the value to the snitcher and that will then decide how stringification goes

so if you snitch with &dd you get raku, if you snitch with &note you get .gist

12:47

and put gives you .Str

lizmat

.snitch("foobar" => &put)

timo

that doesn't help unless we can ask &put "hey how would you stringify this?" before doing it so we can concat the description afterwards

12:49

we can in theory call once for the description and once for the value, but then we get them on two lines for most cases

lizmat

ah, good point :-)

I guess .snitch("foobar") would be the same as: .snitch({ note "foobatr: $_.gist()" }) ?

12:50

*foobar

12:51

timo

should we make a decision up front which of .Str, .gist, or .raku would be the one users would want most often?

lizmat

I think .gist by default makes the most sense, as it will limit output for large data structures

12:52

timo

fair

12:57

hey, do you think we want to introduce a lexically scoped option of some kind that decides how snitch without arguments behaves in a whole file or block or whatever?

12:58

if that's a symbol that's exportable, a module like Data::Dump::Tree could have a :snitcher export tag

lizmat

&*SNITCHER ?

timo

for example, yeah

13:00

we don't expect people to want extremely high performance for this feature, since outputting a lot to the terminal is also a great way to slow down your code just in general

13:01

lizmat

yup, especially with .fmt or printf

13:02

timo

i feel like we need someone to provide pushback against overcomplicating this feature :D

13:04

lizmat

hehe... KISS I guess

timo

i'll go for another one of these walks now, maybe i'll even have some thoughts