🦋 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.
roguerakudev where can one find the Apocalypses these days? The old URIs are broken 04:51
Xliff \o 10:37
How can I force raku to use a class method over a role method of the same name? 10:38
lizmat m: role A { method a() { say "A" } }; class B does A { method a() { say "B" } }; B.a; B.A::a 10:46
camelia B
A
lizmat Xliff ^^
assuming that's what you meant, as a method in a class always shadows the same method in a role 10:47
Xliff Does that apply to multis, as well? 10:52
m: role A { multi method a() { say "A" } multi methold a(Int) { say "IntA" }; }; class B does A { multi method a() { say "B" }; method a(Int) { say "IntB" }; }; B.a; B.A::a 10:54
camelia ===SORRY!=== Error while compiling <tmp>
Strange text after block (missing semicolon or comma?)
at <tmp>:1
------> role A { multi method a() { say "A" }⏏ multi methold a(Int) { say "IntA" }; };
expecting any of:
in…
Xliff m: role A { multi method a() { say "A" }; multi methold a(Int) { say "IntA" }; }; class B does A { multi method a() { say "B" }; method a(Int) { say "IntB" }; }; B.a; B.A::a
camelia ===SORRY!=== Error while compiling <tmp>
Missing block
at <tmp>:1
------> ti method a() { say "A" }; multi methold⏏ a(Int) { say "IntA" }; }; class B does
expecting any of:
new name to be defined
Xliff m: role A { multi method a() { say "A" }; multi method a(Int) { say "IntA" }; }; class B does A { multi method a() { say "B" }; method a(Int) { say "IntB" }; }; B.a; B.A::a 10:55
camelia ===SORRY!=== Error while compiling <tmp>
Cannot have a multi candidate for 'a' when an only method is also in the package 'B'
at <tmp>:1
Xliff m: role A { multi method a() { say "A" }; multi method a(Int) { say "IntA" }; }; class B does A { multi method a() { say "B" }; multi method a(Int) { say "IntB" }; }; B.a; B.A::a 10:56
camelia B
Cannot dispatch to method a on A because it is not inherited or done by B
in block <unit> at <tmp> line 1
Xliff m: role A { multi method a() { say "A" }; multi method a (Int) { say "IntA" }; }; class B does A { multi method a() { say "B" }; multi method a (Int) { say "IntB" }; }; B.a; B.A::a
camelia B
Cannot dispatch to method a on A because it is not inherited or done by B
in block <unit> at <tmp> line 1
Xliff m: role A { multi method a() { say "A" }; multi method a (Int) { say "IntA" }; }; class B does A { multi method a() { say "B" }; multi method a (Int) { say "IntB" }; }; B.a;
camelia B
Xliff m: role A { multi method a(*@a) { say "A" }; multi method a (Int) { say "IntA" }; }; class B does A { multi method a(*@a) { say "B" }; multi method a (Int) { say "IntB" }; }; B.a(1, 2, 3); 11:51
camelia B
Voldenet roguerakudev: www.perl.com/pub/2001/04/02/wall.html/ 12:00
also web.archive.org/web/20200123132845...o/A01.html 12:02
tbrowder__ ugexe: when accessing a distro oobject from RESOURCES, is the .open always required (as in %?RESOURCES<key>.open.slurp)? 12:12
it seems to work ok while testing a module locally during a test install with zef 12:22
ugexe tbrowder__: yes… if it does work without it it’s probably because it was unintentionally made so at one point. Since it has to be implemented per comp unit repository you should still use open because other comp unit repos *do* still require it to be opened first 12:42
ugexe Actually I’m think about DISTRIBUTION, but you’re talking about RESOURCES 13:10
tbrowder__ yes. i'm tidying up a module giving me the warning from zef about RESOURCES 13:18
for us journeyman raku coders a good HOWTO would be very helpful. you could submit a corrective PR for my HowToUseModuleResources distro (or a new but similar distro). :-) 13:24
with a better name 13:27
say, DistroHowTo or...take a vote on Raku.land 13:29
for a good name 13:30
DistroBestPractices ... 13:33
ugexe what warning? 13:43
roguerakudev Voldenet - thanks! 14:59
jdv since when can't a rakudo install dir be moved? 15:10
tadzik I'm pretty sure that's since the original Rakudo Star release :) 15:53
unless it's changed later and broke again
antononcube @tadzik Do you use "Geo::Coder::OpenCage", or you have abandoned it? 🙂 15:59
patrickb jdv: I implemented that in 2019. That was my first contribution to rakudo back then. 16:57
patrickb tadzik: I'm pretty sure it never worked before my changes. The binary Rakudo Star releases back then relied on being installed into the exact same location they were compiled in. 16:59
2019.07 was the first relocatable release. 17:02
tadzik antononcube: I did it for a customer back then, I never used it myself 17:06
patrickb: aha, I missed the news back then it seems (or have forgotten :))
tbrowder__ ugexe: my bad, i thought this warning was from zef but it looks like it was from App::Mi6 19:14
gist.github.com/tbrowder/f2757cc16...a853301e5c
that's when i changed to use %?RESOURCES<key>.slurp to get the file contents and then rewrote it in a tempdir for use 19:29
tbrowder__ fyi, i just submitted a PR for community module File::Temp (github.com/raku-community-modules/raku-File-Temp). i could merge it but o prefer someone else do it for 2-person control. 19:50
s/o/i
[Coke] tbrowder__: is it common to show git hash ids in the changes file? 19:58
Thought that was just "everything that rolls up into the next version" usually
otherwise seems OK to me on the documentation side (I can't speak to the testing parts) 19:59
tbrowder__ hm...looking...mine do because i haven't squashed stuff. i used to be careful about not submitting a PR before extensive testing, but using mi6 and the auto changes to the README make that harder for me because i forget about it until after the first submission. 20:03
i don't know how to squash an active PR 20:04
or whatever the proper git term is
i have to change to the proper receiving repo name in the README 20:06
oh, you mean the Changes file? those are changes i made to ensure there is a record of changes prior to any Changes file 20:09
docos were sparse when the repo was started 20:10
[Coke] ok 20:25
patrickb weekly: dev.to/patrickbkr/stability-3mla 20:58
notable6 patrickb, Noted! (weekly)
aruniecrisps @SmokeMachine, do you think you'd wanna pair up on migrations for Red? Or are you still working on HTML::Component? 22:22
tbrowder__ hi 22:28
tbrowder__ can anyone see this msg? 23:14
can anyone see this msg? 23:16
howdy
hello 23:18
gfldex looks at msg 23:19
Voldenet yes 23:19

Powered by Cro and the Raku® Programming Language.

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

Thank you!