Array

(First of all, you may want to subscribe to
help-smalltalkgnu.org -- it 
is moderated for non-subscribers, so no spam).
> I've been reading the GNU smalltalk manual, but the
following I havn't
> been able to find on the web yet:
> - A GNU smalltalk compatible, functional program
You mean a program written with gst?  Unfortunately I don't
know of any 
:-(  Mike Anderson has some on his blog, but they're small.
> - A way of seperating smalltalk source over multiple
files
You write the source code in multiple files, and then
provide a loading 
script that loads them all (optionally saving everything to
an image 
file, see later).
> - A way of editing smalltalk files without the use of a
commercial IDE
GNU Smalltalk has an Emacs mode.
> - A way of running smalltalk probrams like other
programs (from the
> commandline) without the need of a wrapper script (The
normal
> '#!/usr/bin/env doesn't work, nor could i find ways
of creating
> bytecode/packages/binaries)
You can use (with GNU Smalltalk 2.2)

#! /usr/bin/env gst -f

or

#! /bin/sh
"exec" "gst" "-f"
"$0" "$"

GNU Smalltalk special cases the #! at the beginning of a
file as a 
one-line command.  Comments are quote-delimited in
Smalltalk, so the 
second line is eaten by GNU Smalltalk's parser in the
second example.

In addition, GNU Smalltalk can save a snapshot of its status
in an image 
(.im) file that can be made executable with chmod.  Making
something run 
automatically when the image file is reloaded is feasible. 
Just create 
a class-side method named #update: including some code like

update: aspect
    "Flush instances of the receiver when an image is
loaded."
    aspect == #returnFromSnapshot ifTrue: [ self restart ]!

and then evaluate code like

ObjectMemory
    addDependent: NameOfTheClassWithTheUpdateMethod;
    snapshot: 'myprogram.im'

Then, running gst with "gst -I myprogram.im" (or
just making 
myprogram.im executable) will invoke the #restart method on
the class 
NameOfTheClassWithTheUpdateMethod.

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

Sorry to be weighing in so late on this one. My brain works
slowly in
the summer heat...

Paolo Bonzini wrote:
>> I've been reading the GNU smalltalk manual, but
the following I havn't
>> been able to find on the web yet:
>> - A GNU smalltalk compatible, functional program
> 
> You mean a program written with gst?  Unfortunately I
don't know of any
> :-(  Mike Anderson has some on his blog, but they're
small.

What you will find is that one of the major problems
Smalltalk has as a
language is that the dialects are sufficiently dissimilar
that programs
are not very portable, so the only programs you will find
for GSt are
those that were written for GSt. There are projects that aim
to remedy
this, eg. Sport. Porting Sport to gst would be a very useful
project.

The other main problem, related to the above, is that the
Smalltalk Way
is image-based development, which unfortunately means that
the easiest
way to distribute programs is as images, not code.

At a personal level, the main problem I have is that the
packaging
system is a bit inflexible, so splitting out a package is
hard work.

>> - A way of editing smalltalk files without the use
of a commercial IDE

This sounds as if you're thinking about commercial
Smalltalks, like
Visual Works. Actually, most other Smalltalks don't use
files - you
develop within the IDE, and code at the method level. Where
the source
code is outside of the image, it is found in a repository
like Envy or
Store, ie. a database.

> GNU Smalltalk has an Emacs mode.

SciTE also has syntax-highlighting, if, like me, you never
really got to
grips with Emacs (if you're using Emacs, surely you must
prefer Lisp
over Smalltalk?).

Mike


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 7/5/06, Mike Anderson <gnu-smalltalkgingerbread.plus.com> wrote:
> What you will find is that one of the major problems
Smalltalk has as a
> language is that the dialects are sufficiently
dissimilar that programs
> are not very portable, so the only programs you will
find for GSt are
> those that were written for GSt. There are projects
that aim to remedy
> this, eg. Sport. Porting Sport to gst would be a very
useful project.
This is a problem, but with the growing number of
architectures and
operating systems, it is just as hard for any other language
(probably).


> The other main problem, related to the above, is that
the Smalltalk Way
> is image-based development, which unfortunately means
that the easiest
> way to distribute programs is as images, not code.
>
> At a personal level, the main problem I have is that
the packaging
> system is a bit inflexible, so splitting out a package
is hard work.
I have not found anything about packaging yet, however this
is the
kind of thing that will keep a language from ever getting
out (even
out of a computer  ).

>
> >> - A way of editing smalltalk files without the
use of a commercial IDE
>
> This sounds as if you're thinking about commercial
Smalltalks, like
> Visual Works. Actually, most other Smalltalks don't
use files - you
> develop within the IDE, and code at the method level.
Where the source
> code is outside of the image, it is found in a
repository like Envy or
> Store, ie. a database.
I'm sorry, but if Smalltalk can't even get out of my
computer, I might
just not bother to learn it at all. This does explain why I
can't find
any real-life implementations on the internet (like a simple
hello,
ls, find, sort or anything like that with install scripts,
documentations and comments).

Then I guess there arn't any standard commandline argument
parsing
libraries in the stdlib either, right?

Greets,
  Bram

PS If all this is really like I now think it is, I can
imagine why
this language never took off!


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk

> This is a problem, but with the growing number of
architectures and
> operating systems, it is just as hard for any other
language
> (probably).
It's a bit different, and actually worse.  It's like you
had ten 
different forks of Python, and somebody writes for one and
somebody for 
the others.
> I have not found anything about packaging yet, however
this is the
> kind of thing that will keep a language from ever
getting out (even
> out of a computer  ).
I don't think the packaging system is *too* inflexible. 
It's 
underdeveloped, true, and feature requests will only help.
>> >> - A way of editing smalltalk files without
the use of a commercial 
>> IDE
>>
>> This sounds as if you're thinking about commercial
Smalltalks, like
>> Visual Works. Actually, most other Smalltalks
don't use files - you
>> develop within the IDE, and code at the method
level. Where the source
>> code is outside of the image, it is found in a
repository like Envy or
>> Store, ie. a database.
> I'm sorry, but if Smalltalk can't even get out of my
computer, I might
> just not bother to learn it at all. This does explain
why I can't find
> any real-life implementations on the internet (like a
simple hello,
> ls, find, sort or anything like that with install
scripts,
> documentations and comments).
Mike is speaking about commercial Smalltalks.  GNU Smalltalk
is by 
design different.  You can write your code in files, with
SciTE or 
Emacs.  The next version, when it comes out, will almost
surely have a 
more compact and less arcane syntax for defining classes,
and so on.
> Then I guess there arn't any standard commandline
argument parsing
> libraries in the stdlib either, right?
If you want, I can write one in half an hour. :-P  Would
this syntax 
satisfy you (I'm getting the command line options from
autoconf)?

Smalltalk
    arguments: '-B|--prepend-include: -I|--include:
-t|--trace: 
-p|--preselect= -F|--freeze --help --version -v'
    do: [ :arg :option | (arg->option) printNl ].

The output could be something like

    'trace'->'AC_DEFUN'
    $v->nil
    'prepend-include'->'/usr/local/share'

if you invoked your script like

    gst -f script.st --trace=AC_DEFUN -v -B/usr/local/share
> PS If all this is really like I now think it is, I can
imagine why
> this language never took off!
Maybe that's because the language was born 20 years before
Python.  The 
problem is not the inflexibility of the language, is that
nobody 
implemented the features that people love in other languages
(due to 
lack of time, lack of funding, or sometimes even human
stupidity).

Paolo


_______________________________________________
help-smalltalk mailing list
help-smalltalkgnu.org

http://lists.gnu.org/mailman/listinfo/help-smalltalk