This channel is intended for people just starting with the Raku Programming Language ( Logs are available at
Set by lizmat on 8 June 2022.
00:28 MasterDuke joined 00:47 Heptite joined 00:54 deoac joined 01:18 razetime joined 01:58 deoac left 01:59 deoac joined 02:26 frost48 joined 02:28 frost48 is now known as frost, frost left, frost joined 02:59 deoac left 03:48 Kaipei joined 04:03 frost left 04:05 frost joined 04:40 frost left 05:13 frost joined 05:48 Heptite left 06:14 Kaipei left 06:15 Kaipei joined 07:05 frost left 08:52 dakkar joined 10:05 tappi joined, tappi left 11:50 razetime left 12:16 frost joined 12:24 guifa joined 12:33 tappi joined 12:35 frost left 12:45 tappi left 13:07 razetime joined 14:04 razetime left 15:00 falsifian joined
falsifian ("{$_}" for ^1).join eq "0" --> True (as I expect) 15:04
die unless ("{$_}" for ^1).join eq "0"
Use of uninitialized value $_ of type Any in string context.
Doesn't happen if I use "$_" instead of "{$_}".
What's going on?
15:19 razetime joined
Nemokosch falsifian: {} creates a block with its own $_ 15:22
falsifian Nemokosch: Even {} in string interpolation? Then why did the first one (without die) work?
Nemokosch I also wonder about the first one 15:23
falsifian Nemokosch: Also, even outside string interpolation, I don't see {...} always getting rid of $_ 15:25
e.g. for (^3) { say $_; { say $_; } }
Prints each number twice. The inner {} didn't get rid of $_.
Nemokosch fair point, although I think that's because the inner $_ gets bound to the outer one. Wouldn't know from the top of my head, to be honest 15:26
lizmat m: say { say "foo" }.signature 15:27
camelia (;; $_? is raw = OUTER::<$_>)
lizmat note how the default value for the argument $_ is the outer $_
Nemokosch phew, seems like I did manage to understand something, after all 15:28
but then we might as well ask the difference, still 15:29
the prefix if/unless works, the postfix one does not 15:30
I think we've had code generation problems regarding for 15:32 this is what I remembered 15:34
15:35 Heptite joined
really hard to imagine that this isn't a bug 15:37
15:38 Guest11 joined, Guest11 left
m: say 'TRU' if { .say } ; 15:46
interesting the least to say 15:47
m: say 'TRU' if { .say } ;
lizmat m: say 'TRU' if { .say } 15:49
camelia TRU
Nemokosch are blocks evaluated to true without being called?
lizmat that'd be a considered a postfix if with a block as a parameter, and the block is *not* being run
Nemokosch seems like that 15:50
lizmat like any instantiated object by default
m: class A { }; say "class" if A; say "instance" if
camelia instance
Nemokosch that's the strange part of strangely consistent 😛
(still better than strangely inconsistent though) 15:51
lizmat m: class A { method defined(--> False) { } }; say "class" if A; say "instance" if
camelia instance
lizmat m: class A { method Bool(--> False) { } }; say "class" if A; say "instance" if
camelia ( no output )
lizmat it's just that the Any:D Bool defaults to True
Nemokosch this makes sense but it's a dead end for what I wanted to see about that weird {$_} 15:53
but now it works... 15:55
maybe it was some REPL weirdness all along?
m: die unless ("{$_}" for ^1).join eq "0" 15:56
no, the REPL weirdness was that it worked for a while xd 15:57
lizmat the REPL is not a good place to test complicated behaviours 16:02
Nemokosch to be fair though, this shouldn't be complicated at all
sadly, this seems to be deep in the "strangely inconsistent" territory 16:03
falsifian m: die unless ("{$_}" for ^1).join eq "0" 16:29
camelia Use of uninitialized value $_ of type Any in string context.
Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful.
in block at <tmp> line 1
in block <unit> at <tmp> line 1
falsifian m: say ("{$_}" for ^1).join eq "0"
camelia True
falsifian I first observed this outside the REPL. 16:30
16:38 jgaz joined
lizmat and yet another Rakudo Weekly News hits the Net: 17:02
Nemokosch somehow the $_ doesn't propagate in that block but I really can't say much more than it's probably a bug. Feel free to open an issue for it at so that it doesn't get lost 17:05
falsifian Will do after work if someone else doesn't get to it first. Thanks for the answers! 17:21
17:25 baughb joined
baughb I want to read (and process) a file line-by-line, until I find an empty line, and then continue reading (and processing in a different way) line-by-line until the end. My idea was to bind `.IO.lines` with something like `my \lines = 'file'.IO.lines` and then run two for loops over it, but then I get the "The iterator of this Seq is already in 17:29
use/consumed" error. Is there some other way to do this lazily, without caching the file?
17:33 razetime left 17:38 dakkar left 18:27 baughb left
lizmat my $after; for $io.lines { if $after { say "after" } elsif !$_ { $after = True } else { say "before" } } 19:47
Nemokosch something with ff could also work - not sure if it's genuinely worth it 19:55
lakmatiol yeah, this seems ideal for ff 20:14
```perl 20:24
for lines() {
if "" ff * {
say "after";
} else {
say "before";
22:29 jgaz left 23:33 kjp left 23:34 kjp joined