🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
Kaiepi i tried something evil to reanimate the jvm: xzip serialized code, stuffed in an uncompressed segment of its jar. doesn't fix rakudo unsurprisingly, but produces much smaller jars ig 00:20
i tried updating nqp's org.objectweb.asm dependency and actually producing jvm 9 bytecode to see if that would at least help, but past version 5.2 it refuses to build nqp alone outright 00:22
because it tries to inline massive methods
so it's probably not so much a problem with serialization, but the inlining we also do? 00:25
[Coke] jdv: thank you for the release - reminder that we probably want to change "The Perl Foundation" to "The Raku Foundation" 00:37
japhb Hey folks, I did some research on Rakudo versions to use for CI because Jonathan and I were trying to figure out what a reasonable CI horizon is these days, and thought it might be useful here: gist.github.com/japhb/88322d76326d...108c90e567 00:52
Comments and suggestions welcome.
[Coke] japhb: looks good, looks like you gave that a lot of thought. 01:42
japhb Thanks [Coke]! 03:54
jdv thanks guys! 04:27
timo :+1: jdv 08:57
lizmat notable6: weekly 13:02
notable6 lizmat, No notes for “weekly”
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/08/01/2022-...merelease/ 13:44
sena_kun lizmat++ 13:47
Kaiepi i found a java flag combo that seems to help build times: -XX:+UseTransparentHugePages -XX:+AggressiveHeap 14:02
still have no idea how to get CORE.d.setting to build :(
Geth rakudo/lizmat-allow-no: 6a91316724 | (Elizabeth Mattijsen)++ | src/core.c/Main.pm6
Allow for --no-foo as alternative to --/foo

By setting the new "allow-no" flag in %*SUB-MAIN-OPTS:
   $ raku -r 'sub MAIN(|c) { say c }; my %*SUB-MAIN-OPTS=:allow-no' --no-foo
   \(:foo(Bool::False))
as opposed to:
   $ raku -r 'sub MAIN(|c) { say c }' --no-foo
   \(:no-foo(Bool::True))
14:09
rakudo: lizmat++ created pull request #5011:
Allow for --no-foo as alternative to --/foo
patrickb I have just uploaded the compiled release files to rakudo.org 17:54
Geth rakudo: 47f9b2860b | (Elizabeth Mattijsen)++ | src/core.c/Int.pm6
Add a lot of uint candidates for a lot of ops

This makes ++$a about 40% faster when $a is a native uint
19:18
[Coke] lizmat: some of those _u candidates invoke nqp_i variants - shouldn't it be _u all the way down? 19:24
e.g. prefix:<++> 19:25
lizmat there are no _u variants for that, I believe?
[Coke] ... nevermind, Guess there isn't an add_u 19:26
lizmat m: use nqp; nqp::add_u(1,2)
camelia ===SORRY!===
No registered operation handler for 'add_u'
[Coke] yah, just checked the docs file.
is the speedup there because it was hitting Int, not int? 19:27
lizmat yes
[Coke] cool
ok, I'm all caught up. :)
Kaiepi P6OpaqueREPRData and its serialization can be compressed somewhat with some bit magic for its attribute flags, but it has no influence on CORE.d.setting's allocation error 19:31
huhhh 20:55
jdk 20 seems to cope?
wait, env screwup 21:08
tick tock...
nothing with jdk 19 (20 doesn't behave quite yet) 21:21