[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