[squeak-dev] Simulation discrepancy with #return:
Yoshiki Ohshima
Yoshiki.Ohshima at acm.org
Mon Mar 26 17:27:19 UTC 2012
At Tue, 13 Mar 2012 11:36:52 -0700,
Eliot Miranda wrote:
>
> Hi Yoshiki, Hi Hans-Martin, Hi All,
>
> On Tue, Mar 13, 2012 at 10:25 AM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org> wrote:
>
> At Tue, 13 Mar 2012 10:08:12 -0700,
> Eliot Miranda wrote:
> >
> > In this case runUntilErrorOrReturnFrom: aContext should return the sender of the activation of Foo>test and the result to be returned (42). But instead it answers the activation of
> Foo>test
> > and nil. Hence the return in ContextPart>return: isn't simulated and control passes to the next statement, ^666.
> >
> > Once again I'm drawn into the bowels of runUntilErrorOrReturnFrom:
> > :) It is my nemesis.
>
> This seems close to the realm of magic to me. Thank you for looking
> into it!
>
> Alas, I find it near to magic too. I understand what's going on. The terminateTo: call in resume: doesn't trip the unwind-protect in runUntilErrorOrReturnFrom: (as it shouldn't;
> terminateTo: specifically doesn't run unwinds by design). So runUntilErrorOrReturnFrom: doesn't answer the right context to resume. It answers Foo>test instead of Foo>test's sender.
>
> What I don't understand is what is a valid criterion for determining these cases. I can hack the method, special casing it for ContextPart>return: and ContextPart>resume:, but that's not
> acceptable. So if anyone has the desire to pair on this let me know. Perhaps we could have a go at it over skype sometime soon (not today; already blown a lot of time looking at this ;) ).
>
> In any case I've attached two versions of runUntilErrorOrReturnFrom:, one instrumented, one not, containing a hack that gets the right answer (in this case). Yoshiki, you might play with
> the uninstrumented one to get you going. Hans-Martin, I think you're one of very few people who could shed light on this.
Sorry for not replying sooner, but it certainly does what I want,
thanks!
OMeta has exhibited another kind of discrepancy between with and
without debugger and I had a slight hope that the same patch would fix
that problem, too; but it wasn't the case. I'll try to come up with a
simple test case for it.
-- Yoshiki
More information about the Squeak-dev
mailing list
|