ugexe i can't recall if i was only interested in fixing the only one side due to it being related to module loading, or if there was a good reason for that True result. i suspect the former, but its been awhile 00:01
s/fixing the/fixing/ 00:02
ugexe github.com/Raku/roast/blob/981c8c1...sion.t#L24 -- this is the only thing in the roast which disagrees 01:35
imo that test is wrong though -- the 'v1' should be written 'v1.*' to match v1.2.3 01:38
moritz: any opinion? you wrote the test 9 years ago :) 01:39
Geth rakudo/api-sorting: 43613ac536 | (Nick Logan)++ | 2 files
Prefer api sorting over version sorting

When sorting distributions my intention was for the highest api to be preferred (with the highest version being used if there was a tie in api version). This change aligns raku behavior with those intentions instead of preferring version over api.		 02:30
rakudo: ugexe++ created pull request #4152:
Prefer api sorting over version sorting		 02:31
Geth rakudo/dont-squat-common-arg-names: 6bf47c78f8 | (Nick Logan)++ | 2 files
Use less common names for installation shim arguments

A mostly unknown feature of the bin script shims CURI installs is that it allows choosing the distribution to load the script from, which allows loading an e.g. older version of some script. However to do so required using the :$name :$auth :$ver :$api arguments which prevents any installed raku bin script from taking any arguments of those names; the shim scripts breaks things such as providing a `bin/foo --ver` that outputs version information. This changes the argument names to use something far less likely to be used by arbitrary scripts (which is fine for rarely used options).		 05:18
rakudo: ugexe++ created pull request #4153:
Use less common names for installation shim arguments		 05:19
[Tux] Yesterday: 08:59
Rakudo v2020.12-29-g86fd7f67b (v6.d) on MoarVM 2020.12-16-g34f9d8c7a
csv-ip5xs0.818 - 0.848
csv-ip5xs-208.401 - 8.433
csv-parser26.394 - 27.120
csv-test-xs-200.379 - 0.394
test7.514 - 7.976
test-t1.940 - 1.974
test-t --race0.943 - 0.955
test-t-2033.450 - 33.795
test-t-20 --race10.304 - 10.418
Rakudo v2020.12-31-gf89863249 (v6.d) on MoarVM 2020.12-17-g532d9187e 09:20
jmerelo Happy new year everyone! 12:06
Is there a way to find out where NQP ops are implemented in the MoarVM version?
Whenever I search in Raku/NQP I keep finding the implementation in JVM and JS, but I don't really know where to look in MoarVM. 12:07
I've arrived as far as the 6model directory, but then it's not totally clear where the implementation of, say, nqp::copy lies
nine jmerelo: look in src/core/interp.c 12:19
OP(copy_f) 12:20
The names sometimes differ. Look in NQP's src/vm/moar/QAST/QASTOperationsMAST.nqp for the mapping, e.g. QAST::MASTOperations.add_core_moarop_mapping('copy', 'copy_f', 0); 12:21
jmerelo nine: great, thanks! 12:31
m: my @þ; say @þ.of.raku 12:34
camelia Mu
jmerelo m: my @þ; say @þ.of.^name
camelia Mu
jmerelo m: my Str @þ; say @þ.of.raku
camelia Str
jmerelo m: say (my int @).of.WHAT 12:36
camelia (int)
jmerelo m: say (my int @).of 12:38
camelia (int)
jmerelo nine++ thanks to your tip I've been able to answer this: stackoverflow.com/a/65529831/891440 12:53
Geth rakudo/faster-slice-access: 7e15259226 | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Internals/PostcircumfixAdverbs.pm6
Fix comment copy-pasto

Spotted by Christian Bartolomäus++		 19:51
gfldex m: my $c = Channel.new; $c.send: $++; .say for $c.Supply.lines; 20:38
camelia This type cannot unbox to a native string: P6opaque, Int
in block <unit> at <tmp> line 1
gfldex any suggestions how to golf that one further? 20:39
m: my $c = Channel.new; $c.send: $++.Str; .say for $c.Supply.lines;
camelia (timeout)
lizmat gfldex: you mean the one with the error or with the timeout ? 21:12
gfldex: the one with the timeout misses the closing of the channel 21:15
m: my $c = Channel.new; $c.send: $++.Str; $c.close; .say for $c.Supply.lines; 21:16
camelia 0
lizmat also: what is being sent on the channel is missing newlines... so all will be collected into one giant line to be produced when the channel closes
Geth rakudo/faster-slice-access: 738c8fb31e | (Elizabeth Mattijsen)++ | 3 files
Make @a[@i] = @b about 10x as fast

This uses the same ideas as from array slice accesses, but applies them to slice assignment. This breaks 2 tests in roast, that assume that assignment to lazy indexes will actually be lazy. The tests are marked as the assignment being lazy as being experimental.		 21:30
gfldex lizmat: I meant the one with the leaking P6opaque. 21:34
lizmat you're sending Int's down the line, and "lines" expects Str 21:35
*Ints
this commit also fixes: 21:43
m: my @a = <a b c d e>; my @i = 1,2,3; dd @a[1,2,(3,4)] = 1,2,3,4; dd @a
camelia (1, 2, (3, Any))
Array @a = ["a", 1, 2, 3, Any]
lizmat correct result: 21:44
(1, 2, (3, 4))
Array @a = ["a", 1, 2, 3, 4]
gfldex lizmat: That makes sense but leaves the question, if Supply.lines should produce lines. In the end a line is something with $?NL at the end and an Int can't have that. 22:13
lizmat well, it is really as simple (atm) that the supplier of Suppy.lines should produce strings 22:15
at least that's the current assumption
if we're going to allow anything, we're causing unnecessary overhead for the common case 22:16
Geth rakudo/faster-slice-access: 16fd4019e9 | (Elizabeth Mattijsen)++ | 3 files
Give @a[@i] := @b the same semantics as @a[@i] = @b

With respect to handling sublists such as:
   my @a = <a b c d e f g>;
   dd @a[1,2,(3,4)] := 4,5,6,7; # (4,5,(6,7))
   dd @a; # ["a", 4, 5, 6, 7, "f", "g"]		 22:20
lizmat calls it a night 22:22
Geth nqp: patrickbkr++ created pull request #691:
Switch spawnprocasync to use a separate arg for the program name		 23:32
rakudo: patrickbkr++ created pull request #4154:
Switch spawnprocasync to use a separate arg for the program name		 23:34

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!