Geth rakudo: vrurg self-assigned Argument of a coercion type don't have a workable default value. github.com/rakudo/rakudo/issues/4092
44cc88b54c | (Vadim Belman)++ | src/Perl6/Actions.nqp

It must default to coercion target type.
Fixes #4092		 01:55
leont vrurg++ 02:13
linkable6 RAKUDO#4092 [closed]: github.com/rakudo/rakudo/issues/4092 Argument of a coercion type don't have a workable default value.
Geth roast: c2ecee1bac | (Vadim Belman)++ | S12-coercion/coercion-types.t
Test optional coercive parameter

Make sure rakudo/rakudo#4092 doesn't happen again.		 02:29
sena_kun bisectable6, say <1 2 3> \ <1 3> 08:46
bisectable6 sena_kun, Will bisect the whole range automagically because no endpoints were provided, hang tight
sena_kun, Nothing to bisect!
sena_kun, Output on all releases: gist.github.com/fa153398ac71db2748...5bfd5c5883
Geth nqp/fix-multithreaded-mixins: 461318767c | (Stefan Seifert)++ | src/how/NQPClassHOW.nqp
Make mixins concurrency safe

Multiple threads creating mixins on the same type of object could step on each other's toes as the mixin cache was not protected against concurrent access. Instead of adding locks, we now use the VM's parameterization mechanism, which is already concurrency safe and used for mixins in Rakudo.
Fixes "Iteration past end of iterator" when running: raku -e '(^10000).race.map({EVAL "q[];\n"}).sink'		 10:15
lizmat Files=1346, Tests=117143, 223 wallclock secs (30.00 usr 8.48 sys + 3113.00 cusr 298.24 csys = 3449.72 CPU) 10:16
nine a rebase
So....does anyone want to review that? Otherwise I'd just merge it
lizmat merge it, I'd say :-)
Geth nqp: 461318767c | (Stefan Seifert)++ | src/how/NQPClassHOW.nqp
Make mixins concurrency safe

Multiple threads creating mixins on the same type of object could step on each other's toes as the mixin cache was not protected against concurrent access. Instead of adding locks, we now use the VM's parameterization mechanism, which is already concurrency safe and used for mixins in Rakudo.
Fixes "Iteration past end of iterator" when running: raku -e '(^10000).race.map({EVAL "q[];\n"}).sink'		 10:17
nqp: 941b46fef7 | niner++ (committed using GitHub Web editor) | src/how/NQPClassHOW.nqp
Merge pull request #684 from Raku/fix-multithreaded-mixins

Make mixins concurrency safe
Altai-man We should make this snippet a test, though? 10:18
nine Maybe a stress test for now? It consumes almost 4G of memory here 10:19
Altai-man This works for me. 10:20
nine A bit of a consolation for me: even if in-process precompilation will never work, the fixes that fell out of it really help. Apparently e.g. this is now fixed: gist.github.com/ugexe/50f056eedbc7...2ced2a8cda 10:23
This may unlock the use of multi threading in zef
That was caused by returning () 10:24
Altai-man nine++ 10:26
Altai-man Blin is so far clean enough. We still have blockers. 12:13
One is moarvm-level.
lizmat m: class A { method CALL-ME(|c) { dd c } }; A(42) # so far, so good 12:20
camelia \(42)
lizmat m: role A { method CALL-ME(|c) { dd c } }; A(42) # alas 12:21
camelia Cannot invoke this object (REPR: Uninstantiable; A)
in block <unit> at <tmp> line 1
lizmat m: role A { method CALL-ME(|c) { dd c } }; (A.^pun)(42) # what should happen automagically
camelia \(42)
[Coke] m: m: role A { method CALL-ME(|c) { dd c } }; A.^compose; A(42); 13:15
camelia No such method 'compose' for invocant of type
'Perl6::Metamodel::ParametricRoleGroupHOW'
in block <unit> at <tmp> line 1
[Coke] m: m: role A { method CALL-ME(|c) { dd c } }; B = A.new ; B(42);
camelia 5===SORRY!5=== Error while compiling <tmp>
Preceding context expects a term, but found infix = instead.
Did you make a mistake in Pod syntax?
at <tmp>:1
------> 3e A { method CALL-ME(|c) { dd c } }; B =7⏏5 A.new ; B(42);
[Coke] m: m: role A { method CALL-ME(|c) { dd c } }; my B = A.new ; B(42);
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed my (did you mean to declare a sigilless \B or $B?)
at <tmp>:1
------> 3 A { method CALL-ME(|c) { dd c } }; my B7⏏5 = A.new ; B(42);
[Coke] m: m: role A { method CALL-ME(|c) { dd c } }; my \B = A.new ; B(42); 13:16
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '&B' is not declared
at <tmp>:1
------> 3CALL-ME(|c) { dd c } }; my \B = A.new ; 7⏏5B(42);
[Coke] ah well. :)
lizmat [Coke]: I was looking at that for Rake 14:58
so you could do Raku[Int,Int](42,66)
*Rake
Geth rakudo: d1d2546e63 | (Elizabeth Mattijsen)++ | src/core.c/native_array.pm6
Mark the base native array class as Positional

Just for consistency with Array. Should not affect anything else but array ~~ Positional returning True, just like Array ~~ Positional.		 15:25
nqp: b3cc2dbc65 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get the latest goodies.
 15:35
Geth rakudo: 8eb9db3a37 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get latest MoarVM/NQP goodies
 15:46
lizmat bisectable6: old=2020.01 use MoarVM::Profiler; dd MoarVM::Profiler.^name 16:04
bisectable6 lizmat, On both starting points (old=2020.01 new=8eb9db3) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «"MoarVM::Profiler::MoarVM::Profiler"␤»
lizmat bisectable6: old=2019.01 use MoarVM::Profiler; dd MoarVM::Profiler.^name
bisectable6 lizmat, Cannot find revision “2019.01” (did you mean “2020.01”?)
lizmat bisectable6: old=2019.01.1 use MoarVM::Profiler; dd MoarVM::Profiler.^name
bisectable6 lizmat, Cannot find revision “2019.01.1” (did you mean “2020.08.1”?)
lizmat bisectable6: old=2019.02 use MoarVM::Profiler; dd MoarVM::Profiler.^name
bisectable6 lizmat, Cannot find revision “2019.02” (did you mean “2020.02”?)
lizmat bisectable6: old=2019.03 use MoarVM::Profiler; dd MoarVM::Profiler.^name
bisectable6 lizmat, Bisecting by exit code (old=2019.03 new=8eb9db3). Old exit code: 1
lizmat, bisect log: gist.github.com/3556bbc457b6f384c4...ec89386319 16:05
lizmat, (2019-05-23) github.com/rakudo/rakudo/commit/fe...a2f8fb1f35
lizmat aaaahhhh.... 16:06
nine Lesson of the day: if you have the slightest suspicion that something might not be thread safe, even if you have no idea how it could cause issues, it is not thread safe. 16:45
A `raku -e '(^10000).race.map({EVAL "q:to/END/;\nEND\n"}).sink'` will occasionally throw a "No lexical found with name '$_'" error. The reason appears to be github.com/Raku/nqp/blob/master/sr...ck.nqp#L42 16:47
lizmat yikes 16:48
at least on MoarVM that could be turned into an atomic int
nine Thread unsafe incrementation of that number can lead to 2 blocks sharing the same CUUID. This leads to us losing a frame and we may end up with <unit> getting taken as deserialize_frame. This frame does not get the benefit of nqp::forceouterctx thus the lookup of the outer's $_ fails
Could in theory at least. But NQP doesn't have those yet. atomicinc only works on a native container, not directly on a native value. I don't know yet how to create one. For now I've added a lock. 16:49
lizmat nine++ 16:50
that would be backend agnostic
nine Seems to be stable, but will give it another hour during my training
lizmat method symbol(str $name, *%attrs) { 16:51
%!symbol := nqp::hash() if nqp::isnull(%!symbol);
that also looks racey to me ?
Ah, I guess not, as each thread would have its own QAST::Block object
nine exactly 16:52
lizmat grammar NQP::Grammar is HLL::Grammar { 16:58
my $sc_id := 0;
nine: ^^ another case?
QAST::Node.unique also looks racey to me 17:00
as does QAST::Node.dump_indent_string although that may not be such an issue 17:01
afk for a few hours&
nine: feels like another race condition to me: github.com/Raku/nqp/blob/master/sr...r.nqp#L118 18:55
and github.com/Raku/nqp/blob/master/sr...e.nqp#L558 also feels iffy ? 18:57
Geth rakudo: a76e2b6e74 | (Elizabeth Mattijsen)++ | 2 files
Add support for native slice assignment from native

Now that slices on native arrays return arrays of the same native type, it makes sense to optimize assigning those values to a native array. This commit makes @a[1,2,3] = @b where @a and @b are of the same native type, 26x as fast. And makes it 18x as fast if the receiving array is a native shaped array.		 19:45
lizmat afk for a few hours& 19:46
Geth nqp: 440f20ae45 | Coke++ | t/docs/tests.t
make test runnable directly
 20:00
nqp: 2d6c047a71 | Coke++ | docs/ops.markdown
avoid use of ( for scripts parsing docs
nqp: 4fbce486e6 | Coke++ | t/docs/tests.t
Change test from nqp to raku
[Coke] ^^ that test needed some love; shows opcodes that are "tested" (or at least used in a source file) and make sure documented opcodes are tested, and vice versa. 20:01
279 failures on that test, 181 on the 'are ops docced' test.
github.com/Raku/nqp/issues/274 - this test was fudged 4 years ago 20:10
Geth rakudo: 60fa48ec8f | (Elizabeth Mattijsen)++ | 3 files
Don't do recent native array opts on JVM backend

It appears they cause problems in roast, and as they are purely for performance, they can be easily not compiled on the JVM backend.		 22:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!