🦋 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:03 reportable6 left 00:32 rba[m] left, AlexDaniel left 00:33 AlexDaniel joined 00:42 rba[m] joined 02:04 reportable6 joined 03:44 squashable6 left 03:45 squashable6 joined 05:06 SmokeMachine left, jjatria left, SmokeMachine_ joined, jjatria_ joined, jjatria_ is now known as jjatria 06:04 reportable6 left 06:07 reportable6 joined
MasterDuke vrurg: do you have any ideas for how to optimize github.com/rakudo/rakudo/blob/mast...#L115-L216 ? 07:51
08:27 frost joined
Geth roast: 047d253ce6 | (Elizabeth Mattijsen)++ | S06-multi/unpackability.t
Mark suspect test on master as "skip"

This appears to have been fixed on new-disp, but either hangs on master, or produces the incorrect result.
09:14
rakudo: ffde2ba23e | (Elizabeth Mattijsen)++ | src/core.c/Rakudo/Iterator.pm6
Simplify R:I.While

The contract is that once an iterator has produced IterationEnd, it should not be called again. So we don't need to shield against that.
09:24
10:11 linkable6 left, evalable6 left 11:13 evalable6 joined 12:02 reportable6 left 12:07 TempIRCLogger joined 12:12 linkable6 joined 13:12 evalable6 left, linkable6 left 13:13 evalable6 joined
vrurg MasterDuke: not really. It fits well into new-disp, I hoped to replace it with a dispatcher at some point. 13:21
13:55 kjp left 13:57 kjp joined
vrurg MasterDuke: at the second thought some caching could be done which may improve repetitive coercions. Then again, it wouldn't make sense with new-disp then. 14:02
14:02 frost left 14:03 reportable6 joined 14:13 linkable6 joined 15:25 evalable6 left, linkable6 left 15:26 evalable6 joined 15:27 linkable6 joined
nine weekly: lwn.net/Articles/865037/ 16:21
notable6 nine, Noted! (weekly)
17:40 evalable6 left, linkable6 left 17:41 linkable6 joined, evalable6 joined 18:02 reportable6 left 18:05 reportable6 joined 18:31 raydiak_ is now known as raydiak 19:09 melezhik joined 19:18 melezhik left 20:18 evalable6 left, linkable6 left 20:19 evalable6 joined
vrurg m: use nqp; sub foo($a) { say "[", nqp::objectid($a.VAR), " ", $a.VAR.WHICH, "] "; }; foo(1); foo(2); 21:11
camelia [81037904 Scalar|28640512]
[71645072 Scalar|28640512]
vrurg Any idea why .WHICH outcome is the same? 21:12
MasterDuke c: releases sub foo($a) { $a.VAR.WHICH }; say foo(1) eq foo(2) 21:14
committable6 MasterDuke, gist.github.com/8ede6ffddb0cf7ee2a...b66e47fa17
MasterDuke bisectable6: old=2016.09 new=2016.10 sub foo($a) { $a.VAR.WHICH }; say foo(1) eq foo(2)
bisectable6 MasterDuke, Bisecting by output (old=2016.09 new=2016.10) because on both starting points the exit code is 0
MasterDuke, bisect log: gist.github.com/c360babc3a3ab57e35...64e58f2ab9 21:15
MasterDuke, (2016-10-12) github.com/rakudo/rakudo/commit/cf...1643af4348
MasterDuke c: releases sub foo($a) { return $a.VAR.WHICH }; say foo(1) eq foo(2)
committable6 MasterDuke, ¦releases (56 commits): «True␤» 21:16
MasterDuke interesting
vrurg A dynamic variable breaks inlining. But adding `my $*dyn` into the sub haven't changed the outcome either. 21:17
21:18 Kaipi joined
vrurg MasterDuke: do you think it worth an issue? 21:18
21:19 Kaiepi left
MasterDuke dunno 21:19
at least the behavior is consistent now
vrurg What worries me is that one can't trust high-level introspection which is really bad for debugging. 21:20
21:21 linkable6 joined
vrurg .ask lizmat what was the reason to make Scalar.WHICH work against $!descriptor in 329adf8c239c2325d6bcb6c5949501dac52ee132? Why self isn't acceptable? 21:51
tellable6 vrurg, I'll pass your message to lizmat
22:21 evalable6 left, tellable6 left, linkable6 left 22:24 evalable6 joined
lizmat . 22:59
.tell vrurg that's from 7 years ago, I have no idea
vrurg lizmat: I'm thinking about it, but currently it looks like WHICH is totally incorrect. 23:00
It proclaims Scalar to be a value object, but addresses not $!value but $!descriptor. 23:01
lizmat perhaps because all Scalars that have the same descriptor, are basically the same from a value type of view? 23:02
it should definitely *not* be about the value in there 23:03
will sleep on it&
vrurg I also agree it shouldn't be value. But it must not be the descriptor either.
And so, the Scalar is not a value object after all. 23:04
lizmat: g'night.
23:24 MasterDuke left, tellable6 joined