[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: nicolas cellier
Subject: [Help-smalltalk] Re: How can we improve GNU Smalltalk
Date: Fri, 04 Jul 2008 20:46:56 +0200
User-agent: Thunderbird (X11/20080306)

Canol Gokel a écrit :


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]