|
🦋 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
|
|||