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. |
|||
01:19
Heptite left
01:47
Heptite joined
02:12
tea3po joined,
tea3po left
02:13
tea3po joined
02:15
teatwo left
05:42
samebchase joined
07:50
habere-et-disper joined
|
|||
habere-et-disper | Is this expected behaviour ? I was expecting the comment to not be included in the array? | 07:54 | |
my @foo = < | |||
# Hello, World ! | |||
1 2 3 | |||
>; | |||
say @foo | |||
[# Hello, World ! 1 2 3] | |||
07:58
dakkar joined
|
|||
lizmat | m: say "# Hello World" | 08:27 | |
camelia | # Hello World | ||
lizmat | < > is basically a single string with a processor to split on whitespace | 08:28 | |
so yes, any comments inside a string *will* occur in the string | |||
habere-et-disper | Thanks. :) | 08:29 | |
lizmat | m: dd < a b c > | 08:30 | |
camelia | ("a", "b", "c") | ||
lizmat | m: dd ' a b c '.words.List | 08:31 | |
camelia | ("a", "b", "c") | ||
lizmat | < > is just syntactic sugar | ||
Nemokosch | actually, <> and words don't behave the same way with non-breaking space, and it would be good to know what the intention is | 09:01 | |
github.com/Raku/problem-solving/issues/357 | 09:02 | ||
09:17
habere-et-disper left
09:48
Manifest0 joined
|
|||
lizmat | And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/04/17/2023-...udent-win/ | 10:26 | |
13:39
jgaz joined
14:05
Heptite left
14:11
tea3po left,
tea3po joined
14:15
tea3po left
14:16
tea3po joined
14:52
Heptite joined
16:39
dakkar left
18:23
jgaz left,
jgaz joined
|
|||
falsifian | m: my @x = (<0 1>, <a b>); zip @x | 21:15 | |
camelia | WARNINGS for <tmp>: Useless use of "zip @x" in expression "zip @x" in sink context (line 1) |
||
falsifian | m: my @x = (<0 1>, <a b>); say zip @x | ||
camelia | (((0 1) (a b))) | ||
falsifian | Testing for bug report | 21:16 | |
Nemokosch | heh, don't say this is also bad 😅 | 21:18 | |
falsifian | Filed github.com/rakudo/rakudo/issues/5247 . I brought it up here March 7; not sure if it counts as a bug or not | 21:19 | |
Nemokosch | I have spent quite a couple of hours on the other one today | ||
hit my limits but at least I think I know what the cause was | 21:20 | ||
falsifian | Which other one? | ||
Nemokosch | the one with the operators &&, ||, and | 21:21 | |
also // it turns out | |||
falsifian | Right; I thought of the zip one because of the comments on the gh issue | ||
Are you 2colours on gh? | 21:22 | ||
Nemokosch | positive | 21:24 | |
falsifian | Well, thanks for digging into it. Maybe one of these days I'll start fixing the bugs instead of just finding them :) | 21:26 | |
Nemokosch | my particular problem is that I feel there needs to be some sort of decision | 21:35 | |
because there is a clear contradiction between the supposed list associativity and the way arguments are handled | |||
21:56
jgaz left
|
|||
isn't the zip thing just because of the containers? | 22:08 | ||
m: $(<a b>) Z $(0, 1) | 22:09 | ||
Raku eval | WARNINGS for /home/glot/main.raku: Useless use of "Z" in expression "$(<a b>) Z $(0, 1)" in sink context (line 1) | ||
Nemokosch | oops | ||
m: say $(<a b>) Z $(0, 1) | |||
Raku eval | (((a b) (0 1))) | ||
falsifian | Do you mean that's the reason it's happening, or that it should happen because of that? | 22:13 | |
zip uses a single-argument-rule slurpy, and is documented as doing so. Single-argument-rule slurpies do unpack an array if it's the single argument, which would lead me to expect zip(@x) to do what I want | 22:15 | ||
m: sub f(+@a) { say @a.elems }; my @x=<a b c>; f(@x); | 22:16 | ||
camelia | 3 | ||
Manifest0 | How can i use the %?RESOURCES variable? | ||
Nemokosch | in modules of distribution | ||
is there any reason this question got so popular lately, what brought it to your attention? | 22:17 | ||
Manifest0 | sorry i had the question typed since afternoon... and i wanted to press ctrl-k to delete it. Instead i pressed ctrl-j :-| | ||
i made the question via email, cause it was easier to output the tree command. | 22:18 | ||
Sorry for the noise | |||
falsifian | Well I learned something new because of your question :) | ||
Manifest0 | falsifian: :-) | 22:19 | |
Nemokosch | it feels like this was the third or fourth question of this sort within like 2 days so it makes one wonder | ||
but yeah, distribution-related compile-time variables are only set in modules; I wonder if precompilation is also required for them to work | 22:20 | ||
i.e would they still work with no precompilation; set? | |||
Manifest0 | i can test it. How do i disable the precompilation? | 22:21 | |
Nemokosch | with that line of code | 22:23 | |
you can just add it somewhere at the beginning I guess | |||
Manifest0 | do you mean outside of a function? | 22:27 | |
it runs outside a function and also inside a INIT block | 22:29 | ||
Nemokosch | with no precompilation; added? | 22:31 | |
I mean I sure hope it doesn't downright require precompilation to work 😄 but wouldn't be sure | |||
Manifest0 | i don't know... This was the code i used: paste.opensuse.org/pastes/20cada3ce353 | 22:36 | |
Nemokosch | well... you could just put no compilation; in front? 😄 | 22:37 | |
that's literally the pragma | |||
docs.raku.org/language/pragmas.htm...ompilation | |||
Manifest0 | oh. let me try | 22:38 | |
Still works | 22:39 | ||
Nemokosch | nice | ||
then that's probably it. It works within modules of a distribution | 22:40 | ||
falsifian: back to the zip | 22:58 | ||
what you have there is indeed a single argument slurpy and the top layer is not the problem | 22:59 | ||
22:59
habere-et-disper joined
|
|||
the problem is that this array looks like (A, B) | 22:59 | ||
where A and B are items | |||
the problem is with A and B - they have containers | 23:00 | ||
zip([<a b>, <1 2>]) is meant to be identical with $(<a b>) Z $(<1 2>) - as you can say, it expands nicely to two arguments, that's not the problem | 23:02 | ||
the containers are | |||
s / say / see | |||
falsifian | I'm a but fuzzy on containers, but I don't see why an argument being a container should matter here, when in many other situations it's transparent. | 23:16 | |
m: my @x = (<0 1>, <a b>); say [Z] @x | 23:17 | ||
camelia | ((0 a) (1 b)) | ||
falsifian | Also, isn't that ^ inconsistent with zip either way? | ||
To be clear I'm arguing about what I want to happen. No clue about what's actually happening. | |||
23:17
habere-et-disper left
|
|||
Nemokosch | m: my @x = (<0 1>, <a b>); say [~] @x; | 23:19 | |
Raku eval | 0 1a b | ||
Nemokosch | as you can see, the reduction itself also takes containers into account | ||
on the other hand, [Z] does actually omit the containers, lol | 23:26 | ||
falsifian | What does the ~ example show? Output is the same as $(<0 1>) ~ $(<a b>) or just <0 1> ~ <a b> | 23:36 | |
Nemokosch | yes, fair enough... I tripped myself up big time | 23:37 | |
still I think eventually it should work the same way as @x[0] Z @x[1] ; both should actually | 23:41 | ||
it would be good to know why anybody thought acting upon containerisation for Z and X was a good idea | 23:45 | ||
falsifian | Just saw your explanation on gh #5247; thanks. I guess it is all consistent, in an annoying way. | 23:54 | |
Nemokosch | it irks me that [Z] does "the right thing", though, like apparently somebody did think of that a long long time ago | 23:56 | |
to be honest, all this could be made consistent but that would require a level of collaboration that wasn't prevalent for many years | |||
hasn't been, rather | 23:57 | ||
falsifian | The Perl and Raku conference is in my hometown this year. Maybe I should crash it in order to badger people about this. | 23:59 |