How can we improve GNU Smalltalk

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.

 - Documentation should be improved

I know that only very few people is currently working on GNU Smalltalk and
creating the language's core and writing an elegant documentation for it cannot
be done at the same time with this many people, also we can't expect a person to
be talented for every kind of task. But, at least every feature should be given
an example usage so that other people who does not know much about core but
eager to help this beautiful project may create a comprehensive and more
explanatory tutorial for GNU Smalltalk. For example, there is a Tk binding for
GNU Smalltalk which is a great feature. But I couldn't find any documentation
for it, didn't understand the long sample programs written using it and that's
why couldn't use it. Also trying to find out myself didn't give any good
results, either.

I can help with documentation.

 - Installer for different platforms should be present

There are many many many Windows or MacOS users out there, and for middle or
beginner level programmers an installer is a must. Especially on Windows it is a
pain to compile projects using GNU tools and most programmers simply won't do it.

I prepared a basic installer for GNU Smalltalk but because my knowledge is not
enough I don't exactly know which files should be included. Also, I couldn't
compile the extra packages except the Tk binding, Blox. I can prepare an
installer interface but somebody with more knowledge should help me compiling
and listing the files which should be included. For example, my GNU Smalltalk
program always crashes when an error occurs in my scripts and I suspect it is a
thing I do wrong while compiling the GST. If somebody compiles GST and its
packages and zip it to me I will gladly prepare an elegant installer for it.

These are the crucial things I noted and pushed me to learn another language. I
think most of them are soluble problems. After solving these problems we can
move on to do fun parts which is promoting the language with a more attractive
site, more tutorials, success stories etc...

Are there people who can say "I'm in for this, this and this"? Maybe the core
programmers also can list the difficulties they face and we can improve
ourselves to learn some of that concepts. Or they can list the things they
wanted from other users? Maybe more up-to-date sample programs? I will write a
tic-tac-toe game as soon as I learn how to write Blox programs, I promise :)



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Canol Gokel a écrit :

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



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> gst has all needed to implement such a Debugger.

That's the right way of thinking!

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

most of it is already there in DebugTools and examples/MiniDebugger.st.

> Then add the execution control facility.

Yeah, that would be the cool part.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk