Other situations can cause the same symptoms, of course. When I was 
trying to plot   Float e raisedTo: x    I would get situations where I 
had created a massively negative or positive coordinate due to not 
thinking things through properly and squeak would hang without being 
able to interupt. If I DID manage to get an interupt accepted, usually 
they had been buffered for while and there was generally an error dialog 
having to do with empty rectangles or other graphics related stuff mixed 
in with all the dozens of interrupt dialog boxes.

L


On 12/14/11 6:51 PM, Christopher Oliver wrote:
> I spent a bit of time working backwards from the user interrupt watcher process:
>
> 	InputSensor>>userInterruptWatcher
> 	SmalltalkImage>>handleUserInterrupt
> 	MorphicProject>>interruptName:
> 	MorphicProject>>interruptName:preemptedProcess:
> 	Debugger class>>openInterrupt:onProcess:
> 	SmalltalkImage>>logSqueakError:inContext:
> 	SmalltalkImage>>logError:inContext:to:
> 	ContextPart>>errorReportOn:
> 	MethodContext>>printDetails:
> 	ContextPart>>tempsAndValuesLimitedTo:indent:
> 	Object>>printStringLimitedTo:
>
> The story runs as follows: you're more than likely to interrupt '100000 factorial' in SmallInteger>>* since that's the bulk of the computation, and the argument aNumber is
> more than likely a LargePositiveInteger.  When ContextPart>>errorReportOn: displays
> this, the bignum is converted to a decimal string and then truncated, and this appears
> to be the source of the delay.  Nothing prior to or following the invocation of
> Object>>printStringLimitedTo: takes much time at all.  This suggests that vars in the
> first twenty frames (see ContextPart>>errorReportOn:) that have a string representation
> that's expensive to compute will make Smalltalk appear to hang on cmd-.  I can appreciate
> value in being able to look at the stack dump in SqueakDebug.log to determine where
> Smalltalk was when you hit the interrupt key, so I'm at a loss how is best to go here.
>
> Thoughts?
>