🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
Voldenet pretty intriguing that <:trace, :file("a")> worked, since it's a tuple of strings 00:13
patrickb guifa: see github.com/ugexe/zef/issues/515 05:30
Xliff sub a { ... }; sub b { say sub &a.name}; sub a { b; } 05:42
m: sub a { ... }; sub b { say sub &a.name}; sub a { b; }
camelia ===SORRY!=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> sub a { ... }; sub b { say sub⏏ &a.name}; sub a { b; }
expecting any of:
new name to be defined
Xliff m: sub a { ... }; sub b { say &a.name}; sub a { b; }
camelia ( no output )
Xliff m: sub a { ... }; sub b { say &a.name}; sub a { say b; }
camelia ( no output )
Xliff m: sub a { ... }; sub b { say &a.name }; sub a { b; } 05:43
camelia ( no output )
Xliff Is there a way I can get that to work with OUTER?
m: sub a { ... }; sub b { say OUTER::<&?ROUTINE>.name }; sub a { b; }
camelia ( no output )
Xliff m: sub a { ... }; sub b { say OUTER::<&?ROUTINE>.name }; sub a { b(); }
camelia ( no output )
Xliff m: sub b { say OUTER::<&?ROUTINE>.name }; sub a { b(); }
camelia ( no output )
Xliff m: sub b { say OUTER::<&?ROUTINE>.name }; sub a { b(); } a
camelia ===SORRY!=== Error while compiling <tmp>
Strange text after block (missing semicolon or comma?)
at <tmp>:1
------> TER::<&?ROUTINE>.name }; sub a { b(); }⏏ a
expecting any of:
infix
infix stopper
Xliff m: sub b { say OUTER::<&?ROUTINE>.name }; sub a { b(); }; a 05:44
camelia Nil
Xliff m: sub a { ... }; sub b { say OUTER::<&?ROUTINE>.name }; sub a { b(); }; a
camelia Nil
Xliff m: sub a { ... }; sub b { say &a.name }; sub a { b; }; a
camelia a
Xliff Is there a way I can do the above without a predeclaration... like with OUTER and &?ROUTINE... but that doesn't seem to work... see above example. 05:45
Voldenet but OUTER is an outer _scope_, not a caller 06:12
I wonder if CALLER would work 06:13
m: sub b { say CALLER::<&?ROUTINE>.name }; sub a { b(); }; a
camelia Nil
Voldenet m: sub b { Backtrace.new.[*-2].subname.say }; sub a { b(); }; a 06:14
camelia a
Voldenet Xliff: ^ the above works, but I doubt it's enormously useful
uh, backtrace goes backwards 06:15
m: sub b { Backtrace.new.[2].subname.say }; sub a { b(); }; sub c { a }; a; c 06:16
camelia a
a
Voldenet m: sub b { say $*ROUTINE.name }; sub a { my $*ROUTINE = &?ROUTINE; b(); }; a 06:34
camelia a
Voldenet that would work as well
guifa patrickb: aaaah. That *is* correct. 09:19
0.4.1 I screwed up the dependencies in META6
0.4.2 fixes it 09:20
tbrowder__ hi, ref arrays, hashes, and map. i got into trouble using help from ugexe and [Coke] to multiply some data structures. the help was perfect, for the situation i gave them. 10:19
tellable6 2023-05-04T22:45:06Z #raku <Xliff> tbrowder LOL! thanks for the pointer. I might use it. This comes after I had already written a NativeCall based module for Raku! Maybe you could help me with the release? Email: [email@hidden.address]
2023-05-04T22:45:06Z #raku <Xliff> tbrowder LOL! thanks for the pointer. I might use it. This comes after I had already written a NativeCall based module for Raku! Maybe you could help me with the release? Email: clifton.wood@gmail.com
tbrowder__ later i found, to my chagrin, i had more complicated structures in the mix. so, i wound up having to manually unpacking them to see how to program updating them. 10:22
is there any rakuis way to use introspection on an unknown mix of hash and array to unpack it? i think i can do it the "hard" way, but a golfish method would be cool. 10:25
moritz if $thing ~~ Associative { do hashy things }; if $thing ~~ Positional { do array-y things } 10:37
patrickb guifa: I don't think the META6 fix is in 0.4.2. I think it's unreleased. 11:04
patrickb guifa: I revoke that statement and claim the opposite. The fix is included in 0.4.2. 11:09
ugexe remember folks: always `zef install .` in addition to running your tests for CI 12:15
also could you change the source-url and support~>source so they point at wherever the code is living now? 12:19
maybe that is where it lives, but what im seeing hasnt had any changes for months 12:21
[Coke] ugexe: Ah, I never do zef install . if I'm uploading a new version with fez. Good advice. 12:39
Xliff .tell Voldenet Is it always *-2 for Backtrace? 14:55
tellable6 Xliff, I'll pass your message to Voldenet
Xliff So... that's 1,000,000 lines of Raku I've written since 2018-06-18. 14:57
Soon to be released, as soon as I can find the time to update CURI
Special thanks to this channel for its support over that entire time.
andinus 0/join #raku-infra 15:15
Nemokosch kudos for Template::Nested::Fast 15:17
[Coke] tries to grok what a unicode "Presentation form" is other than "extra codepoints that shouldn't have been needed" 15:20
Xliff++
lizmat [Coke]: isn't that another way to describe synthetic codepoints ?
[Coke] m: (8942, 65049).map(*.chr.uniname)>>.say 15:23
camelia VERTICAL ELLIPSIS
PRESENTATION FORM FOR VERTICAL HORIZONTAL ELLIPSIS
Xliff Thanks, [Coke]
[Coke] m: (8942, 65049).map(*.chr)>>.say
camelia
lizmat [Coke] TIL
[Coke] I was just looking for the ⋮ so I could cut and paste it into an email, and then got sucked down this rabbit hole. :) 15:27
tbrowder__ moritz: thanks! 15:48
tonyo . 19:30
[Coke]: it's right there ^ 19:31
[Coke] tonyo: *thwap*
I was sad it wasn't in there under "Hamburger"
tonyo you didn't guess `presentation form for vertical horizontal ellipsis`? 20:30
the hamburger is a bit wider, no? 20:32
m: 2630.chr.uniname.say
camelia <reserved-0A46>
tonyo m: 2630.chr.say 20:33
camelia
tonyo m: 9776.chr.uniname.say 20:34
camelia TRIGRAM FOR HEAVEN
tonyo m: 9776.chr.say 20:35
camelia
lucs What's up with Match?: gist.github.com/lucs/0d659fe98c9b7...6f005b0996 20:56
It fails that way only when run from the REPL. 20:57
[Coke] isn't there a step required after augment to make the classes realize they've been augmented?
afk
lucs Well, Int and Str appear not to need that.
tonyo lucs: that looks a bit strange, are you sure that Baz is being loaded correctly? 22:07
lucs Well, all the code is there. Not sure if anything else could be interfering.
tonyo put Baz.rakumod in `/tmp/monkey/lib/` 22:09
then run that 22:10
lucs Sure, hang on...
tonyo run it with `raku -I/tmp/monkey -MBaz` 22:10
lucs Running from CWD /tmp/monkey, it can't find Baz, but 22:13
from the same CWD, `raku -I/tmp/monkey/lib -MBaz` runs correctly, but with the same Match error.
Oh wait, not quite the same error. 22:14
No, sorry, my mistake, exact same error. 22:15
tonyo put a die in that file and see if it's really loading 22:16
something is wonky, you shouldn't have to call Match.^compose
lucs Er, it must be loading, else the 42.foo for example would fail, no?
tonyo what version of raku?
lucs 2023.02
tonyo try adding a Match.^compose(Match) to baz
hm, same version as what i'm testing with 22:17
lucs It doesn't fail like mine for you?
(trying ^compose, just a minute)
tonyo it doesn't
gist.github.com/tonyooooooo/c1f6e5...8241c12892 22:19
lucs Er, that '^compose' line leads to: Too many positionals passed; expected 2 arguments but got 3 22:21
I trimmed my code to the same as yours, I stil get the error. 22:22
The one apparent difference I have Readline (or something, can't remember), because I don't get your "You may want..." message. 22:23
*difference is
One weird thing I noticed: 22:24
If the class is not augmented, `('a' ~~ /./).foo.say` simply complains with: 22:25
No such method 'foo' for invocant of type 'Match'
Xliff \o 22:26
What is the difference between .pick and .roll?
lucs But with the augment, this is added to that message:
Found 'foo' on type 'Match'
Hi Xliff 22:27
(in the middle of something here :-)
Xliff lucs: No worries. 22:28
vrurg Xliff: pick guarantees each element from the list to appear only once. 22:29
lucs Hmm... Actually, it's going to be the end (temporarily) for me, gotta run, going to a conference.
tonyo: I'll be back later; if you have any ideas, please post, I'll read later.
vrurg People, don't use augment. Just don't....
lucs Thanks.
Xliff vrurg: Why not?
vrurg Because it is global. 22:30
Xliff So?
vrurg It is likely to create problems.
Xliff So are most things in the language.
lucs vrurg: Hmm... I'll have questions about that later then.
Buhbye for now! 22:31
vrurg Xliff: not _that_ way.
Xliff vrurg: I understand most of the issues with augment.
vrurg already cannot use Prettier::Table because there is an augment in its dependency.
Xliff I just find it annoying that _I_ have found it useful with careful application. Yet everyone councels against its use.
If this is true then why is it offered to begin with? 22:32
vrurg Xliff: I consider it a mistake. It helps in the core, but that's the only where I would allow it.
Better than augment we have mixins. 22:33
Xliff So you are saying it should be an implementation detail?
And not a part of the public language?
vrurg Kind of. But even more strict because implementation details is available for use. 22:34
One exception to that, perhaps, is using it within same distribution on own classes. That would be controllable and safe mostly. 22:36
But when Listicles is using it to extend List/Array functionality – I get a big "oops" with parameterized Arrays. Even though the problem is caused by a bug in the compiler or optimizer. 22:37
vrurg will be away for ~1hr. 22:38
gfldex To me augment breaks composebility between authors. And I know that I will not be the same author in 2 years time then today. It's a very powerful tool and as such can backfire in the most spectacular way. 23:47
However, I like to know that I got the nuclear option, even if I don't want to need to use it. 23:48
I did use it to great effect to learn about the guts of the language and I recomend anyone to play with augment for that reason. 23:49
Playing with fire is fine, burning the house down is not. :) 23:50