šŸ¦‹ Welcome to the former MAIN() IRC channel of the Raku Programming Language (raku.org). This channel has moved to Libera (irc.libera.chat #raku)
Set by lizmat on 23 May 2021.
00:01 a3r0 joined 00:02 reportable6 left 00:03 reportable6 joined 00:09 lucerne left 00:30 Tirifto left 00:31 Tirifto joined 00:39 lucerne joined 00:46 Tirifto left 00:47 Tirifto joined 00:49 Eddward joined 01:01 monkey_ joined 01:24 Doc_Holliwood left 01:27 Eddward_ joined 01:30 Eddward left 01:34 monkey_ left 02:34 greppable6 left, coverable6 left, committable6 left, reportable6 left, sourceable6 left, linkable6 left, bloatable6 left, benchable6 left, evalable6 left, quotable6 left, nativecallable6 left, squashable6 left, bisectable6 left, unicodable6 left, shareable6 left, releasable6 left, statisfiable6 left, tellable6 left, notable6 left, shareable6 joined, linkable6 joined 02:35 quotable6 joined, bisectable6 joined, releasable6 joined, notable6 joined, greppable6 joined, bloatable6 joined, tellable6 joined 02:36 committable6 joined, benchable6 joined, reportable6 joined, sourceable6 joined, statisfiable6 joined 02:37 squashable6 joined, coverable6 joined, unicodable6 joined, nativecallable6 joined, evalable6 joined, utfntf98776 joined, guest39843 joined 02:55 guest39843 left 03:41 jmcgnh left 03:44 jmcgnh joined 03:51 utfntf98776 left 03:58 jmcgnh left 04:00 Sgeo_ joined 04:02 [dpk] joined, Altai-man joined 04:04 a3r0_ joined, jmcgnh joined, esh_ joined 04:05 chronon_ joined 04:09 unicodable6 left, coverable6 left, sourceable6 left, committable6 left, bloatable6 left, notable6 left, shareable6 left, a3r0 left, Sgeo left, chronon left, esh left, sena_kun left, dpk left 04:10 lucerne left 04:33 jmcgnh left 04:36 jmcgnh joined 04:59 lucerne joined, notable6 joined, unicodable6 joined, sourceable6 joined, committable6 joined 05:00 bloatable6 joined, coverable6 joined, shareable6 joined 05:41 jmcgnh left, frost joined 05:45 jmcgnh joined 06:02 reportable6 left 06:05 reportable6 joined 06:07 Eddward_ left 06:18 [dpk] is now known as dpk 06:28 Doc_Holliwood joined 06:31 abraxxa joined 06:33 lucerne left 06:34 abraxxa left 06:37 abraxxa joined 06:41 ufobat joined, frost left 06:44 abraxxa left 06:45 abraxxa joined 06:54 chronon_ left 07:05 frost joined 07:35 lucerne joined 07:36 dakkar joined 07:52 chronon joined 07:58 lucerne left 08:18 Doc_Holliwood left, Sgeo_ left 08:19 linkable6 left 08:22 linkable6 joined 09:09 simcop2387 left 09:12 simcop2387 joined 09:27 tejr left 09:32 tejr joined 10:32 linkable6 left, evalable6 left 10:33 linkable6 joined 10:34 evalable6 joined 11:06 Doc_Holliwood joined 11:16 samebchase left, samebchase joined 11:18 holyghost joined 11:29 razetime2 joined 11:41 razetime2 left 11:50 frost left 11:57 Razetime joined 12:02 reportable6 left 12:04 reportable6 joined 12:25 Razetime left 12:32 sftp joined 13:06 RandalSchwartz left 13:09 RandalSchwartz joined 13:35 rassoc joined
rassoc What's the rational behind implementing the safe call operator in such a way that you can't chain them? Aren't we missing a Nil overload for cases like these? Any.?comb.?comb 13:37
Ruby just returns nil for: nil&.chars&.digits 13:39
dakkar looks like it's a `comb` issueā€¦ 13:40
m: Any.?foo.?bar
camelia ( no output )
dakkar m: Any.?foo.?comb 13:41
camelia Use of Nil.comb coerced to empty string
in block <unit> at <tmp> line 1
dakkar m: Any.?comb.?comb
camelia Use of Nil.comb coerced to empty string
in block <unit> at <tmp> line 1
dakkar (oh, I'm running an old rakuā€¦) 13:42
rassoc: what did you expect to happen?
m: say Any.?comb.?comb 13:43
camelia Use of Nil.comb coerced to empty string

in block <unit> at <tmp> line 1
dakkar (I hope that's a warningā€¦)
ugexe m: say Any.?comb.WHAT; say Nil.comb;
camelia Nil
Use of Nil.comb coerced to empty string

in block <unit> at <tmp> line 1
rassoc Hm, might be the old compiler again, but i am seeing:
Cannot resolve caller comb(Nil:U: ); none of these signatures match ...
dakkar yep, 2021.02 here prints that error
so yes, Nil.comb died, now warns 13:44
rassoc alright, thanks! 13:46
13:47 Tirifto_ joined 13:49 Tirifto left
dakkar (let's ignore that `.comb.comb` doesn't do anything usefulā€¦) 13:58
m: say "'$_'" for 'abc'.comb.comb
camelia 'a'
' '
'b'
' '
'c'
14:23 Doc_Holliwood left 14:28 holyghost left 14:43 Sgeo joined 14:44 Doc_Holliwood joined 14:48 just_testing joined 14:49 just_testing left 14:56 raydiak joined
raydiak rba: I got to digging again, and it turns out that SSL error a few of us in the US get on the docs site, is a likely symptom of being blocked (in a rather bizarre way) by Comcast "Xfi Advanced Security". :P I know some affected users were on Cox, but it turns out that Cox licenses various tech from Comcast, so probably the same issue. Comcast has a web form specifically for this nonsense, so I sent them a 15:06
(somewhat pointed) unblocking request. I'll let you know if/when it gets fixed or I hear anything back.
From my searches, there appears to be a substantial number of random sites affected by this, it's nothing we actually did wrong afaik. 15:07
In the mean time if anyone else asks you about it, tell them they can disable Xfi Advanced Security screwery from somewhere in their Xfinity account settings (according to what I read; I haven't tried it) 15:09
15:24 Eddward_ joined
MasterDuke fwiw, recently it's been blocked for me. Sky Broadband Shield thinks not suitable for teens or adults. i've emailed them saying it's a miss-categorization (and manually added it as allowed for my account), but i have no idea how long that request will take to process 15:31
just docs.raku.org, raku.org itself is not blocked
Altreus this censorship nonsense is taking the piss 15:32
15:43 Doc_Holliwood left
El_Che It's crazy how the country with the biggest IT industry is so backwards regarding technology 16:09
16:20 gordonfish- is now known as gordonfish
lizmat there's some politics involved as well, surely ? :-) 16:21
El_Che hoe the champions of free enterprise is the champion of monoploies 16:23
monopolies
Ok, i'll leave my self out :) 16:24
jdv idk how that's "backwards". i'd guess its a mix of politics and less regulated capitalism 16:43
El_Che I see it more as hypocresy 16:44
guifa is it safe to assume that an nqp method like nqp::islt_i($foo, $bar) will always handle an Int (assuming it's small enough for int)? Or should we make sure to call nqp::unbox? 16:57
16:59 MoC joined
lizmat this is really backend specific 17:03
I'm 100% sure you don't need to do that for the MoarVM backend
sorta 100% sure you don't need to do that on the JVM backend anymore (usev6++) 17:04
for the JS backend: no idea...
if the Int is not small enough, it *will* bomb, and not silently truncate 17:05
guifa Alright. So I'm probably overkilling by doing the unbox 17:10
17:11 Tirifto_ left
lizmat I usually don't bother anymore :-) 17:11
dakkar (usual plea to avoid as much as possible to use `nqp` in ecosystem modulesā€¦ because `nqp` is not part of Rakudo)
guifa dakkar: this isn't for a module :-)
dakkar then use all the nqp to your heart's content ā˜ŗ 17:12
guifa well, it is, but only for testing. Then into core assuming RSC approves of my proposal
dakkar it would be nice to have a way to mark modules as "rakudo" modules instad of "raku" modules, or something like that 17:13
(also I notice I used the wrong name before, dammit)
17:14 Tirifto joined 17:16 dogbert17 joined
jdv it would be nice if there wasn't a way to do that since a common retort is to "do it in a module first" 17:17
ugexe "depends" : ["rakudo:from<bin>"] 17:18
dakkar my thinking was to minimise the risk of rakudo/raku/nqp being like Perl/perl/xs, where a non-perl implementation of Perl is essentially not viable because a large part of CPAN depends on XS 17:25
lizmat dakkar: I think that XS is the drug that keeps Perl from moving to a multi-processor world 17:30
17:34 dakkar left
jdv i'm not sure nqp and xs is a fair comparison, in more than one way 17:41
rjbs XS is definitely a big ball and chain. 17:44
tbrowder raydiak: nice debugging on the dns thing. any hope for cox users? 17:50
i'll try elevating the info you found to cox tech support (i'm not real optimistic) 17:53
18:02 ufobat_ joined, reportable6 left 18:04 reportable6 joined 18:05 ufobat left
demostanis[m] `[*] grep { first * + any(@values) + $_ == 2020, @values }, @values 18:06
`
This code has been running since 3 minutes already
With 200 @values 18:07
adventofcode.com/2020/day/1/input
It works well with 4 values tho
Is my code just not optimized at all or is Raku just slow?
18:08 MoC left
demostanis[m] Oh my god it finally completed 18:09
It only took like 5 minutes.
codesections demostanis[m]: a bit of both, I think. Junctions are a particularly slow point as of yet (if I understand correctly ) 18:10
demostanis[m] Junctions are so great to use tho 18:11
codesections yeah, agreed
github.com/codesections/advent-of-raku-2020 has a bunch of different Raku solutions for day 1, if you want to compare performance 18:12
(Thinking through the time complexity of the code you posted, it does seem like a fairly un-optimized way to get there) 18:15
18:15 codesect` joined 18:18 codesections left 18:25 codesect` left 18:26 codesections joined
codesections demostanis[m]: I got curious and decided to double check, and that solution is definitely O(nĀ²), which explains a big chuck of the slowness. 18:29
m: my $i=0; my @v = 42 xx 5; [*] grep -> $a { @v.first({ $i++; $_ + any(@v) + $a == 2020})}, @v; say $i 18:30
camelia Potential difficulties:
Useless use of [*] in sink context
at <tmp>:1
------> 3my $i=0; my @v = 42 xx 5; 7ā5[*] grep -> $a { @v.first({ $i++; $_ + a
25
codesections m: my $i=0; my @v = 42 xx 10; [*] grep -> $a { @v.first({ $i++; $_ + any(@v) + $a == 2020})}, @v; say $i
camelia Potential difficulties:
Useless use of [*] in sink context
at <tmp>:1
------> 3my $i=0; my @v = 42 xx 10; 7ā5[*] grep -> $a { @v.first({ $i++; $_ + a
100
18:30 perryprog joined
codesections m: note 1; #`(( a valid comment )) note 2 18:34
camelia 1
2
codesections m: note 1; #`(( a typo'ed comment ) note 2
camelia 5===SORRY!5=== Error while compiling <tmp>
Starter (( is immediately followed by a combining codepoint. Please use ( without a combining glyph ((( was at line 1)
at <tmp>:1
------> 3note 1; #`(( a typo'ed comment ) note 27ā5<EOL>
ā€¦
samebchase lizmat: Happy Birthday!! šŸŽ‚
codesections ^^^ that seems like a LTA error msg
Oh, is it Liz's birthday? Happy birthday! 18:35
18:35 MoC joined
codesections (er, and I wasn't saying that "Happy Birthday!! šŸŽ‚" was a LTA error message. Though, come to that, I can't really think of an error where that *would* be an awesome error msg!) 18:36
18:36 Doc_Holliwood joined
perryprog Happy birthday Liz, and hello #raku for the first time in a while! 18:37
18:47 MoC left 19:15 MoC joined 19:17 sono joined
moritz lizmat++ 19:24
lizmat thank you :-) 19:35
PSA: due to this and other stuff happening, the Rakudo Weekly News will be published tomorrow 19:36
raydiak oh, cool! happy birthday lizmat, I'm glad you were born :) 19:54
codesections m: say (1, 2)Ā».:<-> 19:59
camelia Type check failed in binding to parameter '&code'; expected Callable but got Int (1)
in block <unit> at <tmp> line 1
raydiak tbrowder: I read that cox leases some of its tech from comcast, and the very strange behavior is exactly the same for both. so I'm hoping they're pulling from the same block list such that if one unblocks it, it'll also be unblocked on the other.
codesections is that a bug ^^^
tbrowder raydiak: thnx! 20:01
raydiak tbrowder: yw, happy to help! for now, you could try disabling what cox calls "advanced security", as mentioned at the end of this thread: forums.cox.com/forum_home/internet...-it/106753 . there's likely a web interface for it too if you don't have/want the app installed, probably the one at login.cox.com/ if I had to guess 20:02
20:04 Doc_Holliwood left
tbrowder ok, i donā€™t have the fancy panoramic wi-fi but that safebrowse sounds familiar from a deep dive when we all found we had similar dns probs. i think it was not on, but iā€™ll look again. 20:07
lizmat: Happy Birthday! 20:08
20:09 Doc_Holliwood joined
raydiak yeah I get that safebrowse.io page sometimes if I try taking out the s from the https. let me know if it works, I doubt my girlfriend remembers her password for me to try it myself :D I suspect it's all the same comcast stuff, just with rebranded wrappings. wikipedia mentioned that cox leased the xfinity x1 platform from comcast and sold it under their existing product name. I don't know what all "x1" is/means, 20:11
or how much else they might have licensed that wasn't mentioned in that article, but since the behavior is identical and they're known to use comcast stuff, it seems probable 20:12
20:14 Doc_Holliwood left 20:16 Doc_Holliwood joined
bartolin_ lizmat++ # happy birthday 20:17
raydiak tbrowder: also, if you want ideas for your message to cox, here's what I put in the comment box of comcast's unblock request form: gist.github.com/raydiak/c29ce56cd9...95bc80f76a 20:18
demostanis[m] Why can't I find a way to get a string slice in Rust? Or at least get char at index in some string? 20:31
Shit I wrote Rust instead of Raku lol
codesections m: say "foobar".comb[3] 20:32
camelia b
codesections m: say "foobar".comb[3..5]
camelia (b a r)
codesections m: say "foobar".substr(3..5)
camelia bar
demostanis[m] Thanks
codesections (depending on whether you want a Seq of chars or a Str) 20:33
20:38 MoC left
raydiak codesections: my vote would be yes, that is a bug. so far I can't find a solid irrefutable statement to cite from docs or anything, but I also don't see any reason it couldn't or shouldn't work. even if there were such a reason, at the very least the error is certainly LTA 20:47
20:47 nirnam joined
codesections raydiak++ I guess I'll open an issue :) 20:47
20:53 bd3i joined
raydiak codesections++ you're the one who found and reported it! I get karma for being more opinionated than educated? wfm :D 20:53
codesections here's another maybe-bug, while I'm at it:
raydiak (didn't even remember .: was a thing, had to look it up) 20:54
rassoc "had to look it up" -- where? search didn't help. also curious what that does 20:55
codesections m: sub f(|c) { dd c }; sub g(|c) { f(1, |c)}; sub h(|c) { 1 [&f] |c}; say g(1); say h(1) 20:56
camelia \(1, 1)
Nil
Nil
\(1, slip(1,))
raydiak rassoc: in the operators doc, under the language tab on the docs site: docs.rakulang.site/language/operat...perator%3E
codesections shouldn't &g and &h be the same? (and both do what &g does?) 20:57
guifa Ah, so it's really .:<>, rather than just .: :-)
rassoc raydiak: thanks for that! 20:58
guifa (or I guess you could do .:Ā«Ā» to add some extra arrows lol)
codesections oh, there already is a bug for it. Oops. github.com/rakudo/rakudo/issues/1592
raydiak oh good, my poor brain was still digesting all the punctuation :) 20:59
codesections oh, I meant for the first one (with :<-> ) 21:00
rassoc yeah, as a noob, [...].map: -* is way easier to parse than the above ;)
raydiak ah, I'll keep digesting, then
21:01 ufobat_ left
raydiak (I'm sure the whole channel needs to hear about my digestion :D) 21:01
guifa Got butterflies in your stomach?
guifa will see himself out
codesections better than hearing about someones indigestion
raydiak well we haven't seen what my brain spits that out as on the other end yet 21:03
codesections maybe I can clarify a bit: you can call a function &f with infix form: $a [&f] $b, which is supposed to be the same as f($a, $b 21:06
raydiak my first thought is that the difference is that a slip in a list (as in &g) will flatten into the surrounding list, but in &h the slip isn't in a list, syntactically speaking
codesections S/f($a,b/f($a,$b)/
hmm, interesting 21:07
I'm not sure if that means its not a bug, or if tells us where the bug is. Isn't the slip still put into &f's argument list? 21:08
tbrowder raydiak: got the note. are you a lawyer? if not, you write like one ;-D 21:10
raydiak tbrowder: no, but comcast doesn't have to know that :)
tbrowder yepper!
raydiak codesections: I'm not sure either. I'm looking it up, but I think | in an argument list to a function is a different syntax than | constructing a slip 21:12
codesections sub f(|c) { dd c }; say 1 [&f] |(2); say f 1, |(2) # much simpler example
evalable6 \(1, slip(2,))
Nil
Nil
\(1, 2)
guifa codesections: I'm fairly certain what's happening is that the [&f]Ā is scalarizing(ish) the two sides 21:13
codesections raydiak: yeah, that's definitely right. I guess the question is whether the syntax $a [&f] $b is supposed to treat $a, $b as an argument list 21:14
maybe it's not. 21:15
m: say 1 + |(99); say &infix:<+>(1, |(99))
camelia 2
100
ugexe using (2).Slip doesnt hit you with the 65535 argument limit like |(2) fwiw 21:16
(or like (1..65536) rather)
codesections what camelia just returned surprises me, but I guess is intended ā€” or at least consistent 21:17
ugexe m: sub foo(*@_) { say @_.elems }; foo( (1..65536).Slip ); foo( |(1..65536) );
camelia 65536
Too many arguments (65536) in flattening array, only 65535 allowed.
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
guifa m: my $a := |(99); say &infix:<+>(1, $a)
camelia 2
raydiak codesections: I'm tending towards the idea that it's an entirely different syntax by design. the fact that | flattens into a capture, and that | constructs a slip, is just incidental. syntactically, operators don't have captures 21:20
now you could make the argument that a slip ought to flatten into an argument list (semantically, not syntactically), but that's obviously not how it works now. I'm assuming that's intentional 21:22
codesections so, the statement that $a + $b is syntactic sugar for infix:<+> $a, $b is not correct? 21:23
CIAvash rakudo-bin 2021.06 for AUR is now available aur.archlinux.org/packages/rakudo-bin/ 21:24
codesections in that they're similar, but the second captures its arguments into an argument list, but the first doesn't?
CIAvash++
raydiak m: sub f (|c) { dd c }; f 1.Slip; f |1; # |1 here is *not* making a Slip object, it's a syntactic construct 21:26
camelia \(slip(1,))
\(1)
guifa codesections: I think it's more that the arguments are already bound, which prevents the slip expansion
sub f(|c) { dd c }; my $a := 1; my $b := |(2,3); f $a, $b;
evalable6 \(1, slip(2, 3))
guifa in $a + $b, there's no list context where the slip would expand. But it's easy enough to make that. Same code, but with an extra assignment: 21:28
sub f(|c) { dd c }; my $a := 1; my $b := |(2,3); f $a, $b; my @c = $a, $b; dd @c;
evalable6 \(1, slip(2, 3))
Array @c = [1, 2, 3]
codesections guifa: so, the more technically accurate thing to say about $a + $b is that it's syntactic sugar for something like my $pos1 := $a; my $pos2 := $b; infix:<+> $pos1, $pos2 . Am I following that correctly? 21:29
guifa Eh, probably even more succinctly 21:31
m: sub f(|c) { dd c }; f( (1), (|(2,3)) );
camelia \(1, slip(2, 3))
guifa Just binding was a way to prevent the evaluation without the parentheses 21:32
so you could say that $a + $b is sugar for infix:<+>( ($a), ($b) )
codesections guifa: I agree that's an accurate description of the current behavior. But I'm not sure it's intended. 21:36
> $y [&atan2] $x # same as atan2($y, $x)
design.raku.org/S03.html#Turning_a...o_an_infix
(I know that's not Roast, but still) 21:37
ugexe those design docs are from before the GLR
guifa ugexe: it is, but I think what it says still holds true. An infix operator pretty much by definition will have two (and exactly two) arguments. 21:38
(although IIRC chaining operators can be written to take more, but that's a bit different) 21:39
If you were to expand a slip, you'd be opening yourself up to potentially two or more arguments: 21:41
sub f($a, $b) { dd $a, $b }; f 1, |(2,3);
codesections which doesn't work in sub form. But right now, that *does* work in [&f] form, which seems incorrect? 21:43
guifa sure it works in sub form: 21:44
sub f($a, $b) { dd $a, $b }; f (1), (|(2,3));
evalable6 1
$(slip(2, 3))
codesections well, yeah, *if* you wrap it like that :D
raydiak imo, the main thing to understand is that the syntax inside an argument list is not entirely the same as the syntax outside of it, even though it mostly looks similar. doesn't matter that the things being written will get passed as args eventually, it matters whether it's written in an argument list or not. here's another example of something that looks the same but isn't: 21:45
m: sub f (*@a, *%h) { (@a, %h).raku }; say f(a => 1) eq f("a" => 1); say (a => 1).raku eq ("a" => 1).raku
camelia False
True
codesections m: sub f (*@a, *%h) { (@a, %h).raku }; say f(a => 1) eqv f("a" => 1); say (a => 1).raku eq ("a" => 1).raku 21:47
camelia False
True
21:48 abraxxa left
raydiak outside of an arg list, the quotes make no difference, it's the same Pair either way. inside, the syntactic rules are different, it's the difference between being taken as a named arg or a Pair as a positional arg 21:48
codesections yeah, I get all that. I just think that $a + $b ought to be a different syntax for constructing an argument list to &infix:<+> 21:49
guifa codesections: I guess it just makes sense to me that by definition the left hand side is packaed up and passed as argument 0, and right side hand side is packaged up and passed as argument 1. The parentheses just reinforce the packaging up aspect.
guifa is afk
raydiak but then you couldn't have special syntax for arg lists, because the same rules would apply anywhere in any expression 21:52
codesections raydiak: I don't know enough about Raku's compilation process to understand why that would follow. Do you mind explaining? (I thought ops were basically a special case anyway) 21:54
if that's correct (and I'm not doubting it; I really don't know) then yeah, the current treatment of $a + $b has to be right 21:55
21:57 nirnam left
raydiak well you're saying all operators should have argument syntax. but the difference between ops and subs is exactly the syntax 21:59
I'm trying to think up a good example to make this less abstract (but failing atm) 22:00
codesections hmm. I guess you've convinced me, even without one :D. 1 other question re: operators, though, while we're here: 22:01
m: my &f = {$^a ~ $^b}; say [[&f]] <a b c>; 22:02
camelia abc
codesections m: ; say [[&{$^a ~ $^b}]] <a b c>;
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing required term after infix
at <tmp>:1
------> 3; say [[&{$^a ~ $^b}]] <a b c>7ā5;
expecting any of:
prefix
term
codesections Is there a reason for the second version not to work? 22:03
raydiak I didn't even know it allowed routine literals there :D where do you come up with this stuff? 22:05
22:06 b2gills left
codesections :D :D our docs are *really* good! docs.raku.org/language/operators#R...aoperators 22:06
22:06 b2gills joined
codesections err, wait. 22:07
from the page I just linked: ā€œThe argument list is iterated without flattening. This means that you can pass a nested list to the reducing form of a list infix operatorā€
doh. I guess *that* answers my earlier question! 22:08
oops
MasterDuke does anyone here use the DUMP sub/method? 22:09
raydiak I'm still not sure it allows that. I'm trying to figure out what it's attempting to parse as
codesections (I mean, technically that's just talking about the reduction meta operator, but it's not too much of a stretch to say it apples to others) 22:10
raydiak m: say [[&{ say $^a }]] 1 # doesn't seem to work
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3say [[&{ say $^a }]]7ā5 1 # doesn't seem to work
expecting any of:
infix
infix stopper
postfix
statement enā€¦
codesections MasterDuke: I haven't 22:11
japhb MasterDuke: I worked on it, once upon a time. But even I don't use it much anymore. dd is usually enough. Why do you ask? 22:13
MasterDuke it's not it roast, greppable6 doesn't seem to see any instances of it in use. i'd say it's a candidate for removal
japhb It was always a part of Rakudo, not Raku.
MasterDuke yeah, not sure what it does that dd doesn't
codesections m: say [[&{say $^a}]] <1 2> 22:14
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3say [[&{say $^a}]] <17ā5 2>
expecting any of:
infix
infix stopper
postfix
statement end
statementā€¦
japhb Show you whether there's a container around each element or not, and pretty-prints the structure.
codesections m: say [[&{say $^a}]] <a b>
camelia 5===SORRY!5=== Error while compiling <tmp>
Missing required term after infix
at <tmp>:1
------> 3say [[&{say $^a}]] <a b>7ā5<EOL>
expecting any of:
prefix
term
codesections not sure why those two get different msgs, though
japhb s/element/node/
codesections japhb: oh, I didn't realize it did pretty printing. I might find that useful. 22:15
MasterDuke m: dd %*ENV; say DUMP %*ENV
camelia Hash element = {:HOME("/home/camelia"), :LC_CTYPE("en_US.UTF-8"), :LOGNAME("evalbot"), :MAIL("/var/mail/evalbot"), :PATH("/usr/bin:/bin:/usr/sbin:/sbin"), :SHELL("/bin/bash"), :SUDO_COMMAND("/home/camelia/rakudo-m-inst/bin/perl6-m --setting=RESTRICTEDā€¦
MasterDuke m: say DUMP %*ENV
camelia Hash<1>(
:$!descriptor(ContainerDescriptor::Untyped<2>(...)),
:$!storage(BOOTHash<3>(...))
)
japhb MasterDuke: To be clear, I have *no* problem with just merging those capabilities with dd, or ripping it out into a module at this point. It existed before dd, and was the best we had in core at the time. 22:16
ugexe ive used it in the past for dumping ast and stuff i was making with Perl6::World / Perl6::Actions
japhb Generally the high-level to low-level list has gist higher than dd higher than DUMP
MasterDuke i just discovered it today (happened to notice messages from its test fly by during a `make m-test`) and didn't know if dd was (meant as) a complete replacement 22:17
japhb (Which, BTW, is why it's all in uppercase. IF you have to pull out DUMP, you're having to look at pretty low level stuff)
The key thing is that it needs to be able to look at container descriptor stuff, so it's relatively tied to a Rakudo version in principle ... we just haven't changed that stuff in a while. 22:19
MasterDuke well, i don't think it's ever held back some wanted changed in the rakudo development history i'm aware of, so i guess no urgent need to remove it
raydiak codesections: I really don't think it lets you write literal blocks of code in there, pretty sure each of those is trying to parse as something else. e.g.:
m: say [[&{say $^a}]] <1# 2> 22:20
camelia False
raydiak m: dd [[&{say $^a}]]
camelia Array element = [-> $a { #`(Block|63954096) ... }]
japhb MasterDuke: That was kinda my feeling too. I figured, leave it there if the other core folks use it (even occasionally), but if there was strong sentiment to move it, I'm sure we can work something out.
For me the big thing is that it's explicitly a Rakudo feature, not a Raku one. 22:21
codesections Ok, *that* first one mystifies me. What is that parsing as?
japhb In a similar way to the B:: modules in Perl land, I suppose.
ugexe m: use Perl6::Grammar:from<NQP>; use Perl6::Actions:from<NQP>; my $source = q|{ say 42 }|; my $*LINEPOSCACHE; my $p6g = Perl6::Grammar.parse($source, :actions(Perl6::Actions)); say $p6g.ast.dump 22:22
camelia - QAST::CompUnit :W<?> :UNIT<?> :CAN_LOWER_TOPIC<?>
[pre_deserialize]
- QAST::Stmt
- QAST::Stmt
- QAST::Op(loadbytecode)
- QAST::VM
[moar]
- QAST::SVal(ModuleLoader.moarvm)
ā€¦
ugexe i was wrong, i was using .dump
raydiak codesections: an array with a code block in it, coerced to a num and compared with 1 via &infix:Ā«<Ā»
that's why you get TTIAR, because it's seeing `[...] <1`, then `2 >` 22:24
well, ` 2>`. you know what I mean :)
MasterDuke yeah, i've used .dump
anyway, off to sleep 22:25
codesections Ok, you've 100% convinced me that it's not even trying to parse [[&{ā€¦}]] as a code block. But that still leaves the question of whether that's intentional or a bug
raydiak I see no mention of it ever being designed to take anonymous literal blocks of code in there, only names 22:27
codesections hmm, fair point. Is there anywhere else in Raku where you can't use a lambda in place of a named fn, though? 22:29
raydiak probably several? 22:32
m: 1 [&say] 2 # ignore the warning :) 22:33
camelia WARNINGS for <tmp>:
12
Useless use of &say in sink context (line 1)
raydiak or that .: thing from earlier 22:36
moon-child that warning feels wrong
I guess it's triggering on all infixes, but it should only happen for pure ones
codesections m: say 1 [&(&{$^a ~ $^b})] 2 # Can too put a block there :D 22:37
raydiak agreed
camelia 12
raydiak what the heck is that monstrosity!? 22:39
codesections not the prettiest syntax, I admit
&(ā€¦) is fn context (just like @(ā€¦), $(ā€¦), and %(ā€¦)) 22:40
raydiak the good news is, one of those & are redundant, which makes it an iota less offensive. the bad news is that you are a derranged individual. seek help. 22:44
codesections :D Maybe *that* should be the title for my raku-conf talk! 22:45
but my point stands: that syntax works for 1 [&({ā€¦})] 2 ( and with Ā« Ā», for that matter) but not with [&({ā€¦})] 1, 2 ā€“ and that seems like a bug, imo 22:47
22:51 rassoc left
raydiak I'm not entirely sure it's even *supposed* to work 22:55
22:55 bd3i left
codesections here's something that feels related from the docs: 22:56
By default, only the final result of the reduction is returned. Prefix the wrapped operator with a \, to return a lazy list of all intermediate values instead. This is called a "triangular reduce". If the non-meta part contains a \ already, quote it with [] (e.g. [\[\x]]).
when is [\[x]] ever valid syntax, currently?
m: my \x = { $^a ~ $^b}; say [\[\x]] 1, 2 22:58
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3my \x = { $^a ~ $^b}; say [\[\x]]7ā5 1, 2
expecting any of:
infix
infix stopper
postfix
statement end
ā€¦
codesections S/'when is [\[x]]'/when is [\[\x]]/ 22:59
raydiak m: say [\+] ^3 23:04
camelia (0 1 3)
codesections right, sorry; I corrected the typo
I'm asking about the *inner* \ 23:05
raydiak ah, right
m: sub infix:<\\+> { $^a + $^b }; say [\[\+]] ^5 23:06
camelia (0 1 3 6 10)
codesections ah 23:07
raydiak acutally, s/\\\\/\\/
m: sub infix:<\+> { $^a + $^b }; say [\[\+]] ^5
camelia (0 1 3 6 10)
raydiak if you want to file your monstrosity as an issue, maybe someone else can tell you definitively if it should or shouldn't work and why or how. I really don't know what to tell you about that. obviously it *does* work in the [] infix case. still not convinced it *should*, but it does 23:11
codesections here's something that will surprise you, then: 23:12
m: say [[[&({$^a~$^b})]]] 1, 2
camelia 12
codesections m: say [[[&({$^a ~ $^b})]]] 1, 2
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3say [[[&({$^a ~ $^b})]]]7ā5 1, 2
expecting any of:
infix
infix stopper
postfix
statement end
statā€¦
codesections I think I'm going to file an issue. At this point, I don't know what the correct behavior is, but the intent can't **possibly** be to allow code blocks if and only if they don't contain whitespace! 23:13
raydiak it also works with one less set of [] 23:14
codesections just figured that out too
raydiak and yeah, no idea if that's by design. possibly relying on some unintentional quirk of the internals. it's over my head for the moment 23:16
it does explicitly expect no space in there: github.com/rakudo/rakudo/blob/mast....nqp#L3874 23:20
codesections oh, thanks, I'll mention that in the issue.
Oh, looks like I found a vaguely similar issue that got fixed sometime without us noticing 23:21
bisectable6: reduce &[<=], (23, 5, 46) 23:22
bisectable6 codesections, Will bisect the whole range automagically because no endpoints were provided, hang tight
codesections, Ā¦6c (55 commits): Ā«Ā»
codesections, Nothing to bisect!
raydiak I'm trying to trace down how it works through the grammar and actions, but I'm not great at those kinds of details these days 23:30
23:53 Eddward_ left
raydiak I *think* it has to do with github.com/rakudo/rakudo/blob/mast....nqp#L1854 allowing arbitrary sequences of statements 23:55
codesections hmm, I don't know the Grammar well enough to have a sense whether that's true. Feel free to add it to the issue I opened if you'd like/think it'd help 23:59
github.com/rakudo/rakudo/blob/mast....nqp#L1854
er

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!