| IRC logs at
Set by AlexDaniel on 12 June 2018.
01:02 konvertex left 02:32 AlexDaniel` left 02:55 AlexDaniel` joined
nwc10 good *, #moarvm 06:54
jnthn: MVMStaticFrame.c doesn't seem to copy lexical_frames_list (it does copy lexical_frams, the "hash", and num_lexicals, and plenty of other stuff). Given that spesh uses lexical_frames_list, I can't see how this isn't buggy. Which sort of implies that that code is never reached. What did I miss? 06:55
MasterDuke nwc10: you mean lexical_names_list? 07:14
nwc10 MasterDuke: I think I do. Thanks. Your coffee must be better than mine :-)
MasterDuke heh. it is pretty good, what i'm drinking now 07:15
nwc10: that does seem to be an omission, but i added a print inside and it never gets hit when building nqp and rakudo 07:32
so far the only thing that's triggered it is t/04-nativecall/00-misc.t
doesn't look like any spectests did either 07:35
08:09 zakharyas joined
jnthn nwc10: I think that the only time we do clone static frames is in freshcoderef, which is only used for stooges during compilation, and so the cloned ones probably never actually end up with code being run, and so would never be seen by spesh. 09:24
nwc10: That's not a good reason for it to be broken, but it would explain why we've gotten away with it.
nwc10 ah OK cool 09:26
09:33 sena_kun joined 09:37 konvertex joined 10:09 Altai-man_ joined 10:12 sena_kun left
nwc10 jnthn: as far as I can figure out, lexical_names and lexical_names_list are (should - ie bug in clone) always created at the same time, and we can't have duplicate lexical names, and so HASH_CNT() on lexical_names should always be the same as num_lexicals, and would be cheaper written as that. 10:34
not that I've tested any of this with assert()s yet, but I'm going to be surprised if there's a corner case where it's not true, as it' snot documented
10:48 zakharyas1 joined
jnthn Yes, it should always be true 10:48
10:51 zakharyas2 joined 10:52 zakharyas left 10:54 zakharyas1 left 11:27 zakharyas2 left
lizmat and yet another Rakudo Weekly News hits the Net: 11:44
11:56 leont joined 12:10 sena_kun joined 12:12 Altai-man_ left 12:34 zakharyas joined
bartolin_ lizmat: thanks for the weekly! (again) 13:58
lizmat: one note (maybe you could correct that): it was andreoss++ who did the work of renaming s/perl6/raku/ for the JVM backend. I only tested and hit the merge button: and 13:59
oops, sorry, not exactly the right channel ;) 14:00
14:09 Altai-man_ joined 14:11 sena_kun left 14:37 lucasb joined 15:52 travis-ci joined
travis-ci MoarVM build passed. Suman Khanal 'update .appveyor.yml 15:52
15:52 travis-ci left 16:10 sena_kun joined 16:12 Altai-man_ left 16:14 travis-ci joined
travis-ci MoarVM build errored. Suman Khanal 'fixing strawberry perl install 16:14
16:14 travis-ci left
Geth MoarVM: sumanstats++ created pull request #1300:
fix appveyor.yml
16:48 zakharyas left 16:58 zakharyas joined 17:34 zakharyas left 18:09 Altai-man_ joined 18:12 sena_kun left 18:23 MasterDuke left 18:28 jjatria left 18:31 jjatria joined 18:35 AlexDaniel` left 18:37 MasterDuke joined 18:49 zakharyas joined 19:19 AlexDaniel` joined 19:41 MasterDuke left
nwc10 jnthn: when entries are created in sc_weakhash... 20:02
in sc.c there's MVM_ASSIGN_REF:
MVM_ASSIGN_REF(tc, &(sc->common.header), scb->handle, handle);
MVM_HASH_BIND(tc, tc->instance->sc_weakhash, handle, scb);
but in bytecode.c there's just
MVM_HASH_BIND(tc, tc->instance->sc_weakhash, handle, scb); 20:03
and maybe it should be "obvious" to me why it's not needed, but it's not :-(
20:10 sena_kun joined 20:12 Altai-man_ left 20:16 MasterDuke joined 20:22 sena_kun left
nwc10 jnthn: also 20:23
20:50 zakharyas left 21:34 AlexDaniel joined, AlexDaniel left, AlexDaniel joined
jnthn hah :D 21:47
22:38 sena_kun joined 23:00 sena_kun left