On 12/16/2011 15:11, David Corking wrote:
> I disagree that it is obscure.
>
> It is very easy for a beginner to mistakenly get Smalltalk into a
> tight loop. I have done it myself, and I have loaded others' code that
> made Squeak uninterruptible.

My point about this situation being obscure related exclusively to the 
example of 10000 factorial. If you have had other code that has similar 
issues I would encourage you to try it out to see if the workaround Bert 
has been posting actually addresses it. I kinda doubt it. Bert's 
workaround works for situation where there is a problem with printing 
the call stack (as exercised with 10000 factorial); but these situations 
are extremely rare.

It is more likely that in the situations where you've found Squeak to be 
non-interruptable, some other issue (such as selecting the 'wrong' 
process) is the cause of your problems.

> The user interrupt should be a selling point for Squeak, not a
> discouragement. Unfortunately, beginners, no matter how clueful, are
> likely to be discouraged by a broken promise, rather than seek out
> advice to turn off logging in their image.

Certainly. But I'm questioning your assumption that most cases of 
non-interruptability of Squeak would be caused by logging delays. My 
claim is that under "normal" operations these delays are practically 
non-existent.

> FWIW, I haven't tested Bert's patch, but I think the proposal to
> comment out one line is appropriately minimal for a pre-release code
> freeze.

Then please, go ahead and test it. If you find that your various 
situations under which you've seen non-interruptability are solved by 
it, you can color me impressed :-)

Cheers,
   - Andreas