[Help-smalltalk] Re: How can we improve GNU Smalltalk

[nicolas cellier]

Canol Gokel a écrit :

> Hello,
>
> Smalltalk is the most beautiful language I ever met. I started learning a few
> languages but Smalltalk is always the different one on my mind. After seeing the
> Smalltalk syntax I just can get it out of my mind and every other language,
> every other library looks ugly to me.
>
> I think, although it is one of the oldest languages the reason it didn't get
> acceptance widely is the need for a file-based approach, (like Python, Ruby or
> even C, Pascal) which currently only GNU Smalltalk provides. But, after trying
> to write a few programs with GNU Smalltalk, unfortunately, I decided that I
> should learn also another scripting language to do serious work and keep GNU
> Smalltalk just for experimental purposes, at least for now.
>
> I took notes about the problems I faced during my tryings with GNU Smalltalk and
> I will list the most crucial things below. I will also tell in which areas I can
> help. Here are they:
>
>  - Errors are very uninformative
>
> When compared with other languages' error reports, GNU Smalltalk's error reports
> are very uninformative. Actually, I for the first time, faced with a language
> that I cannot find out where the errors are. Most errors does not say in which
> line the error occured, leaving it to you to find out the error from other clues
> it gives. Also, I get similar error reports for different kind of errors.

It's a pity, because Smalltalk-80 was pioneering in debugging and 
correcting a live system, and other Smalltalk with a GUI still have 
unequalled debugging facilities (see Visualworks)...

Just use a little imagination to invent how to bring these fantastic 
tools on the command line...

We could imagine having an active Debugger.
we could simply trigger it with:
        [anObject doSomething] on: Error do: [:exc | Debugger activateOn: exc].

Then the active Debugger would preemt the command line and every 
following code would be executed in the context of debugged method.

To print a variable (inst var or temporary), simply type its name...
(This requires a Compiler able to evaluate in a Context)
        myVariable printNL.

To change a variable, as simple as:
        myVariable : 3.14.

Some information about the context:
        Debugger active printContextVariableNames.
        Debugger active printMethodSource.
        Debugger active printStack.

print only 10 messages, centred on current active method:
        Debugger active printStack: 10.

Controlling active method selection
        Debugger active upStack; downStack, topStack; bottomStack.

Controlling execution:
        Debugger active stepOver.
        Debugger active stepInto.
        Debugger active stepUntilMethodReturn.
        Debugger active continue.

To abandon execution and give command line back to main UI loop:
        Debugger terminateActive.

Of course, accepting new code would be possible.

gst has all needed to implement such a Debugger.
Certainly all this is very do-able and would be a nice project for a GSOC.
More over, the project could be implemented in several partial stages:
Only implement a passive debugger first with all context scanning facility.
Then add the execution control facility.

Nicolas