[02:05] *** frost joined [03:33] hello [03:33] m: my $sig = :($a); say 1 ~~ $sig; [03:33] rakudo-moar 3bde138cb: OUTPUT: «False␤» [03:33] m: my $sig = :($a, $b); say (1,2) ~~ $sig; [03:33] rakudo-moar 3bde138cb: OUTPUT: «True␤» [03:34] m: my $sig = :($a); say (1,( ~~ $sig; [03:34] rakudo-moar 3bde138cb: OUTPUT: «===SORRY!=== Error while compiling ␤Expected a term, but found either infix ~~ or redundant prefix ~␤ (to suppress this message, please use a space like ~ ~)␤at :1␤------> my $sig = :($a); say (1,( ~~⏏ $sig;␤» [03:34] m: my $sig = :($a); say (1,) ~~ $sig; [03:34] rakudo-moar 3bde138cb: OUTPUT: «True␤» [03:35] can I only match one value 1 rather than a list (1,) ? [06:15] frost: I don't think so, you're matching against a signature, so it has to be a list of positionals and/or named parameters, unless you use a capture [06:15] m: say \(1) ~~ :($a) [06:15] rakudo-moar 3bde138cb: OUTPUT: «True␤» [08:48] CIAvash: Thanks! [11:49] Is there a way to cut a sequence at the first repetition? [11:49] like some greedy uniq [12:02] m: [12:02] ``` [12:02] 1, {1+1/$_ } ... * =~= * andthen .say [12:02] ``` [12:02] m: 1, {1+1/$_ } ... * =~= * andthen .say [12:02] m: `1, {1+1/$_ } ... * =~= * andthen .say` [12:10] hm no, not like this, perhaps I wasn't clear enough [12:10] the repetition doesn't have to happen for neighborous elements [12:12] so, say, 3, 2, 1, 2, 8, 1, 6, 2, 1, 3, .. should stop at 3, 2, 1 [12:14] *** discord-raku-bot left [12:15] *** discord-raku-bot joined [12:18] Nemokosch: you can use "last" in a grep or a map [12:19] *** discord-raku-bot left [12:19] *** discord-raku-bot joined [12:22] m: my %seen; dd (1,2,3,4,5,1,6,7).grep: { %seen{$_}++ ?? (last) !! True } [12:22] rakudo-moar 907243814: OUTPUT: «(1, 2, 3, 4, 5).Seq␤» [12:22] oh, so can it outlast the block? [12:22] m: 3, 2, 1, 2, 8, 1, 6, 2, 1, 3 andthen [\,] $_ andthen .toggle: !*.repeated andthen .tail.say [12:24] do you think this could work for a sequence? [12:25] .grep works on anything sequency [12:25] m: my %seen; dd (1,2,3,4,5,1,6,7).map(* ** 2).grep: { %seen{$_}++ ?? (last) !! True } [12:25] rakudo-moar 907243814: OUTPUT: «(1, 4, 9, 16, 25).Seq␤» [12:27] m: { (^10).pick } ... * andthen [\,] $_ andthen .toggle: !*.repeated andthen .tail.say [12:27] I suppose the irc bridge cannot take dc replies into account; that question was directed to wamba [12:27] hmmm [12:29] is toggle like the flipflop operator? [12:33] I'm curious about how this works... [12:33] Liz's solution is already better than what I knew but this... what the hell 😄 [12:37] that is a produce metaoperator, right? [12:37] just discord ate it [12:37] yes [12:39] oh right, makes sense [12:39] it looks nicer, although the other one with the explicit hash should be more resource effective [12:39] for my own particular case, that's not a serious concern 😛 [12:40] Nemokosch: just showing that you can use "last" (and "next" actually) in a .map or .grep [12:43] that's definitely good to know, thank you [12:43] are blocks really just like inline blocks, with the same scoping and control flow? [12:45] *** discord-raku-bot left [12:46] *** discord-raku-bot joined [12:47] Nemokosch: they're all blocks [12:47] m: my $block = { .say }; $block("foo") [12:48] rakudo-moar 907243814: OUTPUT: «foo␤» [12:48] m: my $block = -> $text { $text.say }; $block("foo") [12:48] rakudo-moar 907243814: OUTPUT: «foo␤» [12:48] m: if "foo" -> $text { $text.say } [12:48] rakudo-moar 907243814: OUTPUT: «foo␤» [12:48] they're all basically the same thing [12:49] m: my $block = *.say; $block("foo") [12:49] rakudo-moar 907243814: OUTPUT: «foo␤» [12:51] so they are transparent to anything a usual block would be [12:51] however you can't use recursion with them, or can you? [12:58] > Cannot use samewith outside of a routine [13:01] *** discord-raku-bot left [13:01] *** discord-raku-bot joined [13:03] indeed, that needs a sub :-) [13:10] okay, it's coming along... [13:12] one last question: in the light of this, what is the lifecycle of state variables? [13:13] They exists once per routine and thread. [13:13] I think technically it's called "once per capture clone" [13:14] and, fwiw, I would advise against using state variables in anything multi-thready [13:14] as state variables still have a race condition :-( [13:15] (if I remember correctly, it's been a while since I looked at that) [13:16] m:``` [13:16] my &s1 = sub { state $i; say $i++ }; [13:16] s1; [13:16] s1; [13:16] my &s2 = &s1.clone; [13:16] s2; [13:16] ``` [13:18] m:``` [13:18] my &s1 = sub { state $i; say $i++ }; [13:18] s1; [13:18] s1; [13:18] &s1.wrap(sub { nextsame }); [13:18] s1; [13:18] ``` [13:18] what if a state variable is contained by a block? [13:18] It is best to assume that all blocks are inlined. [13:19] That `.wrap` resets state vars is an ENODOC. [13:20] .wrap introduces another scope, so no surprise in my understanding [13:21] blocks do limit the access scope though, right? [13:22] they aren't some funky dynamic var makers [13:27] blocks create a scope [13:30] What I'm trying to understand is the lifecycle of a scoped state variable [13:30] is it like a variable of the outer scope? [14:21] *** frost left [15:10] *** jgaz joined [15:12] *** jgaz left [16:57] Visibility and lifetime is not the same thing. [16:57] Yes, I know, that's why I ask about both separately [19:32] *** discord-raku-bot left [19:32] *** discord-raku-bot joined [19:38] *** MasterDuke left [19:46] *** MasterDuke joined [21:30] it's visible only in the scope in which it is declared but in terms of lifetime it's as if you declared it exactly one scope out from that [21:30] m: ``` [21:30] for 1..2 { [21:30] for 1..2 { [21:30] state $i; [21:30] say $i++; [21:30] } [21:30] }``` [21:32] and that's static scope afaik, not dynamic [21:32] oh I see [21:32] we're wondering about wrapped routines here [21:35] To my understanding, the wrapped version is not considered the same subroutine as the original, so it gets a newly-created set of storage locations for those state variables [21:36] in the same way that the following two subroutines would have different stores for their state variables: [21:36] ``` [21:36] sub a { state $i; } [21:36] sub b { state $i; }``` [21:37] that behavior might be less-than-awesome because, naïvely, one would not expect wrapping a subroutine to "reset" anything [21:37] but it does make sense [21:38] from an implementation perspective