🦋 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.
timo looks like the implementation of method min currently turns any arity-one &by into a comparator first 00:22
[Coke] is the sub smarter? 00:47
timo looks like it directly delegates to the method 00:48
05:28 Xliff left
Geth rakudo/json-reborn: 5ffcf48d2a | (John Longwalker)++ | src/core.c/Rakudo/Internals/JSON.rakumod
from-json now uses 'parse-json' syscall
06:38
rakudo/json-reborn: 1c4a5eb1e9 | (John Longwalker)++ | src/core.c/Rakudo/Internals/JSON.rakumod
from-json now uses 'parse-json' syscall
06:40
rakudo: ab5tract++ created pull request #5869:
Draft: Make Rakudo::Internals::JSON 4-6x as fast
06:44
08:54 melezhik joined 09:23 finanalyst joined 10:51 melezhik left 11:28 melezhik joined 11:30 melezhik left
[Coke] wonders if json-reborn is a play on Jason Bourne 12:12
12:14 melezhik joined 12:51 JimmyZhuo joined
JimmyZhuo everytime I see rakudo core setting is rewritten by nqp or c, I think it's wrong direction. It didn't make rakudo faster, it makes users think rakudo is slow, so they don't use raku, use a faster language instead. 12:59
13:06 finanalyst left
JimmyZhuo another thing RakuAST has high use dispatcher, It looks like every loop uses dispatch a lot ? i.e: 'for @parameters -> $type, $name, $named, $optional {}', or 'if XXX {}' ?? 13:08
nine JimmyZhuo: you mean programs compiled with the RakuAST frontend? Yes, that's because static inlining of blocks is not yet implemented 13:09
JimmyZhuo nine: I mean RakuAST itself
which is NQP 13:10
this makes me think , nqp needs a subset of RakuAST, to have a better optimizer of nqp 13:12
nine Indeed. NQP doesn't have static inlining at all. I wonder if that could be somewhat straight forward to retrofit though. 13:17
JimmyZhuo: actually that might be a nice task for you :) NQP compiles and tests much faster than Rakudo 13:18
JimmyZhuo nqp has no static inlining of blocks, makes v6c.nqp is slow, and makes compiling core setting slow, am I right? 13:19
13:20 melezhik left
nine Yes. Though it's hard to predict how much slower this makes it. MoarVM's spesh also does inlining, so for very hot paths there should be no difference. 13:21
13:21 melezhik joined
nine The difference could be significant if we call a lot of different cold paths 13:21
JimmyZhuo nine: not sure about it , but for RakuAST , 'for 1...X {}' is compiling into a 'map', It is much slow than the old frontend, this always makes me think a better static optimizer helps spesh a lot 13:26
just for some discussion, not ask for something. good night :) 13:28
nine The old frontend also compiles for to a map
JimmyZhuo yes, and then the optimizer changes it, iirc? 13:29
anyway, I still like the new frontend, really good night 13:32
13:32 JimmyZhuo left, melezhik left 13:53 Geth left 13:54 Geth joined, lizmat left, lizmat_ left, lizmat joined
[Coke] Anyone here have a preference on what spec tests should be shipped with the .tgz each release? master vs. 6.d-errata ? (has been the latter, I have a PR to switch it to the former) 15:52
If no one speaks up, I'll go ahead and apply it.
ugexe why do we not implement slurp using IO::Handle.READ() 17:40
github.com/rakudo/rakudo/blob/b527...#L252-L254
at least for binary reads
i guess presumably READ would still need to consume from the decoder instead of what it does not 17:42
s/not/now/
19:32 finanalyst joined 19:53 notna joined 21:00 notna left 22:22 finanalyst left