🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 00:18 dogbert17 joined 00:19 dogbert11 joined 00:23 dogbert17 left 00:31 dogbert11 left 00:50 dogbert11 joined 00:55 dogbert17 joined 00:59 dogbert11 left 01:04 reportable6 joined 02:09 dogbert17 left 02:28 dogbert17 joined 03:50 melezhik left 04:50 reportable6 left, notable6 left, quotable6 left, unicodable6 left, bloatable6 left, statisfiable6 left, greppable6 left, committable6 left, bisectable6 left, benchable6 left, squashable6 left, releasable6 left, linkable6 left, coverable6 left, shareable6 left, evalable6 left, tellable6 left, sourceable6 left, nativecallable6 left, reportable6 joined, quotable6 joined 04:51 benchable6 joined, tellable6 joined, notable6 joined, committable6 joined, linkable6 joined 04:52 shareable6 joined, squashable6 joined, unicodable6 joined 04:53 bloatable6 joined 05:08 frost left 05:32 SmokeMachine left, SmokeMachine joined 05:52 statisfiable6 joined, nativecallable6 joined 05:55 [Coke] left 05:57 dogbert11 joined 05:59 dogbert12 joined 06:00 dogbert17 left 06:02 reportable6 left 06:03 reportable6 joined, dogbert11 left 06:04 dogbert17 joined, dogbert12 left 06:08 Kaiepi left 06:51 greppable6 joined, bisectable6 joined, dogbert17 left 06:52 sourceable6 joined 07:08 Kaiepi joined 07:30 dogbert17 joined 07:33 dogbert11 joined 07:34 dogbert17 left 08:05 dogbert17 joined 08:06 dogbert11 left 08:13 dogbert11 joined 08:15 dogbert17 left 08:24 dumarchie joined, dogbert17 joined
lizmat Files=1349, Tests=117863, 306 wallclock secs (35.59 usr 9.66 sys + 4272.10 cusr 342.41 csys = 4659.76 CPU) 08:25
dumarchie lizmat, I've a question regarding github.com/rakudo/rakudo/commit/40...a06860bda1 08:26
lizmat dumarchie: and the question is?
dumarchie `QuantHash` appears to be the only type that implements its own `multi method list(QuantHash:U:)`. Do you know why? 08:27
08:28 dogbert11 left
dumarchie All other types rely on `multi method list(Any:U)` instead of overriding it. 08:28
lizmat probably because QuantHashes are not Iterable ? 08:29
dumarchie But the QuantHash:U multi just calls the Any:U multi. 08:30
lizmat m: dd infix:<,>(set(1,2,3)) 08:31
camelia Set.new(2,1,3)
dumarchie Why would that not work without overriding the Any:U multi?
lizmat well, that's just a type object, calling .list on a type object should create a list with one element in it: that type object 08:32
dumarchie m: QuantHash.list.raku 08:33
camelia ( no output )
dumarchie m: dd QuantHash.list
camelia (QuantHash,)
dumarchie m: dd Any.list
camelia (Any,)
dumarchie The only good reason I can think of that there are cases where QuantHash.isa(Any) is False, but I did not find such cases. 08:35
I meant cases where a type that does QuantHash does not inherit from Any. 08:36
Shall I try and remove this apparently redundant candidate? 08:38
lizmat you mean the U: candidate ? 08:39
dumarchie Yes, the QuantHash:U candidate
lizmat yeah, pretty sure that can go :-) 08:40
dumarchie (y)
Geth rakudo: dumarchie++ created pull request #4600:
Remove redundant multi method list
08:50 coverable6 joined 09:21 frost joined
Geth rakudo: 8fd65670f8 | (Peter du Marchie van Voorthuysen)++ | src/core.c/QuantHash.pm6
Remove redundant multi method list

The multi method list(QuantHash:U:) just called self.Any::list
rakudo: 6278c4f77a | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/QuantHash.pm6
Merge pull request #4600 from dumarchie/master

