[ANN] Koans for Teaching the Basics of Smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[ANN] Koans for Teaching the Basics of Smalltalk

Michael Perscheid
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Koans for Teaching the Basics of Smalltalk

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


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Koans for Teaching the Basics of Smalltalk

Eliot Miranda-2


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?


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






--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Koans for Teaching the Basics of Smalltalk

Christopher Oliver
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]>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Koans for Teaching the Basics of Smalltalk

Christopher Oliver
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]>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Koans for Teaching the Basics of Smalltalk

Eliot Miranda-2
In reply to this post by Christopher Oliver


On Tue, Dec 13, 2011 at 3:01 PM, Christopher Oliver <[hidden email]> wrote:
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?

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 <[hidden email]>




--
best,
Eliot



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Koans for Teaching the Basics of Smalltalk

Christopher Oliver
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]>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Koans for Teaching the Basics of Smalltalk

Andreas.Raab
In reply to this post by Eliot Miranda-2
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



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Koans for Teaching the Basics of Smalltalk

Bob Arning-2
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 <[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




    


Reply | Threaded
Open this post in threaded view
|

Broken user interrupt (was: Koans for Teaching the Basics of Smalltalk)

Bert Freudenberg
In reply to this post by Andreas.Raab

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 -




Reply | Threaded
Open this post in threaded view
|

Re: Broken user interrupt

Bert Freudenberg

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 -




Reply | Threaded
Open this post in threaded view
|

Re: Broken user interrupt

Bert Freudenberg
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?

- Bert -




Reply | Threaded
Open this post in threaded view
|

Re: Broken user interrupt

Christopher Oliver
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]>

Reply | Threaded
Open this post in threaded view
|

The broken user interrupt, or the saga of 100000 factorial.

Christopher Oliver
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]>

Reply | Threaded
Open this post in threaded view
|

Re: The broken user interrupt, or the saga of 100000 factorial.

LawsonEnglish
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?
>


Reply | Threaded
Open this post in threaded view
|

Re: The broken user interrupt, or the saga of 100000 factorial.

Casey Ransberger-2
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]>
>

Reply | Threaded
Open this post in threaded view
|

Re: The broken user interrupt, or the saga of 100000 factorial.

Bert Freudenberg
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 -



Reply | Threaded
Open this post in threaded view
|

Re: The broken user interrupt, or the saga of 100000 factorial.

Juan Vuletich-4
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



Reply | Threaded
Open this post in threaded view
|

Re: Broken user interrupt

Levente Uzonyi-2
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 -
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Broken user interrupt

Bert Freudenberg

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 -



123