Self-interest November 1990

self-interest@lists.selflanguage.org

16 participants
20 discussions

Continuing woes, X11, UIs
by Sean.Levy＠CS.CMU.EDU 30 Nov '90

30 Nov '90

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(a)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(a)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+(a)cs.cmu.edu | ...!harvard!cs.cmu.edu!snl

1 0

Please take me off your e-mail list
by adobe!cs.UAlberta.CA!sorenson＠labrea.stanford.edu 30 Nov '90

30 Nov '90

Hi self-interest... Could you please take me off your e-mail list. Currently, two of us are receiving messages: myself and naren(a)cs.UAlberta.ca. >From now on, please just sent messages to naren... Thank you... Paul Sorenson

1 0

Re: X & Self
by R James Noble 30 Nov '90

30 Nov '90

Some more random thoughts generally in response to recent messages by trot%reed.BITNET, Sean Levy and Craig Chambers. My current thinking is also that writing an Xlib in Self (using TCP, not linking in the C Xlib) is probably the way to go. There may be a bit more work, and a loss of speed, but a great gain in style :-). I don't like Xt and would hate it to become the defacto Self windowing toolkit. In a real OO language we should be able to do much better. I like Sean's idea of object-based interfaces but it seems better to have the objects in the same world - everything done in Self, in other words. This makes things easier when you need two-way communication, or when the graphics object needs to query the Self object world. The other advantage of a UI server would be display system independence. If we want to keep as much in Self as possible, we could define a Self Graphics & Interaction Model (SWIM, pun intended) which could then talk to X, SunView, XGL, (or even a UI server). This could be a standard specification to which interface objects would have to adhere, or we could have SGIM objects which would know how to talk to the individual graphics systems. Regarding X again, at the low level I suppose you could just have a connection object to handle the TCP stream, doing all the conversions (I'd put buffering here too), and each protocol request would just be a message to this object - rather than each object knowing how to send particular requests out the wire. So a window might respond to w lineFrom: 5@5 To: 10@10 GC: fooGC by sending connection drawLineDrawable: w GC: fooGC From: 5@5 To: 10@10 to the connection, rather than stuffing the bytes itself. (And I suppose with inline set appropriately, we wouldn't even take a performance hit). Regarding the namespace, ("x display clone" vs "display clone" vs "xdisplay clone"), we've got multiple inheritance so objects interested in X can inherit from an X namespace object. Thus, most objects using X can access it without prefixes, while not intruding much into the system namespace. I would make my window objects have their display & superwindow as slots, I built a minimal X toolkit and this seems a good idea, I'd probably add default GC's as well. (But this depends on how much of a "toolkit" the interface is to be). Finally, on another note, I am considering doing a bit of Self hacking (as Self has reached the top of my ToDo list, but I'd like a bit more practice before starting on X :-). I will probably try a set of Stream objects based upon the design of the Smalltalk classes, unless this seems a bad idea, or somebody already has some. kjx R James Noble, Graduate Student, Computer Science Department Victoria University, Box 600, Wellington 1, New Zealand kjx(a)comp.vuw.ac.nz 1. mail self-interest 2. receive 1000 mailer errors.

1 0

Re: Am I missing something?
by craig 29 Nov '90

29 Nov '90

