🦋 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:00 reportable6 left 00:01 reportable6 joined 00:03 ab5tract joined 00:37 ab5tract left
MasterDuke japhb: i think copying native arrays should be using memcpy, if you're going from one to another of the same parameterization 01:55
m: my int @a = ^10_000; my int @b; my $s = now; @b = @a for ^100_000; say now - $s; @b[3_000] = 23; say @b[3_000]; say @a[3_000] 01:59
camelia 0.148709466
MasterDuke locally, perf shows ^^^ spending most of its time in memcpy 02:00
m: my int32 @a = ^10_000; my int @b; my $s = now; @b = @a for ^100_000; say now - $s; @b[3_000] = 23; say @b[3_000]; say @a[3_000]    # but if they differ... 02:02
camelia 6.021918929
02:11 linkable6 left, evalable6 left 02:12 linkable6 joined 02:13 evalable6 joined
japhb MasterDuke: In the case of CBOR-Simple the problem is that a Buf is a VMArray and a CArray is a CArray and a native_array is neither. 02:56
MasterDuke hm. converting between all combinations of the three? 02:57
japhb Not all of them. Mostly native_arrays or CArrays in and out of buf8's, possibly with byte swapping. But yeah, pretty much all the native_array types, including unusual stuff like 16-bit floats. 02:58
MasterDuke huh. and how do you currently do something like `my int64 @a = 1,2; my buf8 $b = @a;`? 03:31
or do the sizes always match?
05:27 quotable6 left, tellable6 left, sourceable6 left, benchable6 left, notable6 left, coverable6 left, committable6 left, nativecallable6 left, statisfiable6 left, bisectable6 left, reportable6 left, greppable6 left, evalable6 left, shareable6 left, releasable6 left, unicodable6 left, linkable6 left, bloatable6 left, squashable6 left 05:28 notable6 joined, bisectable6 joined, nativecallable6 joined, committable6 joined, evalable6 joined, coverable6 joined 05:29 shareable6 joined, quotable6 joined, linkable6 joined, statisfiable6 joined, releasable6 joined, unicodable6 joined, greppable6 joined, tellable6 joined 05:30 sourceable6 joined, bloatable6 joined, reportable6 joined, squashable6 joined, benchable6 joined 06:00 reportable6 left 06:03 reportable6 joined
japhb Packing is relatively reasonable: github.com/japhb/CBOR-Simple/blob/...#L393-L490 06:05
Unpacking is ... less so: github.com/japhb/CBOR-Simple/blob/...L778-L1004 06:06
07:03 linkable6 left, evalable6 left 07:04 evalable6 joined 07:05 linkable6 joined
Geth rakudo/main: 87585eaac4 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Sorting.pm6
Streamline sorting of degenerate lists

Specifically the 0, 1 and 2 element lists.
This got rid of a helper sub, and reduced the bytecode size of the sorting logic. Still nowhere near inlining, but will allow more inlining into it.
09:56 linkable6 left, evalable6 left 09:58 linkable6 joined 09:59 evalable6 joined 10:00 jjatria left, JRaspass left
Geth rakudo/main: 53edf4e425 | (Elizabeth Mattijsen)++ | 2 files
Implement List.sort(&by?, :k) to return result indices

rather than the original or mapped values. There are basically 3 flavours:
  - .sort(:k) sort values, return indices
  - .sort(*.Str), :k) sort stringified values, return indices
  - .sort(&[==], :k) sort using given comparator, return indices
lizmat nemokosch ^^ 10:08
10:14 jjatria joined, JRaspass joined 10:32 timo left 10:37 timo joined
vendethiel lizmat++ # sub prefix:<⍋> = *.sort(:k); sub prefix:<⍒> = *.sort(:k).reverse; 10:41
10:45 Geth left, Geth joined, RakuIRCLogger left, RakuIRCLogger joined 11:09 JRaspass left, jjatria left 11:21 JRaspass joined
lizmat aah... APL :-) 11:26
11:27 jjatria joined 12:00 reportable6 left, reportable6 joined 12:05 |Tux| left, tbrowder__ left, rba left, leont left, |Tux| joined, tbrowder__ joined, rba joined, leont joined 12:17 JRaspass left, jjatria left 12:29 jjatria joined 12:34 JRaspass joined 12:56 ab5tract joined 13:22 JRaspass left 13:33 JRaspass joined 13:45 rypervenche left 14:01 rypervenche joined
lizmat ugexe nine looks like a4a2bbd24e9aed012fd175028501effb96ad35da causes a -28 in make test on RakuAST 14:06
basically all of NativeCall dies
INIT my Lock $setup-lock .= new
apparently does not precompile correctly yet in RakuAST 14:07
14:07 linkable6 left
lizmat m: say Q|INIT my Lock $setup-lock .= new|.AST.EVAL 14:08
camelia Lock.new
lizmat runs fine otherwise, just when it gets to be precompiled
14:08 linkable6 joined
Geth rakudo/main: 20bd4165d1 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: add support for "once" statement prefix

  - add class RakuAST::StatementPrifix::Once
  - add grammar and action hooks
Sadly, the "once" block does not get executed, so the value always remains Mu. Looking at the generated QAST, it looks ok to me. But I'm surely missing some subtlety. At least it doesn't break any tests.
lizmat nine ^^ if you have any suggestions for me to look at
14:42 lizmat_ joined 14:43 lizmat left 14:46 lizmat_ left, lizmat joined
ugexe Unfortunately I don't have anything to add. I'm not quite sure why the INIT was needed for NativeCall to run when disabling precomp, but it felt like some nativecall role that gets mixed in with a trait was trying to access the lock variable in such a way that the Lock.new had not been run yet ($setup-lock would still be Lock:U). It also seems like we would only want to create locks at runtime, 14:47
and that creating this specific one asap at runtime didn't *not* make sense
lizmat understood 14:50
15:46 linkable6 left, evalable6 left 15:48 linkable6 joined 15:49 evalable6 joined 17:31 ab5tract left 18:00 reportable6 left 18:02 reportable6 joined 19:02 linkable6 left, evalable6 left 19:03 linkable6 joined, evalable6 joined 19:13 squashable6 left, squashable6 joined 20:15 ab5tract joined 20:27 ab5tract left 20:54 finanalyst joined
finanalyst @coleman I left a couple of messages for you on raku-doc 21:03
coleman Roger
21:34 ab5tract joined 23:18 finanalyst left 23:59 guifa__ joined