| 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
|
|||