🦋 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.
elcaro The linux download on rakudo.org/downloads is halting at 16.2M (~82%) 02:23
coleman can you paste the exact link you're using elcaro 02:47
coleman i can't reproduce 02:50
elcaro rakudo.org/dl/rakudo/rakudo-moar-2...gcc.tar.gz 05:45
wget from multiple linux boxes gets "Connection closed" after 16M. Also tried downloading via Firefox on Windows and it also fails 05:48
avuserow elcaro: works for me on two different ISPs. Though if I download via IPv6 it is slow (~500KB/s vs ~60MB/s on IPv4), so maybe try `wget -4 ...`? 05:52
Geth advent/main: 7593e0e9e2 | (Nigel Hamilton)++ (committed using GitHub Web editor) | raku-advent-2023/authors.md
Update authors.md
 08:26
elcaro avuserow: Already using IPv4. Doesn't even connect with IPv6. Dunno if it's related, but I've tried from 3 different boxes, different ISP's, but all in Australia 11:38
elcaro If it's any help, trying to download with curl also fails with the error: 'curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)' 11:44
kjp wget also fails from here, also Australia 11:45
elcaro Looking up that error, first SO result suggests it could be an issue with 'proxy_buffering' in nginx, or maybe Application Load Balance (ALB) on AWS. 11:47
avuserow More data points on (pre-)compilation speed: if I make an empty A.rakumod and a B.rakumod that imports A, and change A.rakumod (to force recompilation), `use B` takes ~500ms longer than `use A`. With RAKUDO_NO_PRECOMPILATION=1, then it's only a ~18ms difference. This is on 2023.11 on older hardware; on current hardware all the numbers are roughly half as much 17:10
It seems like there is may be some potential optimization opportunities. I see that github.com/rakudo/rakudo/issues/4845 might be potentially related, but I'll file a new ticket and cross-reference. 17:11
ab5tract avuserow++ 17:12
avuserow Once I get to actual code, the 500ms difference between the A and B scenarios seems to increase. In my actual application it's more like 1.5s added. I have a few refactoring opportunities that would reduce the amount of work that compilation has to do (depending on what changed), but not until this is improved 17:15
avuserow I think a cause of slowness in precomp might be process startup time since it uses additional rakudo processes to compile. `raku -e'{}'` is 40% of the additional time between A and B above, on both computers. Unfortunately the profiling options don't seem to matter for the inner processes (and I don't even know if it's something that can be profiled?) 19:52
melezhik sparrowci build with PAKKU_VERBOSE=debug looks a bit weird for me - ci.sparrowhub.io/report/3824 20:03
AlexDaniel I've never seen 3 almost identical PRs for the same module XD github.com/Util/Perl6-Math-Quaternion/pulls 22:23
the same issue I mean 22:24
antononcube weekly:rakuforprediction.wordpress.com/20...-via-raku/
notable6 antononcube, Noted! (weekly)
avuserow I have a proof of concept of an environment variable that lets Raku use existing compiled sources but not generate new ones. This makes reloading the code much faster when changing one dependent module. It's 2x faster when changing and reloading my actual application code. 23:01
My idea is that in dev mode, I would precompile everything, then start the service with NO_NEW_PRECOMP, then run precomp in the background for next time. This should improve timing of restarting the service for developers at the cost of doing redundant compilation work. 23:02
ugexe In process precomp is a known missing and welcome feature fwiw 23:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!