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:05 Ebudae joined 00:35 kjp joined 00:43 Manifest0 left 01:37 frost joined 01:40 frost left 01:51 frost joined 02:00 frost left 02:58 rf left 05:00 Ebudae left 06:47 teatwo joined 06:50 tea3po left 07:02 teatwo left 07:03 teatwo joined
QuiRay hello, enums are not unsupported as a type in parameters of MAIN? asking, because runtime started crashing with unhelpful error message after adding it and only thing I found about it is years old issues on "old issue tracker" (not sure where is the current one) 07:34
enum InputType (JSON => 'json', JS => 'js'); unit sub MAIN( ... InputType :t($input-type) = JSON, No exception handler located for catch at SETTING::src/core.c/Exception.pm6:570 (/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/perl6/runtime/CORE.c.setting.moarvm:print_exception) from SETTING::src/core.c/Exception.pm6:626 07:37
(/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/perl6/runtime/CORE.c.setting.moarvm:<anon>) from gen/moar/stage2/NQPHLL.nqp:2120 (/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/nqp/lib/NQPHLL.moarvm:command_eval) from gen/moar/Compiler.nqp:105 (/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/perl6/lib/Perl6/Compiler.moarvm:command_eval) from gen/moar/stage2/NQPHLL.nqp:2039
(/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/nqp/lib/NQPHLL.moarvm:command_line) from gen/moar/rakudo.nqp:140 (/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/perl6/runtime/perl6.moarvm:MAIN) from gen/moar/rakudo.nqp:1 (/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/perl6/runtime/perl6.moarvm:<mainline>) from <unknown>:1
(/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/perl6/runtime/perl6.moarvm:<main>) from <unknown>:1 (/home/xxx/.rakubrew/versions/moar-2022.07/bin/../share/perl6/runtime/perl6.moarvm:<entry>)
Nemokosch I know some related issues: github.com/rakudo/rakudo/issues/5090 github.com/rakudo/rakudo/issues/5091 08:22
The lookup is quite fragile 08:23
However, using the module Getopt::Long tends to fix these problems as a bonus 08:24
08:40 CIAvash` joined
CIAvash` m: enum InputType (JSON => "json", JS => "js"); sub MAIN(InputType :t($input-type) = JSON) { dd $input-type }; @*ARGS=<-t JS> 08:42
camelia InputType::JS
Nemokosch actually that ... might not be possible with CLI parsing issues 08:43
there are all kinds of crazy interactions
but yeah tbh my experience is that you can just take Getopt::Long that has better defaults anyway 08:44
and you get working variants for free
QuiRay second noob question, why is it telling me it's not useful, when the result looks correct? [9] > 'abac' ~~ S:g/(a)/<$0>/ Potential difficulties: Smartmatch with S/// is not useful. You can use given instead: S/// given $foo ------> 'abac' ~~ ⏏S:g/(a)/<$0>/ <a>b<a>c 08:50
08:50 pkg joined
Nemokosch you are really giving me hurtful memories 😅 08:50
github.com/Raku/problem-solving/issues/350 08:51
end of the story: "no, it has to be useless, this is a regression"
so yeah, it wouldn't work anymore, although I fully agree that it makes sense 08:52
pkg Hello. Can I embed comment in heredoc? 08:53
Nemokosch I see no hints that you could, and by a quick search, you can't in PHP at least 08:57
I think the implementation could bear with it in theory but I wonder who could read that part of the source 😅 08:58
09:09 Manifest0 joined 09:12 dakkar joined
CIAvash` m: my $heredoc = qq:to/END/;␤{␤#`(some comment)␤'some text'␤}␤END␤say $heredoc; 09:38
camelia some text
09:44 pkg left 11:20 frost joined 11:21 frost left 11:26 frost joined 11:28 frost left 11:40 CIAvash` left
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/03/07/2023-10-toronto/ 12:17
12:40 Heptite joined 13:21 rf joined 13:38 seekr joined
falsifian m: say "{(* + *).raku}" 15:11
camelia WhateverCode object coerced to string (please use .gist or .raku to do that)

in block <unit> at <tmp> line 1
falsifian Why does that warning appear? 15:12
I think I'm calling .raku on a Whatever, and the warning seems to tell me I should call .raku on it.
m: (* + *).raku
camelia ( no output )
falsifian Doesn't happen there. Is this a bug or am I missing something?
m: say (* + *).raku 15:13
camelia WhateverCode.new
falsifian Second question: should the following exception to whatever-currying be added to the list of exceptions at docs.raku.org/type/Whatever.html ? 15:14
m: say "plus: ", (* + *).raku, "; and: ", (* && *).raku
camelia plus: WhateverCode.new; and: *
falsifian i.e. && doesn't curry * 15:15
lizmat falsifian: I think you're calling .raku on a WhateverCode 15:16
not a Whatever
m: say (*+*).^name
camelia WhateverCode.new
lizmat and stringification of a WhateverCode will give you that warning 15:17
falsifian lizmat: What confuses me is that (* + *).raku doesn't generate the warning but wrapping the .raku call in "{...}" does.
(* + *).raku is a string, I think, so "{(* + *).raku}" ought to just be interpolating a string into a string. 15:18
Nahita m: { (* + *).raku }
Raku eval Exit code: 1 ===SORRY!=== Error while compiling /home/glot/main.raku Malformed double closure; WhateverCode is already a closure without curlies, so either remove the curlies or use valid parameter syntax instead of * at /home/glot/main.raku:1 ------> { (* + *).raku }⏏<EOL>
falsifian m: "{(* + *).raku}"
camelia WhateverCode object coerced to string (please use .gist or .raku to do that)
in block <unit> at <tmp> line 1
lizmat no, (* + *).raku is a WhateverCode as well
falsifian ohhhh 15:19
Tricky *
lizmat m. say ((* + *).raku)(42,666)
m: say ((* + *).raku)(42,666)
camelia 708
falsifian Hm, what if I really wanted to call .raku on that WhateverCode object?
Thanks for the explanation 15:20
lizmat that will give you the warning, as currently there is no way to reproduce what made the WhateverCode object
with RakuAST we might be able to do it: 15:21
m: say Q|* + *|.AST.DEPARSE
camelia * + *
falsifian lizmat: I'm not so much asking for a *good* string representation of * + *, as wondering how to make the WhateverCode not behave like one. But maybe the answer is WhateverCode just doesn't implement .raku, except in the usual currying FALLBACK way? 15:22
lizmat but we're still not sure about the lifetime of RakuAST objects, do they stick around at runtime or not
indee
d
falsifian kk, thanks lizmat
15:29 pkg joined 15:39 jgaz joined
pkg <CIAvash`> Finally I can insert some comments here and there into a very long heredoc. Really appreciate your kind help. <3 15:41
falsifian m: zip((0,1), (1,1), with => &infix:<+>) 16:09
camelia WARNINGS for <tmp>:
Useless use of "zip((0,1), (1,1), with => &infix:<+>)" in expression "zip((0,1), (1,1), with => &infix:<+>)" in sink context (line 1)
falsifian m: say zip((0,1), (1,1), with => &infix:<+>) 16:10
camelia (1 2)
falsifian m: say zip((0,1), (1,1), with => &infix:<&&>)
camelia ((0 1) (1 1))
falsifian Why does the last one produce a list of lists?
rf Because the result of zipping with && returns a list 16:17
falsifian m: say((0,1) Z+ (1,1)); say((0,1) Z&& (1,1)) 16:18
camelia (1 2)
(0 1)
rf Ok maybe I'm interpreting this wrong then. 16:19
lizmat && is really a bit weird as it is really a macro because of its short-circuiting 16:20
m: 0 && die
camelia ( no output )
lizmat m: 1 && die
camelia Died
in block <unit> at <tmp> line 1
rf Ah 16:21
Nemokosch sometimes we take short-circuiting for granted but if one thinks about it, it's quite a tricky thing
rf m: say zip((0,1), (1,1), with => &infix:<and>)
camelia (0 1)
Nemokosch smartmatching also does something fairly similar to short-circuiting
falsifian m: 0 and die 16:22
camelia ( no output )
Nemokosch $_ is localized to the rhs before the rhs is evaluated
falsifian Both and and && short-circuit, but && breaks zip and and doesn't seem to.
lizmat and || and or as well 16:23
.oO( let ChatGPT chew on that :-)
falsifian Nemokosch: Where does localization come into this?
lizmat it doesn't, I'd say
Nemokosch yeah it doesn't 16:24
falsifian I am rather confused. What kind of object is &infix:<&&>, and does it somehow preserve the short-curcuit behaviour?
lizmat that's the point: it doesn't
arguments to &infix:<&&> will always be evaluated
m: &infix:<&&>(0,die) 16:25
camelia Died
in block <unit> at <tmp> line 1
falsifian Does any of this tie back to my zip example? Or are we all confused about why with => &infix:<&&> behaves strangely?
lizmat well, using &infix:<&&> is a bit of a code smell to me
that's why, didn't have the spare cycles at the moment to dive into the seen behaviour 16:26
falsifian lizmat: Is there a less smelly way to zip two lists with the and operator? I could always write my own and function...
I don't need the short-circuiting.
lizmat then it should work ?
falsifian It doesn't, though. 16:27
Nemokosch m: (0, 1) Z&& (1,1) andthen .say
Raku eval (0 1)
Nemokosch this is on 2022.02 btw
lizmat falsifian: then maybe you found a bug :-)
falsifian Yay! Will try reporting. 16:28
Nemokosch m: say zip((0,1), (1,1), with => &infix:<&&>) 16:29
Raku eval ((0 1) (1 1))
Nemokosch hmmm
rf What is the expected return value? 16:30
falsifian (0 1) in my opinion
Nemokosch m: say zip((0,1), (1,1), (2,3), with => &infix:<&&>)
Raku eval ((0 1 2) (1 1 3))
Nemokosch transposed it? lol 16:31
falsifian github.com/rakudo/rakudo/issues/5227
Nemokosch m: say zip((0,1), (1,1), (2,3), with => &infix:<and>) 16:32
Raku eval ((0 1 2) (1 1 3))
Nemokosch this is the same now
falsifian Where is zip implemented?
Nemokosch github.com/rakudo/rakudo/blob/2022....pm6#L1617 16:34
we are rallying away from beginner chat 😄
lizmat indeed :-) 16:36
Rog #raku-advanced 16:46
lizmat #raku-dev I guess :-) 16:51
falsifian About half my questions turn out to be raku bugs, but the rest are beginner confusion. 16:53
lizmat falsifian: well, I'm hoping that some of them are beginner confusion on my end :) 16:54
16:56 pkg left
falsifian Next Q: I'm confused about passing an array variable to zip: 16:57
m: my @x=(<a b>, <0 1>);say zip(@x);say zip(@x.List);
camelia (((a b) (0 1)))
((a 0) (b 1))
falsifian m: my @x=(<a b>, <0 1>);sub f(+@a) { @a.elems };say f(@x);
camelia 2
falsifian The docs claim zip's signature is (+@e, ...) so I'd expect @x to be taken as the list of args, like in the second example. docs.raku.org/routine/zip.html 16:58
But it doesn't work; through trial and error I found passing @x.List gets what I want.
Nemokosch you know the single argument rule, right?
falsifian I'm reading it here:docs.raku.org/language/signatures.html
Is @x not iterable? And if it isn't, why does my second example with sub f(+@a) work differently? 16:59
Nemokosch the second example is right 17:00
falsifian Nemokosch: By second example do you mean my sub f(+@a) ... line above?
Nemokosch yes 17:01
falsifian That example did what I expect. I'm confused why the previous line, using zip, seems to behave differently.
I have to explicitly add .List to get it to behave like the f(+@a) example.
Nemokosch the signature of zip is slightly different, right? 17:02
falsifian Nemokosch: are you referring to the signature in the code link you sent, or in the docs I linked to? 17:03
for the zip routine
Nemokosch in the code 17:04
not sure if it matters tbh
but it could at least
falsifian m: my @x=(<a b>, <0 1>);sub f(+lol --> Seq:D) { 1 xx lol.elems };say f(@x); 17:05
camelia (1 1)
falsifian Hm, it's a multi sub, though... let me play with that... 17:06
m: my @x=(<a b>, <0 1>);proto sub f(|) is pure {*};multi sub f(+lol, :&with! --> Seq:D) {!!!}; multi sub f(+lol --> Seq:D) { 1 xx lol.elems};say f(@x) 17:07
camelia (1 1)
falsifian Now the only difference is the infix part, I think
m: my @x=(<a b>, <0 1>);proto sub infix:<F>(|) is pure {*};multi sub infix:<F>(+lol, :&with! --> Seq:D) {!!!}; multi sub infix:<F>(+lol --> Seq:D) { 1 xx lol.elems};my constant &f = &infix:<F>;say f(@x) 17:08
camelia (1 1)
falsifian m: my @x=(<a b>, <0 1>);Seq.new(Rakudo::Iterator.ZipIterables(@x)) 17:10
camelia ( no output )
falsifian m: my @x=(<a b>, <0 1>);say Seq.new(Rakudo::Iterator.ZipIterables(@x))
camelia (((a b) (0 1)))
Nemokosch this is going to be a containerisation issue, I bet
m: my @x=(<a b>, <0 1>); dd @x[0] 17:11
Raku eval List @x = $("a", "b")
Nemokosch notice the $
lizmat yeah, looks like containerization 17:13
Nemokosch m: zip('a', 'b').say 17:14
Raku eval ((a b))
Nemokosch this can well be unfortunate design, rather than an explicit bug 17:15
falsifian I wonder if it's worth filing an issue asking for the behaviour to change, whether or not it's actually a bug.
lizmat is looking at whether this is a bug or not 17:16
falsifian I run into this often when using zip.
lizmat the thing is: zip() is an alias for infix:<Z> 17:17
Nemokosch m: my @x=(<a b>, <0 1>); say @x[0] Z @x[1]; 17:18
Raku eval (((a b) (0 1)))
falsifian Because @x[0] is again a container, I guess. 17:19
Nemokosch I have the feeling that it would take a GLR 1.5 to do significantly better
falsifian First I learned of the GLR, but is this problem not confined to zip and infix:<Z>? 17:20
Nemokosch m: my @x=(<a b>, <0 1>); .say for @x[0]; 17:24
Raku eval (a b)
Nemokosch as opposed to
lizmat correction: containerization only matters on Iterables
Nemokosch m: my @x=(<a b>, <0 1>); .say for @x0;
Raku eval a b
lizmat m: my @x=(<a b>, <0 1>); .say for @x0; 17:25
camelia ===SORRY!=== Error while compiling <tmp>
Variable '@x0' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> my @x=(<a b>, <0 1>); .say for ⏏@x0;
lizmat I guess a Discord artefact
Nemokosch m: my @x=(<a b>, <0 1>); .say for @x[0];
Raku eval (a b)
Nemokosch should be binding, no?
m: my @x:=(<a b>, <0 1>); .say for @x[0]; 17:26
Raku eval a b
lizmat m: my @x:=(<a b>, <0 1>); .&dd for @x[0]
camelia "a"
"b"
Nemokosch in my brave new world of fantasy, itemisation and containerisation are two distinct things - but will that ever manifest? wouldn't bet on it 17:27
lizmat who knows, maybe in Rakudo v2024 17:29
Nemokosch Slang::Raku42
lizmat go for it! 17:30
Nemokosch the zeroeth problem is usually that these things take a lot of time allocated for a short (or perhaps not even that short...) period 17:33
maybe if I went back to being a full-time student... but life is just too expensive for that tbh 17:34
lizmat afk& 17:36
17:48 dakkar left 18:13 jgaz left 18:46 teatwo left, teatwo joined 18:50 tea3po joined 18:53 teatwo left 19:12 jgaz joined 19:49 dgrigoro joined 20:44 Heptite left 20:45 Heptite joined 20:49 NemokoschKiwi joined 20:52 NemokoschKiwi left 22:05 dgrigoro left 22:14 jgaz left 22:56 habere-et-disper joined
habere-et-disper The sub form of tail asks for the tail specifier as the first argument. What is a "tail specifier"? 22:57
Ah! The number of elements you want! 22:58
Nemokosch yep 23:00
that's to be consistent with map, grep kind of stuff, and hence leveraging use of ==>
m: 1, 2, 3, 6, 7, 23, 12, 4 ==> grep * %% 3 ==> say() 23:01
Raku eval (3 6 12)
Nemokosch since the IRC has a newer Rakudo, you can do something like that with tail as well 23:02
habere-et-disper Thanks! Helpful!
:_
:)
Nemokosch 🍰
habere-et-disper Why are .key and .value not available on Arrays? 23:30
Eg m: [1,2,3].grep( .key %% 2 )
m: [1,2,3].grep( .key %% 2 )
camelia No such method 'key' for invocant of type 'Any'. Did you mean 'keys'?
in block <unit> at <tmp> line 1
Nemokosch the elements of the array are iterated, they aren't pairs by default 23:31
m: [1,2,3].pairs.grep( .key %% 2 )
Raku eval Exit code: 1 No such method 'key' for invocant of type 'Any'. Did you mean 'keys'? in block <unit> at main.raku line 1
Nemokosch oh okay, there was a syntax error as well
habere-et-disper m: [1,2,3].pairs.grep( { .key %% 2 } )
camelia ( no output )
Nemokosch m: [1,2,3].pairs.grep(*.key %% 2 ).say
Raku eval (0 => 1 2 => 3) 23:32
habere-et-disper It just seems natural that an Array has an index (key) and a value and I imagine that while iterating over them it would be available. 23:33
Nemokosch I'd say the opposite seems just as natural: the entries of an array are the values, and if you want a sequence with pairs, it's pretty easy to get 23:35
habere-et-disper I mean you can still get at them, it just more line noise: $_ and $++ for .value and .key 23:36
Nemokosch yeah, did that today. Keep in mind that by using $++, you give up on parallelisation 23:37
habere-et-disper Noted. $++ seems missing from the new documentation search. 23:39
Nemokosch docs.raku.org/language/variables.h...$_variable 23:40
habere-et-disper Merci encore. :) 23:41
Nemokosch 🥖 23:45
😛
23:48 deoac joined
habere-et-disper Quelle horreur ! Une baguette sans fromage ! 23:50
🥖+🧀=😋
Nemokosch 🤣

Powered by Cro and the Raku® Programming Language.

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

Thank you!