Well, I just tried both the Sun-4 and the Sun-3 binaries on SunOS 4.1, and they worked fine. They were developed under SunOS 4.0.3, and so they should work fine on those OS's as well. Other people have been able to ftp the binaries and use the system. Have you tried ftp'ing the binaries again? You can certainly run Self when you're not on the console; I almost never run Self from the console of a machine. The only problem is that the UI and the _Spy monitor always put their output on the console, so if you're not on the console, then you won't see the output (and if someone else is on the console, they'll get these weird images on their screen). But in any case, Self should never crash just because you run the UI or the _Spy. Self should never crash no matter what you do to it [See Below for Comment]. As far as porting goes, there are no immediate plans for us to port Self to another machine. I've always wanted to port Self to a PMAX (Decstation 3100, MIPS RISC-based machine) so that I could feel good about having my compiler be reasonably retargettable, but have always had more pressing things to do. Other people have requested that we port Self to other machines, mostly 68k- based machines. I wouldn't be too hard to port Self to a machine that's 68K-based or SPARC-based, if the run-time conventions are similar to what's on a Sun (i.e. all UNIX boxes?), since the Self compiler wouldn't have to be changed. A Macintosh port has been attempted several times, and each time we've run up against problems in various Mac program development tools (such as the C++ compiler on the Mac not compiling some of our files, or the A/UX tools like the preprocessor not working). I think at last check we were able to get most of our code to compile using MPW C++, but since MacOS has a different run-time architecture than SunOS, there's still some work remaining to change the code generated by the Self compiler. In summary, we should do some ports to the more common machines. Perhaps some of these can be done by people other than us, for the machines which are very close to either the Sun-3 or the Sun-4. Previous messages have discussed whether people need the source released before it's cleaned up and documented, and if we do release source people can attempt their own ports to similar machines. It's a much harder task to port to a different machine, since the Self compiler would have to be retargetted; changing complex undocumented C++ code is not recommended for the faint at heart. As far as X primitives goes, once upon a time the UI was based on X/InterViews, and we had Self primitives that accessed X and InterViews operations. It wouldn't be too hard to add them back in. With a source release, it wouldn't be too hard for people to add their own primitives to the system; there's even a tool written in Self to help automate the process of generating the required Self and C++ stub routines to interface Self programs to C++ programs. There is the TCP primitive for low-level access to the X server, but I can understand the desire to have a higher-level interface to X than TCP links, especially if it's already implemented. The followup comment that adding Xlib primitives to Self would lead to memory management problems is partially true. However, we currently have a similar problem managing bitmaps using the existing Pixrect interface, since these bitmaps currently reside in the C heap, not the Self heap. So explicit memory management (calls to _PrClose) are required to manage space in the C heap. Similar calls would be required to manage Xlib resources, too, but this is no worse than in C (just not as good as in Self). -- Craig Chambers [Self Never Crashing Comment] This is not completely true. There are a couple of holes that a terribly malicious user could exploit to get Self to crash. Some of these are documented on pages I-2 and I-3 of the Self manual. Others are that certain Pixrect primitives don't fully check that their arguments are legal (such as using a bogus or freed pixrect handle or writing to arbitrary parts of bitmaps with clipping disabled) and so could crash the system inside a pixrect primitive. These problems shouldn't occur unless a programmer is working directly with Self primitives (not through the Self wrapper methods) and attempting to cause problems.

1 0

X & self
by trost%reed.BITNET＠Forsythe.stanford.edu 29 Nov '90

29 Nov '90

Folding Xlib into Self sounds like a not-too-clever idea --- all the sudden you'd have to worry about X memory allocation and all that silliness. Self already supports TCP communications, so writing a Self version of Xlib is probably simpler (and you'd rather write Self code anyway, right? :-) ). And no, I haven't started working on it yet -- one of my Things to Do :-). Though I suppose I ought to foist *my* views onto the world while I have the chance.... First, one probably wants to avoid putting the prototypical X display at the top level; i.e., things should be arranged so that "display" is not a parent of "x", so that you have to say "x display clone" instead of simply "display clone" -- this namespace division should prevent confusion with different window systems (like the Self builtin system). Windows should have their display (screen?) in one of their slots -- avoids passing the display all over the place. To create a window, you shouldn't have to clone a window -- you should send a message to the window's intended parent to create the window. Querying the display (or actually, a screen on the display) will give you the root window. Implementation should probably proceed in two layers -- "traits x" could have a slot named "primitive" which would contain the very basic protocol-conversion information. More sophistication (like buffering of requests) could then be implemented at the higher level. Just my ideas...any comments?

2 1

Am I missing something?
by Sean.Levy＠CS.CMU.EDU 29 Nov '90

29 Nov '90

