Hi all,
it's a pleasure for me to announce the Koans tutorial project for teaching beginners the basics of Smalltalk. Inspired by the Edgecase Ruby Koans project and the original "The little Lisper" book by Daniel P. Friedman and Matthias Felleisen, we have implemented Smalltalk Koans in order to help our students to get started with Smalltalk.
Smalltalk Koans will guide you as a Smalltalk novice from first steps in Smalltalk to your first small project. The path is simple: You get a task, you solve it and, in the process, learn something. The Koans Sensei (jap.: teacher) will be your guide and introduce you to fundamental concepts in Smalltalk such as strings, blocks, collections and many more.
After a first internal use, we'd like to announce that we make this tutorial project available for the community.
https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...
Especially, we'd like to acknowledge our student assistants, Eric Seckler, Robin Schreiber, and Partick Rein for implementing Koans in Smalltalk.
If you have any wishes for new lectures and feedback to existing ones, please let us know.
Best regards, Michael
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.
That is the feedback I'm getting from my videos.
L.
On 12/13/11 8:31 AM, Michael Perscheid wrote:
Hi all,
it's a pleasure for me to announce the Koans tutorial project for teaching beginners the basics of Smalltalk. Inspired by the Edgecase Ruby Koans project and the original "The little Lisper" book by Daniel P. Friedman and Matthias Felleisen, we have implemented Smalltalk Koans in order to help our students to get started with Smalltalk.
Smalltalk Koans will guide you as a Smalltalk novice from first steps in Smalltalk to your first small project. The path is simple: You get a task, you solve it and, in the process, learn something. The Koans Sensei (jap.: teacher) will be your guide and introduce you to fundamental concepts in Smalltalk such as strings, blocks, collections and many more.
After a first internal use, we'd like to announce that we make this tutorial project available for the community.
https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...
Especially, we'd like to acknowledge our student assistants, Eric Seckler, Robin Schreiber, and Partick Rein for implementing Koans in Smalltalk.
If you have any wishes for new lectures and feedback to existing ones, please let us know.
Best regards, Michael
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?
That is the feedback I'm getting from my videos.
L.
On 12/13/11 8:31 AM, Michael Perscheid wrote:
Hi all,
it's a pleasure for me to announce the Koans tutorial project for teaching beginners the basics of Smalltalk. Inspired by the Edgecase Ruby Koans project and the original "The little Lisper" book by Daniel P. Friedman and Matthias Felleisen, we have implemented Smalltalk Koans in order to help our students to get started with Smalltalk.
Smalltalk Koans will guide you as a Smalltalk novice from first steps in Smalltalk to your first small project. The path is simple: You get a task, you solve it and, in the process, learn something. The Koans Sensei (jap.: teacher) will be your guide and introduce you to fundamental concepts in Smalltalk such as strings, blocks, collections and many more.
After a first internal use, we'd like to announce that we make this tutorial project available for the community.
https://www.hpi.uni-potsdam.**de/hirschfeld/trac/** SqueakCommunityProjects/wiki/**smalltalk_koanshttps://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/smalltalk_koans
Especially, we'd like to acknowledge our student assistants, Eric Seckler, Robin Schreiber, and Partick Rein for implementing Koans in Smalltalk.
If you have any wishes for new lectures and feedback to existing ones, please let us know.
Best regards, Michael
On Tue, 13 Dec 2011 14:30:13 -0800 Eliot Miranda eliot.miranda@gmail.com wrote:
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?
I'm not seeing any difficulty with alt-. on Linux either crashing out of 100000 factorial or 50 benchFib. This is with Cog 2508.
What platform is giving the grief?
On Tue, Dec 13, 2011 at 3:01 PM, Christopher Oliver < current.input.port@gmail.com> wrote:
On Tue, 13 Dec 2011 14:30:13 -0800 Eliot Miranda eliot.miranda@gmail.com wrote:
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?
I'm not seeing any difficulty with alt-. on Linux either crashing out of 100000 factorial or 50 benchFib. This is with Cog 2508.
What platform is giving the grief?
If I try 100000 factorial on the Mac in a trunk 4.2 image and I hit command-. the debugger does not appear. If, on the Mac with the same VM, I try 100000 factorial in my Qwaq-derived image the debugger comes up immediately I hit command-. . So the difference is not the platform, but the image.
-- Christopher Oliver current.input.port@gmail.com
On Tue, 13 Dec 2011 15:24:53 -0800 Eliot Miranda eliot.miranda@gmail.com wrote:
If I try 100000 factorial on the Mac in a trunk 4.2 image and I hit command-. the debugger does not appear. If, on the Mac with the same VM, I try 100000 factorial in my Qwaq-derived image the debugger comes up immediately I hit command-. . So the difference is not the platform, but the image.
To test that idea, I tried adding "SmalltalkImage current quitPrimitive" after the "InterruptSemaphore wait" in InputSensor>>userInterruptWatcher, and squeak shuts down quickly after I hit the interrupt key with the 100000 factorial test, so that seems to support this.
On Tue, 13 Dec 2011 14:30:13 -0800
I spoke (wrote) too soon. I have replicated the hang on 100000 factorial with cog 2508 and 2519 on Linux.
On 12/13/2011 23:30, Eliot Miranda wrote:
On Tue, Dec 13, 2011 at 1:36 PM, Lawson English <lenglish5@cox.net mailto: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
FWIW, if I try this in the 4.2 all-in-one, the first CMD-period does nothing. The second CMD-period brings up two debuggers, one for the factorial and one for WeakArray class>>finalizationProcess. Similar sort of behavior if I use a CogMT from August rather than the VM included in the all-in-one. If I dismiss the WeakArray debugger (and, thus, no finalization process), then CMD-period works as expected. MacOS 10.5
Cheers, Bob
On 12/14/11 3:07 AM, 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 mailto: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
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 -
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 -
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?
- Bert -
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?
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?
At a glance, the below is some damned fine sleuthing. Excellent work.
On Dec 14, 2011, at 5:51 PM, Christopher Oliver current.input.port@gmail.com 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?
-- Christopher Oliver current.input.port@gmail.com
On 15.12.2011, at 02:51, 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?
Sounds tempting, but I don't think that is the core of the problem. Try this in Debugger>>openInterrupt:onProcess:
Preferences logDebuggerStackToFile ifTrue: [[(aString includesSubString: 'Space') & (aString includesSubString: 'low') ifTrue: [Smalltalk logError: aString inContext: debugger interruptedContext to: 'LowSpaceDebug.log'] ifFalse: [Smalltalk logSqueakError: aString inContext: debugger interruptedContext] ] on: CurrentReadOnlySourceFiles do: [:ex | "ignore"]].
With this, interrupting factorial works fine. However, replacing it with this:
Preferences logDebuggerStackToFile ifTrue: [[(aString includesSubString: 'Space') & (aString includesSubString: 'low') ifTrue: [Smalltalk logError: aString inContext: debugger interruptedContext to: 'LowSpaceDebug.log'] ifFalse: [Smalltalk logSqueakError: aString inContext: debugger interruptedContext] ] valueWithin: 200 milliSeconds onTimeout: []].
... does not let you interrupt factorial.
And "[true] whileTrue" can't be interrupted even if logging is disabled. That seems like another problem though because in that tight loop, the image does not even get to process the interrupt.
- Bert -
Bert Freudenberg wrote:
... ... does not let you interrupt factorial.
And "[true] whileTrue" can't be interrupted even if logging is disabled. That seems like another problem though because in that tight loop, the image does not even get to process the interrupt.
- Bert -
Just in case it is useful to someone: In Cuis, both '100000 factorial' and '[true] whileTrue' can be interrupted without problems.
Cheers, Juan Vuletich
On Thu, 15 Dec 2011 07:34:15 -0300 Juan Vuletich juan@jvuletich.org wrote:
Just in case it is useful to someone: In Cuis, both '100000 factorial' and '[true] whileTrue' can be interrupted without problems.
For the factorial, try 'proceed' from the initial debugger window and then re-interrupting. :-(
I'm having no trouble at all with [true] whileTrue on 4.2-10976 whereas 4.2-11819 hangs on that test.
I tend to agree with Bert that disabling the logging is a good idea pending a clear understanding about the root causes. As it stands there is a Preferences setting for this, but that also shuts off the LowMemoryDebug file as well. Would anyone miss it if the preference was shut off by default?
On 15.12.2011, at 17:00, Christopher Oliver wrote:
I tend to agree with Bert that disabling the logging is a good idea pending a clear understanding about the root causes. As it stands there is a Preferences setting for this, but that also shuts off the LowMemoryDebug file as well. Would anyone miss it if the preference was shut off by default?
Yes. It governs all debug logging. I'd just comment out the offending log send.
- Bert -
Christopher Oliver wrote:
On Thu, 15 Dec 2011 07:34:15 -0300 Juan Vuletich juan@jvuletich.org wrote:
Just in case it is useful to someone: In Cuis, both '100000 factorial' and '[true] whileTrue' can be interrupted without problems.
For the factorial, try 'proceed' from the initial debugger window and then re-interrupting. :-(
Morphic redraw not immediate. Thanks for the report. Fix is attached. :)
Cheers, Juan Vuletich
On Thu, 15 Dec 2011 11:35:55 +0100 Bert Freudenberg bert@freudenbergs.de wrote:
Sounds tempting, but I don't think that is the core of the problem. Try this in Debugger>>openInterrupt:onProcess:
I'll look at these, but figure I'd share things found out so far. I've been using this crude instrument to see where and when things are going on:
|counter enabled|
counter := 0. enabled := false.
WriteTTYEnabled := [:arg| enabled := arg].
WriteTTY := [:arg | | sender | sender := thisContext sender. enabled ifTrue: [ FileStream fileNamed: '/dev/tty' do: [:handle| handle nextPutAll: '== ', counter asString,' ', sender receiver className,'(', sender methodClass asString,')>>', (sender method selector) asString, ' ',Time now asString,' == ', arg asString; lf]. counter := counter+1]]. WriteTTYReset := [counter := 0].
" WriteTTYReset value WriteTTYEnabled value: true WriteTTYEnabled value: false "
When I file this in and evaluate 'WriteTTYEnabled value: true', I can sprinkle the code I want to understand with 'WriteTTY value: SOMESTRING', and have output on the console without depending on morphic display updates and the like. I put this in the vars loop in ContextPart>>errorReportOn:, and in Object>>printStringLimitedTo: contingent on a Flag in the Smalltalk globals. I found that sometimes, Smaltalk indeed gets stuck converting that bignum, but other times, the seems to go astray and the factorial marches on. Hitting the interrupt a second time sometimes succeeds, and two debugs appear after a while: the expected factorial, but also BlockClosure>>newProcess/WeakArray class>>restartFinalizationProcess. This suggests the running process has been misidentified, but I've not much idea what is happening here.
Thoughts?
On Thu, Dec 15, 2011 at 08:06:19PM -0500, Christopher Oliver wrote:
On Thu, 15 Dec 2011 11:35:55 +0100 Bert Freudenberg bert@freudenbergs.de wrote:
Sounds tempting, but I don't think that is the core of the problem. Try this in Debugger>>openInterrupt:onProcess:
I'll look at these, but figure I'd share things found out so far. I've been using this crude instrument to see where and when things are going on:
This is a good way to debug thing like this. FYI, a similar convenience method is OSProcess class>>trace: if you happen to have OSProcess loaded.
|counter enabled|
counter := 0. enabled := false.
WriteTTYEnabled := [:arg| enabled := arg].
WriteTTY := [:arg | | sender | sender := thisContext sender. enabled ifTrue: [ FileStream fileNamed: '/dev/tty' do: [:handle| handle nextPutAll: '== ', counter asString,' ', sender receiver className,'(', sender methodClass asString,')>>', (sender method selector) asString, ' ',Time now asString,' == ', arg asString; lf]. counter := counter+1]]. WriteTTYReset := [counter := 0].
" WriteTTYReset value WriteTTYEnabled value: true WriteTTYEnabled value: false "
When I file this in and evaluate 'WriteTTYEnabled value: true', I can sprinkle the code I want to understand with 'WriteTTY value: SOMESTRING', and have output on the console without depending on morphic display updates and the like. I put this in the vars loop in ContextPart>>errorReportOn:, and in Object>>printStringLimitedTo: contingent on a Flag in the Smalltalk globals. I found that sometimes, Smaltalk indeed gets stuck converting that bignum, but other times, the seems to go astray and the factorial marches on. Hitting the interrupt a second time sometimes succeeds, and two debugs appear after a while: the expected factorial, but also BlockClosure>>newProcess/WeakArray class>>restartFinalizationProcess. This suggests the running process has been misidentified, but I've not much idea what is happening here.
Thoughts?
I think what you are seeing here is that the finalization process *is* the running process. It just happens to be the process that is running at the time the interrupt key event is delivered to the image. I think I recall Bert suggesting in an earlier thread (months ago?) that certain normal background processes be excluded from interruption. This might very well be the best way to handle the issue, but I don't think that any of us followed up on that suggestion.
If the above is true, then it also begs the question of why the finalization process should be so active that it just happens to be the process that gets interrupted so often. That suggests that the finalization process may be much busier than it needs to be.
Dave
On Thu, 15 Dec 2011 21:31:05 -0500 "David T. Lewis" lewis@mail.msen.com wrote:
If the above is true, then it also begs the question of why the finalization process should be so active that it just happens to be the process that gets interrupted so often. That suggests that the finalization process may be much busier than it needs to be.
Factorial generates a lot of garbage bignums. Might that bear on this?
On Thu, 15 Dec 2011 11:35:55 +0100 I wrote:
"the seems to go astray"
That should have read: "the interrupt seems to go astray"
Note to self: get new typing fingers.
On Thu, 15 Dec 2011 11:35:55 +0100 I added a tty output debug to MorphicProject>>interruptName:preemptedProcess:, and I found that Processor>>preemptedProcess occasionally answers the system weak array finalization process. Yikes! This isn't what we want to debug at all. Are we being adequately clever in determining which process to debug?
On Thu, 15 Dec 2011, Christopher Oliver wrote:
On Thu, 15 Dec 2011 11:35:55 +0100 I added a tty output debug to MorphicProject>>interruptName:preemptedProcess:, and I found that Processor>>preemptedProcess occasionally answers the system weak array finalization process. Yikes! This isn't what we want to debug at all. Are we being adequately clever in determining which process to debug?
I'm pretty sure that the currently running process is interrupted. After GC (which happens often during calculations with LargeIntegers) this is likely to be the finalization process.
Levente
-- Christopher Oliver current.input.port@gmail.com
On Fri, 16 Dec 2011 03:33:22 +0100 (CET) Levente Uzonyi leves@elte.hu wrote:
On Thu, 15 Dec 2011, Christopher Oliver wrote:
I'm pretty sure that the currently running process is interrupted. After GC (which happens often during calculations with LargeIntegers) this is likely to be the finalization process.
That's my reasoning as well given that factorial generates a lot of garbage bignums. Nonetheless, alt-. perhaps shouldn't hit that. It seems we need to be smarter than Processor>>preemptedProcess.
On 12/16/2011 3:33, Levente Uzonyi wrote:
On Thu, 15 Dec 2011, Christopher Oliver wrote:
On Thu, 15 Dec 2011 11:35:55 +0100 I added a tty output debug to MorphicProject>>interruptName:preemptedProcess:, and I found that Processor>>preemptedProcess occasionally answers the system weak array finalization process. Yikes! This isn't what we want to debug at all. Are we being adequately clever in determining which process to debug?
I'm pretty sure that the currently running process is interrupted. After GC (which happens often during calculations with LargeIntegers) this is likely to be the finalization process.
Correct. To make matters worse, when an interrupt is signaled in the midst of GC, the signal will be delivered after the GC cycle completes, therefore almost guaranteeing that the interrupted process will be the finalization process.
And so the determination of the process to be interrupted is moderately stupid. What we'd really need to do is to start a slightly leaner version of CPUWatcher, i.e., instead of blindly interrupting whatever process is active, start sampling the running processes and after a short while (100-500 ms) decide which process to kick[*]. Plus, after that ensure that the UI is actually responsive so that the user can interact with the system and if not, keep kicking processes unless the system becomes interactive again. Alas, not a trivial task to be solved.
[*] A more radical version would suspend *all* user processes and let the user decide which of the suspended processes to inspect. This might have some interesting side effects though...
Cheers, - Andreas
Bug tracking notes:
I have added Andreas' note below to Mantis 7656. Mantis 7656: User interrupts key does not always work the first time it is pressed.
The parent Mantis issue for several related issues is http://bugs.squeak.org/view.php?id=7655 Mantis 7655: A mother for user interupt bugs and problems
Background on the underlying signaling mechanism (not directly related to the current discussion but worth knowing) is Mantis 1041: [VM][ENH] LowSpaceAndInterruptHandler-dtl
This one is still open but should probably be closed as a "will not fix" Mantis 4818: [KernelImageOverride] InputSensor userInterruptWatcher
Dave
On Fri, Dec 16, 2011 at 08:00:03AM +0100, Andreas Raab wrote:
On 12/16/2011 3:33, Levente Uzonyi wrote:
On Thu, 15 Dec 2011, Christopher Oliver wrote:
On Thu, 15 Dec 2011 11:35:55 +0100 I added a tty output debug to MorphicProject>>interruptName:preemptedProcess:, and I found that Processor>>preemptedProcess occasionally answers the system weak array finalization process. Yikes! This isn't what we want to debug at all. Are we being adequately clever in determining which process to debug?
I'm pretty sure that the currently running process is interrupted. After GC (which happens often during calculations with LargeIntegers) this is likely to be the finalization process.
Correct. To make matters worse, when an interrupt is signaled in the midst of GC, the signal will be delivered after the GC cycle completes, therefore almost guaranteeing that the interrupted process will be the finalization process.
And so the determination of the process to be interrupted is moderately stupid. What we'd really need to do is to start a slightly leaner version of CPUWatcher, i.e., instead of blindly interrupting whatever process is active, start sampling the running processes and after a short while (100-500 ms) decide which process to kick[*]. Plus, after that ensure that the UI is actually responsive so that the user can interact with the system and if not, keep kicking processes unless the system becomes interactive again. Alas, not a trivial task to be solved.
[*] A more radical version would suspend *all* user processes and let the user decide which of the suspended processes to inspect. This might have some interesting side effects though...
Cheers,
- Andreas
On Fri, 16 Dec 2011 08:00:03 +0100 Andreas Raab andreas.raab@gmx.de wrote:
[*] A more radical version would suspend *all* user processes and let the user decide which of the suspended processes to inspect. This might have some interesting side effects though...
This is somewhat similar to tty group handling under UNIX derived systems. This would also be fairly trivial to implement. Processes could be flagged as system or non-system, and on user interrupt, all non-system process would be suspended and debuggers would raise on all. The user could decide which to resume. This would be painful only if there were many user threads running, and that's another unusual use case. Typically, we're running stuff under UIProcess. Or alternatively, suspend and debug all if there are fewer processes than some configurable limit (possibly zero), and otherwise, suspend all and bring up a dialog for choosing debug, suspend, terminate, or resume on each (system processes excluded).
I think quantum counting is expensive, a heuristic, and thus potentially wrong.
Hi Andreas,
On Thu, Dec 15, 2011 at 11:00 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 12/16/2011 3:33, Levente Uzonyi wrote:
On Thu, 15 Dec 2011, Christopher Oliver wrote:
On Thu, 15 Dec 2011 11:35:55 +0100
I added a tty output debug to MorphicProject>>interruptName:**preemptedProcess:, and I found that Processor>>preemptedProcess occasionally answers the system weak array finalization process. Yikes! This isn't what we want to debug at all. Are we being adequately clever in determining which process to debug?
I'm pretty sure that the currently running process is interrupted. After GC (which happens often during calculations with LargeIntegers) this is likely to be the finalization process.
Correct. To make matters worse, when an interrupt is signaled in the midst of GC, the signal will be delivered after the GC cycle completes, therefore almost guaranteeing that the interrupted process will be the finalization process.
And so the determination of the process to be interrupted is moderately stupid. What we'd really need to do is to start a slightly leaner version of CPUWatcher, i.e., instead of blindly interrupting whatever process is active, start sampling the running processes and after a short while (100-500 ms) decide which process to kick[*]. Plus, after that ensure that the UI is actually responsive so that the user can interact with the system and if not, keep kicking processes unless the system becomes interactive again. Alas, not a trivial task to be solved.
[*] A more radical version would suspend *all* user processes and let the user decide which of the suspended processes to inspect. This might have some interesting side effects though...
it's smetimes helpful to look at other systems' approaches. In VisualWorks there is no special interrupt handling in the VM; the keyboard event comes in like any other:
keyAt: keyNumber character: aCharacter alternative: alternativeCharacter down: isDownTransition "A keyboard key has been pressed or released; take appropriate action"
| keyboardEvent | (self state isModifierKey: aCharacter) ifTrue: [^self]. (self *allProcessInterruptMatchesCharacter*: aCharacter inTransition: isDownTransition) ifTrue: [^(#{CraftedSmalltalk.DebuggerService} valueOrDo: [Processor]) *interruptAllUserProcesses*]. (self warpToLauncherMatchesCharacter: aCharacter inTransition: isDownTransition) ifTrue: [^#{VisualLauncher} ifDefinedDo: [:launcherClass | launcherClass raiseOrOpen]]. (aCharacter = self state class *interruptKeyValue* and: [isDownTransition]) ifTrue: [(self state *shiftDown* or: [(keyNumber bitAnd: 256) ~= 0]) ifTrue: [[*EmergencyWindow open*] fork] ifFalse: [(#{CraftedSmalltalk.DebuggerService} valueOrDo: [Processor]) *interruptActiveUserProcess*]] ifFalse: [isDownTransition ifTrue: [keyboardEvent := KeyPressedEvent new] ifFalse: [keyboardEvent := KeyReleasedEvent new]. keyboardEvent := keyboardEvent code: aCharacter meta: (self state metaState bitOr: (keyNumber bitShift: -8)) alternative: alternativeCharacter. self addMetaInput: (keyboardEvent window: window)]
further, UserInterrupt is a signal that can be handled, and there is some special interpretation applied before raising that signal:
ProcessorScheduler>>interruptActiveUserProcess
| proc deb | proc := self runableProcesses detect: [:p | p isSystemProcess not] ifNone: [nil]. (proc isNil and: [Window currentWindow notNil]) ifTrue: [proc := Window currentWindow windowProcess]. proc isNil ifTrue: [^self interruptAllUserProcesses]. (deb := proc environmentAt: #debugger) notNil ifTrue: [^deb abortDebugOperationInProcess: proc]. proc isUnderDebug ifTrue: [^DebuggerService abortDebuggingFor: proc]. proc interruptWith: [Object userInterruptSignal interruptWith: thisContext sender sender errorString: (#exceptUserInterrupt << #dialogs >> 'User Interrupt')]
DebuggerService class>>interruptActiveUserProcess | proc | proc := self getActiveUserProcess. proc isNil ifTrue: [proc := self getCurrentWindowProcess]. proc isNil ifTrue: [^self interruptAllUserProcesses]. proc isUnderDebug ifTrue: [^proc debugger abortDebugOperationInProcess: proc]. proc interruptWith: [Object userInterruptSignal interruptWith: thisContext sender sender errorString: (#UserInterrupt << #pdp >> 'User Interrupt')]
This is a variation on having a smarter Processor>>preemptedProcess. It seems to me that using the GUI to select the active process makes sense, that when using the debugger, interrupting simulation makes sense, and that making UserInterrupt a signal is a really, really good thing, especially for deploying applications.
Cheers,
- Andreas
On Fri, Dec 16, 2011 at 9:40 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
This is a variation on having a smarter Processor>>preemptedProcess. It seems to me that using the GUI to select the active process makes sense, that when using the debugger, interrupting simulation makes sense, and that making UserInterrupt a signal is a really, really good thing, especially for deploying applications.
Another nice thing about the VW scheme is that you can open a process browser and just kill all user processes. The ones running the UI will get respawned from scratch, and you're back to a working system. I've been able to get out of some pretty gnarly situations that way.
Colin
On Fri, 16 Dec 2011 09:40:42 -0800 Eliot Miranda eliot.miranda@gmail.com wrote:
it's smetimes helpful to look at other systems' approaches. In VisualWorks there is no special interrupt handling in the VM; the keyboard event comes in like any other:
I've always had a strong aversion to sending control and data on the same channel. (vis. Capn' Crunch, SQL injection, XSS) While I don't think we've got those sorts of nasties, I like control and data well differentiated as a matter of principle. Here's an idea which preserves backward compatibility with old images, and permits multiple attention keys: let primSetInterruptKey take either an integer or an array of integers. The VM makes a list of the keys passed; the list has only one element if an integer is passed. When a key in the list is encountered, the VM records that in a buffer (only the most recent attention key is remembered), and sends the semaphore in the current fashion. Create a new primitive to read the buffer. The advantage is that existing images still work, while newer images can set multiple attn. keys, and they can dispatch them appropriately after finding out which key was hit.
On Fri, 16 Dec 2011 09:40:42 -0800 Eliot Miranda eliot.miranda@gmail.com wrote:
sutff about how VW handles use interrupts.
Sorry about my last screed. I was unaware that user interrupt handling had moved into EventSensor. That will teach me to open my mouth without reading ALL of the relevant the code first.
Since new images handle user interrupts onboards rather than in the VM, do we really need to carry along the old InputSensor>>primSetKeyboardInterrupt: and InputSensor>>primInterruptSemaphore: anymore? If those can be discarded, then multiple attn keys as in Elliott's example are trivial to do as the argument to primSetKeyboardInterrupt can be other than an integer. It seems to me that given current event handling the methods in InputSensor are a bit of a red herring to trap the unwary (me), and they should be jettisoned save for setting the VMs interrupt key to something that simply can't be typed on startup.
Thoughts?
On Fri, Dec 16, 2011 at 08:00:03AM +0100, Andreas Raab wrote:
On 12/16/2011 3:33, Levente Uzonyi wrote:
On Thu, 15 Dec 2011, Christopher Oliver wrote:
On Thu, 15 Dec 2011 11:35:55 +0100 I added a tty output debug to MorphicProject>>interruptName:preemptedProcess:, and I found that Processor>>preemptedProcess occasionally answers the system weak array finalization process. Yikes! This isn't what we want to debug at all. Are we being adequately clever in determining which process to debug?
I'm pretty sure that the currently running process is interrupted. After GC (which happens often during calculations with LargeIntegers) this is likely to be the finalization process.
Correct. To make matters worse, when an interrupt is signaled in the midst of GC, the signal will be delivered after the GC cycle completes, therefore almost guaranteeing that the interrupted process will be the finalization process.
And so the determination of the process to be interrupted is moderately stupid. What we'd really need to do is to start a slightly leaner version of CPUWatcher, i.e., instead of blindly interrupting whatever process is active, start sampling the running processes and after a short while (100-500 ms) decide which process to kick[*]. Plus, after that ensure that the UI is actually responsive so that the user can interact with the system and if not, keep kicking processes unless the system becomes interactive again. Alas, not a trivial task to be solved.
[*] A more radical version would suspend *all* user processes and let the user decide which of the suspended processes to inspect. This might have some interesting side effects though...
I think I found the underlying cause of all this grief, which in fact has nothing to do with the user interrupt handler. The problem is that the weak finalization process is very busy due to thrashing between the VM and the image. The VM notifies the image when weak references need to be cleaned up, and the weak finalization process responds by creating new weak references for the VM to clean up, etc etc etc ...
A fix is posted to the inbox in Collections-dtl.466
As Andreas observes, creating a smarter user interrupt handler is not at all trivial. But creating a smarter weak finalization process is really easy :) The solution was to move the check for VM support of new finalization out of the finalization process, and perform the check once at image startUp time.
With that change in place, the following may all be interrupted in the expected way:
"[true] whileTrue" "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" "Smalltalk createStackOverflow" "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
Just for the record, this problem was a whole lot harder to figure out than it was to explain ;-)
Dave
Am 22.12.2011 22:24 schrieb "David T. Lewis" lewis@mail.msen.com:
Just for the record, this problem was a whole lot harder to figure out than it was to explain ;-)
I bet! Thanks for your endurance.
Alex
Santa hath come early this year! This is a double-win -- because we can not only interrupt again but performance should be better too. This was for Igors attempt to improve the finalization mechanism, ironically for better performance back in 2010 I think -- and in which I was very interested because of how the hyper-activity of the finalization process was causing half of the processing time to be spent spinning through the weak references.
Not creating garbage will help a lot, even if it still seems like overkill to be finalizing every single weak collection on every single incremental GC -- I ran with a 10 second delay at the end of the whileTrue loop and noticed a noticeable gain in performance.. Unfortunately there are a few processes which rely on the results of GC..
Can't wait to try this out, thanks a lot Dave!
On Thu, Dec 22, 2011 at 3:24 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Dec 16, 2011 at 08:00:03AM +0100, Andreas Raab wrote:
On 12/16/2011 3:33, Levente Uzonyi wrote:
On Thu, 15 Dec 2011, Christopher Oliver wrote:
On Thu, 15 Dec 2011 11:35:55 +0100 I added a tty output debug to MorphicProject>>interruptName:preemptedProcess:, and I found that Processor>>preemptedProcess occasionally answers the system weak array finalization process. Yikes! This isn't what we want to debug at all. Are we being adequately clever in determining which process to debug?
I'm pretty sure that the currently running process is interrupted. After GC (which happens often during calculations with LargeIntegers) this is likely to be the finalization process.
Correct. To make matters worse, when an interrupt is signaled in the midst of GC, the signal will be delivered after the GC cycle completes, therefore almost guaranteeing that the interrupted process will be the finalization process.
And so the determination of the process to be interrupted is moderately stupid. What we'd really need to do is to start a slightly leaner version of CPUWatcher, i.e., instead of blindly interrupting whatever process is active, start sampling the running processes and after a short while (100-500 ms) decide which process to kick[*]. Plus, after that ensure that the UI is actually responsive so that the user can interact with the system and if not, keep kicking processes unless the system becomes interactive again. Alas, not a trivial task to be solved.
[*] A more radical version would suspend *all* user processes and let the user decide which of the suspended processes to inspect. This might have some interesting side effects though...
I think I found the underlying cause of all this grief, which in fact has nothing to do with the user interrupt handler. The problem is that the weak finalization process is very busy due to thrashing between the VM and the image. The VM notifies the image when weak references need to be cleaned up, and the weak finalization process responds by creating new weak references for the VM to clean up, etc etc etc ...
A fix is posted to the inbox in Collections-dtl.466
As Andreas observes, creating a smarter user interrupt handler is not at all trivial. But creating a smarter weak finalization process is really easy :) The solution was to move the check for VM support of new finalization out of the finalization process, and perform the check once at image startUp time.
With that change in place, the following may all be interrupted in the expected way:
"[true] whileTrue" "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" "Smalltalk createStackOverflow" "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
Just for the record, this problem was a whole lot harder to figure out than it was to explain ;-)
Dave
On Thu, Dec 22, 2011 at 07:19:03PM -0600, Chris Muller wrote:
Santa hath come early this year! This is a double-win -- because we can not only interrupt again but performance should be better too. This was for Igors attempt to improve the finalization mechanism, ironically for better performance back in 2010 I think -- and in which I was very interested because of how the hyper-activity of the finalization process was causing half of the processing time to be spent spinning through the weak references.
I hope that this hold up as a proper fix, and it certainly does need to be reviewed. But I want to be sure I do not leave any bad impression about the new finalization mechanism. Igor's improved finalization mechanism is in fact a *huge* performance win. People starting with a freshly downloaded image may not notice it, but as time goes on the benefits become more apparent. When using an image over a long period of time (as I tend to do), the accumulated load of handling weak finalization can be a real problem. Igor's new finalization mechanism addresses this very effectively, and this results in very noticable real-world performance improvements for Squeak.
I think that I may have uncovered a problem in the weak finalization update process that has gone unnoticed for a long time. If so, then good, this should help the new finalization to work as intended. But kudos to Igor for implementing the weak finalization improvements, and I hope that fixing this glitch in the weak finalization process will clean up a few loose ends.
Dave
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
Cheers, Bob
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
Dave
David,
While I was a little suspicious about the close placement of the init and test, my observation was from a 4.2 image with no changes in this area. Just curious what image/vm implements this *new* finalization.
Cheers, Bob
On 12/23/11 10:13 AM, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
Dave
The image side changes were part of Squeak 4.2, and VM changes happened before that. I think that all the VMs currently in circulation will have this support, but I'm not certain of it.
For the interpreter VM, the changes were introduced here:
Name: VMMaker-dtl.175 Time: 25 May 2010, 8:01:19 am Ancestors: VMMaker-dtl.174
VMMaker 4.2.2 Reference Mantis 7473: VM changes for better finalization support Add Igor's VM changes to support better finalization (weak-finalizers-VM.1.cs merged with Alien support updates).
The Cog VMs would have had the support added in a similar time frame, although I don't recall exactly when.
HTH, Dave
On Fri, Dec 23, 2011 at 10:22:25AM -0500, Bob Arning wrote:
David,
While I was a little suspicious about the close placement of the init and test, my observation was from a 4.2 image with no changes in this area. Just curious what image/vm implements this *new* finalization.
Cheers, Bob
On 12/23/11 10:13 AM, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
Dave
On Fri, 23 Dec 2011, David T. Lewis wrote:
The image side changes were part of Squeak 4.2, and VM changes happened before that. I think that all the VMs currently in circulation will have this support, but I'm not certain of it.
Eliot's CogVMs don't have this patch.
Levente
For the interpreter VM, the changes were introduced here:
Name: VMMaker-dtl.175 Time: 25 May 2010, 8:01:19 am Ancestors: VMMaker-dtl.174
VMMaker 4.2.2 Reference Mantis 7473: VM changes for better finalization support Add Igor's VM changes to support better finalization (weak-finalizers-VM.1.cs merged with Alien support updates).
The Cog VMs would have had the support added in a similar time frame, although I don't recall exactly when.
HTH, Dave
On Fri, Dec 23, 2011 at 10:22:25AM -0500, Bob Arning wrote:
David,
While I was a little suspicious about the close placement of the init and test, my observation was from a 4.2 image with no changes in this area. Just curious what image/vm implements this *new* finalization.
Cheers, Bob
On 12/23/11 10:13 AM, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
Dave
On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
The following seems to take care of the issue without requiring anything to be done in the startUp: method.
WeakArray class>>finalizationProcess | initialized | initialized := false. [FinalizationSemaphore wait. initialized ifFalse: ["check VM capability once at image startup time" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. initialized := true]. FinalizationLock critical: [FinalizationDependents do: [ :weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] ifError: [:msg :rcvr | rcvr error: msg]] repeat
I'll update this in the inbox. Bob, thanks for catching the error.
Dave
On Fri, 23 Dec 2011, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
The following seems to take care of the issue without requiring anything to be done in the startUp: method.
WeakArray class>>finalizationProcess | initialized | initialized := false. [FinalizationSemaphore wait. initialized ifFalse: ["check VM capability once at image startup time" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. initialized := true]. FinalizationLock critical: [FinalizationDependents do: [ :weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] ifError: [:msg :rcvr | rcvr error: msg]] repeat
I'll update this in the inbox. Bob, thanks for catching the error.
There's still a very small window during startUp while the value of HasNewFinalization can be incorrect and it seems to be really hard to fix it from the image side. I don't know if this can cause any problems, but a new primitive for checking the availability would have been a better choice IMHO.
Levente
Dave
On Fri, Dec 23, 2011 at 04:51:58PM +0100, Levente Uzonyi wrote:
On Fri, 23 Dec 2011, David T. Lewis wrote:
The image side changes were part of Squeak 4.2, and VM changes happened before that. I think that all the VMs currently in circulation will have this support, but I'm not certain of it.
Eliot's CogVMs don't have this patch.
Oh! I'm afraid you are right, I did not notice that.
For reference, the weak finalization enhancement with original change sets for Cog and squeak VM is on Mantis: http://bugs.squeak.org/view.php?id=7473
On Fri, Dec 23, 2011 at 04:57:02PM +0100, Levente Uzonyi wrote:
On Fri, 23 Dec 2011, David T. Lewis wrote:
There's still a very small window during startUp while the value of HasNewFinalization can be incorrect and it seems to be really hard to fix it from the image side. I don't know if this can cause any problems, but a new primitive for checking the availability would have been a better choice IMHO.
Yes a primitive or VM parameter might have been better, although it's probably too late to worry about it now.
I think that in practice this is harmless, since any problems should be corrected once the new weak finalization process has started running. But a related concern may be that the weak finalization process is terminated before the new one is started, and it is probably not a good idea to terminate that process if it might be in the middle of e.g. finalizing values in a WeakKeyDictionary. Again this is probably not an issue in practice, but it does look a bit dangerous.
Dave
On 23.12.2011, at 16:38, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
The following seems to take care of the issue without requiring anything to be done in the startUp: method.
WeakArray class>>finalizationProcess | initialized | initialized := false. [FinalizationSemaphore wait. initialized ifFalse: ["check VM capability once at image startup time" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. initialized := true]. FinalizationLock critical: [FinalizationDependents do: [ :weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] ifError: [:msg :rcvr | rcvr error: msg]] repeat
I'll update this in the inbox. Bob, thanks for catching the error.
Dave
Guess we should resume this discussion:
This is in trunk now, but if I uncomment the workaround in #openInterrupt:onProcess: I still can't break into 100000 factorial.
How to proceed?
- Bert -
On Fri, 6 Jan 2012, Bert Freudenberg wrote:
On 23.12.2011, at 16:38, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
The following seems to take care of the issue without requiring anything to be done in the startUp: method.
WeakArray class>>finalizationProcess | initialized | initialized := false. [FinalizationSemaphore wait. initialized ifFalse: ["check VM capability once at image startup time" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. initialized := true]. FinalizationLock critical: [FinalizationDependents do: [ :weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] ifError: [:msg :rcvr | rcvr error: msg]] repeat
I'll update this in the inbox. Bob, thanks for catching the error.
Dave
Guess we should resume this discussion:
This is in trunk now, but if I uncomment the workaround in #openInterrupt:onProcess: I still can't break into 100000 factorial.
Do you mean that it still interrupts the finalization process first?
How to proceed?
I'd mark processes which shouldn't be interrupted by default. The easiest thing to do this is to store them in a WeakSet guarded by a Semaphore. Then define two different user interrupt methods: - one that can interrupt all processes - one that can interrupt all processes except for those, which are stored in that set.
This way we could prevent interrupting system processes (finalization, low space watcher, idle process, rfb session processes, etc) when a user process gets stuck.
Levente
- Bert -
On 06.01.2012, at 14:15, Levente Uzonyi wrote:
On Fri, 6 Jan 2012, Bert Freudenberg wrote:
On 23.12.2011, at 16:38, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 10:13:18AM -0500, David T. Lewis wrote:
On Fri, Dec 23, 2011 at 07:39:41AM -0500, Bob Arning wrote:
I've seen suspicious behavior (tough time interrupting and lots of finalization in MessageTally reports) in my 4.2 image, so I thought I'd look at applying this fix. One thing I'm a little puzzled about: HasNewFinalization is false in my image (I'm using a Cog that's a few months old). Under what conditions is it true?
I think you have spotted a timing problem here. I put the initTestPair and checkTestPair calls together in a startUp: method, which is wrong because it does not give the VM an opportunity to do its updates, so the results of the test are not valid.
This is not exactly elegant, but if you force a garbage collection between initTestPair and checkTestPair, the test will work properly.
WeakArray class>>startUp: resuming resuming ifFalse: [ ^self ]. "Check if new finalization is supported by the VM" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. self restartFinalizationProcess.
A better fix is needed - sorry about that. I'm not sure if I'll have a chance to look at this today, but the important thing is to arrange for the check to be done when the image is started, but not to continue repeating the test after it has been successfully performed.
The following seems to take care of the issue without requiring anything to be done in the startUp: method.
WeakArray class>>finalizationProcess | initialized | initialized := false. [FinalizationSemaphore wait. initialized ifFalse: ["check VM capability once at image startup time" WeakFinalizationList initTestPair. Smalltalk garbageCollect. WeakFinalizationList checkTestPair. initialized := true]. FinalizationLock critical: [FinalizationDependents do: [ :weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] ifError: [:msg :rcvr | rcvr error: msg]] repeat
I'll update this in the inbox. Bob, thanks for catching the error.
Dave
Guess we should resume this discussion:
This is in trunk now, but if I uncomment the workaround in #openInterrupt:onProcess: I still can't break into 100000 factorial.
Do you mean that it still interrupts the finalization process first?
No, I don't get a debugger to open at all, even if I press cmd-. multiple times. Do I need a later VM?
Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.128] Croquet Cog 4.0.0 Mac OS X built on Sep 28 2011 13:20:56 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3) platform sources revision r2496 http://www.squeakvm.org/svn/squeak/branches/Cog CoInterpreter VMMaker.oscog-eem.128 uuid: 314823f6-cd6c-468f-9183-843b558f630b Sep 28 2011
- Bert -
On Fri, 6 Jan 2012, Bert Freudenberg wrote:
On 06.01.2012, at 14:15, Levente Uzonyi wrote:
snip
Do you mean that it still interrupts the finalization process first?
No, I don't get a debugger to open at all, even if I press cmd-. multiple times. Do I need a later VM?
It works on windows (with both Cog and the interpreter), so I think no. Try printing the contents of the smalltalk stacks when the interrupt fails to see what causes the problem.
Levente
Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.128] Croquet Cog 4.0.0 Mac OS X built on Sep 28 2011 13:20:56 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3) platform sources revision r2496 http://www.squeakvm.org/svn/squeak/branches/Cog CoInterpreter VMMaker.oscog-eem.128 uuid: 314823f6-cd6c-468f-9183-843b558f630b Sep 28 2011
- Bert -
Hmm...
I tried this with a CogMT from the beginning of December.
1. 4.3 image with latest trunk updates 2. Removed comments in #openInterrupt:onProcess: 3. Evaluated 100000 factorial with cmd-p 4. Pressed cmd-period
Sometimes I get an interrupt in factorial (although not particularly quickly).
Sometimes... - the SqueakDebug.log is written right away - nothing else happens until the factorial prints out, then - debugger appears on the WeakArray finalization process
Don't know why one happens vs the other.
Cheers, Bob
On 1/6/12 8:54 AM, Bert Freudenberg wrote:
Do you mean that it still interrupts the finalization process first?
No, I don't get a debugger to open at all, even if I press cmd-. multiple times. Do I need a later VM?
On Thu, 22 Dec 2011 16:24:17 -0500 "David T. Lewis" lewis@mail.msen.com wrote:
I think I found the underlying cause of all this grief, which in fact has nothing to do with the user interrupt handler. The problem is that the weak finalization process is very busy due to thrashing between the VM and the image. The VM notifies the image when weak references need to be cleaned up, and the weak finalization process responds by creating new weak references for the VM to clean up, etc etc etc ...
A fix is posted to the inbox in Collections-dtl.466
As Andreas observes, creating a smarter user interrupt handler is not at all trivial. But creating a smarter weak finalization process is really easy :)
I look forward to trying this out. I still think down the road, we could buy some additional generality/cleverness in regards to whom we interrupt; I think this is what Elliott was suggesting, though I get nervous about looking at any commercial code (did he say that was from VW?) for intellectual property reasons. I have an idea of using small identity dictionary of interrupt actions by keystroke to use in EventSensor>>processEvents, but I need to think on this more; it's not even half baked yet. There really is a lot of indirection between seeing the key stroke and knocking down a process.
Happy whatever you may celebrate!
On 23 December 2011 05:19, Christopher Oliver current.input.port@gmail.com wrote:
On Thu, 22 Dec 2011 16:24:17 -0500 "David T. Lewis" lewis@mail.msen.com wrote:
I think I found the underlying cause of all this grief, which in fact has nothing to do with the user interrupt handler. The problem is that the weak finalization process is very busy due to thrashing between the VM and the image. The VM notifies the image when weak references need to be cleaned up, and the weak finalization process responds by creating new weak references for the VM to clean up, etc etc etc ...
A fix is posted to the inbox in Collections-dtl.466
As Andreas observes, creating a smarter user interrupt handler is not at all trivial. But creating a smarter weak finalization process is really easy :)
I look forward to trying this out. I still think down the road, we could buy some additional generality/cleverness in regards to whom we interrupt; I think this is what Elliott was suggesting, though I get nervous about looking at any commercial code (did he say that was from VW?) for intellectual property reasons.
As a general principle, that's laudable. Cog is, however, MIT licensed (http://www.mirandabanda.org/cogblog/about-cog/) so in this case there's no need to fret.
frank
I have an idea of using small identity dictionary of interrupt actions by keystroke to use in EventSensor>>processEvents, but I need to think on this more; it's not even half baked yet. There really is a lot of indirection between seeing the key stroke and knocking down a process.
Happy whatever you may celebrate!
-- Christopher Oliver current.input.port@gmail.com
On 12/22/2011 22:24, David T. Lewis wrote:
I think I found the underlying cause of all this grief, which in fact has nothing to do with the user interrupt handler. The problem is that the weak finalization process is very busy due to thrashing between the VM and the image. The VM notifies the image when weak references need to be cleaned up, and the weak finalization process responds by creating new weak references for the VM to clean up, etc etc etc ...
Excellent find!
Cheers, - Andreas
A fix is posted to the inbox in Collections-dtl.466
As Andreas observes, creating a smarter user interrupt handler is not at all trivial. But creating a smarter weak finalization process is really easy :) The solution was to move the check for VM support of new finalization out of the finalization process, and perform the check once at image startUp time.
With that change in place, the following may all be interrupted in the expected way:
"[true] whileTrue" "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1" "Smalltalk createStackOverflow" "[Smalltalk createStackOverflow] forkAt: Processor userSchedulingPriority + 1"
Just for the record, this problem was a whole lot harder to figure out than it was to explain ;-)
Dave
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?
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.
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
With this change I can easily interrupt [ true ] whileTrue and even [] repeat. :)
Levente
- Bert -
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 -
On 15.12.2011, at 15:33, Bert Freudenberg wrote:
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 -
Oh, actually ... with Eliot's Cog VM, the interrupt does work. But not with the 5.8 Cog VM I still kept around.
- Bert -
On Thu, 15 Dec 2011, Bert Freudenberg wrote:
snip
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.
Agreed.
Levente
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 -
On Wed, 14 Dec 2011 18:03:23 +0100 Bert Freudenberg bert@freudenbergs.de wrote:
Found something: reverting #openInterrupt:onProcess: from the "mtf 2/5/2011" version to the older "sd 11/20/2005" version restores interruptability
I'm in the same place. Also turning off "Log Debug Stack To File" in the preferences does the same thing. The earlier method write the log file only for Low Space issues. Trouble seems to be somewhere in ContextPart>>errorReportOn: or lower. If I return from this immediately ([^nil] value), I observe normal interruptability. BTW, I've seen the aberrant hanging behavior today with stackvm as well reinforcing that this is not a Cog bug. Isn't code archaeology great. :(
squeak-dev@lists.squeakfoundation.org
-
Alexander Lazarević -
Andreas Raab -
Bert Freudenberg -
Bob Arning -
Casey Ransberger -
Chris Muller -
Christopher Oliver -
Colin Putney -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
Juan Vuletich -
Lawson English -
Levente Uzonyi -
Michael Perscheid