From: chromatic <[EMAIL PROTECTED]>
Date: Tue, 26 Dec 2006 16:26:03 -0800
On Tuesday 26 December 2006 14:35, Bob Rogers wrote:
> AFAICS, the old code failed because Parrot_switch_to_cs (which is what
> normally sets ctx->contants in a sub call) is not given a chance to run
> in this situation. Parrot_loadbc sets interp->code without doing any of
> the other Parrot_switch_to_cs bookeeping. Sub:invoke subsequently finds
> that sub->seg is already installed properly in interp->code, so it skips
> calling Parrot_switch_to_cs, leaving ctx->contants uninitialized.
That makes sense. However, I'm curious whether Parrot_loadbc() does
the right thing.
It certainly doesn't do much. I'm not sure I understand the point of
the interp->initial_pf slot . . .
> Dropping the interp->code assignment in Parrot_loadbc sorta works
> (after telling RetContinuation:invoke not to panic if no returning code
> segment), but causes other failures. Replacing the assignment with a
> Parrot_switch_to_cs call fails immediately; this might be made to work,
> but it would be setting the constants in the old context, just as
> Nikolay's patch (and Parrot_call_sub) do; this seems wrong.
I don't understand why; would you consider writing up some rough
documentation on how contexts and interpreters and code segments
currently work? Having to dig in the implementation and guess by
reading the code isn't getting me very far.
I can try, but I don't know much about code segments; I'm just digging
in the code myself. But I'll certainly post anything I learn.
-- Bob
