| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:02 sena_kun joined 00:04 Altai-man_ left 01:13 samcv left, samcv_ joined 02:01 Altai-man_ joined 02:03 sena_kun left 03:23 lucasb left 04:02 sena_kun joined 04:03 Altai-man_ left 06:01 Altai-man_ joined 06:04 sena_kun left 08:02 sena_kun joined 08:04 Altai-man_ left 09:00 samcv_ left 09:01 samcv joined 10:01 Altai-man_ joined 10:04 sena_kun left
Geth MoarVM/kosher-unicode-names-only: 4 commits pushed by (Nicholas Clark)++ 11:24
nwc10 and I think that that is correct solution. And it solves a bug that we didn't know that we had. 11:26
11:35 raku-bridge left, raku-bridge joined, MasterDuke left, MasterDuke joined, kawaii left, kawaii joined, lizmat left, lizmat joined, samcv left, samcv joined 11:36 timotimo left, timotimo joined 11:44 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 12:02 sena_kun joined 12:03 Altai-man_ left
lizmat I've come across a few of those lately :-) 12:56
Q: given an empty nqp::hash, will an nqp::atkey on it short-circuit and not actually hash the key ? 13:13
14:01 Altai-man_ joined 14:04 sena_kun left 15:47 patrickb joined 16:02 sena_kun joined 16:04 Altai-man_ left
Geth MoarVM/master: 4 commits pushed by (Nicholas Clark)++ 16:14
nwc10 lizmat: if nqp::atkey ends up calling MVMHash_at_key in MVMHash.c then that ends in HASH_FIND_VM_STR and it will short-circuit (and not hash the key) if the hash is NULL. 16:23
and I believe that the hash is NULL when (and whenever) it has no elements.
lizmat nwc10++ # thanks for verifying that!
nwc10 ie, not just "before we allocate storage", but due to the crazy inside-out way UT Hash works, also when the last key is deleted.
16:56 zakharyas joined 17:45 lucasb joined 18:01 Altai-man_ joined 18:03 sena_kun left 19:00 zakharyas left 19:06 zakharyas joined 20:02 sena_kun joined 20:04 Altai-man_ left 20:57 zakharyas left 22:01 Altai-man_ joined 22:04 sena_kun left 22:15 patrickb left
timotimo i'm having trouble finding any example of raku-assign being recorded? 22:17
tellable6 2020-06-27T23:31:01Z #raku-dev <AlexDaniel> timotimo please file a ticket about .kill! Thanks!
timotimo okay maybe there's only one occurence of it in this program? 22:23
in the spesh log, i mean
and it's decorated by "never dispatched"
but this is in postfix:<--> and that has no branches in it, so if it appears in the spesh log, surely it must have been called a few times 22:24
well, it has, according to the log anyway, and the next two dispatches in it even have results stored in the spesh log
oh 22:37
maybe when we resolve to invoke a frame, we log the result too late, and we end up storing it in whatever frame that was invoked as the result
timotimo tries something 22:42
single stepping is giving me very strange behavior, huh. 22:51