Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-01-18

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:57 kjs_ joined #moarvm
08:36 vendethiel joined #moarvm
09:24 rurban joined #moarvm
10:30 FROGGS joined #moarvm
11:24 jnthn timotimo: Oh, it's with local patch to Rakudo.
11:56 tgt joined #moarvm
11:57 kjs_ joined #moarvm
12:44 zakharyas joined #moarvm
12:52 jnthn I may have identified what's going on.
12:53 jnthn 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:54 jnthn 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:57 JimmyZ \o
12:58 JimmyZ jnthn++ # hard work 6pe
13:08 kjs_ joined #moarvm
14:08 timotimo i'm ... not really sure i understand the thing about fixup handling and dynamic compilation?
14:16 JimmyZ timotimo: https://github.com/rakudo/rakudo/commit/3f474a178f#diff-5ffca53dab84bf14d60bffa2cc59b6aeR191
14:18 jnthn timotimo: Sometimes, nor am I :P
15:02 zakharyas joined #moarvm
15:24 brrt joined #moarvm
15:25 rurban joined #moarvm
15:42 dalek MoarVM/6pe: aa448bf | jnthn++ | src/6model/sc.c:
15:42 dalek MoarVM/6pe: Improve missing SC code ref error reporting.
15:42 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/aa448bf21c
16:01 dalek MoarVM/6pe: 026fe9a | jnthn++ | src/6model/serialization.c:
16:01 dalek MoarVM/6pe: First serialization/parametrics integration step.
16:01 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/026fe9a91f
16:07 jnthn Unfortunately, my latest Rakudo work uncovers an...interesting...spesh bug.
16:07 jnthn It's one of those "looses the handler annotation" ones
16:07 jnthn It loses it because it's in a delete basic block
16:08 jnthn 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:15 timotimo o_O
16:43 arnsholt That sounds like the kind of bugs where when you find it, you go "how did this ever work?" =)
17:37 kjs_ joined #moarvm
18:06 jnthn Well, I know already it's going to be some unhandled case.
18:07 jnthn Mostly I'm happy that an internal consistency check caught it.
18:07 jnthn So we know about it now, rather than it being a horribly hard to find bug later.
18:10 timotimo \o/
18:33 FROGGS_ joined #moarvm
19:24 ChanServ joined #moarvm
19:40 brrt joined #moarvm
19:49 brrt :-)
19:49 brrt jnthn, fwiw, i haven't been able to track down the other bug yet
19:56 LLamaRider joined #moarvm
20:09 kjs_ joined #moarvm
20:10 zakharyas joined #moarvm
20:16 brrt joined #moarvm
20:22 jnthn brrt: OK; thanks for trying. I'll have time to look tomorrow or Tuesday.
20:23 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:25 jnthn brrt: Same as the other one I mentioned?
20:25 jnthn I don't believe so. Or at least, it seems very unlikely
20:26 brrt :-)
20:26 brrt my current guess is that somehow the facts on the relevant istrue become 'overspecified'
20:52 jnthn Well, that or they're fictions... :)
20:55 brrt i guess you could call it that
22:18 dalek MoarVM/6pe: 0a9f052 | jnthn++ | src/spesh/optimize.c:
22:18 dalek MoarVM/6pe: Don't delete BBs with handler annotations.
22:18 dalek MoarVM/6pe:
22:18 dalek MoarVM/6pe: We can in the future instead look at moving them down to the next BB,
22:18 dalek MoarVM/6pe: but for now this avoids bugs.
22:18 dalek MoarVM/6pe: review: https://github.com/MoarVM/MoarVM/commit/0a9f052e72
22:32 FROGGS_ jnthn: the utf16 decodestream functionality is not that hard to implement right?
22:32 FROGGS_ jnthn: I mean, do I have to care about endianess?
22:33 jnthn FROGGS_: Well, the current decoder does not
22:34 jnthn 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)
22:35 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
22:37 FROGGS_ cp1252 should be pretty easy to implement I guess
22:40 jnthn Yeah, that's a near-copy of latin-1
22:41 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 FROGGS_ though, I have to think about my talk for FOSDEM too
22:41 FROGGS_ (only have like four pages atm *g*)
22:41 FROGGS_ gnight
22:42 jnthn 'night
23:07 timotimo hm
23:08 timotimo moarvm's native call model is pretty much lifted 1:1 from parrot, right? what makes parrots native call stuff especially good?
23:09 jnthn timotimo: No, that's not really the history of it.
23:11 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
23:11 timotimo "The P6 folks were developing their own bindings which used the (much nicer) 6model and the (much nicer) P6 native bindings instead."
23:11 jnthn So I ended up building 6model-integrated native stuff, in the NQP repo.
23:11 jnthn Given it was 6model-based, the design was broadly applicable on MoarVM too.
23:12 timotimo OK, i think i understand now
23:33 brrt left #moarvm
23:35 kjs_ joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary