JimmyZ morning, jnthn 09:21
jnthn: gist.github.com/zhuomingliang/78fa...16d2d5a890 is it right? added 3 MVM_ASSIGN_REF 09:22
jnthn Certainly ot. 09:24
*not
Well, the first one you added is obviously wrong
Just by looking at the pointer type. 09:25
JimmyZ oh, yes
jnthn MVMObject ** is not a GC-able thing, it's a C array of GC-able things.
And I'm not sure the extra whitespace is warranted.
JimmyZ and how about the other two?
jnthn The lifting of the STABLE(obj) is OK, though, but elsewhere in the code we normally just call such vars "st" 09:26
Second one is certainly wrong too 09:27
MVMFrame * is *not* a GC-able thing either.
The static_info one is correct, however.
Though note the cast to MVMObject* could go away in favor of something more like sf->common.header 09:28
JimmyZ oh, it's MVMStaticFrame!
jnthn Yes, MVMStaticFrame is an MVMObject. 09:29
But MVMFrame is not.
JimmyZ yeah
jnthn So anyway, only one out of three of these should be added. :)
JimmyZ I still don't why sf->common.header is better? 09:30
jnthn Because it avoids a cast.
JimmyZ jnthn: irclog.perlgeek.de/moarvm/2015-01-01 I added some explaintion 09:31
jnthn Yeah, I'm still uncomfortable with the idea. I think partly because it makes termination harder to reason about... 09:35
JimmyZ but call something like optimize_set etc is not good too :( 09:39
everywhere... 09:40
jnthn I'm not sure we should be doing that. 09:41
dalek arVM: 5149e5d | (Jimmy Zhuo)++ | src/core/interp.c:
small refactor, and add a missing MVM_ASSIGN_REF
 10:07
jnthn JimmyZ: Oh, that patch does something bad. 10:09
You can't lift the dereferences of obj and ctx above the things thta check for type and concreteness. 10:10
Otherwise we can get segfaults.
(that's in the forceouterctx bit) 10:11
JimmyZ hmm, I did make spectest, maybe we have not test to cover it 10:13
you mean ((MVMCode *)obj)->body.outer = context; ? I tought it's safe if there were eqv 10:15
*thought 10:16
jnthn No
MVMFrame *orig = ((MVMCode *)obj)->body.outer;
That 10:17
You can't deref obj until *AFTER* if (REPR(obj)->ID != MVM_REPR_ID_MVMCode || !IS_CONCRETE(obj)) {
Otherwise heck knows what memory you're going to be trying to access.
JimmyZ ah, I didn't seee it ..
jnthn You've fixed one bug and introduced 2 new ones :/
We were better off before.
JimmyZ 2 ? 10:18
jnthn Well, 3 if we're going to count all 3 memory accesses you lifted above the if statements :P 10:19
JimmyZ yeah
nwc10 hat trick! 10:20
jnthn Anyway, please be careful when re-ordering things. It's nice when we can get things intialized at their point of declaration, and certainly I structure code that way when it's possible, but often correctness doesn't allow it. 10:21
dalek arVM: a112b47 | (Jimmy Zhuo)++ | src/core/interp.c:
fix potential segfault
 10:23
jnthn Looks better. JimmyZ++
JimmyZ Thanks 10:26
FROGGS_ jnthn: when do you think you'll have some time to review and discuss a moarvm branch? 10:29
jnthn FROGGS_: Next week.
FROGGS_ jnthn: will perhaps take 15 to 30 minutes in total I guess
jnthn (Will have time on Mon or Tue.) 10:30
FROGGS_ jnthn: what's your timezone offset these days?
jnthn Yours + 1.
FROGGS_ ahh, that's quite nice :o)
jnthn Yeah, and back to same as you from Mon :) 10:31
Well, very late Sun, but I'll probably only be useful for sleeping by then :)
FROGGS_ :o)
okay, then I'll ping you monday afternoon/evening... it is about IO/open/separators 10:32
jnthn OK :) 10:33
Gone for most of day & 10:44
FROGGS_ .oO( enjoying the Most of the day ) 12:01
jnthn FROGGS__: That comment was a bridge too far... :P 20:20
FROGGS__ but I'd do it again :o) 20:28
TimToady this is going to be the longest day... 20:55
jnthn Gee, the shortest was only a few weeks ago... 20:56
lizmat wonders how she can sneak in "battle of the bulge" in this conversation
TimToady Nuts! 20:57
lizmat hmmm.... the order is wrong: first the longest day, then a bridge too far, then the battle of the bulge
TimToady some company probably holds a patton on the correct order 21:00
jnthn That sounds overly general... 21:01
TimToady I thought that was, like, Ike... 21:02

Powered by Cro and the Raku® Programming Language.

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

Thank you!