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_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 |
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/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, Dec 13, 2011 at 1:36 PM, Lawson English <[hidden email]> wrote: That sounds really great. 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?
best, Eliot |
On Tue, 13 Dec 2011 14:30:13 -0800
Eliot Miranda <[hidden email]> 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? -- Christopher Oliver <[hidden email]> |
In reply to this post by Eliot Miranda-2
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. -- Christopher Oliver <[hidden email]> |
In reply to this post by Christopher Oliver
On Tue, Dec 13, 2011 at 3:01 PM, Christopher Oliver <[hidden email]> 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.
best, Eliot |
On Tue, 13 Dec 2011 15:24:53 -0800
Eliot Miranda <[hidden email]> 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. -- Christopher Oliver <[hidden email]> |
In reply to this post by Eliot Miranda-2
On 12/13/2011 23:30, Eliot Miranda wrote:
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: |
In reply to this post by Andreas.Raab
On 14.12.2011, at 09:07, Andreas Raab wrote:
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:
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:
... as does ignoring the CurrentReadOnlySourceFiles exception in the logging code. Levente? - Bert - |
In reply to this post by Bert Freudenberg
On Wed, 14 Dec 2011 18:03:23 +0100
Bert Freudenberg <[hidden email]> 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. :( -- Christopher Oliver <[hidden email]> |
In reply to this post by Bert Freudenberg
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 <[hidden email]> |
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? > |
In reply to this post by Christopher Oliver
At a glance, the below is some damned fine sleuthing. Excellent work.
On Dec 14, 2011, at 5:51 PM, Christopher Oliver <[hidden email]> 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 <[hidden email]> > |
In reply to this post by Christopher Oliver
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 |
In reply to this post by Bert Freudenberg
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 <[hidden email]> 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 <[hidden email]> 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 - |
Free forum by Nabble | Edit this page |