First Impressions of a running Self

Stefan Matthias Aust sma at 3plus4.de
Thu Feb 1 23:09:54 UTC 2001


Jecel,

At 20:17 29.01.01 -0200, Jecel Assumpcao Jr wrote:
> > [couldn't allocate more than 130 MB of memory]
>
>Very strange - my machine has just 64 MB. What do you mean by crash?

I got "out of memory" errors displayed in the self console.  I looked into 
"top" and noticed that only 130 MB were allocated, on a machine with 2 GB 
free memory.

>I don't think I've ever caused a display error in Squeak.

I get them regulary if I write new morphs - in morphic.

>How does it deal with it?

Squeak notices if there's an error when it tries to display a morph.  In 
that case, a special flag is set so that this display method isn't called 
again until somebody fixes the problem and manually resets that flag.  A 
flagged morph is displayed as a gray box with two crossing red lines.

>  The UI is indeed extremely fragil, as my trainees found out.

Too bad...


>When the machine was being shared by 20 students in the

20?!  I never thought that morphic would scale to that number of users?  Is 
it still responsive, especially if you move morphs?

Yesterday, I tried to use Self remotely over a 128/160 Kbps DSL line and I 
needed all of my patience to work with that system.  Actually, typing stuff 
in or moving the mouse was okay, but opening menus, dragging morphs or 
expanding outliners was a small pain.  I also tried to collaborate with 
another colleague (which of course diveded the available bandwidth by 2) 
and I wasn't barely able to open popup menus.  This was real pain.


>class I gave then it did freeze up for a while whenever someone called
>up a factory morph, but it also froze up in several other situations so
>I paid no attention.

But why does it freeze at all?

>The only other thing I run on my Sparc is Squeak (2.2!), so I have

You should definitely upgrade to version 2.9 :-)

>nothing to compare it with. There is a certain lag, but it was fast
>enough on much slower machines (Ultra I) that I was able to write a
>real time CAD program.

Cool.

>Yes. Here is a version of the BareBones snapshot that includes it:

Thanks, I'll try to download that.

>I have only tested the 16 bit and 8 bit modes.

I see.

>While I thought this would be awkward (you have to drag it around to
>point to the different objects, it easily gets buried underneath other
>stuff, etc) I have found it much nicer to use in practice than Squeak's
>handles.

Yes. And it shouldn't be that difficult to make it "always stay on top"

>No that is a bad idea. Smalltalk wouldn't have this either except that
>they were forced to do this due to the addressing limitations on 16 bit
>machines.

Well, if you've an external source file, you can share it with multiple 
images.  I don't like the idea that every image contains a perhaps slighty 
different version of the sources.

>With a proper object virtual memory, the sources can live on
>disk and be brought to memory as needed in a much more elegant way than
>Smalltalk's current manual solution.

Only if you have just one image.  With multiple snapshots, it makes sense 
to share as much as possible.  My 15+ Squeak images for example already 
need more than 1 GB on my harddisk.

>If Self had a universal undo, then a lot of things besided writing code
>would be nicer.

I gave that idea some thought but it seems to be quite difficult to 
implement such a thing like an universal undo feature.  Some programming 
support however is required or I cannot really do serious programming 
within Self.

>If the object that you wish to be the new value for the slot is on the
>screen, you can use the yellow button menu option "drag arrow" to get
>the object to point to it. If it is not visible, then typing the whole
>expression in the evaluator is your only option for now.

I don't like that.  I definitely do not want to keep the numbers 0..10 
handy on my screen to arrow-drag them to slots if needed.  The shell 
evaluator is also too clumsy because it forces me to always typein the slot 
name.

>There are several preferences objects that are supposed to tell the
>editors what to use. Try "preferences" in any evaluator.

That didn't work for me.


>They are updated in the "step" method by polling the object for its
>current values. The polling rate is kept low in order not to waste
>processor cycles.

However it's still too high.  I kept the system running over the weekend - 
we normally don't log out as we've nice SunRay stations with smartcards at 
our office - and it consumed more than 13 hours cpu time - too much for an 
idle system.

bye
Stefan Matthias Aust // Pilgrims, beware of the Dark between the Fading Suns




More information about the Self-interest mailing list