I do not believe David's change is correct. Maybe the #outer test cases are incorrect. Exception>>#outer is implemented according to the ANSI definition given to us by John Brant in a previous email (http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-June/061349.html).

I have attached a test case that hopefully captures the behavior described in John Brant's email.

Assuming that the new test case is right, the "fix" I proposed fails the new test case and should be rejected. The original (broken?) version of #outer passes the new test but fails the one in the image as originally reported.

I don't know if the test case is broken or if #outer is broken. Can someone please have a look at #testSimpleOuter and see if it looks right? I'd hate to be trying to fix something that ain't broke.

Anthony Hannan ajhannan@yahoo.com wrote:

Tim Rowledge tim@sumeru.stanford.edu wrote:

...

Whilst digging around I was also startled by the current implementation of #aboutToReturn:through: which really doesn't look as if it could possibly work. I'm reasonably convinced that it shouldn't involve #terminateTo: until after the unwinding is completed but I could be wrong. Can anyone explain the comment in ContextPart>return: ? If nothing else it's a bit strange to not make use of the VM provided initial context.

In senders of #terminateTo:, like #return: and #restart, unwinding is done while terminating. They find the next ensure:/ifCurtailed: (unwind) sender, terminate to it, execute its unwind block, then repeat until the target home context is found.

Yeah, ok I'll buy that. The older implementation didn't bother to do explicit terminations since it simply reset the sender ivar and left cleanup to the GC.

#aboutToReturn:through: simply calls #return: which performs the unwind loop described above. The supplied first unwind sender is redundant. To use it would require starting in the middle of the unwind loop, requiring another interface to the return method. I would rather keep a single simple #return: interface and pay the extra primitive call to find the first unwind sender again. Non-local returns through an unwind context are probably rare, so I don't think its worth adding the extra return interface to save this one primitive call. Of course, others may disagree.

Probably a toss up. One could replace return: with return:from: and pass in either thisContext or the VM supplied first-unwind as needed.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- He's not a complete idiot -- some parts are missing.

Anthony Hannan ajhannan@yahoo.com wrote:

Hello guys,

I do not believe David's change is correct. Maybe the #outer test cases are incorrect. Exception>>#outer is implemented according to the ANSI definition given to us by John Brant in a previous email (http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-June/061349.html).

It looks to me (after spending a lot of time looking round the web for Smalltalk exception related stuff and making my head spin around axes I didn't think existed outside a superstring) that the example ought to work thus:-

simpleOuterTest "uses #resume"

[[self doSomething. MyTestNotification signal. self doSomethingElse] on: MyTestNotification do: [:ex | ex outer]] on: MyTestNotification do: [:ex | self doYetAnotherThing. ex resume]

We correctly get doSomething. Then MyTestNotification is signalled and we climb up to the first handler. This sends #outer which is supposed to 'mark' the handler block and then pass on the signal. This _ought_ to go on up to the second handler and give us doYetAnotherThing. Then we resume - and that should resume in the 'outerd' block _not_ the original block.

Which indeed would appear to fail the test according to the test code. If I change the test to follow my understanding we get:-

simpleOuterTest "uses #resume"

[[self doSomething. MyTestNotification signal. "self doSomethingElse" self doSomethingExceptional] on: MyTestNotification do: [:ex | ex outer. self doSomethingElse]] on: MyTestNotification do: [:ex | self doYetAnotherThing. ex resume]

...and the test now seems to pass and we do not get an error.

So, my opinion as of this late hour is that the test is fsck'd. Am I right or am I hallucinating?

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: RIW: Re-Invent Wheel