00:59 JRaspass left, JRaspass joined 02:54 japhb joined 04:02 japhb left 04:34 japhb joined 06:14 japhb left 07:47 finanalyst joined 10:27 [Coke] left 10:29 [Coke] joined
releasable6 Next release in ≈3 days and ≈7 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
11:11 librasteve_ left 12:16 [Tux] left 12:26 [Tux] joined 12:32 finanalyst left 13:10 ChanServ sets mode: +o lizmat 14:01 librasteve_ joined
jdv blin run was clean except it looks like cro won't pass its tests. not sure if that's rakudo or cro though. 15:52
can anyone cleanly install cro on head with tests? 15:53
[Coke] jdv: started the changelog but didn't do much 16:02
jdv cool 16:12
lizmat running a zef install cro on a clean head 16:14
jdv: gist.github.com/lizmat/9869c6b73dd...954b01e013 16:19
jdv that looks familiar. it almost looks like a local env assumption is wrong? 16:23
lizmat could be.. 16:26
17:01 summerisle left, summerisle joined 17:11 japhb joined 17:26 Nemokosch joined 17:28 lizmat sets mode: +b *!~Nemokosch@2a02:ab88:388f:5100:3f10:8b08:ff1c:706
jdv hmm, i thought maybe ipv6 but i disabled that and same 17:42
17:48 Voldenet left, Voldenet joined
librasteve jdv: I guess you have seen this github.com/croservices/cro/issues/170 17:50
17:54 lizmat sets mode: +b TheUnforgiven!*@*
jdv yeah, that's why i thought they were related but seem not 18:05
18:12 Nemokosch left 19:49 lizmat sets mode: +b Nemokosch!*@*
Geth rakudo/lizmat-no-backtrace: ae42f7a6a2 | (Elizabeth Mattijsen)++ | 2 files
Rename "no-backtrace" to "without-backtrace"

Which is more verbose, but more indicative of the functionality
20:02
rakudo/lizmat-split-enz: 1906e83c01 | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod
Make coercion consistent with other methods

2colours++ for spotting
20:06
20:23 ugexe left 20:29 finanalyst joined
jdv cro head fails its tests on rakudo 2026.01 so its not a blocker but its not great 21:26
stdfermat Saw this raku snippet on a new dot ycombinator thread: $ raku -e 'say (0, 1, 2, * × * ... )[^10]' # for readability (0 1 2 2 4 8 32 256 8192 2097152) $ raku -e 'say (0, 1, 2, * * ... *)[^10]' # for typeability (0 1 2 2 4 8 32 256 8192 2097152) However when trying it on a Linux instance: $ raku -e 'say (0, 1, 2, * × * ... )[^10]' ===SORRY!=== Error while compiling -e Missing required term after infix at -e:1 ------> 21:37
say (0, 1, 2, * × * ... ⏏)[^10] expecting any of: prefix term $ raku -e 'say (0, 1, 2, * * ... *)[^10]' (0 1 2 WhateverCode.new Nil Nil Nil Nil Nil Nil) $ raku --version Welcome to Rakudo™ v2026.01. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2026.01.
timo it does need the * after the ... and before the ) 21:38
are you missing an operator between the * and * there before the ...? 21:41
or is the question why the last one parses at all or something? 21:45
[Coke] m: say (0, 1, 2, * × * ... *)[^10]
camelia (0 1 2 2 4 8 32 256 8192 2097152)
[Coke] m: say (0, 1, 2, * * ... *)[^10]
camelia (0 1 2 WhateverCode.new Nil Nil Nil Nil Nil Nil)
timo i think you might have found a very fun way to reach this syntax: 21:46
[Coke] m: say (0, 1, 2, * * * ... *)[^10]
timo m: sub test { ... }; say test()
camelia (0 1 2 2 4 8 32 256 8192 2097152)
Stub code executed
in sub test at <tmp> line 1
in block <unit> at <tmp> line 1
timo m: (* * ... *)()
camelia Too few positionals passed; expected 1 argument but got 0
in block <unit> at <tmp> line 1
timo m: (* * ... *)(1)
camelia *
in block <unit> at <tmp> line 1
[Coke] the middle * is equivalent to the × - without it that's parsing as something else.
timo that's funky as heck
m: ... "hi?" 21:47
camelia hi?
in block <unit> at <tmp> line 1
timo m: ... *
camelia *
in block <unit> at <tmp> line 1
timo it's the ... acting as a sub-like in terms of how the parsing works out 21:48
22:12 finanalyst left
librasteve please bear in mind that Discord randomly swallows markup chars line * 22:17
lizmat yeah, and so does HN :-( 23:30