00:20 btyler joined 01:13 FROGGS_ joined 01:27 jnap joined 02:28 jnap joined 03:28 jnap joined 04:29 jnap joined 05:30 jnap joined 06:31 jnap joined 06:42 FROGGS joined 07:06 zakharyas joined 07:32 jnap joined 07:40 odc joined 08:32 jnap joined 09:33 jnap joined 09:39 jnap joined 10:13 woosley joined 10:30 woosley left 11:41 jnap joined 11:58 btyler joined 12:04 colomon joined 12:42 jnap joined 13:05 colomon joined
nwc10 FROGGS: are you Linux? 13:17
or do you have gcc 4.8 or newer?
FROGGS nwc10: I am a human 13:18
nwc10 er, good point
are you using Linux
FROGGS yes
nwc10 it's like "are you the ...?"
FROGGS gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
nwc10 "no, I'm a human"
ie "is this bus... ?"
could you try building MoarVM with ASAN, and then NQP?
cognominal ASAN? 13:19
nwc10 gcc address sanitizer
(well, or clang...)
FROGGS clang would be okay?
nwc10 yes, hangon, I might have a better answer 13:20
FROGGS k
nwc10 (computer is working on it) 13:21
FROGGS *cough* "Computer say no" 13:23
nwc10 valgrind will replicate it: paste.scsys.co.uk/360308
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
(and, usefully, valgrind can report symbols. ASAN just goes boom)
FROGGS ohh
nwc10 (but ASAN is fast enough to do the entire build and test)
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"
at least, ASAN build of the parent commit can bootstrap NQP and Rakudo all the way to the spectest 13:26
FROGGS nwc10: yes, that is very helpful indeed, and I will care about fixing it 13:32
nwc10 well, I would have liked to have been able to tell you the likely fix :-( 13:49
13:54 jnap joined
jnthn I'm glad we found the problem. 14:16
nwc10++
FROGGS yes 14:19
btw, I meant to push that code to a branch :/ 14:20
dunno how I managed to commit that to master
jnthn By committing in master. Duh. :P 14:21
FROGGS well, yeah *g* 14:23
[Coke] mmhehehe
FROGGS I mean, ummm
14:28 jnap joined 14:44 jnap1 joined 15:21 donaldh joined 16:19 FROGGS joined
FROGGS jnthn: how do I shovel a MAST::IVal into a MAST::Local? 16:21
like in: At Frame 0, Instruction 819, op 'bindexcategory', operand 1, expected MAST::Local, but didn't get one 16:24
jnthn const_i64 16:25
FROGGS thank you! 16:26
16:43 brrt joined
dalek arVM: 68ff6e3 | (Tobias Leich)++ | / (12 files):
Revert "add support for named exception handlers for use in labeled loops"

This feature gets moved into branch 'loop_labels'.		 17:59
arVM/loop_labels: c29c0c7 | (Tobias Leich)++ | / (6 files):
add support for named exception handlers for use in labeled loops

This also let one throw an exception with a label attached, so we can rethrow the exception until we hit the handler that is in charge for that label and exception category. This happens by putting a Label into the exception's payload, and setting the catogory mask to MVM_EX_CAT_LABELED.		 18:08
FROGGS okay, that is better
18:09 brrt joined
brrt :-o spesh is complicated :-o 18:26
timotimo i'm sorry, brrt :) 18:39
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:46
nwc10 and a pony? 18:51
jnthn No, it doesn't do a pony, sorry.
nwc10 oh :-(
jnthn Maybe once it can JIT... :) 18:52
nwc10 ah OK
at which point, Moon on a Stick becomes the next strech goal?
see www.chiark.greenend.org.uk/~sgtatha...stick.html for a mock-up
jnthn Hm, seems harder than a stick in a box... 18:55
nwc10 maybe compramise with Button Moon on a stick 18:56
19:15 brrt joined
FROGGS nwc10: I can reproduce: 19:36
==25378== Invalid read of size 8
==25378== at 0x4F95A34: compile_instruction (compiler.c:832)
nwc10: that is, MoarVM HEAD is clean again, but the branch loop_labels is contaminated 19:37
nwc10 I guess that that's "good", because it means that the bug didn't mysteriously disappear 19:38
FROGGS yes 19:39
and I probably have a fix
nwc10 even better
FROGGS I am not sure if this is a fix or just plain stupid: gist.github.com/FROGGS/05dfddbd81f2bab1a3fe 19:42
I bet it is the latter
:/
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
and in case I need a label, I would malloc the one with the label...
otherwise I mess with stage0... is that the case?
damn, that does not even sound sane to me
jnthn FROGGS: Um. Me either :P 19:48
Do you need to somehow evolve the bytecode format?
FROGGS yes, I think so
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
*g*
I' not sure :P
jnthn Oh...
er.
Hmmm.
I'm not sure I'd do it that way.
FROGGS here is the diff to master btw: github.com/MoarVM/MoarVM/compare/loop_labels 19:50
the good thing is: it is not that much code
jnthn Well, I'd pondered that we'd just check "is this the right label"
In the code-gen.
FROGGS hmmm 19:51
so, I should emit a check+jump like I did for parrot?
jnthn Check + rethrow-if-not-match, I guess? 19:52
FROGGS yes, exactly
jnthn What are labels in this design?
Objects?
FROGGS yes
jnthn Ref'd as a wval?
OK, good.
FROGGS instances of NQPLabel and Label in rakudo
yes
jnthn \o/
Nice
That's how I'd ahve done it. :)
FROGGS that is how you told me how to do it :o) 19:53
jnthn oh...
:D
FROGGS *g*
okay, this was in november or so, when I did it for parrot
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:54
but I'll have a look 19:55
because the I can drop the extra element in several places
jnthn I think you could put it in the payload?
Or maybe not...
FROGGS a handle has no payload 19:56
it is in the payload of an exception of course, when we throw
github.com/perl6/nqp/compare/loop_labels#diff-3 19:58
jnthn :category_mask($HandlerCategory::last + $HandlerCategory::labeled), 19:59
FROGGS yes
jnthn I'm a little curious on this as we could hit it in a non-labeled situation?
FROGGS we can? 20:00
I thought this is a bitmask
jnthn Yeah but
foo: while 1 { next; } # that next should here mean "nearest", no? 20:01
FROGGS yes 20:02
and say next has the category 4, so it will hit the first handler that has the mask 4 20:03
if (mask & cat) { goto ... }
jnthn right... 20:06
But why is "has a label" in the mask? So we can skip all those without labels, iiuc?
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:07
github.com/MoarVM/MoarVM/commit/c2...85d75feL71 20:08
I know, could probably be written nicer :/
I should probably create two code paths there, one for labels and one normal exceptions... the stuff inside would be identical still 20:11
but yeah, since we do not check anything in codegen, but just emit a HandlerScope, this thingy has to do it 20:12
means, in C, and carrying the label with it
at least that is how I see it right now
jnthn There may well be optimization benefits to pushing this into the VM level... 20:13
FROGGS yes, and it should definitely have like zero impact to exceptions without labels 20:14
not that next/redo/last gets slower because of this... I think loops already suffer enough :o)
jnthn I think it should be doable without a stage0 update 20:15
Since I guess if the category mask implies there's a label then you can know to read that.
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:16
dalek arVM/loop_labels: cece3ba | (Tobias Leich)++ | src/mast/compiler.c:
only read the label if we know the handler has one
 20:17
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:20
and there is also that one should be able to introspect &?BLOCK.labels or attach more than one label to a block 20:23
20:27 brrt left
FROGGS gnight 20:39
lizmat gnight FROGGS ! 20:44
TimToady n: sub term:<*> { "smurf" }; say * 23:47
camelia niecza v24-109-g48a8de3: OUTPUT«smurf␤»
TimToady m: sub term:<*> { "smurf" }; say * 23:48
camelia rakudo-moar dfd343: OUTPUT«*␤»
TimToady we probably have that rakudobug already; looks like it's not implementing tiebreaking properly
oh, jnthn++ was looking at LTM later in the backlog 23:51
oh, not to mention wrong window, oops 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!