🦋 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.
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
23
3000
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
23
3000
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?
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
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.
08:30
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
10:06
lizmat nemokosch ^^ 10:08
vendethiel lizmat++ # sub prefix:<⍋> = *.sort(:k); sub prefix:<⍒> = *.sort(:k).reverse; 10:41
lizmat aah... APL :-) 11:26
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
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
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.
14:19
lizmat nine ^^ if you have any suggestions for me to look at
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
finanalyst @coleman I left a couple of messages for you on raku-doc 21:03
coleman Roger