02:57 kjs_ joined 08:36 vendethiel joined 09:24 rurban joined 10:30 FROGGS joined
jnthn timotimo: Oh, it's with local patch to Rakudo. 11:24
11:56 tgt joined 11:57 kjs_ joined 12:44 zakharyas joined
jnthn I may have identified what's going on. 12:52
Seems that - perhaps because we get stronger type matching with the mixin cache, or perhaps something else - the optimizer takes a path it did not previously. This path triggers dynamic compilation of some methods. 12:53
But by the time we reach the optimizer, I think we already tore down the fixup handling that's in effect during the actions. 12:54
JimmyZ \o 12:57
jnthn++ # hard work 6pe 12:58
13:08 kjs_ joined
timotimo i'm ... not really sure i understand the thing about fixup handling and dynamic compilation? 14:08
JimmyZ timotimo: github.com/rakudo/rakudo/commit/3f...59b6aeR191 14:16
jnthn timotimo: Sometimes, nor am I :P 14:18
15:02 zakharyas joined 15:24 brrt joined 15:25 rurban joined
dalek arVM/6pe: aa448bf | jnthn++ | src/6model/sc.c:
Improve missing SC code ref error reporting.
 15:42
arVM/6pe: 026fe9a | jnthn++ | src/6model/serialization.c:
First serialization/parametrics integration step.
 16:01
jnthn Unfortunately, my latest Rakudo work uncovers an...interesting...spesh bug. 16:07
It's one of those "looses the handler annotation" ones
It loses it because it's in a delete basic block
Funny thing: it's one block in a chain of them that get deleted for being unreachable, and the chain is 20 blocks long. :P 16:08
timotimo o_O 16:15
arnsholt That sounds like the kind of bugs where when you find it, you go "how did this ever work?" =) 16:43
17:37 kjs_ joined
jnthn Well, I know already it's going to be some unhandled case. 18:06
Mostly I'm happy that an internal consistency check caught it. 18:07
So we know about it now, rather than it being a horribly hard to find bug later.
timotimo \o/ 18:10
18:33 FROGGS_ joined 19:24 ChanServ joined 19:40 brrt joined
brrt :-) 19:49
jnthn, fwiw, i haven't been able to track down the other bug yet
19:56 LLamaRider joined 20:09 kjs_ joined 20:10 zakharyas joined 20:16 brrt joined
jnthn brrt: OK; thanks for trying. I'll have time to look tomorrow or Tuesday. 20:22
brrt maybe it's the same bug. and it may be that disabling the istrue_isfalse opt (specifically, the isconcrete constant opt) simply masks some other bug 20:23
jnthn brrt: Same as the other one I mentioned? 20:25
I don't believe so. Or at least, it seems very unlikely
brrt :-) 20:26
my current guess is that somehow the facts on the relevant istrue become 'overspecified'
jnthn Well, that or they're fictions... :) 20:52
brrt i guess you could call it that 20:55
dalek arVM/6pe: 0a9f052 | jnthn++ | src/spesh/optimize.c:
Don't delete BBs with handler annotations.

We can in the future instead look at moving them down to the next BB, but for now this avoids bugs.		 22:18
FROGGS_ jnthn: the utf16 decodestream functionality is not that hard to implement right? 22:32
jnthn: I mean, do I have to care about endianess?
jnthn FROGGS_: Well, the current decoder does not 22:33
FROGGS_: I'd read the ASCII one to understand the concept, the UTF-8 one to understand multi-byte handling issues, and then have a shot at it, if you like :) 22:34
FROGGS_ that'd would have been my approach :o)
jnthn The decode stream API exists because you can get two incoming read buffers and a char dangling over the edge 22:35
FROGGS_ yeah, from the sepsis branch I know that much
cp1252 should be pretty easy to implement I guess 22:37
jnthn Yeah, that's a near-copy of latin-1 22:40
FROGGS_ I'll consider doing utf16... I do not quite need it but I see that it can be fairly important for some... 22:41
though, I have to think about my talk for FOSDEM too
(only have like four pages atm *g*)
gnight
jnthn 'night 22:42
timotimo hm 23:07
moarvm's native call model is pretty much lifted 1:1 from parrot, right? what makes parrots native call stuff especially good? 23:08
jnthn timotimo: No, that's not really the history of it. 23:09
timotimo i'm just now reading whiteknights post and i just saw this sentence: 23:11
jnthn Parrot has its own set of native calling stuff, but (a) I got fed up of various things about it, and (b) it was pretty obvious after a while that we wanted smart integration with 6model stuff
timotimo "The P6 folks were developing their own bindings which used the (much nicer) 6model and the (much nicer) P6 native bindings instead."
jnthn So I ended up building 6model-integrated native stuff, in the NQP repo.
Given it was 6model-based, the design was broadly applicable on MoarVM too.
timotimo OK, i think i understand now 23:12
23:33 brrt left 23:35 kjs_ 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!