Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-04-28

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

All times shown according to UTC.

Time Nick Message
00:20 btyler joined #moarvm
01:13 FROGGS_ joined #moarvm
01:27 jnap joined #moarvm
02:28 jnap joined #moarvm
03:28 jnap joined #moarvm
04:29 jnap joined #moarvm
05:30 jnap joined #moarvm
06:31 jnap joined #moarvm
06:42 FROGGS joined #moarvm
07:06 zakharyas joined #moarvm
07:32 jnap joined #moarvm
07:40 odc joined #moarvm
08:32 jnap joined #moarvm
09:33 jnap joined #moarvm
09:39 jnap joined #moarvm
10:13 woosley joined #moarvm
10:30 woosley left #moarvm
11:41 jnap joined #moarvm
11:58 btyler joined #moarvm
12:04 colomon joined #moarvm
12:42 jnap joined #moarvm
13:05 colomon joined #moarvm
13:17 nwc10 FROGGS: are you Linux?
13:17 nwc10 or do you have gcc 4.8 or newer?
13:18 FROGGS nwc10: I am a human
13:18 nwc10 er, good point
13:18 nwc10 are you using Linux
13:18 FROGGS yes
13:18 nwc10 it's like "are you the ...?"
13:18 FROGGS gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
13:18 nwc10 "no, I'm a human"
13:18 nwc10 ie "is this bus... ?"
13:18 nwc10 could you try building MoarVM with ASAN, and then NQP?
13:19 cognominal ASAN?
13:19 nwc10 gcc address sanitizer
13:19 nwc10 (well, or clang...)
13:19 FROGGS clang would be okay?
13:20 nwc10 yes, hangon, I might have a better answer
13:20 FROGGS k
13:21 nwc10 (computer is working on it)
13:23 FROGGS *cough* "Computer say no"
13:23 nwc10 valgrind will replicate it: http://paste.scsys.co.uk/360308
13:24 nwc10 I think that your commit 09d52dcc8f6edad6cacad8be4ad5f6abdf1432c4 adds a read beyond a malloed buffer, but I don't know anything better than the stack trace given
13:24 nwc10 (and, usefully, valgrind can report symbols. ASAN just goes boom)
13:24 FROGGS ohh
13:24 nwc10 (but ASAN is fast enough to do the entire build and test)
13:25 FROGGS I am working on that code at the moment and it is likely that I revert that commit
13:25 nwc10 I can't really help better than "there is now the problem shown above, and there wasn't before that commit"
13:26 nwc10 at least, ASAN build of the parent commit can bootstrap NQP and Rakudo all the way to the spectest
13:32 FROGGS nwc10: yes, that is very helpful indeed, and I will care about fixing it
13:49 nwc10 well, I would have liked to have been able to tell you the likely fix :-(
13:54 jnap joined #moarvm
14:16 jnthn I'm glad we found the problem.
14:16 jnthn nwc10++
14:19 FROGGS yes
14:20 FROGGS btw, I meant to push that code to a branch :/
14:20 FROGGS dunno how I managed to commit that to master
14:21 jnthn By committing in master. Duh. :P
14:23 FROGGS well, yeah *g*
14:23 [Coke] mmhehehe
14:23 FROGGS I mean, ummm
14:28 jnap joined #moarvm
14:44 jnap1 joined #moarvm
15:21 donaldh joined #moarvm
16:19 FROGGS joined #moarvm
16:21 FROGGS jnthn: how do I shovel a MAST::IVal into a MAST::Local?
16:24 FROGGS like in: At Frame 0, Instruction 819, op 'bindexcategory', operand 1, expected MAST::Local, but didn't get one
16:25 jnthn const_i64
16:26 FROGGS thank you!
16:43 brrt joined #moarvm
17:59 dalek MoarVM: 68ff6e3 | (Tobias Leich)++ | / (12 files):
17:59 dalek MoarVM: Revert "add support for named exception handlers for use in labeled loops"
17:59 dalek MoarVM:
17:59 dalek MoarVM: This feature gets moved into branch 'loop_labels'.
17:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/68ff6e3e82
18:08 dalek MoarVM/loop_labels: c29c0c7 | (Tobias Leich)++ | / (6 files):
18:08 dalek MoarVM/loop_labels: add support for named exception handlers for use in labeled loops
18:08 dalek MoarVM/loop_labels:
18:08 dalek MoarVM/loop_labels: This also let one throw an exception with a label attached, so we can
18:08 dalek MoarVM/loop_labels: rethrow the exception until we hit the handler that is in charge for
18:08 dalek MoarVM/loop_labels: that label and exception category.
18:08 dalek MoarVM/loop_labels: This happens by putting a Label into the exception's payload, and
18:08 dalek MoarVM/loop_labels: setting the catogory mask to MVM_EX_CAT_LABELED.
18:08 dalek MoarVM/loop_labels: review: https://github.com/MoarVM/MoarVM/commit/c29c0c7629
18:08 FROGGS okay, that is better
18:09 brrt joined #moarvm
18:26 brrt :-o spesh is complicated :-o
18:39 timotimo i'm sorry, brrt :)
18:46 jnthn All it does is make a CFG, compute a dominance tree, put things in SSA form, do varius bits of type-driven optimization and code-gen it with a de-opt table just in case... :P
18:51 nwc10 and a pony?
18:51 jnthn No, it doesn't do a pony, sorry.
18:51 nwc10 oh :-(
18:52 jnthn Maybe once it can JIT... :)
18:52 nwc10 ah OK
18:52 nwc10 at which point, Moon on a Stick becomes the next strech goal?
18:52 nwc10 see http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/moon-on-stick.html for a mock-up
18:55 jnthn Hm, seems harder than a stick in a box...
18:56 nwc10 maybe compramise with Button Moon on a stick
19:15 brrt joined #moarvm
19:36 FROGGS nwc10: I can reproduce:
19:36 FROGGS ==25378== Invalid read of size 8
19:36 FROGGS ==25378==    at 0x4F95A34: compile_instruction (compiler.c:832)
19:37 FROGGS nwc10: that is, MoarVM HEAD is clean again, but the branch loop_labels is contaminated
19:38 nwc10 I guess that that's "good", because it means that the bug didn't mysteriously disappear
19:39 FROGGS yes
19:39 FROGGS and I probably have a fix
19:39 nwc10 even better
19:42 FROGGS I am not sure if this is a fix or just plain stupid: https://gist.github.com/FROGGS/05dfddbd81f2bab1a3fe
19:42 FROGGS I bet it is the latter
19:42 FROGGS :/
19:47 FROGGS I think instead of adding an element to MVMFrameHandler like I did, I should create another struct like that plus the extra element
19:47 FROGGS and in case I need a label, I would malloc the one with the label...
19:47 FROGGS otherwise I mess with stage0... is that the case?
19:47 FROGGS damn, that does not even sound sane to me
19:48 jnthn FROGGS: Um. Me either :P
19:48 jnthn Do you need to somehow evolve the bytecode format?
19:48 FROGGS yes, I think so
19:49 jnthn Did you first patch bytecode.md? :)
19:49 FROGGS I need to stuff the label to a handler, in case the loop had a label
19:49 FROGGS *g*
19:49 FROGGS I' not sure :P
19:49 jnthn Oh...
19:49 jnthn er.
19:49 jnthn Hmmm.
19:49 jnthn I'm not sure I'd do it that way.
19:50 FROGGS here is the diff to master btw: https://github.com/MoarVM/MoarVM/compare/loop_labels
19:50 FROGGS the good thing is: it is not that much code
19:50 jnthn Well, I'd pondered that we'd just check "is this the right label"
19:50 jnthn In the code-gen.
19:51 FROGGS hmmm
19:51 FROGGS so, I should emit a check+jump like I did for parrot?
19:52 jnthn Check + rethrow-if-not-match, I guess?
19:52 FROGGS yes, exactly
19:52 jnthn What are labels in this design?
19:52 jnthn Objects?
19:52 FROGGS yes
19:52 jnthn Ref'd as a wval?
19:52 jnthn OK, good.
19:52 FROGGS instances of NQPLabel and Label in rakudo
19:52 FROGGS yes
19:52 jnthn \o/
19:52 jnthn Nice
19:52 jnthn That's how I'd ahve done it. :)
19:53 FROGGS that is how you told me how to do it :o)
19:53 jnthn oh...
19:53 jnthn :D
19:53 FROGGS *g*
19:53 FROGGS okay, this was in november or so, when I did it for parrot
19:54 FROGGS I just sticked the label into the handler because I did not immediately have seen how to check for the label in QASTcompilerMAST or what it is called
19:55 FROGGS but I'll have a look
19:55 FROGGS because the I can drop the extra element in several places
19:55 jnthn I think you could put it in the payload?
19:55 jnthn Or maybe not...
19:56 FROGGS a handle has no payload
19:56 FROGGS it is in the payload of an exception of course, when we throw
19:58 FROGGS https://github.com/perl6/nqp/compare/loop_labels#diff-3
19:59 jnthn :category_mask($HandlerCategory::last + $HandlerCategory::labeled),
19:59 FROGGS yes
19:59 jnthn I'm a little curious on this as we could hit it in a non-labeled situation?
20:00 FROGGS we can?
20:00 FROGGS I thought this is a bitmask
20:00 jnthn Yeah but
20:01 jnthn foo: while 1 { next; } # that next should here mean "nearest", no?
20:02 FROGGS yes
20:03 FROGGS and say next has the category 4, so it will hit the first handler that has the mask 4
20:03 FROGGS if (mask & cat) { goto ... }
20:06 jnthn right...
20:06 jnthn But why is "has a label" in the mask? So we can skip all those without labels, iiuc?
20:07 FROGGS in case we are having a label, and therefore we're searching for one with a label, we skip these without or with not-matching label
20:08 FROGGS https://github.com/MoarVM/MoarVM/commit/c29c0c7629a9b174e4b91b8bd8b1f8ad49797d25#diff-fe97d52dc5421467e7ff342f385d75feL71
20:08 FROGGS I know, could probably be written nicer :/
20:11 FROGGS I should probably create two code paths there, one for labels and one normal exceptions... the stuff inside would be identical still
20:12 FROGGS but yeah, since we do not check anything in codegen, but just emit a HandlerScope, this thingy has to do it
20:12 FROGGS means, in C, and carrying the label with it
20:12 FROGGS at least that is how I see it right now
20:13 jnthn There may well be optimization benefits to pushing this into the VM level...
20:14 FROGGS yes, and it should definitely have like zero impact to exceptions without labels
20:14 FROGGS not that next/redo/last gets slower because of this... I think loops already suffer enough :o)
20:15 jnthn I think it should be doable without a stage0 update
20:15 jnthn Since I guess if the category mask implies there's a label then you can know to read that.
20:16 FROGGS okay, the I push the two-line patch I have to build again under clang+valgrind, and still leave it in a branch for now
20:17 dalek MoarVM/loop_labels: cece3ba | (Tobias Leich)++ | src/mast/compiler.c:
20:17 dalek MoarVM/loop_labels: only read the label if we know the handler has one
20:17 dalek MoarVM/loop_labels: review: https://github.com/MoarVM/MoarVM/commit/cece3bac79
20:20 FROGGS while/until and loop loops should handle that at least partly right in rakudo/loop_labels_test, need to do for loops and then excessive testing
20:23 FROGGS and there is also that one should be able to introspect &?BLOCK.labels or attach more than one label to a block
20:27 brrt left #moarvm
20:39 FROGGS gnight
20:44 lizmat gnight FROGGS !
23:47 TimToady n: sub term:<*> { "smurf" }; say *
23:47 camelia niecza v24-109-g48a8de3: OUTPUT«smurf␤»
23:48 TimToady m: sub term:<*> { "smurf" }; say *
23:48 camelia rakudo-moar dfd343: OUTPUT«*␤»
23:48 TimToady we probably have that rakudobug already; looks like it's not implementing tiebreaking properly
23:51 TimToady oh, jnthn++ was looking at LTM later in the backlog
23:55 TimToady oh, not to mention wrong window, oops

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