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
02:32 evalable6 left, linkable6 left 02:33 evalable6 joined 02:34 linkable6 joined 03:17 Kaiepi left 03:29 leont left 05:16 sourceable6 left, coverable6 left, shareable6 left, benchable6 left, releasable6 left, nativecallable6 left, bisectable6 left, notable6 left, evalable6 left, quotable6 left, squashable6 left, greppable6 left, tellable6 left, committable6 left, linkable6 left, bloatable6 left, statisfiable6 left, unicodable6 left, squashable6 joined, committable6 joined 05:17 tellable6 joined, notable6 joined, quotable6 joined, greppable6 joined, benchable6 joined, releasable6 joined, statisfiable6 joined, coverable6 joined 05:18 unicodable6 joined, nativecallable6 joined, shareable6 joined, bisectable6 joined 05:19 sourceable6 joined, linkable6 joined, bloatable6 joined, evalable6 joined 05:29 frost-lab joined 08:42 sena_kun joined
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
09:07 Altai-man joined 09:10 sena_kun left 09:33 Kaiepi joined
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
11:11 JJAtria[m] left 11:12 MitarashiDango[m left, AlexDaniel` left 11:13 unclechu left 11:31 JJAtria[m] joined 11:40 unclechu joined, MitarashiDango[m joined 11:45 AlexDaniel` joined
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)
12:28 frost-lab left 13:01 leont joined 13:07 sena_kun joined 13:09 Altai-man left
[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
15:38 cog left 15:43 cog_ joined, oddp joined
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
16:43 sena_kun left
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
19:49 oddp left 19:56 cog joined, cognominal left
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
20:55 ggoebel_ left 21:37 lucasb joined 22:24 ggoebel_ joined 22:29 ggoebel_ left
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
23:53 ggoebel_ joined