Selves: I just FTP'ed both the Sun3 and Sun4 versions of Self, after having graciously been given an account to do so. Both images dump core immediately, under Mach and SunOS, on both architectures. The SunOS version on the Sun3 is 4.1, and 4.0.3 on the Sun4. The Mach versions probably won't mean anything to you, but it should be noted that I generally have little or no trouble running SunOS binaries under Mach, assuming that said binaries make no calls to libpixrect or other SunOS nonsense. I had been under the impression that I didn't _have_ to use the Sun GUI if I didn't want to -- is this indeed the case? I was trying to run Self in an xterm telnetted to the two SunOS machines, so obviously if Self was EXPECTING me to be on the console, it was sorely disappointed. The little blurb in the mail I got seemed to imply that I didn't HAVE to sit in front of the console unless I wanted to try the UI. On three other notes (a chord!): . Will Self be ported to PMAXen and other archtectures? We are VERY interested in using Self for development of a system for supporting engineering design and collaborative work, but one of our MAIN requirements on a language is that it work on EVERY reasonable archtecture (this count currently hovers around 7, depending on who you talk to). . I have developed a library of X11 widgets under Xt for use in Object Oriented User Interfaces, and was hoping VERY much to use said library from Self. Will this simply not be possible with only the binary? . Will sources ever be available? Of course, the answer to this last question is really the one I want, since if I have source I can port it myself. Appologizing in advance for the temerity of my questions, I am faithfully yours, { Sean } Mail: Sean Levy | EDRC | CMU | 5000 Forbes Ave | Pittsburgh, PA 15213 Campus: Hamburg Hall 2212, Ext. 2257 (+1 412 268 2257) EMail: snl+(a)cs.cmu.edu | ...!harvard!cs.cmu.edu!snl

1 0

Self source code whoami message
by R James Noble 28 Nov '90

28 Nov '90

You probably know all this but: I am James Noble, a doctoral student at Victoria University of Wellington. What I am most likely to do with Self is get it running on our faster HP 68K machines and do an X windows interface, plus any other random hacks, and perhaps use it in a thesis project. I would be very interested in your 50K lines of C++ code :-). Other than that, I agree with much of Roland's comments in his last message. james

1 0

Re: self
by Roland McGrath 25 Nov '90

25 Nov '90

> But, lately, several people have asked for the source and expressed a > willingness to cope with its "research software" condition. Releasing source is often a very good way to get a lot of work done for you. You have to deal with umpteen people using the system, some of whom will come up with truly inane things to bother you about. But in return you get just as many people to find (and often fix) bugs, make enhancements, and support the system throught their use of it. > I am compiling a list of folks who want the source code and would > be interested in adding you to it. Please tell me who you are, > what your organisation is (if any), what you want to do with it, > and how willing you would be to deal with 50,000 lines of > poorly documented C++ code. I am Roland McGrath. I work for the Free Software Foundation. My interest in Self is mostly curiosity. If and when I get the system, I will hack on it until it runs, figure out what the language is like, and start playing around. Having run up against the limitations of Smalltalk, been generally unimpressed with C++, and not wanting to spend the entire rest of my life using C and Lisp alone, I think Self sounds very interesting. The FSF per se doesn't have any interest in Self, though if it's free we might distribute it. The FSF is, however, very interested in as much software as possible becoming freely available. That is why we exist. Have you read the GNU Manifesto? I have no problem at all dealing with 50,000 lines of poorly documented C++ code. How much effort I will put into it is a function of available time (which I can make if I so desire), interest, and whim. I have at times been interested enough in some random hack to spend days or weeks doing it before moving on to the next neat thing that came to mind (or getting real work done). I can't guarantee that Self will generate such interest, but the little I've heard sounds very intriguing.

1 0

PS
by ungar 25 Nov '90

25 Nov '90

Roland(a)ai.mit.edu asks why we place restrictions on the use of the binaries we distribute. The answer is that we would feel exploited if someone were to turn around and sell them without cutting us in. Please let us know if you have specific plans that the restrictions curtail-- maybe we could work something out.` David

1 0

self
by Roland McGrath 24 Nov '90

24 Nov '90

Why do you not make the source to the SELF system available, and why do you place restrictions on the use of the binaries you distribute? Thanks, Roland We put in a lot of time to "clean up & document" the Self system as distributed. We have been reluctant to put in another chuck of time like that on the heels of the first effort, and this is what would be required to get the source code in shape. But, lately, several people have asked for the source and expressed a willingness to cope with its "research software" condition. However, the source code is for the current version of Self, which has more features (and is less stable) than the distributed version. We are seriously thinking about (i.e. this should happen but I don't want to promise yet) updating our docs and releasing the current system, AND making the source code available, too. I am compiling a list of folks who want the source code and would be interested in adding you to it. Please tell me who you are, what your organisation is (if any), what you want to do with it, and how willing you would be to deal with 50,000 lines of poorly documented C++ code. Thanks David

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest November 1990