02:47 ilbot3 joined 05:31 vendethiel joined 06:46 virtualsue joined 07:06 virtualsue joined 07:11 domidumont joined 07:17 domidumont joined 08:06 Ven joined 08:08 FROGGS joined 08:15 Ven joined 08:37 zakharyas joined 09:27 leont joined 09:35 brrt joined 10:15 kjs_ joined
dalek arVM: cc59c5e | (Jimmy Zhuo)++ | src/core/interp.c:
re-order op
 11:00
arVM: bc36ad6 | (Francois Perrad)++ | src/core/args.c:
remove useless curly brackets
 11:08
arVM: ae463e0 | (Francois Perrad)++ | src/core/callsite.c:
remove unreachable code
arVM: 2f4d271 | (Francois Perrad)++ | src/core/exceptions.c:
remove duplicated include
arVM: 5345c2f | (Francois Perrad)++ | src/core/validation.c:
comment FALLTHROUGH in uppercase is understood by many lint tools
MoarVM: bddcf29 | (Francois Perrad)++ | src/core/bytecodedump.c:
MoarVM: add parentheses around parameters in macro
11:44 FROGGS joined 11:48 zakharyas joined
JimmyZ jnthn: I found haveat_s op not used, Do you think it need to be DEPRECATED? 12:43
jnthn No. Stop deprecating stuff. 12:44
What's the point?
brrt \o jnthn 12:47
jnthn o/ brrt 12:48
JimmyZ it looks like doing something like index_s
brrt long time no see here? :-) 12:49
jnthn brrt: Indeed. :) Hope you're doing fine?>
JimmyZ: iirc, it's checking if the string in question exists at the specified index.
So, a bit different.
timotimo so it's like eqat?
brrt i'm very busy with my thesis still.. eating all my time :-) but it's going well 12:50
jnthn Yes...so how does it different from eqat? :)
timotimo i hope your time is tasty
brrt :-D
its been caffeinated, for one thing
timotimo :) 12:51
brrt i do have lots of notes on how to proceed with the jit
maybe i should write them up in a gist, then others can look at them too
timotimo well, to be honest, i wouldn't be able to contribute much 12:52
so if writing it down is only a time sink, it's not helpful from my POV
if it makes things easier for you, though, that's a whole 'nother story
brrt you can add comments? :-)
hmmm
jnthn will be doing more optimization-y stuff, so could be in a position to help, and could use such a doc.
brrt do you think the even-moar-jit work has become too complex? 12:53
ok, i'll make it one of them days...
would be very helpful if you could take a look :-)
(you = plural you, fwiw)
jnthn :) 12:54
I wonder a bit if even-moar-jit has suffered from not cheating enough to Get Something Working that can then be incrementally improved. 12:55
Good code-gen is relatively complex, so I can imagine that's an amount of necesary complexity in there. 12:56
*there's
brrt hmm.... i could kind of agree on that
although the current version is quite cheating
i.e., doesn't do anything conditionally and all that
personally, i kind of think the whole issue of internal-basic-blocks caught me by surprise 12:57
like, if something conditionally calls a c function, then that invalidates all variables that live in registers
i really have / had no proper way to deal with that, and dealing with it inline in the register allocator routines itself, i never got that to work properly 12:58
jnthn Where did we end up with on that? A JIT graph that was low level enough that it captured all kinds of basic blocks may be a way to go...
brrt that is kind of my next step, yes 13:06
we have lots and lots of moarvm-level nodes which end up into multiple low-level basic blocks 13:07
anytime there is an if (some_check) { do_this(); } else result=NULL;, that's three basic blocks right there
jnthn Indeed 13:08
brrt if i have if (some_check) { do_this(); result=1; } else result = 0; that is four
jnthn This is why spesh tries to re-write various things to ops that don't have such indirections. 13:09
brrt now what is interesting, or annoying, is that i first have to linearise instructions into a sequence before i can define the basic blocks, because otherwise a subtree (which may be refered to by different parents) may belong to multiple basic blocks.... 13:10
e.g. (let ((foo (bar baz)) (if (nz foo) (bar foo) (bar (null))) - now foo is shared by the first and second bb;
hence, my graph becomes: bb(0): foo = bar(baz); bb(1): if zr foo goto bb(3); bb(2): result=bar(foo); goto bb(4); bb(3): result = bar(null()); bb(4): unify_results(); 13:12
maybe this can be solved in some more clever way by a more clever tree representation... 13:13
timotimo a tree where a node can have multiple parents? preposterous! heresy! 13:16
brrt i know.... 13:17
it's bad enough :-$
timotimo i have no clue, honestly 13:20
jnthn Well, it's a graph rather than a tree by this point. 13:21
timotimo mhm 13:22
i say if it makes the implementation make more sense, do it. even if classic compsci training would tell you "that's not proper!"
brrt yeah, it's a graph alright. the question is, whether i want to rename it :-P 13:35
timotimo let's just go with "goobledygook" for now and just continue coding :P 13:36
brrt right, it is irrelevant :-) 13:38
timotimo well, hopefully it is :)
names are good for communication between humans; if it's just the three of us plus a few people like nwc10 helping out by running automated tools or looking over the code manually at a fine-grained level, it doesn't make a big difference 13:39
since everybody is "in on the joke"
long-term, we probably want to have cleaner terminology
... incoherent ranting again 13:42
i don't know why, but i feel extremely exhausted 13:43
jnthn also, though he knows why :) 13:44
timotimo i'm not feeling up to debugging "Internal error: Unwound entire stack and missed handler" any more in my gtk_cairo_shooter example script ... 13:47
i put a say statement at the beginning of everything in my "user" code that is callback related and none of that triggers 13:48
perhaps it's argument binding or something
but could we install a default exception handler that gets run when that internal error occurs?
so that we at least can has backtrace? 13:49
actually ... i suppose we can just print the backtrace from inside moar when we get to that error. any good reason why we don't do that already?
oh, heh. 13:52
remove_one_frame(tc, 1) fails, so we don't actually have anything backtrace-like at that point? or something?
13:57 Ven joined 14:57 domidumont joined 15:29 virtualsue joined 16:10 zakharyas joined 16:23 zakharyas joined 17:10 zakharyas joined 17:40 leont joined 18:02 virtualsue joined 18:08 kjs_ joined 18:13 virtualsue joined 18:24 kjs_ joined 18:26 zakharyas joined 18:36 kjs_ joined 19:10 kjs_ joined 21:49 vendethiel joined 22:26 leont joined 22:31 virtualsue joined 22:44 zakharyas 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!