Selves:
Two things, with subparts.
1: Continuing problems getting a working copy of Self.
a: Many thanks to those who responded to my previous missive.
b: I re-FTP'ed (yes, I used binary mode -- I did previously as well)
the SPARC binary to a Sun4 runnung SunOS 4.0.3 (the same one I had used
before), and had the following interaction, after uncompressing and
chmod'ing +x:
{alps(snl):3} ./Self
Segmentation fault
{alps(snl):4} ls core
core
{alps(snl):5} dbx Self core
warning: cannot read pcb in core file: registers' values may be
wrong
^Cwarning: no symbols
Symbol reading interrupted - symbol reading abandoned
(dbx) quit
{alps(snl):6} ls -l Self
-rwxrwxrwx 1 snl edrc 735076 Nov 29 19:59 Self*
I imagine that dbx would not have yielded anything useful anyway (at one
time I was slightly adept at examining core images produced by Lucid
common lisp under dbx, but I have undergone psychoanalysis in the
interim).
c: Does the above size jibe with what other people have on their
SPARCs? If not, I would be willing to change my password for a short
period of time on this machine for the purpose of allowing some kind
soul to FTP me their working copy of Self for SPARC, since my two
attempts so far have produced nil. Alternatively, if anyone reading this
has /afs access and is willing to point me at a path I can access from
the CS.CMU.EDU cell, I would be most appreciative.
d: I would also like a working copy of the Sun3 image, but this is not
as important.
2: X11 Considerations
a: Preamble:
As kjx@comp.vuw.ac.nz (R James Noble) writes, having the objects and
their graphical analogues in the same world does indeed have some
advantages, the main one being that you can implement the graphical
aspects in the same environment as the non-graphical ones. This,
however, seems a separate issue to me than whether or not, at run time,
the graphical objects exist in the same "space" (world, whatever) as the
non-graphical ones. I could be talking about distributed Self here. I
could also not be.
b: Distributing the UI from the Application
In my experience, separating the user interface from the application has
been a big win. This has partially been due to the tools I have been
restricted to using for bulding my UI domain (Xt and its inbred
cousins), and partially due to other factors more specifically related
to the application{,s} {it,them}sel{f,ves}. Using the Unix process
abstraction (to glorify it so for the purposes of discussion) has been a
natural way of doing this. The approach I am taking to my UI server
environment at the moment (and the one I think I will stick with) is to
embed an interpreter in it that you can use to download, among other
things, intelligence about what the client of the UI server should be
told. This architecture begins to look more like hardware in some ways
than software, e.g. an intelligent controller that can have microcode
downloaded into it. Right now, my UI microcode is Scheme
(gjc@paradiogm.com's SIOD, which is very pretty). The main factor behind
this choice is that the penalty for providing this layer of
programmability should be as low as possible, both in terms of speed and
portability. Thus, my UI server can run on many machines that any given
application might not be able to run on, e.g. a specialised application
that takes advantage of the Ardent's graphics hardware could still have
a generic UI based on the UI server.
This is really one of the main points behind separating the UI from the
application -- Fortran analysis programs can use the UI server. Old C
programs can use it. C++ programs can use it. Etc. In the field of
engineering design, at any rate, we are stuck with such beasts, and will
be for some time to come. Providing useable, interoperable, modifyable
and shareable (in the groupware sense) user interfaces that somehow
encapsulate such systems, as well as systems based more naturally on
object-oriented paradigms, is a large part of our work.
c: Implementing the UI
Now, theoretically, I could just as easily use Self for my UI microcode.
If my applications were written in Self, this would be a great
advantage, depending on how I implement the connection between the UI
and the Application. This ranges on a continuum from some TCP-based (or
not -- Mach Virtual Memory and IPC primitives would provide a terrific
base for implementing this) distributed Self to a very simple protocol
for transmitting some small number of requests between running Selves in
a relatively transparent manner.
However, the main questions, from the point of developing the UI server,
are:
1: how (by whom/what) will it be used?
2: what (microcode) language best (most naturally) supports this use?
3: what (microcode) language best (most naturally) provides a basis
for building the UI server itself?
The answer to (1) has many dimensions, including:
1: contraints/expectations on the part of clients
2: shared use issues (use for groupware)
3: reliability
4: extensibility
If the answer to (3) is "Self", then it is a very simple matter to use
the UI environment in either a distributed or a non-distributed way from
Self applications, depending on the circumstances.
The answers to (2) and (3) may both be "Self" in the long term. This is
what I am trying to determine at the moment. Scheme works well, but is
not, as it stands, the most natural environment for this. Smalltalk
would be more natural (we had a rough implementation of the same idea in
GNU Smalltalk, but have not updated it in several months because my poor
officemate (the local Smalltalk guru) is momentarily swapped out). Self
seems to me more natural still, but there are all those contraints...
Comments are more than welcome.
Cheers,
{ Sean }
Mail: Sean Levy | EDRC | CMU | 5000 Forbes Ave | Pittsburgh, PA 15213
Campus: Hamburg Hall 2212, Ext. 2257 (+1 412 268 2257)
EMail: snl+@cs.cmu.edu | ...!harvard!cs.cmu.edu!snl