Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-01-13

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

All times shown according to UTC.

Time Nick Message
01:18 harrow joined #moarvm
01:40 timotimo hm. can i package dynops with a module i can put onto the ecosystem, i wonder?
01:43 timotimo oh, but that wouldn't let me set up an nqp::op for a dynops thingie just like that
01:46 ssutch joined #moarvm
01:53 timotimo for other things, there's always NativeCall
02:17 jnap joined #moarvm
03:02 eternaleye joined #moarvm
05:05 diakopter timotimo: ping
05:15 diakopter timotimo: unping
07:34 ssutch joined #moarvm
07:52 FROGGS joined #moarvm
08:27 odc joined #moarvm
09:35 nwc10 if I have a pointer to a (MVMCollectable *)
09:35 nwc10 what is the easiest way to work out what it is
09:35 nwc10 (by chasing the stable and then what?)
09:36 nwc10 (context is I'm in the GC, and I want to know what was just allocated but not rooted, and all I have is an anonymous pointer to it
09:36 nwc10 )
09:36 arnsholt The STable has pointers to the REPR and the type object
09:37 nwc10 the REPR gives no clues
09:37 nwc10 as in thanks, but the REPR gives no clues
09:37 arnsholt REPR has a name field, IIRC. Not sure if the type object normally does
09:37 arnsholt Which REPR is it?
09:37 nwc10 oh, yes it does
09:37 nwc10 thanks
09:38 nwc10 name = 0x7ffff7a4c61c "MVMCode"
09:38 nwc10 missed that in all the noise
09:38 arnsholt Yeah, easy to miss
09:38 arnsholt So some kind of function-y thing
09:39 nwc10 it's the continuations test, and this is the cause of GC entry:
09:39 nwc10 #8  0x00007ffff79d993b in MVM_frame_takeclosure (tc=tc@entry=0x602430,  code=0x1ccbcb0) at src/core/frame.c:558
09:39 nwc10 and I think it's the previous but one thing to be allocated
09:39 nwc10 that's not been rooted
09:39 nwc10 but now I just need my time machine to run my debugger backwards
09:39 arnsholt Hehe
09:40 arnsholt GDB does reverse debugging, but the memory overhead is probably too big to be useful on Moar
09:40 arnsholt It was on Parrot at least
09:41 arnsholt I really need to get hacking on Moar at some point, but first I need to finish the JVM NativeCall bits
09:45 FROGGS bits, yeah :o)
09:49 arnsholt There's actually not all that much left to do
09:49 arnsholt But the remaining bits (CStruct) involve run-time generation of classes, which means I have to sit down and figure out how this ASM library works
09:52 nwc10 I was guessing that reverse debugging would be a massive drag
09:52 nwc10 and it would be faster to hack in a count on the allocator function
09:52 nwc10 note the number for the problem
09:52 nwc10 and then re-run with a breakpoint on it for 2 earlier.
09:54 nwc10 arnsholt: it would be awesome if you could make more progress on the JVM stuff. Even if it's just working out which questions you need someone else to answer for you
09:54 arnsholt Yeah, I have a solution I think will work mostly worked out in my head
09:54 arnsholt It should mostly be a question of sitting down and doing it
09:55 arnsholt I've been busy at work lately (article deadline last friday), but tuits aren't in quite as short supply these days
09:55 nwc10 deadline went whooshing past and now all is calm? :-)
09:55 arnsholt I think I might do some hacking today actually, rather than thesis-writing =)
09:55 arnsholt More or less
09:56 nwc10 gah, thesis. pesky things don't write themselves
09:56 arnsholt Article submitted with only one embarrasing thing left in it \o/
09:57 arnsholt Indeed they don't. On the upside, writing it is part of my job so I don't have to work double =)
10:25 lue joined #moarvm
11:03 V_S_C joined #moarvm
11:13 V_S_C git push gives 403 for https://github.com/MoarVM/dyncall
13:23 FROGGS V_S_C: that is not a url you can push to, right?
14:33 arnsholt Progress report: Code generation is weird, but the ASMifier is quite useful =)
14:47 jnap joined #moarvm
14:53 timotimo diakopter: pong, unpong
14:54 diakopter timotimo: depong
14:58 FROGGS pardon?
15:13 timotimo perdong
15:32 * [Coke] hopes that moar will continue to get slightly better every day, even if jnthn++ is offline.
15:33 * FROGGS .oO( well volunteered [Coke]! )
15:33 FROGGS :o)
15:33 [Coke] oh, I have a simple plan: write a test from RT. then the abs # is going up each day. :P
15:34 FROGGS (test coverage)++ :o)
15:35 [Coke] I think we're already covered for today.
16:13 FROGGS[mobile] joined #moarvm
16:36 FROGGS joined #moarvm
16:43 [Coke] r: say 27778 / 28457 # today's likely numbers.
16:44 camelia rakudo-parrot eb1aa5, rakudo-jvm eb1aa5: OUTPUT«0.976139␤»
16:55 FROGGS yay! better than I hoped :o)
17:01 cxreg dumb question, is moar intended for anything beyond a rakudo backend?
17:01 [Coke] I don't think so, though it could be used as such.
17:01 [Coke] and it's technically an nqp backend.
17:02 [Coke] I think that one of the design goals was "be exactly what perl6 needs".
17:02 [Coke] as opposed to parrot's "one vm to rule them all"
17:02 cxreg yeah, i gathered
17:02 FROGGS cxreg: thing is moarvm is based on the so alled 6model object system
17:02 [Coke] we now have -2- segfaults.
17:02 FROGGS so if you need something else, moarvm might not be the best choice
17:03 FROGGS [Coke]: about subtypes?
17:03 [Coke] https://gist.github.com/coke/8250608 updated.
17:04 * FROGGS takes a look at S06-macros/unquoting.t
17:04 [Coke] pushed today's moar run to http://feather.perl6.nl/~coke/moar.out
17:04 [Coke] r: say 261/ 571 # percent of failures left in S05
17:04 camelia rakudo-parrot eb1aa5, rakudo-jvm eb1aa5: OUTPUT«0.457093␤»
17:05 [Coke] looks like 9 errors in re: line numbers/subs in stack traces.
17:15 ssutch joined #moarvm
17:30 ssutch joined #moarvm
17:47 jnthn 97.6% :D
17:47 jnthn The two segfualts are in tests that failed differently yesterday
17:47 jnthn like, didn't get as far as they do now
17:49 FROGGS jnap: https://gist.github.com/FROGGS/f60df49d1439982723f0
17:49 FROGGS err
17:49 FROGGS jnthn: : https://gist.github.com/FROGGS/f60df49d1439982723f0
17:49 FROGGS sort of
17:49 FROGGS jnthn: that is from unquote.t
17:52 jnthn ah, hmm
17:53 FROGGS weird errors are weird :o)
17:55 jnthn What's the multi one?
17:57 ssutch_ joined #moarvm
17:58 FROGGS jnthn: the very last test here: https://gist.github.com/FROGGS/abdcf476cb2edc1b47a2
17:58 FROGGS no proper backtrace
17:59 jnthn well, we can get a gdb one, no?
17:59 * jnthn is in le meeting and kinda can't look more for now :)
17:59 [Coke] jnthn++
18:00 FROGGS jnthn: I have a debug build of moar and of rakudo's ops, but I just get a few lines about MVM_interp_run
18:02 jnthn Is it a null access or bad pointer?
18:03 FROGGS jnthn: I put the gdb out in a comment of that gist
18:03 jnthn argh, no line number?
18:04 FROGGS wait... I will rebuild moar
18:04 jnthn k
18:05 timotimo FROGGS, cxreg: the thing is, that 6model is very flexible. it could even do a prototype object system easily
18:05 FROGGS jnthn: I updated my comment with a proper bt
18:06 FROGGS reload, I've put it in a formatted file thingy
18:07 FROGGS it is the getwhat op obviously
18:08 FROGGS timotimo: k, if you say so :o)
18:09 timotimo cxreg: if you have interesting things to use moarvm with, i'd personally be somewhat likely to help you make it work
18:10 jnthn FROGGS: Can you p GET_REG(cur_op, 2).o
18:11 FROGGS jnthn: no, all of GET_REG(cur_op, 2) seem to be NULL-ish
18:11 FROGGS jnthn: reload the gist to see
18:13 jnthn well, it's a union
18:13 jnthn But if it's null...yeha
18:13 jnthn that's not too bad
18:24 jnthn ah, it's another case of a general problem
18:25 jnthn mebbe I get around tuit tonight
18:26 FROGGS jnthn: btw, I would start to implementloop labels for nqp for the jvm and moar backends these days...
18:27 FROGGS I really think that the parrot code is correct, the only thing that could be wrong is about releasing registers
18:35 arnsholt jnthn: Semi-random question: Do you know if the JVM has any restrictions on valid field names?
18:47 ilbot3 joined #moarvm
18:47 topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
19:15 nwc10 there is one GC bug in the newly added continuation stuff
19:15 nwc10 but I can't quite work out what.
19:15 FROGGS timotimo: the Hash.delete thingy is probably this recent commit: https://github.com/rakudo/rakudo/commit/2312829a335626403a4c84040f57e96a60091019
19:15 FROGGS timotimo: so nothing to worry about
19:15 FROGGS :/
19:43 jnthn nwc10: what are the symptoms?
19:43 nwc10 point in fromspace shows up on the worklist during GC
19:43 nwc10 might have located it
19:43 nwc10 could you give me 5 minutes
19:44 nwc10 pointer to fromspace
19:44 jnthn no hurry, mostly busy today
19:45 nwc10 your planes were all well behaved this time?
19:45 nwc10 might *just* have located it, that is. about 60 seconds before you asked
19:46 jnthn yes
19:47 nwc10 good. long may it stay that way
19:48 V_S_C joined #moarvm
19:58 jnthn nwc10: Where did the continuations bug show up, ooc?
19:58 jnthn In the tests?
19:58 nwc10 yes
19:58 nwc10 t/moar/01-continuations.t
19:58 jnthn k
19:58 V_S_C @FROGGS, okay, I submitted the build patch for msvcAMD64 to diakopter gmail id from MoaRVM readme. Its minor but relieves by saving time on pointless x86 legacy link errors.
19:58 jnthn Which test, ooc?
20:00 nwc10 the one after
20:00 nwc10 ok 18 - invoke also sees the invocation context
20:00 V_S_C left #moarvm
20:00 nwc10 it's an allocation of a MVMCode object in MVM_frame_takeclosure
20:02 nwc10 334582nd allocation
20:03 nwc10 getpid here is a hack to give me something to breakpoint
20:03 nwc10 http://paste.scsys.co.uk/291101
20:04 nwc10 it's that allocation which soon appears in the worklist
20:04 nwc10 2 allocations later
20:04 nwc10 er, that address that appears in something in the worklist
20:04 nwc10 but by then, that address is in fromspace, with a forwarding pointer
20:04 nwc10 so something didn't get rooted
20:05 nwc10 but I am having real difficulty figuring out what
20:05 nwc10 next plan was to watch everything that gets added to the worklist
21:07 timotimo joined #moarvm
21:17 nwc10 jnthn: http://paste.scsys.co.uk/291114 -- it's r5 of a frame added here which ends up being in fromspace
21:18 nwc10 oh, hangon. no, more interestingneeds needed
21:18 nwc10 stuff moved after I recompiled
21:18 nwc10 scrub that
21:55 nwc10 jnthn: r3 is already in fromspace, but it's being added to a worklist -- http://paste.scsys.co.uk/291127
22:11 nwc10 http://paste.scsys.co.uk/291130 -- object in question is allocated here, but the reference in r3 to it is taken after the allocation after this one
22:29 nwc10 jnthn: stale area of memory used as registers is initialised in  MVM_frame_clone
22:29 nwc10 specifically
22:29 nwc10        memcpy(clone->work, f->work, f->static_info->body.work_size);
22:29 [Coke] official count today: rakudo.moar,2014-01-13,97.60%,4c65527,27778,571,637,1407,30392,28500,
22:30 nwc10 jnthn: and yes, that's the problem, I think
22:32 nwc10 jnthn: http://paste.scsys.co.uk/291135
22:35 nwc10 jnthn: is the solution to move the result = (MVMContinuation *)MVM_repr_alloc_init(tc, tc->instance->boot_types.BOOTContinuation); before the while loop?
23:38 jnthn nwc10: lemme take a look
23:40 jnthn eeks, that's subtle...
23:45 dalek MoarVM: 5fb3591 | jonathan++ | src/core/continuation.c:
23:45 dalek MoarVM: Fix GC bug in continuation cloning.
23:45 dalek MoarVM:
23:45 dalek MoarVM: Discovered/tracked down by nwc10++.
23:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5fb3591be3
23:45 jnthn nwc10: Hopefully that does it. Thanks!

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