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