ports and morphs (was: Solaris 2.5 x86?)

[Jecel Assumpcao Jr <jecel@lsi.usp.br>]

Thierry Goubier wrote:
> On Mon, 3 Jun 1996, Jecel Assumpcao Jr wrote:
> > That's great! The more implementations there are of
> > the language, the stronger it is (as long as they can
> > run the same programs).
> 
> This is a hard question. Will the implementation runs the same programs ?
> I don't think so, unless those programs don't use certain features (like
> the UI, for example).

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?

> 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.

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). 

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.

> 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.

> By the way, what is the position of the Self group (or owners) about the
> reuse of the Self 4.0 source ? Not the VM source, but the Self one ? Can
> we use it to accelerate the development of others implementations ?

The license says you can do anything you want with the program
and doesn't make any distinction between the Self part and the
VM part. Of course, an answer from Sun's lawyers would be much
better than my opinion. I once contacted Jim Anderson of Digitalk
to ask about using just the Smalltalk part of Smalltalk V/286.
The license said I could do anything I wanted with it as long
as I didn't copy the V.EXE virtual machine (which was ok, as I
was writing my own anway). He asked for some time to think about
it (this was in 1988 and he still hasn't answered...). So even
they wouldn't be able to do a thing if I just grabbed the sources
part and reused it in my project, it would hardly be a nice
thing to do. The moral of the story is that it is always a best
to check of the program's authors really meant to be as liberal
as the wording on the license agreement seems to imply.

> 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?).

> And the compiler used is gcc...

Which will make ports to other machines much easier than
if the Sun compiler had been used, right?

> I think a Self 5.0 will be needed for a Linux port.

Or someone could port Self 2.0. It had much more modest
hardware requirements. Much less functionality as well,
of course!

-- Jecel