🦋 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.
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
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
hmmm...
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:45
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		 09:35
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
[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
 17:35
lizmat that's pretty good! 17:36
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
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.		 19:33
lizmat bartolin ^^
bartolin lizmat: Thanks! I'll try that out. 19:57
Geth rakudo: vrurg++ created pull request #4602:
Clarify let and temp operators		 20:54
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
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:08
Geth roast: MasterDuke17++ created pull request #769:
Some more tests that negative numbers aren't prime		 22:41
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
  github.com/MoarVM/MoarVM/pull/1587.		 23:08
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␤»

Powered by Cro and the Raku® Programming Language.

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

Thank you!