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@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 -