This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html
Set by lizmat on 8 June 2022.
00:08 Heptite joined 00:50 habere-et-disper joined 02:08 jacob_c joined 02:19 sivoais left 02:29 habere-et-disper left 03:10 rf left 03:19 sivoais joined 04:38 jacob_c left 04:44 discord-raku-bot left 04:46 discord-raku-bot joined 04:47 shmup left, shmup joined 06:48 tea3po joined 06:51 teatwo left 07:37 Sussysham joined
Sussysham Good Afternoo everyone 07:41
Sussysham Good Morning bro 07:42
07:44 Sussysham60 joined, Sussysham60 left 07:47 Sussysham left
Nahita you too 08:01
Sussysham :camelia: 08:02
08:07 Sussysham joined 09:10 dakkar joined 09:26 habere-et-disper joined
tried to install few modules with zef most of the time i am ending up with some sort of error 😩 09:31
Nahita windows? 09:32
Sussysham yup
Nahita happened to me too
Sussysham I see
Nahita REPL for some reason started to increase CPU usage a lot on Windows, so i had to leave it 09:33
like typing "raku" only
i turned out other users face the issue as well, in fact there is an issue on the tracker for it i believe 09:34
Sussysham I don't have skill to make pull request resolve them by myself
Nahita me neither
Sussysham one liner you mean 09:35
Nahita i mean REPL
"raku" and enter
Sussysham you should try one liner mode 09:36
though implemetation will be limited 09:38
tbh it isn't much of problem for me yet just my lappy getting heated 09:41
Nahita cool
09:43 habere-et-disper left
the sound level of the computer increases a lot, so... 09:44
interestingly, i didn't even change the version of Rakudo on Windows
at some point it decided to use more CPU, it seems
it's 2021.07, maybe i should try a new one 09:45
Sussysham how to check that 09:46
Nahita raku -v
Sussysham >raku -v Welcome to Rakudo™ v2023.02. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2023.02. 09:47
Nahita that's the newest i guess
Sussysham well i am myself new 09:48
for some reason i wasn't able to setup rakudo and comma so i used use replit 09:49
10:21 Heptite left 10:52 habere-et-disper joined 11:01 Sussysham left
habere-et-disper Can snip take multiple * ? 11:14
Or do I have the syntax wrong ?
m: snip *.succ != *, 1, 2, 4, 5, 6, 8, 9;
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
snip used at line 1. Did you mean 'slip', 'skip'?
Nemokosch the error is probably unrelated 11:16
in general, each whatever star indicates a separate positional argument
so *.succ != * is like {$^x.succ != $^y} 11:17
11:17 ab5tract joined
habere-et-disper Thanks -- that is clear and what I expected. 11:18
Nemokosch docs.raku.org/routine/snip.html "Available as of 6.e language version" 11:20
habere-et-disper m: use v6.e.PREVIEW; snip *.succ != *, 1, 2, 4, 5, 6, 8, 9; 11:21
camelia Too few positionals passed; expected 2 arguments but got 1
in block <unit> at <tmp> line 1
Nemokosch hm, then the answer is no. What behavior would you expect? 11:24
habere-et-disper Much the same as with a generating sequence: 11:28
m: ( 0, 1, * + * ... * ).head( 10 )
camelia ( no output )
habere-et-disper m: ( 0, 1, * + * ... * ).head( 10 ).say 11:29
camelia (0 1 1 2 3 5 8 13 21 34)
Nemokosch no, I mean, what would be the output of the snip?
semantically
habere-et-disper Oh, (1,2),(4,5,6),(8,9) 11:30
lizmat snip in its current implementation, smartmatches the values with the given argument
m: use v6.*; say (1..10).snip(*<5, *<8)
camelia ===SORRY!=== Error while compiling <tmp>
Whitespace required before < operator
at <tmp>:1
------> use v6.*; say (1..10).snip(*<5, *<8)⏏<EOL>
expecting any of:
postfix
lizmat m: use v6.*; say (1..10).snip(* < 5, * < 8) 11:31
camelia ((1 2 3 4) (5 6 7) (8 9 10))
lizmat smartmatch with a Callable assumes 1 argument
habere-et-disper I was wanting to snip on non-integer-adjacent pairs. 11:33
lizmat I guess you could do that with a Callable that has a state variable to keep the previous value ? 11:35
Nemokosch yeah, I guess it would be kinda confusing to progress in overlapping fashion 11:38
with all the reification 11:39
habere-et-disper @lizmat: Yes it sounds always doable but I'm loving the exploration of the subordination of detail that lies at the boundary between more implicit versus explicit programming. Topicalization of things (the iterable, the state, are there more?) are proving -Ofun. 11:42
I'm coming to rely more on raku's suggestibility and so generating sequence syntax made me think snip could handle multiple *s too.
lizmat I guess it potentially could, but that's not how it's implemented atm 11:43
it would require special handling of Callables, introspecting their signature, and then do the right thing
Nemokosch I have the impression that this would require magic, though, because you'd need to fetch the same value as the second argument and later as the first argument 11:45
lizmat that would be part of "do the right thing" :-)
Nemokosch I don't know, "the right thing" sounds too stateful here 😛 11:46
lizmat now, with map semantics, two positional args in the Callable would mean to eat 2 values from the iterator each time
and this is *not* what habere-et-disper would like for their case
Nemokosch yes, and that's without overlaps
lizmat so I think habere-et-disper will have to live with the current snip semantics 11:47
Nemokosch I think for adjacent value stuff, rotor is a pretty useful choice most of the time
lizmat and use a Callable with a state vvar
habere-et-disper Thank you for both for the clarifications. 11:48
Nemokosch although it will be definitely longer with rotor as well... let me think about it
lizmat: is it possible to cut on the same condition repeatedly? 11:52
lizmat yes, if you do cond xx * 11:54
12:00 habere-et-disper left, teatime joined 12:01 tea3po left 12:03 NemokoschKiwi joined
NemokoschKiwi m: use v6.*; (1, 2, 4, 5, 6, 8, 9).rotor(2 => -1).snip({ .[0].succ != .[1] } xx Inf).say; 12:04
camelia (((1 2) (2 4)) ((4 5)) ((5 6) (6 8)) ((8 9)))
NemokoschKiwi why is there a cut after (4 5) ?
12:11 habere-et-disper joined
lizmat m: use v6.*; say (1, 2, 4, 5, 6, 8, 9).snip({ state $p = -Inf; LEAVE $p = $_; $p.succ != $_} xx *) 12:11
camelia ((1 2 4) (5 6 8) (9))
NemokoschKiwi it would be good to know regardless 12:13
12:13 NemokoschKiwi left
lizmat then figure it out :-) 12:15
Nemokosch I wouldn't have asked if it made sense to me 🤔
12:56 habere-et-disper left 13:24 jacob_c joined 13:42 jacob_c left 14:10 jgaz joined 14:38 Heptite joined 14:49 jgaz left 14:52 jgaz joined 14:56 avuserow left 15:45 habere-et-disper joined
habere-et-disper Would it be more helpful with consistency/suggestibility 16:18
to have the prefix forms of head and tail more closely
match the postix forms ?
       (2, 8, 7, 6).tail  #  OK: 6
  tail (2, 8, 7, 6)       #  () Hoping for 6
  tail  2, 8, 7, 6        #  OK: 7, 6 as first item specifies quantity
