Re: ports and morphs (was: Solaris 2.5 x86?)

[Thierry Goubier <Thierry.Goubier@enst-bretagne.fr>]

On Mon, 3 Jun 1996, Jecel Assumpcao Jr wrote:
> If it doesn't run at least text-only programs (like most of
> the bechmarks) then it wouldn't make much sense calling it
> "Self", right?

Text-only programs should be OK. A goal would be, if we can't reuse the
Self 4.0 sources, to be able to reload part of the Self 4.0 sources to run
the benchmarks.

I don't want to spend a long time trying to recreate the Self 4.0 sources
just to run the benchmarks !

> > I'm not particularly found of morphs :-) 
> 
> I didn't like morphs initially either. They are rather "heavyweight"
> and not very modular. I was more used to OO graphic libraries with
> color wrapper objects, translation wrapper objects, rotation wrapper
> objects and so on. So what you saw on the screen was the result of
> a web of fine grained objects. Many of them were not visible by
> themselves, but I think a core sampler-like tool could easily
> handle this problem. You could set up the web do certain objects
> would be independent (in terms of position, color, rotation...)
> and others would be linked.

My opinion is that morphs lack the extensibility of UI architectures like
Garnet and Amulet (interactors, etc...) and don't provide a way of linking
the functionnal core of an application to the morphs.

The goal of fine-grained objects in interfaces (you describe a glyph-based
system) is to reuse as much functionality as possible and to ease
modifications. This decomposition is pushed forwards by peoples like the
authors of "Design Patterns...". I believe that Self has the power to ease
the use of those design patterns.

> I now think that this is the moral equivalent of a class based
> system. Everything is set up in advance and runtime reorganization
> is limited. Morphs do a better job of getting the "object based"
> style to the graphics library. Of course it could be a little
> better - the fact that paint is used as an object's color
> makes it hard to have textured objects (in general, that is). 

Well, I disagree with this. A glyph-based system (a system with light,
singleton objects on the interface) has nothing to do with classes, but
with a runtime organisation (the accent is on dynamic, instance based,
specialisation, a thing Self do extremely well). I'm not sure morphs are
more object-based; they're certainly heavier, however.

About paint, that's a lack of dynamicity in the current design :-) Not
really a problem, in fact.

> The problem is how to be able to change the color of these
> two objects together but not that third one. I have an idea
> that I call "slices", which is just an extension of the idea
> of "selections" used in window systems. I write more about
> that some other day.

I'll wait for it...

> > and the self world is really
> > slow to run, unless you allocate 20 MB to the code cache... There's also
> > some problems with the metaphor used. Is it the response time, or is it
> > the lack of scrollbars, but I think the display of large collections (or
> > arrays) in an outliner is particularly annoying.
> 
> I have no more problems dragging a tall object up and down to see
> it all than using a scroll bar. In fact, I prefer this to the
> scroll bars. It would be nicer if the object could be made smaller
> so I could it all at the same time. Both zooming (as in the PAD++
> interface) or 3D woud allow this.

I've tried to extract the list of primitives to send to J.C. Mincke from
the Self world. After many attempts, I've looked into the VM source
because I was unable to manage such a large collection.

I believe the PAD++ interface is a nice idea to be tried... Or a 3D
interface. As soon as I may be able to run a Self implementation on a PC,
I'll try thoses new, fast 3D libraries available (3DR, BRender, etc...).
I've already studied a few virtual reality metaphors like the one used in
EuroParc. Theses technologies are the right idea, in my opinion (I have no
ergonomic data for this, even if my attempt at hypermedia cartography
seems correct on this). But to find a metaphor usable in 3D may be hard.

> > Hum, to get a truly efficient Self 4.0, 64 MB isn't enough on a Sparc 20
> > biprocessor. Even if the x86 code is more compact that the Sparc one, I'd
> > bet 32 MB isn't enough under Linux (and Linux has response problems under
> > heavy swapping).
> 
> I have run Self 4 on a Sparc 10 with 48MB of RAM and *no* cache
> (don't ask me why the university buys such configurations). It
> runs very well, even if other people are using the machine at
> the same time! And the Voyager, the machine they like to
> demonstrate Self on, is a Sparc 2 class machine (if I remember
> correctly). I think there is something wrong with your setup
> (or your expectations?).

My problem is that we use Solaris on Sparc 10/20/5 workstations. 32MB
under solaris means 26MB usable; add Openwin on top of that... And the
minimum Self process is around 40 MB. What's more is that the stability of
Solaris (and memory leaks) oblige us to reboot frequently under heavy
usage. The only usable computer was the Sparc 20 with 64 MB, but I can't
use it any more now. All others workstations have 32 MB.

My expectations were more along the lines of VisualWorks 2.5 / Envy that
I'm using now to programm for my PhD. I'll downgrade my Self code to
Smalltalk within a few weeks, sadly.

Thierry.
___________________Thierry.Goubier@enst-bretagne.fr__________________
    Je ne suis pas un patriote car je n'ai pas peur de l'etranger
        I'm not a patriot because I don't fear foreigners
http://www-info.enst-bretagne.fr/~goubier/