🦋 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.
00:08 reportable6 left, reportable6 joined
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
03:04 frost joined 03:16 frost left 03:35 frost joined
japhb Thanks [Coke]! 03:54
jdv thanks guys! 04:27
06:07 reportable6 left 06:09 reportable6 joined 06:38 djinni` left, rba left, sjn left, sjn joined 06:39 rba joined, djinni` joined 06:51 SmokeMachine joined 06:54 crystalfrost[m] joined 06:55 RakuIRCLogger left, RakuIRCLogger joined 06:59 RakuIRCLogger left, RakuIRCLogger joined 07:39 sena_kun joined 08:39 RakuIRCLogger left, RakuIRCLogger joined
timo :+1: jdv 08:57
09:22 sena_kun left 09:40 discord-raku-bot left, discord-raku-bot joined 10:04 sena_kun joined 10:30 gfldex left, discord-raku-bot left 11:40 benchable6 left, coverable6 left, greppable6 left, sourceable6 left, releasable6 left, shareable6 left, reportable6 left, bloatable6 left, quotable6 left, nativecallable6 left, notable6 left, unicodable6 left, linkable6 left, evalable6 left, bisectable6 left, committable6 left, statisfiable6 left, tellable6 left 11:41 nativecallable6 joined, coverable6 joined, bisectable6 joined, releasable6 joined, shareable6 joined, committable6 joined, benchable6 joined 11:42 unicodable6 joined, quotable6 joined, tellable6 joined, evalable6 joined, reportable6 joined, statisfiable6 joined, linkable6 joined 11:43 bloatable6 joined, notable6 joined, sourceable6 joined, greppable6 joined 12:07 reportable6 left 12:09 reportable6 joined 12:38 Xliff left
lizmat notable6: weekly 13:02
notable6 lizmat, No notes for “weekly”
13:09 frost left, vrurg left 13:10 vrurg joined
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
as opposed to:
   $ raku -r 'sub MAIN(|c) { say c }' --no-foo
rakudo: lizmat++ created pull request #5011:
Allow for --no-foo as alternative to --/foo
14:56 [Coke]_ joined 14:58 [Coke] left 16:41 discord-raku-bot joined 16:58 [Coke]_ is now known as [Coke] 17:02 sivoais left 17:15 sivoais joined 17:18 sena_kun left 17:31 sivoais left 17:39 sivoais joined
patrickb I have just uploaded the compiled release files to rakudo.org 17:54
17:54 sena_kun joined 18:06 reportable6 left 18:07 reportable6 joined 18:57 sena_kun left 19:00 sena_kun joined
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
[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
21:38 sena_kun left 21:43 lucs_ joined 21:48 lucs left 22:36 linkable6 left 22:38 linkable6 joined