00:01 kjs_ joined 00:17 vendethiel joined 01:15 vendethiel joined 03:05 vendethiel joined 03:22 zakharyas joined
dalek arVM: e96d4b6 | jimmy++ | src/ (3 files):
Small fix
 03:42
03:49 vendethiel joined 04:13 vendethiel joined 04:47 vendethiel joined 06:07 vendethiel joined 06:40 vendethiel joined 07:07 vendethiel joined 08:40 vendethiel joined 09:52 JimmyZ joined
timotimo while laying in bed i thought we may want to expose the common inlined callsites to extops, too 10:00
p6routinereturn uses invoke, for example, and passes a "custom" non-inlined callsite 10:03
and p6finddispatcher also invokes under certain circumstances 10:04
dalek arVM: abceb18 | (Timo Paulssen)++ | src/core/callsite. (2 files):
expose callsite interning for extops
 10:54
12:07 zakharyas joined
dalek arVM: 0754017 | (Timo Paulssen)++ | src/ (3 files):
jit randscale_n through a little helper function
 12:26
timotimo low-ish hanging fruit: implement isnanorinf as well as cmp_n for the jit 13:40
please-k-thanks :)
as well as invokewithcapture, which i'm hoping brrt will get around to building
JimmyZ and as well as cmp_i ? 13:52
timotimo we don't have cmp_i yet? 15:23
in that case, go ahead :)
JimmyZ sleep firstly here :)
23:23 here 15:24
timotimo OK, good night :)
JimmyZ good night 15:26
timotimo jnthn: does it seem like an acceptable idea to merge BBs if they strictly follow each other and all that breaks them up is an unconditional goto and they each have only one successor/predeccessor between them? 15:42
intra-BB-optimizations seem a bit easier than inter-BB-optimizations
timotimo is trying to get the name of lexicals to show up in the speshlog, too 16:32
jnthn: is this the right idea? i have to take the SpeshGraph's sf, follow the ->outer->body as often as the lexical's "outers" value and then use the "idx" to index the literal_names_list array and get the entry's ->key and print that out, no? 16:33
jnthn Sounds approximately correct, yes 16:34
timotimo OK, then i'll just have to figure this segfault out :)
pff. --optimize=g and still all locals got optimized out 16:36
the 7th lexical name list entry is a null pointer; does that mean i have to demand the deserialization fo that frame to be completed? 16:38
jnthn Potentially yes 16:40
timotimo um ... the num_lexicals is 2, the index is 7 16:41
this is with outers being 0 16:42
so i'm directly accessing the g->sf->body->lexical_names_list
jnthn Umm...latest MoarVM master won't build for me... :( 16:45
callsite.c
src\core\callsite.c(41) : error C2375: 'MVM_callsite_get_common' : redefinition; different linkage c:\consulting\moarvm\src\core/callsite.h(104) : see declaration of 'MVM_callsite_get_common'
timotimo oh
i must have forgotten to commit tthat?
no, i did commit that
i put MVM_PUBLIC in front of that in the header and the source
perhaps i off-by-one'd the right function? 16:46
jnthn You didn't put it in the header.
timotimo fixed
i *did* off-by-one the right function
oh, dalek has gone to take a nap? 16:47
jnthn Seems happier. 16:52
FROGGS timotimo: feather2 has a downtime, and I guess that's where dalek runs 16:55
timotimo jnthn: now i just check for the index being in range and print a little note when it happens 16:57
happens only a single time in the program i just tested 16:58
looks good now i think
and committed 17:02
17:12 colomon joined 17:13 dalek joined
dalek arVM: 8922b62 | jnthn++ | src/ (3 files):
Only look at MVM_NFA_DEB env var once.

It's horribly expensively to access it repeatedly on Windows.		 17:34
17:43 vendethiel- joined 17:45 kjs_ joined 17:52 FROGGS_ joined 18:52 tadzik joined 19:27 kjs_ joined 19:33 [Coke] joined 19:57 synopsebot joined 20:17 colomon_ joined 20:28 colomon joined 20:46 colomon joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!