On 15.12.2011, at 12:57, Levente Uzonyi wrote:

> On Wed, 14 Dec 2011, Bert Freudenberg wrote:
> 
>> On 14.12.2011, at 18:03, Bert Freudenberg wrote:
>> 
>>> On 14.12.2011, at 17:55, Bert Freudenberg wrote:
>>> 
>>>> On 14.12.2011, at 09:07, Andreas Raab wrote:
>>>> 
>>>>> On 12/13/2011 23:30, Eliot Miranda wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, Dec 13, 2011 at 1:36 PM, Lawson English <lenglish5 at cox.net> wrote:
>>>>>> That sounds really great.
>>>>>> 
>>>>>> However, there are some broken bits in Squeak that will make learning Smalltalk difficult.
>>>>>> 
>>>>>> Most simple and important example I have right now is the well-known issue that the VM will freeze indefinitely if you input a long running calculation, e.g. x := 100000 factorial. The interrupt key doesn't work, usually.  Newbies like me, like to experiment, and if the VM freezes with every typo, then its hardly worth using.
>>>>>> 
>>>>>> This is interesting because it does *not* freeze in my Qwaq-derived work image.  Here the interrupt key works perfectly with no delay.  I'll see if I can investigate.  Andreas, do you recall doing anything to the debugger to fix issues like this in the Qwaq system?
>>>>> 
>>>>> Nothing I can recall. Also, when I try interrupting 100000 factorial in a 4.2 image with either a Teleplace or OpenQwaq VM I have no trouble interrupting anything. So it doesn't look like it's an issue in the image that is causing it. Wonder if there's anything changed in the support code perhaps...
>>>>> 
>>>>> Cheers,
>>>>>  - Andreas
>>>> 
>>>> 
>>>> I think there may be an error when trying to bring up the user interrupt dialog.
>>>> 
>>>> Pressing Cmd-. during "100000 factorial" does create a SqueakDebug.log file immediately, but does not show the debugger.
>>>> 
>>>> - Bert -
>>> 
>>> 
>>> Found something: reverting  #openInterrupt:onProcess: from the "mtf 2/5/2011" version to the older "sd 11/20/2005" version restores interruptability
>>> 
>>> - Bert -
>> 
>> ... as does ignoring the CurrentReadOnlySourceFiles exception in the logging code. Levente?
> 
> I'm lost. Where does CurrentReadOnlySourceFiles appear and what kind of problem does it cause?

See my other message - ignoring it around the logging code does make the interrupting work. However, that may be simply due to it aborting the logging. A red herring.

> Also, reverting #openInterrupt:onProcess: doesn't solve the issue. About every second time I interrupt the finalization process, so I won't see a debugger till 100000 factorial finishes. Pressing Alt+. one more time can interrupt the factorial calculation though.

Same here, but that is unrelated.

> I benchmarked the log creation and found that it takes anywhere between a second and a minute depending on the machine and the state of the calculation, so that's the real reason why the debugger doesn't appear instantly. I rewrote SmalltalkImage >> #logError:inContext:to: to fork the log creation, and the debugger appears instantly (if I'm lucky and the right process get interrupted), but I'm not sure if it's a good idea to log the context of another process.
> 
> logError: errMsg inContext: aContext to: aFilename
> 	"Log the error message and a stack trace to the given file."
> 
> 	[ [
> 		FileStream forceNewFileNamed: aFilename do: [ :file |
> 			file
> 				nextPutAll: errMsg; cr.
> 				aContext errorReportOn: file ] ]
> 		on: Error
> 		do: [ :err | nil "Can't do much" ] ] forkAt: Processor systemBackgroundPriority


Seems like a good solution to me.

IMHO we need to commit some fix before the 4.3 release - either this forking of logging, or removing it altogether as before. 

To be conservative this late in the release cycle I'd disable the logging for now, and re-enable it with forking in 4.4alpha.

> With this change I can easily interrupt [ true ] whileTrue and even [] repeat. :)


Not on my machine. I guess that problem is specific to the Mac VM.

- Bert -