🦋 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.
tbrowder um, shouldn't that new test item be named "exits-ok" to follow the existing pattern of "lives-ok" and "dies-ok" et allii? 00:15
*alii' 00:16
probably too late, but maybe not since i'm probably the only person will ever use it. 00:18
lizmat perhaps... having it in only one release as "exit-ok" and all future ones "exits-ok" 00:24
tbrowder 👍 💗 00:25
lizmat on the other hand, I feel "exits-ok" feels a lot as "exists-ok" ... so our mmv :-(
tbrowder yeah, i feel yr pain. 00:26
but is there an "exists-ok"? 00:27
lizmat no, there isn't 00:30
it's just that my muscle memory is more used to typing exists then exits
tbrowder i unnerstand that...btw my xmas card made it to england 1 or 2 days ago, no report from spain or new zealand 00:33
lizmat nor here...
ugexe i dont think having two similarly spelled words is a good reason for or against a given name 00:34
consistency is far more important 00:35
tbrowder well consistency in name is helpful for memoory 00:36
memory
ugexe i can intuit that the method for checking if something exited ok is exists-ok if i know about any of the other -ok functions
exits-ok rather 00:37
tbrowder hm, hour brain works with higher horse power 00:38
ugexe further, typing makes mistaking a theoretical exists-ok with an exit-ok since i doubt it makes sense that both would take the same type parameters
tbrowder i meant "your"
lizmat github.com/rakudo/rakudo/pull/6061 00:39
sleep&
tbrowder i used to have a russian raku pal but stopped corresponding to minimize surveilance on him 00:46
thnx, lizmat++ 00:48
00:58 ACfromTX joined 00:59 ACfromTX is now known as atcroft 01:28 disbot8 joined 01:31 disbot7 left 01:32 snonux left, simcop2387 left 01:33 snonux joined, tonyo left 01:34 tonyo joined, daemon left 01:35 simcop2387 joined, hvxgr left, sorenson left, thaewrap- joined, thaewrapt left 01:36 daemon joined, xelxebar left, xelxebar_ joined, hvxgr joined 01:38 itaipu joined 01:39 sorenson joined 02:05 itaipu left 02:06 atcroft left, guifa left 02:07 bloatable6 left, bloatable6 joined, human-blip left 02:08 human-blip joined 02:21 itaipu joined 02:27 hulk joined 02:28 kylese left 03:15 hulk left, kylese joined 03:50 Aedil left 04:29 lichtkind_ joined 04:32 lichtkind__ left 04:46 linkable6 left, bloatable6 left 04:47 nativecallable6 left 04:48 linkable6 joined 04:49 bloatable6 joined 05:19 cm left 06:17 cm joined 06:48 Aedil joined 06:49 wayland76 joined
wayland76 Hi all! :) 06:49
06:50 ACfromTX joined, ACfromTX is now known as atcroft
wayland76 Can I use trait_mod ( docs.raku.org/language/traits ) to define a new "provides" trait like `my $variable provides "sql"` or do I have to use is/does for this? 06:51
07:13 annamalai left 07:15 arkiuat left 07:23 annamalai joined 07:29 arkiuat joined 07:34 arkiuat left 07:50 itaipu left 08:00 arkiuat joined 08:05 arkiuat left
Voldenet m: multi sub trait_mod:<is>(Variable:D $v, :$provides) { say $provides }; my $n is provides("sql"); # maybe 08:20
camelia sql
Voldenet though it's not exactly the same syntax
maybe `is providing("sql")` would be better 08:22
though you probably could do something like `rule trait_mod:sym<provides>` in grammar, hm 08:29
08:33 arkiuat joined 08:37 arkiuat left
Voldenet I naively thought this would work `my role Grammar { rule trait_mod:sym<provides> { <sym> <EXPR> } }; my role Actions { method trait_mod:sym<provides>(Mu $/) { … } }; use Slangify Grammar, Actions; my $x provides "sql"` but nope 08:38
I'm still convinced that it's possible, just I don't know how 08:42
08:49 Sgeo left 08:56 arkiuat joined
wayland76 Yeah, I agree it'd be possible with a Slang. I just wanted to find out if there was a non-Slang way to do it. 08:57
Thanks for the advice though -- I'm probably going with "is providing" for now :) 08:58
09:01 arkiuat left
Geth ¦ problem-solving: librasteve assigned to codesections Issue Raku / Rakudo adapt and adopt the LLVM AI Tool Policy github.com/Raku/problem-solving/issues/510 09:14
09:29 arkiuat joined 09:34 arkiuat left 09:47 arkiuat joined 09:51 arkiuat left 09:56 ShimmerFairy left, ShimmerFairy joined 10:04 abraxxa joined
wayland76 We could assign an AI to do that :p 10:11
I was slightly worried for a bit (I'm AI-generating a module now), but when I read the policy, I said "OK, that's what I would've done anyway". I mean, the AI is going to speed things along, but I want to review every line in the thing before putting it live. 10:12
10:13 arkiuat joined 10:18 arkiuat left
Voldenet people who push AI code without even reading it are utterly insane 10:18
They trust these dice rolls way harder than they should 10:19
10:46 arkiuat joined 10:51 arkiuat left 11:15 arkiuat joined 11:19 arkiuat left
disbot8 <librasteve> agreed! … please add your feedback to the issue 11:26
<librasteve> there’s a part of me that says PLs will fork into “efficient way to get code from AI” vs “artisanal medium for the creative acts of humans” 11:29
11:33 arkiuat joined 11:41 arkiuat left 11:54 arkiuat joined, Pixi` joined 11:57 ShimmerFairy left, Pixi left 11:58 arkiuat left 11:59 ShimmerFairy joined 12:00 arkiuat joined 12:04 arkiuat left 12:06 ShimmerFairy left, ShimmerFairy joined 12:18 arkiuat joined 12:25 arkiuat left 12:39 arkiuat joined 12:43 arkiuat left 13:17 arkiuat joined 13:22 arkiuat left
disbot8 <antononcube> I read the policy, makes sense. But that policy is more about collaboration by many people (or other entities) on a certain big project. (Like LLVM.) To what degree that applies to the (current) Raku ecosystem? 13:27
<antononcube> BTW, it would be very interesting for every package in the ecosystem to find prompt(s) and code that generate that package or a package with the same functionalities. 13:33
<antononcube> Also, it would be interesting to know to what degree Raku ecosystem’s missing packages can be LLM generated. Especially the ones dealing with LLMs. 13:38
13:52 arkiuat joined 13:57 arkiuat left 14:01 arkiuat joined 14:06 arkiuat left
tbrowder ok my xmas card to jmerelo got to him in Spain on 30 Dec (about 2 weeks in transit as as forecast by our local USPS office where it was mailed.) 14:28
14:35 arkiuat joined 14:39 arkiuat left 14:48 Aedil left 14:50 Sgeo joined 14:56 jgaz joined 15:00 arkiuat joined 15:06 arkiuat left 15:17 arkiuat joined 15:24 arkiuat left 15:51 arkiuat joined 16:00 arkiuat left 16:08 arkiuat joined 16:12 arkiuat left 16:28 arkiuat joined 16:51 Pixi` is now known as Pixi 17:33 abraxxa left
[Coke] anyone have any examples of an our proto to allow an our multi? 17:35
lizmat what would be the purpose? The proto would shadow the multi, wouldn't it ? 17:36
17:40 tgt joined, tgt left
[Coke] you can't have an our multi 17:40
without a proto. so says this error message. 17:41
17:43 arkiuat left 17:46 arkiuat joined 17:50 atcroft left, linkable6 left, Sgeo left, bloatable6 left, bloatable6 joined, linkable6 joined
[Coke] ah, my stumbling block was that I wanted a proto that differed on arg 0, but then the proto is just very simple. 17:50
Got there.
17:51 arkiuat left, arkiuat joined 17:59 wayland joined, kjp_ joined 18:00 timo left, kjp left, wayland76 left, jgaz left 18:01 jgaz joined 18:02 timo joined, Aedil joined
[Coke] wonders why fez is on version 100+ 18:09
===> Testing: Template::Mustache:ver<1.2.5>:auth<zef:raku-community-modules>:api<1.2.0> 18:11
[Template::Mustache] # Failed test 'Deeply Nested Contexts: All elements on the context stack should be accessible.'
[Template::Mustache] # got: 'This type cannot unbox to a native string: P6opaque, Junction' 18:13
github.com/raku-community-modules/...e/issues/2
This is a blocker for App::Mi6 18:15
18:17 ACfromTX joined, ACfromTX is now known as atcroft
arkiuat .tell wayland thanks for that tip on git worktrees 5 months ago; I couldn't absorb it then, but I tried them again recently and find them very helpful! 18:19
tellable6 arkiuat, I'll pass your message to wayland76
19:48 guifa joined 20:50 bazzrrr0 joined
bazzrrr0 Hi everyone, I'm just following up on the Rakudo installation fail on OpenSuse Leap 16 reported on raku-dev by El_Che on 18/20th Nov. I just tried to compile from source and it still failing for 2025.12, I have a logfile which shows a bit more detail than the one supplied by #El_Che 20:56
[Coke] Is there a ticket somewhere under rakudo or raku/ on github? 21:01
bazzrrr0 Hi [Coke], not that I know about, I put the log file into a gist : gist.github.com/bazzaar/0fcd02cbb8...5fce8d6190 21:16
disbot8 <antononcube> weekly: rakuforprediction.wordpress.com/20...-examples/ 21:26
<antononcube> weekly: rakuforprediction.wordpress.com/20...et-part-2/
[Coke] ok, I see looks like moar builds OK but then there's a segfault using it to build nqp 21:33
... actually that segfault is coming from perl, no? 21:35
what version of perl do you have on that box?
ah, no, segfault is on nqpmo.moarvm 21:36
oof, I need more warm beverage 21:37
bazzrrr0 You had me panicking there, it's a new build, and the perl is the one that came with the distro (perl5 v 42) 21:38
[Coke] I posted your log in the dev channel, fwiw 21:40
if you could open a ticket on github.com/rakudo/rakudo/issues, would help
bazzrrr0 will do, thanks for your help [Coke] :-) 21:42
21:59 wayland76 joined 22:00 wayland left 22:20 jgaz left 22:27 arkiuat left 22:35 arkiuat joined 22:57 bazzrrr0 left 23:40 Pixi` joined 23:43 Pixi left

Powered by Cro and the Raku® Programming Language.

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

Thank you!