00:07 oodani left, oodani joined 01:01 johnjay joined
Voldenet using feed operators is not insanely hard with ops if one uses blocks 01:32
m: (1,2,3) ==> { [+] @^x }() ==> say()
camelia 6
Voldenet however 01:33
m: (1,2,3) ==> { [+] $^x }() ==> say() # uhhh
camelia 3
nemokosch it just lowkey defeats the purpose
Voldenet oh, totally not
nemokosch well, go ahead 01:34
I can't think of one single case where .&{} isn't superior
Voldenet if you want to say "processing from left to right", you can't do it in any other way easily
m: (1,2,3).&{ [+] @^x }.say
camelia 6
nemokosch I can think of two ways right away
.&{} and andthen
Voldenet I can actually think of a case where it isn't superior 01:35
m: (1,2,3) .&{ [+] @^x }.say # you want newlines
camelia ===SORRY!=== Error while compiling <tmp>
Malformed postfix call (only basic method calls that exclusively use a dot can be detached)
at <tmp>:1
------> (1,2,3) .<HERE>&{ [+] @^x }.say # you want newlines
Voldenet :D
nemokosch m: (1,2,3)\ .&{ [+] @^x }.say
Voldenet in fact, that's why I use feed operator instead
nemokosch I honestly think it's stupid but the workaround is simply
simple*
Voldenet that \ gives it that distinct C macros feel, but I'm not a fan
nemokosch well, it's still better than all the nuances of ==> and the random call-looking syntax 01:36
the mere fact that you have to pretend to make a call with ==> is such a red flag imo 01:37
Voldenet I do things like this with feed operators 0x0.st/PcGd.raku
nemokosch so that the compiler frontend can rewrite the call halfway
ironically, ==> is more like a macro than andthen 01:38
andthen does create an evaluation context
Voldenet Yeah, it rewrites the call
but honestly if .& worked with syntax formatting, I'd prefer it too 01:39
nemokosch all the signatures are odd because you have to pass the value on the left as the argument on the right
Voldenet haha yes, but it's nothing too uncomfortable 01:40
other than being "weird"
nemokosch nothing ever is "too uncomfortable" 01:41
this feels like people saying about whatever that "you can do that in C, too, so why bother"
like of course, there will always be a way
that's not a high tally
Voldenet for some reason I recall some horrors of seeing things being doable in C 01:42
Dynamic arrays? Iterators? Everything is possible if you macro it hard enough
but I mean, putting the argument on the other side of the signature is just slightly different syntax than regular .& 01:43
it's not foreign and if you build subs for feed operators use, it requires 0 effort… 01:44
nemokosch as long as you don't consider the functions interfaces 01:45
Voldenet …and in fact, regular ufcs like `sub($topic, $args…)` is just incompatible with it
nemokosch which I think is quite a hard cost in itself
Voldenet so it really depends - if you've written everything for ==> in mind, .& is going to be useless 01:46
and the other way around
well, not useless, since you can still reorder arguments in a block 01:47
nemokosch in one case, the argument to pass comes first 01:51
in the other case, it comes last: what number is that?
in general, I think in one case you do what makes sense anyway, and .& just works with it 01:52
in the other case, you do what ==> forces you to
Voldenet I'd like to disagree, but ==> does feel weird to use 01:53
it's like | in powershell
theoretically like bash, but what the hell 01:54
but once you get used to this weirdness, it's not that different 01:55
nemokosch again, "it's not useless" 01:59
but not really worth using either
[Coke] nice test module for reporting where two long lists differ (not just that they do) 02:14
? 02:15
antononcube @Coke "Algorithm::Diff" should work on sequence. 02:30
"Math::DistanceFunctions::Edit" can be used to find Edit distance between two sequences. 02:33
[Coke] ... Those aren't Test modules, though. 02:38
nemokosch it wasn't clear what kind of criterion "test modules" encodes
antononcube I see. I was not sure what "test module" is. I thought "test" as "function" (for making a test.) 02:39
nemokosch I'd have suggested to just turn them into key-value pairs and then zip and filter some way
02:43 hulk joined 02:45 kylese left
[Coke] as in a module that exports test functions (like Test) that generate TAP, but with helpful output and not "expected: <1000 characters>, got: <1000 slightly different ones>" 02:50
but yes, could use those to make the one I want if it doesn't exist. 02:51
doesn't matter now, the test is passing.
03:11 johnjay left 03:15 hulk left, kylese joined 03:20 arkiuat left 03:36 johnjay joined 03:37 johnjay left 03:45 johnjay joined 03:50 johnjay left 04:04 lichtkind__ joined 04:06 lichtkind_ left 04:10 Romanson joined 04:23 Aedil joined 04:27 stanrifkin_ joined 04:29 stanrifkin left 04:59 wayland76 joined 05:01 stanrifkin_ left 05:09 johnjay joined 05:10 johnjay left 05:18 johnjay joined 09:00 Romanson left
Voldenet question about docs: "$_ is the topic variable. A fresh one is created in every block." 09:57
m: $_ = 3; { $_ = 4; }; say $_ # shouldn't this say 3 if fresh block would create a new topic variable? 09:58
camelia 4
Voldenet m: $_ = 3; -> { $_ = 4; }(); say $_ 10:00
camelia 4
Voldenet m: $_ = 3; sub { $_ = 4; }(); say $_
camelia 3
lizmat no... because the default signature of a block binds to the outer $_ 10:02
m: dd { say "foo" } 10:03
camelia -> ;; $_? is raw = OUTER::<$_> { #`(Block|4771719725712) ... }
lizmat Voldenet: the "-> ;; $_? is raw = OUTER::<$_>" bit
m: m: $_ = 3; -> $_ { $_ = 4; }; say $
camelia (Any)
lizmat m: m: $_ = 3; -> $_ { $_ = 4; }; say $_
camelia 3
lizmat m: { say MY::<$_>:exists } 10:04
camelia True
Voldenet That makes sense, but I thought that `-> {…}` syntax would change the signature to not have the topic 10:09
10:09 librasteve_ joined
lizmat m: m: $_ = 3; -> { $_ = 4; }; say $_ 10:09
camelia 3 10:10
lizmat it does ?
Voldenet (in this case -> {} is not invoked)
lizmat m: m: $_ = 3; -> { $_ = 4; }(); say $_
camelia 4
lizmat heh
that feels... wrid 10:11
weird rather
I guess it's to make this work: 10:12
m: $_ = 42; if 666 { .say }
camelia 42
lizmat maybe we need to look at the docs... 10:13
Voldenet yes, the part about plain `{}` inheriting $_ is clear (and docs already mention it), just the part where `-> {}` also does inherit it is a bit unclear 10:14
and I can't see docs for `$_` in pointy block signatures 10:15
lizmat yeah... *that* feels like a bit of a WAT
Voldenet though it does feel like something undocumented rather than a bug
lizmat yeah... changing that would probably break a lot of code in the wild
Voldenet m: sub n(&fn) { fn(); }; $_ = 3; n(-> { $_ = 4; }); say $_ # this is also modifying the $_ 10:22
camelia 4
Voldenet so I think blocks always inherit $_ unless redefined 10:23
m: $_ = 3; -> $_ { $_ = 4; }(my $n); say $_ #
camelia Cannot assign to a readonly variable or a value
in block <unit> at <tmp> line 1
Voldenet m: $_ = 3; -> $_ is raw { $_ = 4; }(my $n); say $_ #
camelia 3
lizmat yeah looks like 10:24
Voldenet would make more sense in docs.raku.org/language/variables#T...__variable 10:25
…if it's specified in roast, that is
11:19 Sgeo left 11:21 lichtkind__ left 11:28 lichtkind joined
lizmat Raku Resolutions meeting today at 19:00 UTC meet.jit.si/SpecificRosesEstablishAllegedly 11:59
12:35 sibl joined 12:39 sibl left 13:01 oodani left 13:10 oodani joined 14:38 human_blip left 14:39 human_blip joined 14:45 oodani left 14:46 oodani joined 14:50 librasteve_ left 14:55 sibl joined
aruniecrisps @librasteve @SmokeMachine I like both Air:: Components and Cromponent, but I'm wondering if we shouldn't try and add component functionality to the Cro framework itself perhaps 15:53
15:56 sibl left 16:15 oodani left 16:16 oodani joined
SmokeMachine aruniecrisps: I also think so... but I think before components, I think it should exist a way to refer to endpoints by name, call the endpoint sub as usual function, a way to generate url by endpoint + parameters... 16:17
I think all that would be useful for components and web, but also to API (that is/was the original intent for cro)... 16:19
IMHO 16:21
16:31 sibl joined 16:45 arkiuat joined 16:46 sibl left
melezhik. . 16:58
simon_sibl I had this scheduler challenge for interview that a colleague of mine did, he made it in Python and I wrote my own solution in Raku, much shorter but much slower (Python was 25ms while Raku was 520ms), I rewrote the Raku one in Perl and got 6ms. Just sharing the codes here: Perl: glot.io/snippets/hfl11xtsop Python: glot.io/snippets/hfl141y14w Raku: glot.io/snippets/hfl155yc2y 17:07
I know Raku is slow to start, but is there any other reason why it would be that much behind ? 17:08
17:13 human_blip left 17:14 human_blip joined 17:24 arkiuat left 17:27 arkiuat joined 17:28 abraxxa joined 17:31 abraxxa left, johnjay left, abraxxa joined 17:32 arkiuat left, johnjay joined 17:37 wayland joined, wayland76 left 17:44 arkiuat joined
nemokosch what do you mean "is there any other reason"? 17:56
I think there was a profiler feature 17:58
do people use --profile these days? 18:00
[Coke] simon_sibl - here's my time run of the raku: raku foo 0.22s user 0.02s system 126% cpu 0.189 total 18:01
... ok, but the perl one shows as 0.00, ok. :) 18:02
I think about 50% of that is startup, though. :| 18:04
18:19 abraxxa left 18:22 arkiuat left
whistlingzephyr lizmat: ...I noticed the text asking me to change the bridge name from like a week ago just now. sorry for that, I'm glad that the bridge now works though. thanks 18:24
not nice that my bridge doesn't convert IRC pings to Discord pings
nemokosch I thought it did 18:25
lizmat as long as the disbot's name starts with disbot1 we're ok in the future
nemokosch usernames get replaced, at least
18:29 arkiuat joined
whistlingzephyr I didn't change anything, so I guess that's how it should be kept 18:38
hmm, not sure why it didn't ping me then 18:39
librasteve SmokeMachine: @aruniecrisps ... I am not sure of the additional benefit of "making Cromponent part of Cro" - as far as I am concerned it already is - I would be 100% cool to put Cromponent in the Cro distribution. Now that said Cromponent is a natural companion to Cro::Template - it makes precomped templates and feeds them .data. However, Air::Component is different in that components are instantiated Raku objects with 18:48
methods that are run at runtime (ie when the route is hit). So I think it would be confusing to try and also make that part of Cro since it is different. (And maybe other models will come too). Air::Component uses only use Cromponent::MetaCromponentRole so if that makes it into Cro, I would like to see the same interface (is accessible trait) maintained. I guess (?) that SmokeMachine comment about named endpoints is a way to avoid a bunch
of gnarly code in that module and I think the emphasis should be on rebuilding that, which looks like some surgery to Cro::HTTP::Router and maybe even eliminate Cromponent::MetaCromponentRole. Can you help us to build that?
lizmat whistlingzephyr ^^ the previous message by librasteve arrived on 3 different messages on the IRC side 18:51
it would have if the second and third would have the <librasteve> prefix as well
librasteve @simon_sibl - did you try this raku.land/zef:lizmat/Concurrent::PriorityQueue 18:52
lizmat Resolutions meeting starting in a few mins: meet.jit.si/SpecificRosesEstablishAllegedly 18:55
aruniecrisps @librasteve the benefit of adding components to Cro is that right now from what I've seen (@SmokeMachine correct me if i'm wrong) Cromponent relies on EVALs to basically ad-hoc add routes for components, which seems a tad bit unsafe in the long term as opposed to more tightly integrating the functionality with Cro's route building logic 19:07
19:26 stanrifkin joined
librasteve @arun - yes... this is what I meant by "bunch of gnarly code in that module" 19:27
aruniecrisps @librasteve @SmokeMachine, I think considering I do need to build components, I think I can help with the rebuilding of named routes in Cro 19:39
19:46 Sgeo joined
[Coke] Sorry I missed the call; I probably need to add a calendar event to not miss these going forward. 20:13
SmokeMachine aruniecrisps: sorry, I sent you a message on #cro asking if we should discuss there and then realised you weren’t there… 20:31
ab5tract [Coke]: No worries, we punted a ticket to discuss later with you. Re: the calendar: It should be a stable cadence of every two weeks going forward, now that we are past FOSDEM 20:32
mc2 hello people 20:37
nemokosch hi 20:38
mc2 raku.land/zef:martimm/Gnome::GObject < the repository here doesn't exist. I think the one I could need is github.com/MARTIMM/gnome-gobject but it scares me because there is *GNOME* in the name. What I'm searching for is the ability to use the gobject inspector with a project that isn't related to gnome at all 20:44
oh ... about FOSDEM: was it good ?
lizmat Gnome::Gtk4:api<2> is what you want according to raku.land/zef:martimm/Gnome::GObject 20:46
Do not install this package on its own. Instead install Gnome::Gtk4 newest api.
zef install Gnome::Gtk4:api<2>
from what I've seen of FOSDEM, it was good :-) 20:47
sadly I was too sick to enjoy much of it
mc2 damn! that's sad but that's one of the reasons I fear fosdem now: so much crowd at the same place during the virus season don't match with my medication made of immuno-depressors 20:49
hope you're going better now
lizmat well, actually I was getting sick *before* getting to FOSDEM :-) 20:50
fwiw, there where quite a few people walking around with masks
afk&
mc2 ah .. so you came there to share all those viruses with the community ;)
ok 20:51
nemokosch it's a bit strange 20:54
after all, GObject is indeed a GNOME concept
mc2 disbot13: not at all. Gnome is using GTK which is using Glib which provides Gobject but I think there is more Glib projects out of the Gnome project than gnome ones 20:56
(but yes: they all started in the same place long time ago) 20:57
nemokosch I think it's much more than that
GTK is developed for GNOME, by GNOME people
same goes for the whole thing
mc2 we and elephants share common ancestery .. Gnome is the elephant :) 20:58
nemokosch I mean they develop it
mc2 sure: gtk was made for gimp in the first place and gnome was made over gtk so gnome people are taking care of gtk for sure but you can use gtk without all the gnome overhead (GIO and so on ...) 20:59
some people even used glib as a C toolbox at some point. stdint.h was something missing 21:01
nemokosch the important thing is that you know what you are doing
mc2 well ... that's why I'm scared by the name: will this module require all those gnome things to run when I was just trying to use the Gobject inspector ? 21:02
Glib::Gobject would be a much more reassuring name for sure 21:04
21:05 stanrifkin left
mc2 (gtk means Gimp Toolkit, not Gnome toolkit) 21:17
nemokosch even Gimp is maintained by the GNOME project 21:18
let alone GTK
mc2 I was talking about software dependencies, not who made who. Larry Wall wrote patch and perl but you don't need to get perl to run patch (it would be ridiculous, right?). both rely on the libc but I can use the libc without gnome too ... I can use pango, cairo, and the libs from the freedesktop projet without gnome. and I know there are gnome people involved in the freedesktop project, also there are 21:27
KDE people but I don't need QT to run Gobject? Do I ? 21:28
nemokosch not "made", "makes"
anyway, you clarified that what you wanted is not "a project that isn't related to gnome at all" but one that doesn't require a lot of gnome components 21:29
mc2 not *gnome* components ... and I was just reporting a dead link in raku.land and the fact that the name of the package is missleading people (including myself). Imagine a package that would be named Gnome::Cairo or Gnome::XDG because some authors contribute to both gnome and XDG. don't you see a problem here ? 21:32
names are important 21:33
nemokosch it's not the hill to die on for me 21:39
mc2 for sure 21:41
nemokosch one thing is sure: the release is newer by a lot than the latest modification of github.com/MARTIMM/gnome-gobject 21:42
mc2 and actually: the name wasn't missleading: I just tried it to install and cancelled when I saw how many requirements it had
yes but again: too many useless dependencies. It would be nice to pick the part I need to do a Glib::Gobject in the future 21:45
for now I'll stick on my perl code (no rush for porting it in raku) 21:46
nemokosch it's probably better to reach out to the author 21:47
21:47 simcop2387 left 21:48 librasteve_ joined
interesting to see Perl code in 2026 21:49
mc2 I don't want to open too much topics at the same moment so I defer. 21:58
about Perl: I don't use scripting langages that much nowadays but when I do, perl is still my number one. I wish it could be raku but the ecosystem isn't ready to me ... that's why I would like to spend some time to contribute as much as I can (which it not that much) 22:00
actually I do a lot of traditionnal unix tools too (make, mk, dash, rc, awk, sed, grep, gnuplot, C ...) mainly because it's fast, robust, extendable with any other langages ... most of the time that's the shortest way to a working tool for the problems I have to solve at work 22:03
23:00 phogg left 23:01 phogg joined
antononcube weekly: rakuforprediction.wordpress.com/20...c-glow-up/ 23:24
23:30 arkiuat 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!