On Tuesday 11 September 2001 10:12, Jonas Bosson wrote:

This snapshot was what really gave me inspiration to look at Self.

The Smalltalk-snapshot comes as "the example" in sunlabs "Self 4". Its for Sun machines only since there has been no porting of the original Self system to Linux or Windows.

There is now a PowerMac version of Self as well. But no Linux or Windows (sorry, Todd Nathan!) version.

(The GUI puts SmallTalk in the upper left corner of the virtual display)

The GUI has no support for other than 8-bit visuals and is gives you too little information on how to develop "serious" applications in the environment. The lack of loadable packages outside the "snapshot" is limiting. (I think it also requires direct access to X11 with shared memory for blit speed)

Things might have been improved since I saw it.

Self 4.1.x has support for true colors. I have often used it over remote X11 connections (and even over VNC) and it works fine. Sharing a single Self machine with 30 X terminals does make things unusable, though :-(

I didn't understand the part about "loadable packages". Dave Ungar's transporter can let you save and load text and binary "modules". And the access to external C++ libraries is very reasonable.

But the snap is a beauty and gives an experience that folks should have access to.

If somebody wants to try GNU Smalltalk loaded into the BareBones snapshot in Self 4.1.x (it is loaded in the regular Demo snapshot in 4.0), I am trying to upload this file to groups.yahoo so people don't have to put up with my slow DSL line but am having problems. Meanwhile, you can try:

http://www.merlintec.com/download/Smalltalk.snap

See also http://www.sun.com/research/self/release/smalltalk.html

I am not sure if the paper mentioned at the bottom of this page is Mario's "Self Includes: Smalltalk". If not. Cetus lists that paper as

http://linus.socs.uts.edu.au/~cotar/proto/mario.ps

I haven't checked either link. Reading this paper you will see that this is not a limited implementation of Smalltalk, but rather a slight adpatation of Self to be a *full* high performance implementation of GNU Smalltalk extended to include some traditional Smalltalk browsers (GNU ST is text only) using Morphic.

-- Jecel

On Friday 14 September 2001 13:14, Mario Wolczko wrote:

Don't use this address! The Sun Labs web site is now officially under research.sun.com, so the correct address should be http://research.sun.com/self/release/smalltalk.html. It appears that the address above takes you to an apparently identical page, but the link to the documentation does not work.

Thanks for the correction!

We have a real problem with changing web addresses for the main Self page. Here are the references I found via Google:

63 to self.smli.com 160 to self.sunlabs.com 294 to self.stanford.edu 313 to www.sun.com/research/self

It takes time for people to find out about new addresses. I have seen postings to discussion groups this year that give the self.stanford.edu reference.

Perhaps we should adopt this page as the official starting point for Self?

http://www.objenv.com/cetus/oo_self.html

Even Egroups has changed to YahooGroups lately, so the above seems the most stable entry point of all.

-- Jecel

On Monday 17 September 2001 10:42, Jonas Bosson wrote:

Jecel, you are probably right, its just that I had no concept on how to develop say, a web server, using versioning and packages as I would in my "regular" environment.

When I was using the university's computers with two trainees, we didn't have enough disk space to save snapshots. So we just saved our work as text modules and used RCS (or CVS if there was more than one module in a project) to keep track of versions. That allowed us to develop reasonably complex applications with only 10 to 100KB of disk.

Unfortunately, even though it is easy to add module annotations to objects and slots, it does tend to slow you down a bit. And you have to put more effort into morph initialization code than if you were saving "regular objects" and not just prototypes.

For more details, see http://research.sun.com/self/release/Self-4.0/Tutorial/Language/ImportantObj...

The Self desktop is just great but a bit cut off from the "normal" windowing and file "class" system approach. Though I can see the obvious reason for keeping the Self GUI in one desktop (nice drag and drop features!), I would like to have something more (don't we all) than just evalutation terminals and windowing so selfishly. ;-)

Sorry, I dont know, am I making sence here? I dont know if it has to do with beeing without classes or beeing without a structured overviews in a framework for code management.

The closest thing that Self has to Smalltalk's System Browser is opening an outliner for "globals". This is not as useful since there are several alternatives to putting things in globals so you won't find everything in there.

The idea, in Self, is that anything interesting manifests itself in some way on the screen. So you should be able to start by pointing to something interesting and then work your way from there to where you want to go. It doesn't always work out that way. I can understand how frustrating this style can be to some people - unstructured exploration always leaves you with the uncomfortable feeling that the solution was in some path that you overlooked.

But an ordered and extensive list of "everything in the system" will become less and less practical as systems get larger. We used to see everything there was on a floppy in the old days by listing its only directory. With hard disks we had to hide uninteresting stuff in subdirectories. With the web we had to give up a catalog-like view entirely and depend on hyperlinks and search engines instead.

Perhaps, if it is possible, could one create a filesystem (mounting) representing named instances in a running Self VM server so that editing files became interactive with the operatingsystem and all tools like emacs that so many of us like to use? (That would make Self a real competitor with Java, I guess.)

This is pretty much how we used Self between 1990 and 1995, except we used a regular external filesystem and had to reload edited files manually. And you can certainly use it like that today (it is just that we don't want to) and it even would be simple to add automatic reloading of edited files.

Java folks don't consider anything with a non C-like syntax to be competition.

-- Jecel