🦋 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.
00:00 reportable6 left 00:02 reportable6 joined 01:02 greppable6 left, linkable6 left, committable6 left, nativecallable6 left, evalable6 left, bloatable6 left, reportable6 left, statisfiable6 left, sourceable6 left, squashable6 left, benchable6 left, quotable6 left, coverable6 left, notable6 left, tellable6 left, bisectable6 left, releasable6 left, unicodable6 left, shareable6 left, unicodable6 joined, reportable6 joined, notable6 joined, sourceable6 joined 01:03 tellable6 joined, nativecallable6 joined, releasable6 joined, linkable6 joined, quotable6 joined, coverable6 joined 01:04 benchable6 joined, greppable6 joined, statisfiable6 joined, shareable6 joined, bloatable6 joined, squashable6 joined, bisectable6 joined, committable6 joined 01:05 evalable6 joined 01:35 Xliff joined
Xliff Why am I getting the following error when I am executing RakuAST that worked like a month ago: No such method 'IMPL-CURRIED' for invocant of type RakuAST::Statement::Expression 01:36
01:41 razetime joined 02:38 MasterDuke joined 03:38 evalable6 left, linkable6 left 03:40 linkable6 joined 03:41 evalable6 joined 04:13 razetime left 04:27 Xliff left 04:54 razetime joined 05:11 swaggboi left 05:30 wayland76 left 05:31 wayland76 joined 05:34 siavash joined 06:00 reportable6 left 06:02 reportable6 joined 07:02 codesections left 07:31 jpn joined 07:40 sena_kun joined 07:59 bpalmer joined 08:14 jpn left 08:17 teatwo joined 08:20 teatwo left, teatwo joined 08:21 tea3po left
lizmat Xliff: please provide sample and --ll-exception trace :-) 08:30
tellable6 lizmat, I'll pass your message to Xliff
09:12 siavash left 09:21 Sgeo left 09:24 squashable6 left, squashable6 joined 09:29 razetime left 09:38 jpn joined 09:42 jpn left 10:28 amano joined
amano Why is it impossible for A::B to call A::someFunction? 10:29
tellable6 2023-08-24T18:51:55Z #raku <Xliff> amano: stackoverflow.com/questions/769697...3#76972203
lizmat because subs are by default "my". If you defined the A::someFunction as "our", you should be able to ? 10:30
nemokosch if they are by default "my", how can that you can use is export on them by default? 10:31
I tried to make an alias to a sub and export it a couple of days ago, it immediately complained about the alias being my-scoped 10:32
how come*
lizmat m: my sub foo() is export {} 10:33
camelia ( no output )
lizmat m: my $foo is export # nemokosch aren't you confused with this one?
camelia ===SORRY!=== Error while compiling <tmp>
Can't apply trait 'is export' on a my scoped variable. Only our scoped variables are supported.
at <tmp>:1
------> osch aren't you confused with this one?⏏<EOL>
expecting any of:
…
amano I usually just declare a function with `our sub`.
in a module. 10:34
lizmat which also marks it as "is export" so there you go :-)
amano Hell. 10:36
unit module A::B; use A; our sub test() { say A::test() } 10:37
unit module A; our sub test() { "sdfsdf" }
./test: #!/usr/bin/env raku; use lib <.>; use A::B; A::B::test; 10:38
nemokosch yes - why does it say that the my scope is the problem when that's clearly not true?
amano This results in Could not find symbol '&test' in 'A'
Is this a bug in raku?
It seems A::B erases A. 10:39
nemokosch I think you are right in a way
lizmat yeah, that could actually be a bug
nemokosch should read back, I think we've had similar problems before
amano Notice use lib <.>; It is a file repository. 10:40
lizmat what if you put the "use A" *before* the "unit module A::B" ?
nemokosch yes, that should be it
amano Then, it succeeds without an error.
If `use A` is placed above `unit module A::B`, a program succeeds. 10:41
What is wrong?
nemokosch the sole idea that A::B will auto-declare a namespace A
lizmat well, it needs a place to store the "B" package in 10:42
nemokosch it should be an error
lizmat agree, or should do the right thing
nemokosch I wonder how long these "make guesses that help you at your mistake but obfuscate the simple and obvious things" decisions trace back 10:43
lizmat I wonder how much effort it would be to fix
nemokosch These are the things that could be removed technically, but not culturally 10:46
10:52 ChanServ sets mode: +o lizmat 10:54 ChanServ sets mode: -o lizmat 10:57 amano left 11:04 NemokoschKiwi joined 11:17 amano joined
amano Is a `start { }` block the same as `Thread.start({ })`? 11:17
lizmat no, it's more akin to Promise.start( { } ) 11:20
amano Does Promise not use Thread? 11:22
Or, does Promise execute in the current thread?
lizmat Thread.start just returns the Thread object 11:24
which is very lowlevel
Promise.start returns a Promise that will be kept if the code given executes cleanly
amano In javascript engines, async events are processed in the current thread. 11:25
lizmat and that code will be scheduled by the $*SCHEDULER to run at a convenient time
amano I don't know whether Promise tries to execute codes in the current thread.
lizmat in Raku, they are most definitely not
unless you use a special scheduler
amano Does Thread.start({ }) get a dedicated thread while `start { }` does not?
If a start block is shuffled between different threads, then execution can be slower. 11:26
lizmat indeed
amano I want to prioritize a processing queue.
lizmat it will only get shuffled it it is waiting for something such as I/O
*if it 11:27
amano Do I need `whenever someSupply.schedule-on(CurrentThreadScheduler)` in a react block for faster processing?
start { react { whenever someSupply.schedule-on(CurrentThreadScheduler) { someCode } } } 11:29
lizmat if you use the CurrentThreadScheduler, you effectively change "start { code }" into "do { code }" 11:30
so I don't think that's what you want?
amano It didn't.
I don't know what exactly `whenever someSupply.schedule-on(CurrentThreadScheduler)` does in a react block. It is said that only one whenever block is executed at a time in a react block. This means the whenever blocks are executed in the current thread anyway. 11:33
lizmat I don't know either :-) 11:34
amano I guess whenever blocks in react and supply block use CurrentThreadScheduler. 11:35
nemokosch not sure if that follows, could be that the thread is paused or something 11:36
amano Which thread?
nemokosch the thread that isn't scheduled? doesn't really matter, it was just an example
the point is rather that I think you're making an ambitious logical step 11:37
amano You mean the react block's thread is paused while the whenever block is executed in a different thread?
nemokosch if it's an important conclusion for you that the whenever blocks are executed in the current thread anyway, I'm saying that this is far from proven only by what you deduced 11:39
only to make sure you don't "double down" on something that might not even be true 11:40
lizmat m: say $*THREAD # the thread we're in 11:41
camelia Thread #1 (Initial thread)
amano It seems that a whenever block tapping a live supply is interrupted like hell while a whenever block tapping a channel is not interrupted. 11:42
It takes 5 seconds to go through IO operations in a whenever block tapping a liver supply. It takes less than 0.2 second to do the same in a whenever block tapping a channel. 11:43
liver supply -> live supply
nemokosch 😄
amano I can understand that for an on-demand supply, but a live supply should be better. 11:44
nemokosch really the only problem is, so to speak, that there aren't many easy-to-reach people who are knowledgeable with how it works
amano Channels are far faster.
nemokosch stackoverflow.com/questions/495779...-a-channel 11:46
in general, I'd gaze through StackOverflow for async-concurrent-parallel sort of questions
amano Hmm. The terminal emulator weechat runs on does not recognize links split among lines. 11:49
Is there any way to make the terminal emulator recognize multi-line links?
Okay. 11:55
I just confirmed that a channel whenever block is far faster than a live-supply whenever block.
I'm going to use channels whenever possible. 11:56
If you want quick reaction time, channels. 11:57
12:00 reportable6 left 12:01 reportable6 joined
amano How can I make IO::Socket::Async.listen-path($socketPath).Supply.lines.Channel.receive faster? 12:02
I just receive one line over a stream unix domain socket and close the connection.
I just want to quickly receive one line over a stream unix domain socket and close the connection. 12:03
lizmat amano: is the stream in binary, or in some text form ? 12:04
if it is in text, does it end with a CR or a CR/LF ? 12:05
amano I just send one line text command like "update\n" or "toggle\n".
lizmat and it's not arriving immediately ? when does it arrive then ?
amano Receiving a one-line command over a stream unix domain socket seems to take 0.2 second. 12:06
It should be faster.
I'm writing scripts for interactive keyboard shortcuts. 12:07
If it adds 0.2 second, I can feel it.
lizmat amano: that feels... weird... isn't that raku startup time ? 12:08
amano No.
It is a running daemon.
lizmat leont ^^
could it be polling at .2 second intervals ? 12:09
leont It's all just handed off to libuv…
amano What I'm saying is that once I receive a stream unix domain socket connection, it takes 0.2 second to get one line and close the connection. 12:10
I blame Supply.
Supply is slow.
It is not optimized for response latency.
I wish it was implemented as a channel. 12:11
lizmat amano: could you create a gist showing the timing issue ? 12:21
amano I'm fiddling with my codebase. 12:32
12:46 Vyrus left 12:47 Vyrus joined
amano Is there a way to directly extract an item from a Supply without a react block? 12:50
lizmat docs.raku.org/type/Supply#method_tap docs.raku.org/type/Supply#method_act 12:51
amano It turns out that $conn.Supply.lines.Channel.receive is faster than a react block. 12:53
It turns out that the slow part was calling $conn.Supply.lines.Channel.receive in a Supply tap. 12:58
Executing anything in a supply tap is 100 times slower. 12:59
It is better to hand over the execution to channels as soon as possible.
An on-demand supply tap is even slower than a live supply tap. 13:01
Channels are the highway. 13:02
ab5tract if you don't need multiple listeners, channels are definitely the way to go
though I feel like Supply is more documented 13:03
I'm surprised you are finding such a serious lag though
NemokoschKiwi feels like for what you want to do, maybe even a Promise API could be provided
but a Channel is not bad 13:04
13:09 NemokoschKiwi left
amano The lag is about 0.111 second. 13:44
In a channel whenever block, the lag is less than 0.002 second. 13:45
In a supply whenever block, the lag is about 0.111 second.
For receiving a line of text from a stream unix domain socket.
In an on-demand supply whenever block, the lag can be 5 seconds. 13:46
Speed: channel >>> live supply >>> on-demand supply
All of them are fast if they are queued up, thnough. 13:47
No, on-demand supply can still be slow.
Live supply can be fast if it is queued up. 13:48
13:49 jgaz joined
amano The fastest way: start { react { whenever $streamUnixDomainSocketSupply { $chan.send($_) } } }; react { $chan { my $msg = .Supply.lines.Channel.receive; .close; someFunction($msg); } } 13:59
leont: lizmat: ^^ 14:01
Receiving a line of text from a stream unix domain socket in a supply whenever block is very slow, compared to doing so in a channel. 14:02
There is an error. 14:03
The fastest way: start { react { whenever $streamUnixDomainSocketSupply { $chan.send($_) } } }; react { whenever $chan { my $msg = .Supply.lines.Channel.receive; .close; someFunction($msg); } }
Good day 14:10
14:10 amano left 14:57 leah2 left 15:09 swaggboi joined
tbrowder__ ugexe: i'm experimenting with zef and raku and wonder if there is any way to speed up zef's search. i see reference to its cache but it seems like it wanr 15:10
15:11 leah2 joined
tbrowder__ *wants to updatebit often. is there any way to get a cron job to do that and have zef always just use the cache? 15:11
ugexe the cache is more of a download cache. as in when you fetch/download something it saves it to a folder and remembers we have that module of that version saved locally. if its index was the same size as the ecosystem (i.e. if you cached every module) i'm not sure it'd be that much faster 15:18
you mention it wants to update a bit often. if you are suggesting you want those e.g. `===> Updating fez mirror: 360.zef.pm/` to happen less you can use the --/update flag to disable those automatic updates 15:20
a super advanced user could also use a custom config, specifically auto-update ( see github.com/ugexe/zef/blob/bf995228...g.json#L32 ) which is set to the number of hours old the package json file must be for it to automatically update it 15:21
i'd recommend just using --/update though
tbrowder__ thnx. btw, i've found the --force-install option cures some things for sure 15:43
esp. in mixed root/user use for zef 15:48
ugexe eh, --force-install is for reinstalling basically 15:49
it wouldnt speed anything up
tbrowder__ yes, but during at least one situation it was the only way to uograde zef. i'm collecting detailed notes and issues starting with a clean raku/zef (NOT installed) and installing El_Che's rakudo-pkg. 15:51
part of that is, for root and a normal user to install zef via a provided script (which currently installs zef v0.11.8). then i upgrade each and get some weird interaction for the user which i cured by just "zef install --force-install zef" 15:57
i just looked back at some old issues which have similar behaviors 16:00
when i finish i'll put what i have in a gist for you and El_Che 16:01
ugexe yeah if its using v0.11.8 thats pretty old. but i don't think you have to --force-install 16:03
because it would be installing a newer version
installing a newer version != reinstalling
hence no need for --force-install
16:11 linkable6 left, evalable6 left, evalable6 joined 16:12 linkable6 joined
tbrowder__ well on at least one incantation i did. but there are so many env things changing i'm trying to get a good, repeatable setup by scripting. clean house, start over, use shell script; rinse, repeat 16:31
cleaning up some old raku path settings has helped. thanks, nick 16:33
ugexe if you wanna start really fresh run `zef nuke site home` to delete all modules 16:35
including zef itself
16:47 teatime joined 16:57 teatime left 17:32 jpn joined
tbrowder__ yes, i was doing it but now i just blow away root and user .raku, .zef, zef dirs plus /opt/rakudo-pkg dir 17:45
17:46 jpn left 17:47 jpn joined
tbrowder__ i have pretty much confirmed that El_Che's rakudo-pkg has an erroneous path setting at least for root's zef-installed bin setting. but roots actual module distros are usable by root as welll 17:49
well as users. 17:50
the rakudo-pkg by default installs its zef into root's home directory, but root upgrading zef then needs option --install-to=home. 17:53
17:54 jpn left
tbrowder__ other than the zef location, it looks likenusers can use or ignore any of root's module installations. great news for me 17:57
so it seems no bugs for zef, but some suggestions for El_Che 17:58
18:00 reportable6 left 18:01 reportable6 joined
antononcube Please try the (new) module "Clipboard" on Linux and Windows. raku.land/zef:antononcube/Clipboard 18:18
I have only used and tested "Clipboard" on macOS. On a remote Linux machine I verified that my xclip utilization commands are correct, but I could not verify the module implementation through Raku's REPL (on that remote Linux machine.) 18:21
CLI clipboarding on Windows is not something I can easily test... 18:22
18:25 jpn joined
tbrowder__ ugexe: i'm trying to find where root operated zef is getting the site path from for module binaries. is it deterministic somewhere? or is it the "magic" paths for site and home? 18:46
18:53 jpn left 18:58 Sgeo joined 19:41 jpn joined 20:18 tea3po joined 20:21 teatwo left, tea3po left 20:22 tea3po joined 20:32 NemokoschKiwi joined
tbrowder__ ok, disregard that question. 20:34
20:37 jpn left 20:42 jpn joined 20:53 samcv_ joined, bpalmer` joined 20:54 kst` joined, pierrot_ joined 20:56 eseyman_ joined 20:58 avuserow_ joined 21:02 avuserow left, eseyman left, discord-raku-bot left, bpalmer left, pierrot left, kst left, samcv left, JRaspass left 21:06 jpn left 21:07 JRaspass joined 21:41 sena_kun left
El_Che ugexe, tbrowder__: zef is updated to the latest version with every rakudo release. But you can update zef anytime 21:54
tellable6 2023-08-25T13:54:47Z #raku <tbrowder__> El_Che what is the intended use of the path /opt/rakudo-pkg/share/perl6/bin
2023-08-25T14:38:53Z #raku <tbrowder__> El_Che it looks to me like the current /etc/profile.d/rakudo-pkg.sh is pointing to the wrong path
21:55 amano joined
amano . 21:57
21:57 amano left 21:59 kst` left 22:00 kst joined 22:53 NemokoschKiwi left, wayland76 left 23:53 quotable6 left, statisfiable6 left, coverable6 left, sourceable6 left, linkable6 left, greppable6 left, committable6 left, tellable6 left, releasable6 left, reportable6 left, nativecallable6 left, benchable6 left, bisectable6 left, unicodable6 left, notable6 left, squashable6 left, bloatable6 left, evalable6 left, shareable6 left 23:54 coverable6 joined, sourceable6 joined, quotable6 joined, statisfiable6 joined 23:55 releasable6 joined, unicodable6 joined, shareable6 joined, squashable6 joined, evalable6 joined, benchable6 joined, bisectable6 joined, notable6 joined 23:56 linkable6 joined, committable6 joined, reportable6 joined, bloatable6 joined, greppable6 joined, nativecallable6 joined, tellable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!