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