Is there room for another signature to cater for the same behaviour:
multi tail ( $_ where .VAR.^name eq 'Scalar' ) { ... }
Or am I sitting on a Chesterton Fence ?
Nemokosch sort of. iirc I suggested that head and tail subs should exist, particularly to be used with the feed operator 16:24
github.com/Raku/problem-solving/issues/328 16:25
however... it seems that what you are saying also kind of makes sense 16:26
I think first should be checked for an analogy 16:27
m: first (2, 8, 7, 6) 16:28
Raku eval
Nemokosch oops
m: say first (2, 8, 7, 6)
Raku eval Nil
Nemokosch welp, I'd say it's consistent, whether it's nice for this particular use case or not 16:30
m: say first 1, (2, 8, 7, 6)
Raku eval Nil
Nemokosch oops, right, this is kind of a search
m: say first *, (2, 8, 7, 6)
Raku eval 2
16:48 rf joined 17:03 habere-et-disper left 17:04 ab5tract left 17:05 ab5tract joined 17:40 dakkar left 18:30 nommef joined 18:47 teatime left 18:48 teatime joined 18:51 teatime left, teatwo joined 19:06 NemokoschKiwi joined 19:09 jgaz left 19:15 jgaz joined 19:19 NemokoschKiwi left 19:40 nommef left 20:44 ab5tract left 20:58 habere-et-disper joined 22:01 raiph joined 23:09 jgaz left 23:34 raiph left