🦋 Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku
Set by ChanServ on 14 October 2019.
00:01 JRaspass left 00:03 sena_kun joined 00:05 Altai-man_ left 00:14 guifa2 left 00:16 hungrydonkey joined 00:19 Voldenet left 00:20 Voldenet joined, Voldenet left, Voldenet joined, stoned75 left 00:22 stoned75 joined 00:29 xinming left 00:30 xinming joined 00:44 hungrydonkey left 00:56 dataangel left 01:00 aborazmeh joined, aborazmeh left, aborazmeh joined 01:22 a3r0_ is now known as a3r0 01:23 JRaspass joined
codesections is this the correct/preferred way to create a list from two lists? 01:32
m: |(1, 2), |(3, 4)
camelia ( no output )
codesections or is there a better way? That looks off to me, somehow
m: say |(1, 2), |(3, 4) 01:33
camelia 1234
timotimo m: say (flat (1, 2), (3, 4)).raku 01:41
camelia (1, 2, 3, 4).Seq
timotimo when there's two lists inside of an array, the array will be holding the lists in scalar containers, which means "don't flatten me"
gnite!
codesections thanks! I was about to ask if that's better. It's fewer terms but more characters. 01:42
01:54 molaf left 01:56 guifa2 joined 02:02 Altai-man_ joined 02:03 guifa2 left 02:04 sena_kun left 02:05 Manifest0 left, Manifest0 joined 02:06 molaf joined 02:08 aborazmeh left 02:18 wamba joined
cpan-raku New module released to CPAN! LibXML (0.5.5) by 03WARRINGD 02:19
02:36 guifa2 joined 02:43 wamba left, AlexDaniel left 02:44 AlexDaniel joined 02:45 xinming left, AlexDaniel left, AlexDaniel joined 02:46 xinming joined 02:55 MasterDuke left 03:03 El_Che left 03:04 El_Che joined 03:07 guifa2 left 03:11 guifa2 joined 03:15 epony left 03:16 eponym joined 03:26 vike1 joined 03:27 vike left 03:29 Kaiepi joined 03:34 vike1 left 03:37 rbt left, rbt joined 03:49 eponym left 03:50 epony joined
holyghost I just started my evolutionary computation, introductory book, I'll make a genetic algorithm package (on github) with it 03:57
I extended one in C++ in 2001
it needs to be useful for optimization and constraint problems 03:58
Also, I have to watch out for polynomial time, so I have to very clear that the code is somewhat auto-optimezed in surplus 03:59
*optimized
04:00 guifa2 left
holyghost I am going to do all that during summer vacation 04:00
I can write one out of the top of my head, but reading an extra book should'nt hurt 04:01
I did genetic algorithms for my Master CS thesis
04:03 sena_kun joined 04:05 Altai-man_ left 04:13 melezhik joined 04:15 xinming left 04:16 xinming joined 04:18 melezhik left 04:38 aluaces joined 04:40 JRaspass left 04:59 rindolf joined 05:01 nebuchadnezzar joined 05:07 molaf left 05:10 OpenZen left 05:16 sarna joined 05:24 vike1 joined 05:26 bocaneri joined 05:36 antoniogamiz joined
antoniogamiz timotimo, have you seen github.com/timo/json_fast/pull/68? 05:37
05:45 antoniogamiz left, antoniogamiz joined 06:02 Altai-man_ joined 06:04 sena_kun left 06:42 epony left 06:43 epony joined
antoniogamiz which test statement do you use to compare (equality) of two objects of the same class? 06:46
07:01 antoniogamiz left 07:02 dolmen joined
timotimo usually eqv does what you want 07:06
07:12 pecastro joined 07:13 sarna left
Altai-man_ releasable6, status 07:32
releasable6 Altai-man_, Next release in ≈11 days and ≈11 hours. There are no known blockers. Changelog for this release was not started yet
Altai-man_, Details: gist.github.com/b3cb8c7c340fda4e22...df38353e55
07:35 dakkar joined 07:42 JJMerelo joined
JJMerelo Hi, here's the search report for raku.org the past June drive.google.com/file/d/1cKWIVe8B7...sp=sharing 07:43
I really have no idea what's the deal with raku.org/archive/rfc/102.html 07:44
There's a link to www.perl6.org, which is redirected, but maybe that link should be included in the red-background note. 07:45
07:45 squashable6 left, squashable6 joined
JJMerelo BTW, this RFC raku.org/archive/rfc/1.html will be 20 years old in 3 weeks. 07:46
Are we planning any celebration?
Equivalent for docs.raku.org drive.google.com/file/d/1s8J447eHl...sp=sharing Arrays are popular! (and findable) 07:50
releasable6: status
releasable6 JJMerelo, Next release in ≈11 days and ≈11 hours. There are no known blockers. Changelog for this release was not started yet
JJMerelo, Details: gist.github.com/cbd6c71b3efb2c6583...6822f707c2
08:03 sena_kun joined 08:04 telex left 08:05 Altai-man_ left 08:06 telex joined 08:09 eseyman left 08:10 eseyman joined 08:25 leont joined 08:42 xinming left 08:43 xinming joined 08:58 antoniogamiz joined
lizmat clickbaits rakudoweekly.blog/2020/07/06/2020-...beginning/ 09:02
09:03 oddp joined 09:05 Black_Ribbon left 09:07 Manifest0 left 09:08 Manifest0 joined 09:09 cpan-raku left 09:10 cpan-raku joined, cpan-raku left, cpan-raku joined 09:14 AlexDaniel left, AlexDaniel joined 09:16 AlexDani` joined 09:19 AlexDaniel left, hungrydonkey joined
moritz lizmat++ 09:21
awesome weekly, and I appreicate how much work it must have been to assemble all that stuff 09:22
lizmat thank you
09:23 JJMerelo left 09:27 Xliff joined
lizmat AlexDaniel` gist.github.com/lizmat/ab20653dfb0...1575768d31 # minimal attempt 09:29
and it turns out that even something like this: 09:30
my $l = ^10 .map: * * 2; say $l.AT-POS(1); say $l.AT-POS(0); say $l.^name
evalable6 2
0
Seq
09:30 aborazmeh joined, aborazmeh left, aborazmeh joined
lizmat does *not* die. I have no idea why the new AT-POS isn't being called, suspect something deep in the bowels 09:31
and thus stops my attempt
[ptc] lizmat++ re: weekly 09:38
09:43 JJMerelo joined
AlexDani` lizmat: O_O 09:45
09:45 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 09:47 xinming left
AlexDaniel lizmat: ah, because of this I guess? github.com/rakudo/rakudo/blob/a745...m6#L60-L66 09:48
09:49 xinming joined
lizmat no, because the AT-POS in Seq should shadow that ? 09:49
AlexDaniel should it? You provided just the `int` candidate. Also, what's ::?CLASS:D: ? 09:50
lizmat the proto should mask all other candidates 09:51
AlexDaniel protos can mask candidates?
I didn't know that
lizmat m: role A { multi method a(Int:D $a) { "Int" } }; class B does A { }; say B.a(42) 09:53
camelia Int
lizmat m: role A { multi method a(Int:D $a) { "Int" } }; class B does A { proto method a(|) { } }; say B.a(42)
camelia Nil
AlexDaniel lizmat: okay, but it's not that 09:54
m: role Bar { multi method blah(::?CLASS:D: Int:D $idx) is raw { note “Bar Int $idx” }; multi method blah(::?CLASS:D: int $idx) is raw { note “Bar int $idx” }; }; class Foo does Bar { proto method blah(|) {*} }; Foo.new.blah(42)
camelia Bar Int 42
AlexDaniel lizmat: ↑
so ::?CLASS:D: thing will make it end up in the class, or something?
that is, where the proto is
hmm no… 09:55
m: role Bar { multi method blah(Int:D $idx) is raw { note “Bar Int $idx” }; multi method blah(int $idx) is raw { note “Bar int $idx” }; }; class Foo does Bar { proto method blah(|) {*} }; Foo.new.blah(42)
camelia Bar Int 42
AlexDaniel m: role Bar { multi method blah(Int:D $idx) { note “Bar Int $idx” }; multi method blah(int $idx) { note “Bar int $idx” }; }; class Foo does Bar { proto method blah(|) {*} }; Foo.new.blah(42) 09:56
camelia Bar Int 42
AlexDaniel am I doing something completely wrong?
lizmat you mean it not selecting the int candidate ?
AlexDaniel AH 09:57
I see
m: role A { multi method a(Int:D $a) { "Int" } }; class B does A { proto method a(|) {*} }; say B.a(42)
camelia Int
AlexDaniel lizmat: this is your example
all I did is changed {} to {*}
so a proto with {*} doesn't shadow but the one with {} does? 09:58
09:58 guifa2 joined
dakkar AFIK `{*}` means "delegate to the matching multi candidate" 09:58
lizmat hmmm.... either should shadow 09:59
dakkar m: role A { multi method a(Int:D $a) { "Int" } }; class B does A { proto method a(|) { say "in B";{*}; say "leaving B" }; say B.a(42)
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> 3n B";{*}; say "leaving B" }; say B.a(42)7⏏5<EOL>
expecting any of:
postfix
statement end
statement modifier
stat…
dakkar m: role A { multi method a(Int:D $a) { "Int" } }; class B does A { proto method a(|) { say "in B";{*}; say "leaving B" }}; say B.a(42)
camelia in B
leaving B
True
AlexDaniel lizmat: either way it's {*} in Sequence.pm6 so that's why
dakkar: oooooh 10:01
so protos can have bodies
dakkar yes
nice way to factor out behaviours
AlexDaniel dakkar: I wouldn't necessarily call it nice but it is potentially useful indeed
dakkar I think there can be at most 1 proto for each multi, though; you need `.wrap` for more complicated cases 10:02
10:02 Altai-man_ joined
AlexDaniel lizmat: ah, it's other way around, in your patch it should be {} if you want it to shadow 10:02
lizmat yeah, but then it won't dispatch 10:03
AlexDaniel it is documented beautifully btw docs.raku.org/syntax/proto
lizmat and if I make the Seq.AT-POS an only method, it won't even build
AlexDaniel lizmat: you can put the code right into the proto x) 10:04
10:05 sena_kun left
AlexDaniel lizmat: or, actually, just add the right candidate 10:06
the candidate itself will shadow the existing one
it's just that `int` one doesn't do much for `Int`
lizmat go ahead! 10:07
10:16 markoong joined 10:19 markoong is now known as kongmar, kongmar is now known as margeas 10:20 margeas is now known as markoong, markoong left 10:21 markoong joined, markoong left 10:22 markoong joined 10:28 aborazmeh left 10:33 xinming left 10:34 xinming joined 10:39 antoniogamiz left 10:40 guifa2 left 10:42 guifa2 joined
AlexDaniel lizmat: now things behave in the weirdest way possible 10:50
c: remove-Seq-nonsense my $s = <a b c>.words; say $s[0]; say $s[0]; say $s[0]
committable6 AlexDaniel, ¦remove-Seq-nonsense: «Cannot find this revision (did you mean “car-grant-unreduce”?)»
AlexDaniel hmmmm 10:51
lizmat AlexDaniel: what I said, the caching behaviour is *deeply* ingrained in the system
AlexDaniel it's not the caching, hold on…
lizmat well, expect weird erroring :-)
AlexDaniel c: remove-Seq-nonsense my $s = <a b c>.words; say $s[0]; say $s[0]; say $s[0]
committable6 AlexDaniel, ¦remove-Seq-nonsense: «Cannot test this commit (Commit exists, but an executable could not be built for it)»
AlexDaniel c: c9a4f07de2dbe7 my $s = <a b c>.words; say $s[0]; say $s[0]; say $s[0] 10:52
committable6 AlexDaniel, ¦c9a4f07: «Cannot test this commit (Commit exists, but an executable could not be built for it)»
AlexDaniel no no it builds
anyway the output of that is a␤b␤c␤
10:52 xinming left
lizmat if you're not caching, it should have died on the second $s[0] 10:53
AlexDaniel and if you print [1] then that's Nil
10:54 xinming joined
AlexDaniel ooooh 11:00
it can build but it cannot install! 11:01
that's why committable6 is confused
lizmat welcome to the nightmare :-)
AlexDaniel lizmat: it actually looks pretty easy 11:02
No such method 'skip' for invocant of type 'Rakudo::Iterator::OneValue'. Did you mean any of these: 'Slip',
so OneValue doesn't have .skip, which AT-POS is currently using
lizmat [00:02:46] <lizmat>I sorta half expect it will build, but that installing the core modules *will* fail
AlexDaniel it's not so much about the change but about calling .skip on iterators
lizmat OneValue does Iterator, which has a .skip method 11:03
it's even a PredictiveIterator
m: dd Rakudo::Iterator.OneValue(42).skip 11:04
camelia No such method 'skip' for invocant of type
'Rakudo::Iterator::OneValue'. Did you mean any of these: 'Slip',
'skip'?
in block <unit> at <tmp> line 1
lizmat this is weird
ah, the method is called "skip-one"
it's confusing the Seq with the underlying iterator
m: dd Rakudo::Iterator.OneValue(42).skip-one 11:05
camelia 0
AlexDaniel that's ok, I'll tweak it real quick
cpan-raku New module released to CPAN! XML::Actions (0.4.6.1) by 03MARTIMM 11:23
11:26 guifa2 left 11:27 guifa2 joined
AlexDaniel lizmat: ok. Now it builds, installs and works 11:29
will wait a bit for committable to catch up to show it
11:35 sarna joined 11:41 rbt left 11:42 rbt joined
AlexDaniel c: remove-Seq-nonsense my $s = <a b c>.words; say $s[0]; say $s[0]; say $s[0] 11:42
committable6 AlexDaniel, ¦remove-Seq-nonsense: «a␤asked 0, which was already produced␤␤ «exit code = 1»»
AlexDaniel c: remove-Seq-nonsense my $s = <a b c>.words; say $s[0]; say $s[1]; say $s[2]
committable6 AlexDaniel, ¦remove-Seq-nonsense: «a␤b␤c␤»
AlexDaniel c: remove-Seq-nonsense my $s = <a b c>.words; say $s[0]; say $s[1]; dd $s
committable6 AlexDaniel, ¦remove-Seq-nonsense: «a␤Seq $s = $(("c",).Seq)␤b␤»
AlexDaniel c: remove-Seq-nonsense my $s = <a b c>.words; say $s[0]; say $s[1]; say $s
committable6 AlexDaniel, ¦remove-Seq-nonsense: «a␤b␤(c)␤»
AlexDaniel so that works
masak ahoy, #raku 11:53
AlexDaniel hey 11:54
11:54 xinming left 11:55 xinming joined 12:03 sena_kun joined 12:05 rindolf left, Altai-man_ left 12:07 JJMerelo left
moritz \o masak, long time no see! 12:08
12:12 xinming left 12:13 xinming joined 12:22 rindolf joined 12:23 xinming left 12:29 vike1 left 12:30 xinming joined 12:37 vike joined 12:40 xinming left 12:41 xinming joined
tadzik masak: \o/ 12:47
masak \o/ 12:50
moritz: indeed. I'll try to appear more often 12:51
I'm a bit time-zone-challenged, but that's not really an excuse 12:52
12:52 xinming left 12:53 xinming joined 13:21 sarna left 13:22 RaycatWhoDat joined
tadzik everything can be a morning when you're on IRC :) 13:34
13:35 stoned75 left 13:36 stoned75 joined
RaycatWhoDat put that on a mug 13:38
I'd buy it
[Coke] guten tag, masak! 13:39
14:00 titsuki joined 14:02 Altai-man_ joined 14:05 sena_kun left
codesections From the docs for the `==>` operator: "Note: In the future, this operator will see some change as it gains the ability to run list operations in parallel." Based on the way my code is behaving, it appears that `==>` is currently running operations in parallel. Is that right? 14:16
tadzik congratulations, you're in the future :) 14:17
oddp Example code? 14:18
codesections The future is now, as they say :D
moritz our usual line is that on IRC, we leave in the "UGT" time zone ("universal greeting time"), and "It's always morning in UGT!" :-) 14:22
codesections "example code?" … actually, now I'm confused. From the docs, I previously thought these two expressions meant the same thing (with alternate syntax): 14:28
m: (^1000000).map({~$_ })
camelia ( no output )
codesections (^1000000) ==> map({~$_ }) 14:29
but, from my code, I thought they were different, in that the second was parallel (and thus would be faster)
but when I ran `time raku -e ` with both expressions, the first was 3× faster 14:30
"It's always morning in UGT!" I'm also a fan of "time appropriate greetings!", as they say on Linux Unplugged 14:32
AlexDaniel codesections: it's unlikely that it will ever run stuff in parallel just like that 14:35
codesections Ok, good to know, thanks.
So why the speed difference?
AlexDaniel codesections: that's my personal opinion, official position may differ :) 14:36
Voldenet m: (^20) ==> map(*.say)
camelia 0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
14:36 softmoth joined
AlexDaniel codesections: well, “why the speed difference?” can be asked about everything. Should a method form of some operation be the same as the sub performance-wise? (e.g. .substr vs substr, stuff like that) 14:37
codesections: the answer is always yes, but the reality is different
see, rakudo was built with an idea that later the compiler will do magic and everything will become fast 14:38
so the result is expected, you cannot have any performance expectations besides “poor” :P 14:39
jnthn I think Raku as a language was designed on the premise that there'd eventually be a sufficiently smart compiler :)
codesections hmm, yeah, I get that. But there's a difference between two different expressions that "should" have the same performance and two different *syntaxes* that create the same expression 14:40
AlexDaniel codesections: it's very likely you can do a bit of hackety hacking on rakudo and improve the performance of that specific case 14:41
codesections and (from the docs), I thought that the feed operator and method chaining were literally two ways of writing the same thing
am I wrong about that?
jnthn Yes. 14:42
For one, the feed operator is about using subs
14:42 xinming left
codesections (The example in the docs says: `@array ==> sum() ==> say(); # OUTPUT: «15␤»` is the equivalent of writing: @array.sum.say; # OUTPUT: «15␤»` 14:43
14:43 xinming joined
codesections ) 14:43
jnthn At least in the standard language, if you didn't redefine any of the subs involved, they'll get the same thing, but they get there by different ways. 14:44
tobs equi*val*ent but not equi*how*ent
codesections Interesting.
14:48 softmoth left
AlexDaniel jnthn: yeah, that too, and in the end the language itself is wasting resources left and right. Wanna know the number of elements in a seq? Great, it will make sure *all of the elements* are stored at the same time. If the compiler was smart enough to optimize that away it'd also be smart enough not to be a Raku compiler. 14:49
jnthn: speaking of the language design, do you think there's an implied contract that iterating a Seq will give all elements of that Seq? 14:53
that is, that you won't ever get leftovers of the SEq 14:55
Seq*
jnthn Surely not, you could lose interest after N elements (such as .head($n)). Infinite lazy sequences will always have something unused. 14:56
AlexDaniel jnthn: I'm talking about the first elements actually
though judging by your answer it sounds like this wasn't intentional and just happens to be that way 14:57
jnthn Example?
AlexDaniel c: HEAD sub here-we-get-a-seq($seq) { say ‘all elements of the seq:’; .say for $seq }; my $s = <a b c>.words; say $s.head; here-we-get-a-seq $s 14:59
committable6 AlexDaniel, gist.github.com/a004045f988ba7acbe...7aa77b8f89
AlexDaniel jnthn: this behavior
jnthn That output looks disordered? 15:00
AlexDaniel yeah, that's ok, that's just how stderr/stdout is
jnthn yeah, it is 15:01
AlexDaniel c: HEAD sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; .note for $seq }; my $s = <a b c>.words; note $s.head; here-we-get-a-seq $s
committable6 AlexDaniel, gist.github.com/d4c0e4bdcb972b383e...da9372268f
jnthn Yes, it's the correct output; you've already consumed the Seq by .head obtaining the iterator from it.
So the second attempt to obtain the iterator throws
AlexDaniel c: 95cadc8916 sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; .note for $seq }; my $s = <a b c>.words; note $s.head; here-we-get-a-seq $s
committable6 AlexDaniel, ¦95cadc8: «a␤all elements of the seq:␤The iterator of this Seq is already in use/consumed by another Seq␤(you might solve this by adding .cache on usages of the Seq, or␤by assigning the Seq into an array)␤␤ «exit code = 1»»
AlexDaniel huh. 15:02
okay not sure I understand why that doesn't work 15:03
but it's good to know that it can be that way too…
okay, nevermind… hmm
c: 95cadc8916 sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; note $seq }; my $s = <a b c>.words; note $s.head; here-we-get-a-seq $s
committable6 AlexDaniel, ¦95cadc8: «a␤all elements of the seq:␤The iterator of this Seq is already in use/consumed by another Seq␤(you might solve this by adding .cache on usages of the Seq, or␤by assigning the Seq into an array)␤␤ «exit code = 1»»
AlexDaniel c: 95cadc8916 sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; note $seq[1..*] }; my $s = <a b c>.words; note $s.head; here-we-get-a-seq $s 15:04
committable6 AlexDaniel, ¦95cadc8: «a␤all elements of the seq:␤The iterator of this Seq is already in use/consumed by another Seq␤(you might solve this by adding .cache on usages of the Seq, or␤by assigning the Seq into an array)␤␤ «exit code = 1»»
AlexDaniel c: 95cadc8916 sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; note $seq[1] }; my $s = <a b c>.words; note $s.head; here-we-get-a-seq $s
committable6 AlexDaniel, ¦95cadc8: «a␤all elements of the seq:␤Method 'pull-one' must be implemented by Iterator because it is required by roles: Iterator.␤␤ «exit code = 1»»
AlexDaniel c: 95cadc8916 sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; note $seq[1] }; my $s = <a b c>.words; note $s[0]; here-we-get-a-seq $s 15:05
committable6 AlexDaniel, ¦95cadc8: «a␤all elements of the seq:␤b␤»
AlexDaniel c: 95cadc8916 sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; .say for $seq }; my $s = <a b c>.words; note $s[0]; here-we-get-a-seq $s
committable6 AlexDaniel, ¦95cadc8: «a␤(b c)␤all elements of the seq:␤»
AlexDaniel c: 95cadc8916 sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; .note for $seq }; my $s = <a b c>.words; note $s[0]; here-we-get-a-seq $s
committable6 AlexDaniel, ¦95cadc8: «a␤all elements of the seq:␤(b c)␤»
AlexDaniel jnthn: so you'd say this is illegal and I should call the police? :)
or that [] should be smart enough to mark the Seq as consumed so that nobody is able to iterate it that way later? 15:06
jnthn Yes. And I'm confused how that happens, given that .cache should surely just call .iterator and find the iterator already gone...
Voldenet I do wonder what… 15:07
m: sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; .note for $seq }; my $s = <a b c>.words; note $s[1]; here-we-get-a-seq $s
camelia b
all elements of the seq:
(a b c)
Voldenet m: sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; .note for $seq }; my $s = <a b c>.words; note $s[0]; here-we-get-a-seq $s
camelia a
all elements of the seq:
(a b c)
Voldenet c: 95cadc8916 sub here-we-get-a-seq($seq) { note ‘all elements of the seq:’; .note for $seq }; my $s = <a b c>.words; note $s[1]; here-we-get-a-seq $s
committable6 Voldenet, ¦95cadc8: «b␤all elements of the seq:␤(c)␤»
jnthn AlexDaniel: oh wait, I misread... 15:08
AlexDaniel: I thought you had left in the call to .head before indexing...
Thus my confusion.
m: my $s = <a b c>.words; note $s.head; note $s[0]; 15:09
camelia a
The iterator of this Seq is already in use/consumed by another Seq
(you might solve this by adding .cache on usages of the Seq, or
by assigning the Seq into an array)
in block <unit> at <tmp> line 1
jnthn That's what I was expecting
Or rather, that's what I was expecting from the eval I thought you did, but you didn't
AlexDaniel Voldenet: yep, so currently if you try to index a Seq with [] it turns it into a list pretty much. If you're not careful, you can get very large Seqs cached without your explicit consent :P
jnthn Well, largely because .[...] in all of its forms depends on an indexable list 15:10
AlexDaniel which wouldn't've been a problem if you were able to name all operations that do that from the top of your head :)
cpan-raku New module released to CPAN! Gnome::Cairo (0.1.1.1) by 03MARTIMM
AlexDaniel jnthn: ok, name all operations that make Seqs cached
[] is one, fine, what else?
I learned about some by looking at the source code 15:11
15:11 dataangel joined, tecxxx joined
jnthn Everything that [] depends on, thus I'd expect .elems, .AT-POS, and .EXISTS-POS 15:11
AlexDaniel what else? 15:12
Voldenet AlexDaniel: it's not really a big problem, `(^1e100).elems.say` would probably OOM
jnthn Binding to an @-sigil'd parameter
AlexDaniel more?
Voldenet so the weird caching behaviour seems to be already there
jnthn Note that numerous things *do* bind to an @ sigi'd parameter, so that is quite sweeping.
AlexDaniel there are more specific ones. But regarding the @ sigil, as a user how can I know if something does or does not do that? 15:13
15:14 melezhik joined
jnthn I believe .gist and .perl do too, "naughtily", to prevent debugging insertions breaking your code. That's a pragmatic rather than a pure one. 15:14
tecxxx Can anybody help me with building executsble?
jnthn (Presumably .Str too)
AlexDaniel yes, and also .Str
jnthn: I'm actually very impressed
melezhik Next RakuOps issue is going to be about "How to manage multiple hosts using Sparrowdo", here is the draft - github.com/melezhik/sparrowdo/wiki...amic-hosts 15:15
AlexDaniel I had no idea about all that before
melezhik based on u/bobthecimmerian comment in reddit
jnthn How do *I* know when there's an @-sigil? Honestly, often parameter info in the IDE :P I suspect if we went through various of the sub forms of the list operations we'd find some questionable inconsistencies between +foo and +@foo taking things... 15:16
melezhik feedback is welcome on this stage ... so I could clarify knowing questions ahead of time
tecxxx Can i create executable with rakudo?fg 15:17
AlexDaniel jnthn: maybe the IDE should even underline methods/subs that will cache a Seq, if it knows that it's dealing with a Seq that is
15:17 titsuki left
jnthn AlexDaniel: I was pretty much "at the table" when .cache came to be...and the main motiviation was array indexing and not making everyone write .list on the callee side when doing things like foo(@bar.grep(/baz/) 15:18
There was also discussion of a method like .slice that enforced ascending order on the indices, so it could discard as it went 15:20
(And if the indices were not ordered, it would be an exception) 15:21
That never actually happened.
tecxxx: No, there's not a means to do that yet 15:22
tecxxx Can i run raku on Android? 15:26
dakkar tecxxx: sort-of
tecxxx: twitter.com/dakkar/status/1134191160979808256 15:27
jnthn AlexDaniel: I'm not so sure about caching going away entirely (yet...), though I do wonder if making the various array indexing overloads have candidates for Sequence, which call .list and delegate, could have been better. In that the single element case doesn't especially need caching all the elements. 15:30
AlexDaniel: .elems is only really doing it for .[*-1], so far as I recall
My gut feeling is that if we did Sequence candidates for indexing that .list and delegate, and then we make positional bind failover call .list and bind that, getting rid of the caching might maybe kinda just squeak through but that doesn't yet answer .gist/.elems and friends. 15:31
15:32 tecxxx left
jnthn oops, sorry, .gist/.Str 15:32
I'm designing the RakuAST nodes for the regex langauge, so my brain is only half on this :)
15:34 petrtexx joined 15:36 petrtexx left 15:44 rbt left 15:45 rbt joined 15:59 MilkmanDan left, reach_satori_ joined
AlexDaniel m: my $s = (1, { $_ + 5 } … ∞); say $s; say $s.head 16:01
camelia (...)
1
16:01 MilkmanDan joined, Tirifto joined, xinming left 16:02 xinming joined
AlexDaniel jnthn: ↑ in this case .gist doesn't do much, and that's OK. I understand that non-lazy seqs are much more common, but I don't know if it's actually going to be a problem 16:02
16:02 reach_satori left 16:03 sena_kun joined
AlexDaniel jnthn: for example, maybe dd can learn to do something crazy like consume the seq and replace the variable with another one. That sounds very bad, but it's a debugging aid, it's arguably not worse than having .gist doing the same 16:04
16:05 Altai-man_ left
jnthn AlexDaniel: I think .gist needs to give useful output for the non-lazy case, if that's what you're asking. 16:24
Though yeah, there is the trick I mentioned before of .list it and then bind a list iterator, which actually restores the one-shot-ness 16:25
16:26 suman joined
suman m: my %hash = "a" => "zz" , "c" => "yz"; say "abcd".trans: %hash 16:27
camelia zbyd
suman I was expecting zzbyzd ! 16:28
But got zbyd !
How to get zzbyzd instead?
16:29 dakkar left 16:34 squashable6 left 16:36 squashable6 joined
AlexDaniel m: say "abcd".trans: <a c> => <zz yz> 16:39
camelia zzbyzd
AlexDaniel suman: like this
and yeah it's kinda weird, but then things like `'a'..'z' => 'A'..'Z'` work fine 16:40
suman AlexDaniel Is there a way to feed a hash table to trans?
I have 40 keys and 40 values to make substitution 16:41
jnthn m: my %hash = "a" => "zz" , "c" => "yz"; say "abcd".trans: %hash.keys => %hash.values 16:42
camelia zzbyzd
AlexDaniel jnthn: is it guaranteed that they will be in the same order? 16:43
suman jnthn Exactly what I wanted. Thanks
AlexDaniel 6c: my %hash = "a" => "zz" , "c" => "yz"; say %hash.keys => %hash.values
16:43 melezhik left
committable6 AlexDaniel, gist.github.com/3a8bab072beea390ac...9771d3f628 16:43
AlexDaniel by same I mean that keys and values will be matched correctly 16:44
codesections AlexDaniel: the docs make that guarantee: 16:46
> Note that the order in which keys, values and pairs are retrieved is generally arbitrary, but the keys, values and pairs methods return them always in the same order when called on the same object.
[Coke] If you put the keys in a hash, I wouldn't expect the order to necessarily be preserved, no
you'll get them back in the same order each time you ask, but it isn't necessarily the order you put them in there.
16:46 dolmen left
codesections agreed 16:47
AlexDaniel cool
I was about to come up with a cool trick with .rotor, but it's good that there's a simpler way :) 16:48
16:56 skids joined
suman I have a long string with ascii only more than million letters. How can I check if its length is multiple of 3? I want to proceed further only if its multiple of 3. 17:06
m: say "abcdefg".chars %% 3
camelia False
suman m: say "abcdefgh".chars %% 3
camelia False
suman Are there other ways for very long strings? 17:07
m: say "abcdefghi".chars %% 3
camelia True
jnthn suman: .chars is O(1); strings are stored along with their length in Raku 17:09
AlexDaniel jnthn: as I understand the issue is with rakudo being slow with just reading a very long string
suman: is that right? 17:10
suman: if so, where are you getting this string from?
17:11 Woodi left
suman AlexDaniel raw.githubusercontent.com/sumansta...enomic.fna 17:11
Reading this sequence line by line and storing in a string 17:12
AlexDaniel suman: are newlines part of the string?
I see
suman AlexDaniel No. Needs to be trimmed.
AlexDaniel lemme play with it a bit
jnthn Probably faster to loop over the lines and add up the .chars. Also, open it with :enc<ascii> if not already doing so. 17:14
AlexDaniel suman: how fast do you need it to be?
jnthn bbl o/ 17:15
AlexDaniel reading lines and joining takes around 0.130s
which isn't really slow
jnthn: summing the numbers of characters in each line is actually a bit slower 17:16
but roughly the same
suman AlexDaniel Cam I see your code?
*Can
AlexDaniel suman: say ‘file.fna’.IO.lines.skip(1).join.chars 17:17
jdv79 random data point - looping over a file listing and matching 1 regex on each line - perl takes 5s, raku takes 128s
still quite a ways to go:( 17:18
AlexDaniel jdv79: give me the code I'll tell you how to make it faster :P
jdv79 i don't want to contort - i just want to loop nad match
that's a very common "scripting" pattern/use case for my scripting needs
AlexDaniel I'm not really trying to take the blame away from rakudo :) 17:19
jdv79: can you still show it? :)
jdv79 its boring
AlexDaniel well, let me judge :)
jdv79 i wanted to use raku's concurrency to reduce the cost of the sink of this datastream but i'm not sure it'll go fast enough to beat just perl
AlexDaniel WHERE IS THE RAKU SAAAAUCE 17:20
(youtu.be/-rLtbtvR9lg?t=120) 17:23
jdv79 nopaste.linux-dev.org/?1321452
those over a ~5M line file of aws s3 ls output 17:24
AlexDaniel jdv79: can you give me one line of that output? 17:26
jdv79 2020-07-07 11:38:27 594 s3/2020-07-07-15-38-26-9E52F44628D62037
suman AlexDaniel This is the code pastebin.com/uuTfrvPS 17:31
This is much slow. Any faster alternative?
17:32 bocaneri left 17:33 skids left
jdv79 i guess i haven't tried "scripting" in raku lately - i thought it'd be slower but not that slower;) 17:33
suman It takes 9 sec to look for the keys 17:35
jdv79 ah, it appears to be almost completely regex. makes sense.
AlexDaniel jdv79: yeah, the hash part is also playing a role in the slowness
jdv79 a hash build competes with a regex match? i find that hard to believe 17:36
AlexDaniel well it's like 10% or so 17:37
jdv79 was larry really "depressed" about the state of the regex/parser stuff? 17:38