Remove redundant multi method list
09:53 evalable6 joined 11:25 evalable6 left, linkable6 left, frost left 11:26 evalable6 joined 11:27 frost joined, linkable6 joined 11:38 [Coke] joined 11:50 releasable6 joined 12:02 reportable6 left 12:03 reportable6 joined 12:32 dogbert11 joined 12:35 dogbert17 left 13:48 Kaiepi left 13:55 dumarchie left 14:13 dogbert17 joined 14:16 dogbert11 left 14:23 _Xliff_ joined 14:25 Xliff_ left 14:26 Xliff joined 14:28 _Xliff_ left, Xliff_ joined 14:31 Xliff left, _Xliff_ joined 14:34 Xliff_ left 14:46 frost left 14:48 frost joined 15:02 Xliff_ joined 15:04 _Xliff_ left 15:27 _Xliff_ joined 15:30 Xliff_ left 15:37 melezhik joined 16:07 Xliff_ joined 16:09 _Xliff_ left 17:05 zostay_ joined, leont_ joined 17:13 leont left, zostay left, casaca left, leont_ is now known as leont, zostay_ is now known as zostay, casaca joined 17:34 Kaiepi joined
[Tux] Rakudo v2021.10-22-g6278c4f77 (v6.d) on MoarVM 2021.10-15-g51bff712c
csv-ip5xs1.351 - 1.417
csv-ip5xs-2015.028 - 15.686
csv-parser3.970 - 4.099
csv-test-xs-200.374 - 0.377
test6.876 - 7.023
test-t1.536 - 1.570
test-t --race0.975 - 0.999
test-t-2022.220 - 22.515
test-t-20 --race7.382 - 7.454
lizmat that's pretty good! 17:36
18:02 reportable6 left 18:04 reportable6 joined 18:21 _Xliff_ joined 18:23 Xliff_ left 18:38 notna joined 18:47 sena_kun left 18:48 sena_kun joined
bartolin It looks like yesterdays commits to simplify some protos didn't work well for the JVM backend. There are massive spectest failures :(. (I was already afraid of that when I read "Because new-disp allows removel of the nqp::getlexcaller hack".) 19:08
lizmat aaah... ok
shall I revert that and make it backend specific ? 19:09
bartolin I'm +1 on that :)
lizmat ok, will do :-)
bartolin ++lizmat 19:10
19:12 Xliff_ joined 19:15 _Xliff_ left 19:19 _Xliff_ joined 19:21 Xliff_ left 19:24 Xliff_ joined 19:27 _Xliff_ left 19:31 _Xliff_ joined
Geth rakudo: c50bc99856 | (Elizabeth Mattijsen)++ | 2 files
Only simplify protos on the MoarVM backend

On other backends, the nqp::getlexcaller in the proto is still necessary.
lizmat bartolin ^^
19:34 Xliff_ left 19:37 Xliff_ joined 19:40 _Xliff_ left 19:44 _Xliff_ joined 19:46 Xliff_ left 19:47 Xliff_ joined 19:50 _Xliff_ left
bartolin lizmat: Thanks! I'll try that out. 19:57
20:19 notna left
Geth rakudo: vrurg++ created pull request #4602:
Clarify let and temp operators
lizmat bisectable6: our %h is Map 21:08
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, Output on all releases: gist.github.com/b5cb22fcaa311431cc...bd303b8c51
lizmat, Bisecting by output (old=2017.03 new=2017.04.3) because on both starting points the exit code is 1
lizmat, bisect log: gist.github.com/29788d314c3a9c3508...8562aed4a9 21:09
lizmat, (2017-04-14) github.com/rakudo/rakudo/commit/82...75f0bf0f7e
lizmat, Output on all releases and bisected commits: gist.github.com/fcd1bfeeb9b117037b...92f2030521
21:19 evalable6 left, linkable6 left 21:20 evalable6 joined
MasterDuke lizmat: i wonder if this comment is still correct after new-disp github.com/rakudo/rakudo/blob/mast...1570-L1571 21:58
Geth roast: vrurg++ created pull request #768:
Add tests for let/temp preserving holes and containerization
22:22 linkable6 joined 22:39 _Xliff_ joined
Geth roast: MasterDuke17++ created pull request #769:
Some more tests that negative numbers aren't prime
22:42 Xliff_ left 22:45 squashable6 left 22:47 squashable6 joined
Geth roast: f34df3d1e9 | (Daniel Green)++ | S32-num/is-prime.t
Some more tests that negative numbers aren't prime

Add some cases that test the MoarVM bug fixed by
roast: 5da43e96e4 | MasterDuke17++ (committed using GitHub Web editor) | S32-num/is-prime.t
Merge pull request #769 from MasterDuke17/negative_numbers_should_not_be_prime
lizmat bisectable6: for ^10 { $/++ }; say $/ 23:09
bisectable6 lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight
lizmat, ¦6c (59 commits): «10␤»
lizmat, Nothing to bisect!
lizmat bisectable6: old=2016.01 for ^10 { $/++ }; say $/ 23:10
bisectable6 lizmat, On both starting points (old=2016.01 new=c50bc99) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «10␤»
lizmat bisectable6: old=2015.01 new=2016.01 for ^10 { $/++ }; say $/
bisectable6 lizmat, On both starting points (old=2015.01 new=2016.01) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «10␤»