github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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! colabti.org/irclogger/irclogger_lo...06-27#l261 | ||
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 |