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.
Sussysham Good Afternoo everyone 07:41
Sussysham Good Morning bro 07:42
Nahita you too 08:01
Sussysham :camelia: 08:02
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
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
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
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
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) ?
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
lizmat then figure it out :-) 12:15
Nemokosch I wouldn't have asked if it made sense to me 🤔
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!