From mikemac@teleport.com Tue, 31 Mar 1998 09:10:10 -0800 (PST) Date: Tue, 31 Mar 1998 09:10:10 -0800 (PST) From: Mike McDonald mikemac@teleport.com Subject: Make LispM code FREE (fwd) >From lispos-request@math.gatech.edu Tue Mar 31 06:13:26 1998 >Resent-Date: Tue, 31 Mar 1998 08:52:48 -0500 (EST) >X-Sender: joswig@194.64.21.10 >Mime-Version: 1.0 >Date: Tue, 31 Mar 1998 15:52:09 +0200 >To: lispos@math.gatech.edu (Lisp OS project) >From: Rainer Joswig >Subject: Re: Make LispM code FREE (fwd) >Resent-Message-ID: <"MfRDZ3.0.cz2.mKF8r"@math> >Resent-From: lispos@math.gatech.edu >X-Mailing-List: archive/latest/2177 >X-Loop: lispos@math.gatech.edu >Resent-Sender: lispos-request@math.gatech.edu > >At 15:31 Uhr +0200 31.03.1998, Fare Rideau wrote: > >>The MIT AI lab is already planning to make the MIT Lisp Machine system >>free--if they can find a copy of the sources. That may not be easy. >>I don't have a copy myself. >> >>I will forward your message to them. >> >>----- End of forwarded message from Richard Stallman ----- > >Hmm, isn't the Lisp Machine source really ancient? >Before 1980? Before Common Lisp? Written for >special hardware? Based on MacLisp (-> Lisp Machine Lisp)? > >What would you do with it? > >Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041 >Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202, >Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/ > > Play and learn! Mike McDonald mikemac@mikemac.com From moribund@netgsi.com Tue, 31 Mar 1998 12:34:56 -0500 Date: Tue, 31 Mar 1998 12:34:56 -0500 From: Damond Walker moribund@netgsi.com Subject: Make LispM code FREE (fwd) -----Original Message----- From: Dave Mason To: Lisp OS project Date: Tuesday, March 31, 1998 9:48 AM Subject: Re: Make LispM code FREE (fwd) >Rainer Joswig writes: >> Hmm, isn't the Lisp Machine source really ancient? >> Before 1980? Before Common Lisp? Written for >> special hardware? Based on MacLisp (-> Lisp Machine Lisp)? >> >> What would you do with it? > >Study it? Extract snippets of code worth manually translating to >Scheme or CL? Both seem useful to me. > Yeah, why create from scratch when there is a load of code out there waiting to be pulled in or learned from.....? Anyone have any experience with CLX under Allegro CL? Got it working last night mostly (hell, it seems to work anyway) -- would it be a *bad* thing to base some GUI stuff on CLX? Damond From strandh@cs.utexas.edu Tue, 31 Mar 1998 11:48:39 -0600 Date: Tue, 31 Mar 1998 11:48:39 -0600 From: strandh@cs.utexas.edu strandh@cs.utexas.edu Subject: Misc ideas & comments > > 1. I tried RScheme, but it seemed to me too complicated, at > > first in a first glance. After compiling everything, the whole tree > > ocupied about 70MB of disk space. I had some difficulty to find the > > main executable in the dense tree structure. I had to use "find > > . -perm 111 -type f" to find it! But of course, this is my ignorance > > speaking... The bottom line is that RScheme might be too complex to > > allow a fairly good degree of exploration. And by the way, does > > RScheme uses a virtual machine? RScheme is not very complicated in my opinion. But there are still many places in which the documentation is not very explicit. RScheme does use a virtual machine. > This is my impression as well. I looked into the RScheme sources > because I was looking for a Scheme system to which I could add a nice > MOP based object system. In RScheme this is somewhat tedious to do > because you have to update the Scheme code and quite a lot of > hand-written C as well. I am not sure what you mean here. RScheme already has an object system. Why was it necessary to update C code to add an object system? Would it have been easier in some other system? > Furthermore my (admittedly not very thorough) > experiments with RScheme 0.7.1 indicated that performance was not too > hot, even for compiled code. True, but we are working on improving performance. The emphasis so far has been on clarity and simplicity. We think we can combine the two, however. > (RScheme can compile to C via the rsc > module compiler, however you have to `make rsc' in the "src" directory > to generate rsc, We are working to simplify this procedure. > furthermore linking modules compiled with rsc v0.7.2 > to the main executable fails on my Linux/glibc system. This should be reported as a bug. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh@cs.utexas.edu Tue, 31 Mar 1998 12:10:38 -0600 Date: Tue, 31 Mar 1998 12:10:38 -0600 From: strandh@cs.utexas.edu strandh@cs.utexas.edu Subject: Misc ideas & comments > 1) As far as I can see there is no simple way to generate tail > calls in the front end. Gcc does some tail call elimination in the > back end, but not enough to be satisfying for a Scheme compiler (as far > as I can figure out it only optimizes self-tail-calls). I discussed this with RMS and here is what we came up with. He would be willing to include modifications to GCC in order to support it as target for Scheme. Essentially, GCC would support declaring a function to have a different calling convention. All calls to the function as well as the function itself must see the declaration. For the modified calling convention, I can see two possibilities. 1. (the one I prefer, but RMS thinks is too complicated, I think the other one is complicated as well) The calling convention for Scheme compatible functions would be completely altered so that the arguments are allocated in the callee's stack frame the difference between sp and fp would determine argument count. 2. (the one RMS prefers) An additional invisible argument is supplied indicating the argument count (must be the first argument) and the calling convention is altered so that the caller does not remove the arguments after the call is completed. Tail calling involves tricky manipulation of the stack frame such as growing or shrinking the area used for arguments. > 2) The implementation of the stack handling needed to have efficient > first class continuations seems very difficult to integrate with the > gcc back end. The possibilities that I see right now are a > setjmp/longjmp based stack copying approach, suitable only to use > continuations for error handling; or managing your own runtime stack, > which would somewhat defeat the aim of using the gcc back end. The > cleanest approach would probably be to define some additional tree > codes with corresponding implementation in the gcc back end. However > this would be a largish undertaking, and since I'm no proficient > C-hacker I don't think that I can handle this without a lot of support > from people more familiar with both C and the gcc back end. How about using a stack cache and migrating the stack frames to the heap whenever the cache overflows. You get the advantage of using the normal stack convention of GCC but call/cc only involves flushing the cache. > 3) Would it be possible to compile Scheme function calls to be > compatible with C calls so that it would be easy to interface to C? You can either modify GCC or use the following trick that I used successfully: Add two more parameters to a Scheme compatible function, the argument count and the stack offset (which is the amount that the caller will add to sp after the call). Tail calls pass a new argument count but the same stack offset. A return first deallocates the stack frame and then subtracts the stack offset from sp so as to compensate for what the caller will do after the return. It is stupid, but works. > I > think that calling C from Scheme would not be a problem, Right, you just tell the Scheme compiler to generate C compatible code. > but that it > would be necessary to create stubs for Scheme functions that can be > called from C because you cannot simply stack-allocate all parameters > to a Scheme function. I don't see why you could not simply stack allocate all parameters to a Scheme function. > I will investigate these points some more and then ask the people on > the egcs mailing list whether I am on the right track and whether they > would be willing to help with such an undertaking, however I am a bit > sceptical. Answering my (undoubtedly many) question about the gcc > back end would mean spending a lot of their time to help with a scheme > front end to gcc and I suppose they are more interested in improving C > and Fortran, since these are the languages they actually use > themselves. Furthermore I am not really certain whether I want to > spend that many hours writing a compiler that nobody will be > interested in anyway. I'll keep you updated about the results of my > inquiry and my future plans if you are interested. Adding tail calls to GCC according to one of the two possibilities above seems to be the best solution which could be used for Guile as well as for any other Scheme or Lisp system. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From mikemac@teleport.com Tue, 31 Mar 1998 10:22:14 -0800 (PST) Date: Tue, 31 Mar 1998 10:22:14 -0800 (PST) From: Mike McDonald mikemac@teleport.com Subject: Make LispM code FREE (fwd) >From lispos-request@math.gatech.edu Tue Mar 31 10:14:57 1998 >Resent-Date: Tue, 31 Mar 1998 12:51:01 -0500 (EST) >From: "Damond Walker" >To: "Lisp OS project" >Subject: Re: Make LispM code FREE (fwd) >Date: Tue, 31 Mar 1998 12:34:56 -0500 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >Resent-Message-ID: <"bLKh02.0.JP4.5qI8r"@math> >Resent-From: lispos@math.gatech.edu >X-Mailing-List: archive/latest/2183 >X-Loop: lispos@math.gatech.edu >Resent-Sender: lispos-request@math.gatech.edu > > >-----Original Message----- >From: Dave Mason >To: Lisp OS project >Date: Tuesday, March 31, 1998 9:48 AM >Subject: Re: Make LispM code FREE (fwd) > > >>Rainer Joswig writes: >>> Hmm, isn't the Lisp Machine source really ancient? >>> Before 1980? Before Common Lisp? Written for >>> special hardware? Based on MacLisp (-> Lisp Machine Lisp)? >>> >>> What would you do with it? >> >>Study it? Extract snippets of code worth manually translating to >>Scheme or CL? Both seem useful to me. >> > > > Yeah, why create from scratch when there is a load of code out there >waiting to be pulled in or learned from.....? > Anyone have any experience with CLX under Allegro CL? Got it working >last night mostly (hell, it seems to work anyway) -- would it be a *bad* >thing to base some GUI stuff on CLX? > > Damond > That's what my implementation of CLIM is using for the port portion. Mike McDonald mikemac@mikemac.com From dahlman@cs.colostate.edu Tue, 31 Mar 1998 12:08:00 -0700 (MST) Date: Tue, 31 Mar 1998 12:08:00 -0700 (MST) From: eric dahlman dahlman@cs.colostate.edu Subject: Make LispM code FREE (fwd) Gavin E. Gleason writes: [Snipped lots of stuff] > > It seems to me in a world of GUI, that one of the best things > that could further the LispOS ideals would be to develop a free CLIM. > This would alow us to start developing applications that people would > actually use. A CL Emacs writen with a CLIM interface for instance > (Idea shamelessly borrowed off of #:Erik Naggum), would be far more > usefull and flexible then XEmacs, and with a elisp compatibility > package could server to produce a "real" development environment for > CL. > So how come there is so little interest in free CLIM??? This is one of the things that I think would be very important for everyone involved with Lisp and this project. Actually after there was a free CLIM we would already have taken a major step toward a lispOS as far as the user is concerned. For instance all of the talk about making a lisp shell would then be rendered moot for all intents and purposes, just use a dynamic listener. There have been a few people mentioning that they are implementing their own version of CLIM what is the status of these projects? Has someone finished a Silica clone? Started one? Just wondering, -Eric From kragen@pobox.com Tue, 31 Mar 1998 14:14:44 -0500 (EST) Date: Tue, 31 Mar 1998 14:14:44 -0500 (EST) From: Kragen kragen@pobox.com Subject: Make LispM code FREE (fwd) On Tue, 31 Mar 1998, Gavin E. Gleason wrote: > So how come there is so little interest in free CLIM??? Perhaps because the people who could benefit most from it don't know what it is. What is it? Kragen From ptw@pobox.com Tue, 31 Mar 1998 14:29:32 -0500 Date: Tue, 31 Mar 1998 14:29:32 -0500 From: P. T. Withington ptw@pobox.com Subject: Misc ideas & comments On 3/28/98 06:57, Paul Prescod wrote: >P. T. Withington wrote: >> >> And, no LispM was ever infected by the Internet Worm. The day of the >> worm the SMTP logs showed some invalid transactions that were ignored. >> Nothing more. > >Well, the worm was specifically targeted at a *unix* bug. It wouldn't >bother a Lisp Machine, but it wouldn't have bothered a DOS machine >either. That doesn't prove anything interesting! On 3/28/98 08:04, Chris Bitmead wrote: >In a way, that's nothing to be proud of. The internet worm was >designed to exploit weaknesses in the most popular machine >architectures. The fact that the Lispm wasn't one of them is more >an indication that it wasn't popular enough to be bothered >hacking. It proves that it is a good idea not to "bet the farm" on a single strain of a particular crop. Think Irish potato famine. Think heirloom seeds. Think about how the big US seed companies would like to get their hands on primitive seed stocks from third world companies, because they have bred too many useful things right out of the seed stocks they own. Think different. From mikemac@teleport.com Tue, 31 Mar 1998 11:43:38 -0800 (PST) Date: Tue, 31 Mar 1998 11:43:38 -0800 (PST) From: Mike McDonald mikemac@teleport.com Subject: Make LispM code FREE (fwd) >From lispos-request@math.gatech.edu Tue Mar 31 11:38:40 1998 >Resent-Date: Tue, 31 Mar 1998 14:14:52 -0500 (EST) >Date: Tue, 31 Mar 1998 14:14:44 -0500 (EST) >To: "Gavin E. Gleason" >cc: lispos@math.gatech.edu >Subject: Re: Make LispM code FREE (fwd) >MIME-Version: 1.0 >From: kragen@pobox.com (Kragen) >Resent-Message-ID: <"aXnY33.0.RP5.h2K8r"@math> >Resent-From: lispos@math.gatech.edu >X-Mailing-List: archive/latest/2188 >X-Loop: lispos@math.gatech.edu >Resent-Sender: lispos-request@math.gatech.edu > >On Tue, 31 Mar 1998, Gavin E. Gleason wrote: >> So how come there is so little interest in free CLIM??? > >Perhaps because the people who could benefit most from it don't know >what it is. > >What is it? > >Kragen > The spec is at ftp://ftp.digitool.com/pub/mcl/contrib/clim/papers/ and Harlequin has a user's guid on-line at their site: http://www.harlequin.com/education/books/CLIM-2.0/ Mike McDonald mikemac@mikemac.com From joswig@lavielle.com Tue, 31 Mar 1998 21:58:04 +0200 Date: Tue, 31 Mar 1998 21:58:04 +0200 From: Rainer Joswig joswig@lavielle.com Subject: Make LispM code FREE (fwd) At 12:36 31.03.98 +0200, Gavin E. Gleason wrote: >Damond Walker writes: > > waiting to be pulled in or learned from.....? > > Anyone have any experience with CLX under Allegro CL? Got it working > > last night mostly (hell, it seems to work anyway) -- would it be a *bad* > > thing to base some GUI stuff on CLX? Not at all. CLX is low level. For something useful you will have to built on top of CLX something like CLIM. CLIM is portable and CLIM above Motif already exists. >I don't seem to have as big a problem with X as some of the people on >this list. Whether it is reasonable or not - it is there and cannot be ignored. >I've >heard rumors of CLIM being released for free by Franz. If this is >true, CLIM would be much preferable as a substrate, as it is in wider >use, and is based on CLOS instead of a seperate object system like >garnet. Atleast Franz will release a binary version of CLIM for Linux/PC. > > It seems to me in a world of GUI, that one of the best things >that could further the LispOS ideals would be to develop a free CLIM. Yes. And until this will happen, start with one of the existing CLIM implementations (free or not) and write applications. >This would alow us to start developing applications that people would >actually use. A CL Emacs writen with a CLIM interface for instance >(Idea shamelessly borrowed off of #:Erik Naggum), would be far more >usefull and flexible then XEmacs, and with a elisp compatibility >package could server to produce a "real" development environment for >CL. Yes. > So how come there is so little interest in free CLIM??? There is interest, but it is not an easy task. What I expect will happen, once CLIM 2 is really widely available (Win, Macs, X, Genera, Linux, ...), is that CLIM can't be ignored. So there is the chance for a portable free CLIM desktop environment. - based on CL + CLIM - abstracts from the machine - integrates a portable CLIM Emacs - extensible by CLIM components - extensive drag and drop support - maximum use of context sensitive menus - linkable views (for example every result of a lisp listener will be displayed in an inspector) - linked data items - Application Central -- menus: Desktop, File, Edit, Applications, Preferences, Windows, Help -- may have a desktop -- may have a command line -- may have a mouse documentation line - CLIM Emacs -- integrates Editor, Shell, Mail, News, Telnet -- uses CLIM infrastructure as much as possible - File Browser -- browse directories, rename files, create files, delete files, edit files, change properties, find files, open files, move and copy files - Lisp Listener -- presentation-based -- unlimited output history -- supports both Lisp forms and commands - Notice/Warnings browser -- every tool generates objects in case of warnings/errors -- central browsing place for all warnings/errors -- selective display based on tool/time/severity/... - Notes -- notes entered will be stored immediately -- full text search -- links to names, calendar items, files, ... - Inspector -- can inspect every Lisp object -- provides special views for common object types - Calendar -- schedules machine and personal tasks -- links into names, notes, files, ... - Debugger -- displays stack and stack frames - Restarts -- in case of an error enables the selection of a restart - Apropos -- search through the various namespaces (variables, functions, packages, modules, applications, ...) - Names and Addresses, Directory Services -- deals with companies, groups, persons, addresses, phones, printers, networks, sites, ... -- links to calendar items, notes, files, ... - Preferences -- User preferences in one central place for all tools -- extensible - GUI designer - multimedia designer -- port of SK8 to CLIM - Peek -- browse various envioment data: Processes, Windows, Network, machine data, GC, ... - Class Browser -- textual views, graphs, search - Function Browser -- browse functions, methods, generic functions, view documentation, locate source -- remove functions - Package Browser -- gives overviews over packages, external and internal functionality -- documentation overviews - Graphics Editor -- vector graphics - Bitmap Editor -- ala GIMP - System Tool -- browse and edit system informations -- view plans -- execute plans -- maintain versions - Talk -- IRC, Converse, etc. - Web Browser -- also used for the internal documentation generated by CL-HTTP ...more... From mikemac@teleport.com Tue, 31 Mar 1998 11:59:07 -0800 (PST) Date: Tue, 31 Mar 1998 11:59:07 -0800 (PST) From: Mike McDonald mikemac@teleport.com Subject: Make LispM code FREE (fwd) > > So how come there is so little interest in free CLIM??? Because most people don't know what they're missing! > >This is one of the things that I think would be very important for >everyone involved with Lisp and this project. Actually after there >was a free CLIM we would already have taken a major step toward a >lispOS as far as the user is concerned. For instance all of the talk >about making a lisp shell would then be rendered moot for all intents >and purposes, just use a dynamic listener. Most definitely! > There have been a few >people mentioning that they are implementing their own version of >CLIM what is the status of these projects? Has someone finished a >Silica clone? Started one? > >Just wondering, >-Eric > Well, the CLIM spec doesn't require Silica and since I couldn't find any docs on it, I'm not implementing one. I'm implementing what's in the spec. As for status, it's coming along once again. (I was diverted for a few months by a pretty young lady!) I have the basic panes (composite-pane, vbox, hbox, ...) implemented and with frames, frame managers, ports, grafts, mediums, sheets, events, and regions. I haven't implemented graphics (next), command tables, or presentation types yet. I'm hoping to have enough done in a couple of weeks for release 0.1 of it. (Better make that 0.0001!) Presentations and widget will probably be left for last. My goal is to be able to get a simple listener up so people can start writing commands. If you think you might be interested in helping test it, I suggest you get a hold of the spec and start reading it, particularly the parts on presentation types and commands. Then people can start writing all of those useful commands like :Show Directory! And :Show File! And :Load System! And ... Mike McDonald mikemac@mikemac.com From tc@gauss.muc.de 31 Mar 1998 22:19:23 +0200 Date: 31 Mar 1998 22:19:23 +0200 From: Matthias Hoelzl tc tc@gauss.muc.de Subject: Misc ideas & comments strandh@cs.utexas.edu writes: > > This is my impression as well. I looked into the RScheme sources > > because I was looking for a Scheme system to which I could add a nice > > MOP based object system. In RScheme this is somewhat tedious to do > > because you have to update the Scheme code and quite a lot of > > hand-written C as well. > > I am not sure what you mean here. RScheme already has an object > system. Why was it necessary to update C code to add an object > system? Would it have been easier in some other system? Well, my primary interest is not in the object system per se, but rather in meta object protocols and aspect oriented programming. I don't have the RScheme source code available right now, but if I remember correctly most of the generic function invocation protocol is in hand-coded C. This is of course a perfectly valid decisions for building a Scheme system that offers reasonable performance without doing global optimizations. One Scheme compiler that is IMHO somewhat easier to modify in this regard is the bigloo compiler, but since I am currently trying to find out how exactly the MOP/Aspect system should look like, I have switched to a (mostly) portable solution based on tiny-clos for the moment. > > furthermore linking modules compiled with rsc v0.7.2 > > to the main executable fails on my Linux/glibc system. > > This should be reported as a bug. True. I'll try it again and send you the error messages. Matthias From dahlman@cs.colostate.edu Tue, 31 Mar 1998 13:36:55 -0700 (MST) Date: Tue, 31 Mar 1998 13:36:55 -0700 (MST) From: eric dahlman dahlman@cs.colostate.edu Subject: Make LispM code FREE (fwd) Mike McDonald writes: > > > So how come there is so little interest in free CLIM??? > > Because most people don't know what they're missing! > > Well, the CLIM spec doesn't require Silica and since I couldn't find > any docs on it, I'm not implementing one. I'm implementing what's in > the spec. As for status, it's coming along once again. (I was diverted > for a few months by a pretty young lady!) I have the basic panes > (composite-pane, vbox, hbox, ...) implemented and with frames, frame > managers, ports, grafts, mediums, sheets, events, and regions. I > haven't implemented graphics (next), command tables, or presentation > types yet. I'm hoping to have enough done in a couple of weeks for > release 0.1 of it. (Better make that 0.0001!) Presentations and widget > will probably be left for last. My goal is to be able to get a simple > listener up so people can start writing commands. As far as I can tell the sheet protocols and the different issues involving grafts and the such fall under Silica. I have the paper on Silica by Rao and my impression was that these protocols in the CLIM spec were Silica. I could be wrong it wouldn't be a first. The benefit is that if this portion of the system is well isolated it would be possible to take the CLIM implementation for say CLX and remove the CLX dependencies and use it to implement a version for say Windows. Then code written for one system would also work seamlessly on another. And as far as the Lisp OS effort is concerned we would have a better chance for involving outside efforts in the effort. I for one have not made up my mind as to whether I could sell everyone on having a Lisp OS computer on their desk. However, if I could do all my development on a LispM and then ship the resulting ap "Lobotomized for Windows End Users(TM)" I would be a happy camper. > > If you think you might be interested in helping test it, I suggest > you get a hold of the spec and start reading it, particularly the > parts on presentation types and commands. Then people can start > writing all of those useful commands like :Show Directory! And :Show > File! And :Load System! And ... When you have something running let me know and I'll have a look at it. I would be very willing to put some time towards these parts of the system. I may be a bit naive about this whole thing but looking at the CLIM spec there seem to be several large orthogonal protocols that could be implemented by different people in relative isolation once the system's basic framework is in place. It would be really nice if everyone could have the experience of working with a Dynamic Listener like on the Symbolics machines since this would make a lot of these issues clearer. The system you are describing with presentation types and command tables would more than satisfy the shell crowd. And it would work fine on a textual basis. One possible glimpse of kind of what we are talking about is the "presenting listener" that Franz is including with the latest Emacs Lisp interface beta. It is still buggy for me under Xemacs 20.4 Solaris but it does have the ability to "present" objects to an emacs buffer and later "accept" them back. > > Mike McDonald > mikemac@mikemac.com > From mikemac@teleport.com Tue, 31 Mar 1998 12:44:47 -0800 (PST) Date: Tue, 31 Mar 1998 12:44:47 -0800 (PST) From: Mike McDonald mikemac@teleport.com Subject: Make LispM code FREE (fwd) >Date: Tue, 31 Mar 1998 21:58:04 +0200 >To: lispos@math.gatech.edu >From: Rainer Joswig >Subject: Re: Make LispM code FREE (fwd) > >At 12:36 31.03.98 +0200, Gavin E. Gleason wrote: >>Damond Walker writes: > >> > waiting to be pulled in or learned from.....? >> > Anyone have any experience with CLX under Allegro CL? Got it working >> > last night mostly (hell, it seems to work anyway) -- would it be a *bad* >> > thing to base some GUI stuff on CLX? > >Not at all. > >CLX is low level. For something useful you will have to >built on top of CLX something like CLIM. CLIM >is portable and CLIM above Motif already exists. CLIM is only portable IF your comercial lisp vender deams to provide it for your platform. And if you can afford it. With Franz preparing to release their version for Linux, that should help alot. > >> >> It seems to me in a world of GUI, that one of the best things >>that could further the LispOS ideals would be to develop a free CLIM. > >Yes. And until this will happen, start with one of the existing >CLIM implementations (free or not) and write applications. > >>This would alow us to start developing applications that people would >>actually use. A CL Emacs writen with a CLIM interface for instance >>(Idea shamelessly borrowed off of #:Erik Naggum), would be far more >>usefull and flexible then XEmacs, and with a elisp compatibility >>package could server to produce a "real" development environment for >>CL. > >Yes. > Why? I'm serious. Why would you want to implement Emacs using CLIM? I hope you're not thinking of presenting each character/word. I can understand implementing a web browser using CLIM but not Emacs. Please enlighten me! >> So how come there is so little interest in free CLIM??? > >There is interest, but it is not an easy task. That's an understatement! The spec is 364 pages long and leaves a LOT to the imagination. Luckily, some of the authors are on the net and have been gracious enough to explain the meaning/thinking process about various points. >So there is the chance for a portable free CLIM desktop environment. > >- based on CL + CLIM >- abstracts from the machine >- integrates a portable CLIM Emacs >- extensible by CLIM components >- extensive drag and drop support >- maximum use of context sensitive menus >- linkable views (for example every result of > a lisp listener will be displayed in an inspector) >- linked data items > >- Application Central >-- menus: Desktop, File, Edit, Applications, Preferences, Windows, Help >-- may have a desktop >-- may have a command line >-- may have a mouse documentation line > >- CLIM Emacs >-- integrates Editor, Shell, Mail, News, Telnet Ouhh! Yuck! That seems like Unix thinking again. Let them be separate apps that can communicate easily with each other. We don't have to go the kitchen sink route again! (Things like one common, global kill ring help to integrate separate apps.) > >- File Browser >-- browse directories, rename files, create files, delete files, > edit files, change properties, find files, open files, > move and copy files > On my Symbolics, I found that once the Lisp Listener had presentation types, I hardly ever used the File Editor. (Except to find out how many free records were left.) It was easier to just do a :Show Directory in the listener. >- Lisp Listener >-- presentation-based >-- unlimited output history >-- supports both Lisp forms and commands Definitely! >- Inspector >-- can inspect every Lisp object >-- provides special views for common object types Once again, once you have presentation types in the lisp listener, a windowed inspector becomes redundant. Just middle click on any lisp object and it gets described. Right click on one of the slots and get the chance to modify it. Left click on any other object on the screen to use that for the new value. Life's good! >- Apropos >-- search through the various namespaces (variables, functions, packages, > modules, applications, ...) Hmm, I always found (apropos 'foo) to work just fine. >- Class Browser >- Function Browser >- Package Browser All can be done in the lisp listener with presentation types. > >- Web Browser >-- also used for the internal documentation generated by CL-HTTP > >...more... That'd be a good start though! Mike McDonald mikemac@mikemac.com From kragen@pobox.com Tue, 31 Mar 1998 16:08:18 -0500 (EST) Date: Tue, 31 Mar 1998 16:08:18 -0500 (EST) From: Kragen kragen@pobox.com Subject: LISPOS: My manifesto On Sat, 28 Mar 1998, cosc19z5@bayou.uh.edu wrote: > For instance: > select * from f where condition > > Can be modeled in Common Lisp by: > (select '* :from f :where #'(lambda (x) (condition ...))) > > This construct is both familiar to users to Common Lisp, but also > close enough syntactically to the SQL version to be familiar to SQL > users as well. > > On a side note, use of the lambda in the :where adds > some serious power (you now have the ability to format your tables > and perform other side effecting as well as comparison operations > all within the :where, and essentially for free from an > implementation perspective). If it's a traditional Scheme lambda, it's opaque to the select function. This means that it is impossible to use indices. That is, (select '(name) :from users :where (lambda (x) (= (acctnum x) 44833))) can't use the primary-key index on users by acctnum, it has to look at every record and call the lambda function on it. This means that what was originally a simple hash-table lookup and fetch, or possibly a b-tree lookup and fetch, becomes a process that requires fetching something like 50,000 records from disk and calling a couple of Scheme functions for each one of them. This does not meet my definition of `essentially for free'. However, I believe that you might reasonably be able to do it with slightly different syntax. (select '(name) :from users :where '(acctnum = 44833)) This is also more readable to SQL folks. > (in this case lambda expressions give "where" tremendous > flexibility and power [I believe more so than the original SQL], I suspect that it is possible to incorporate lambda expressions into where clauses and order by clauses in a reasonable way. Kragen From mikemac@teleport.com Tue, 31 Mar 1998 13:18:11 -0800 (PST) Date: Tue, 31 Mar 1998 13:18:11 -0800 (PST) From: Mike McDonald mikemac@teleport.com Subject: Make LispM code FREE (fwd) >From: eric dahlman >Date: Tue, 31 Mar 1998 13:36:55 -0700 (MST) >To: lispos@math.gatech.edu >Subject: Re: Make LispM code FREE (fwd) >As far as I can tell the sheet protocols and the different issues >involving grafts and the such fall under Silica. That was kind of my understanding too. But the CLIM spec doesn't call them out separately as "Silica". >I have the paper on >Silica by Rao and my impression was that these protocols in the CLIM >spec were Silica. I could be wrong it wouldn't be a first. The >benefit is that if this portion of the system is well isolated it >would be possible to take the CLIM implementation for say CLX and >remove the CLX dependencies and use it to implement a version for say >Windows. Then code written for one system would also work seamlessly >on another. The protocols defined in CLIM are pretty well designed to separate out the native windowing system dependancies from the core protocols. In my implementation, there's one file called clx-bindings that has all of the window system dependant code in it. This includes the CLX specific classes CLX-PORT, CLX-GRAFT, and CLX-MEDIUM. The core protocols are defined such that the right kind of thing gets created when one is needed. (Usually by asking the port to make one.) > And as far as the Lisp OS effort is concerned we would >have a better chance for involving outside efforts in the effort. I >for one have not made up my mind as to whether I could sell everyone >on having a Lisp OS computer on their desk. However, if I could do all >my development on a LispM and then ship the resulting ap "Lobotomized >for Windows End Users(TM)" I would be a happy camper. I'm trying real hard to keep it from being CLX dependant. I'd also like to see a Motif backend, in addition to a Windoze version. > >When you have something running let me know and I'll have a look at >it. I would be very willing to put some time towards these parts of >the system. I may be a bit naive about this whole thing but looking >at the CLIM spec there seem to be several large orthogonal protocols >that could be implemented by different people in relative isolation >once the system's basic framework is in place. That's precisely my plan. Someone could spend their life just working on refining the presentation part,let alone the other parts. I'd rather be using it! :-) >It would be really nice if everyone could have the experience of >working with a Dynamic Listener like on the Symbolics machines since >this would make a lot of these issues clearer. The system you are >describing with presentation types and command tables would more than >satisfy the shell crowd. YUP! :-) > And it would work fine on a textual basis. An ASCII terminal is harder than I want to think about at the moment. I think it's certainly doable though, to some extent anyway. (with-room-for-graphics might be a bit hard!) >One possible glimpse of kind of what we are talking about is the >"presenting listener" that Franz is including with the latest Emacs >Lisp interface beta. It is still buggy for me under Xemacs 20.4 >Solaris but it does have the ability to "present" objects to an emacs >buffer and later "accept" them back. Heck! And here I am making the 4.3 final version work with CMUCL! I bet they went and changed everythign on me! :-) Mike McDonald mikemac@mikemac.com From perry@zso.dec.com Tue, 31 Mar 1998 13:18:35 -0800 Date: Tue, 31 Mar 1998 13:18:35 -0800 From: Reginald S. Perry perry@zso.dec.com Subject: The Marketing of LispOS? I keep seeing messages on this list which hint toward somehow convincing large numbers of users to use LispOS. Whatever happened to doing something because: It would be way cool to hack to the metal in Lisp. Wouldn't it be cool to have your virtual memory be Lisp aware? Would my device driver model look radically different in Lisp? Wouldn't it be way cool to have OS MetaObjects? What would they look like? How fast would that dusty 486 sitting in my closet be running LispOS? Or pick any one of the cool ideas that people like Rainer Joswig, Henry Baker and others talk about. If you are interested in making a profit out of this venture, unsubscribe from the list now, you are pretty much wasting your time here. The quick way to generate cash flow with lisp is probably with server side COM objects integrated into CL-HTTP to generate interesting content or dynamic presentation of complex analysis. Don't expect one red cent from anything relating to LispOS or the applications developed to support it. That way, if something does happen, which I doubt, it would be a plesant suprise. But, if you really have a burning need for a business model and just can't do things because they are cool (don't you already have a job?), here is a crazy idea. Imagine all of those old 486s that Windows 99 runs like an old dog on. Now imagine several of them networked together communicating with your database on your main system and each other doing analysis of your business data in a way only Lisp lets you. You get nice usage out of hardware which you were about to scrap anyway and you get interesting tidbits out of your database that the data miners may not get because they have to write a specalized app for each business situation. -Reggie From joswig@lavielle.com Tue, 31 Mar 1998 23:32:31 +0200 Date: Tue, 31 Mar 1998 23:32:31 +0200 From: Rainer Joswig joswig@lavielle.com Subject: Make LispM code FREE (fwd) At 12:44 31.03.98 -0800, Mike McDonald wrote: > CLIM is only portable IF your comercial lisp vender deams to provide >it for your platform. Franz: CLIM 2 on Unix and Windows. Harlequin: CLIM 2 on Unix and Windows. Digitool: CLIM 2 on Mac OS, soon. Symbolics: CLIM 2 on Genera and Open Genera. In ancient times vendors shared the source for CLIM. All CLIM implementations came from a common source base. > And if you can afford it. Harlequin's version on Windows is not that expensive. Symbolics Genera 8.3 comes with CLIM source. Digitool might sell CLIM source for MCL for an additional price. >With Franz preparing >to release their version for Linux, that should help alot. Yep. Good move by Franz. >>Yes. >> > > Why? I'm serious. Why would you want to implement Emacs using CLIM? Because I want every editable gadget to be a full Emacs (ala Macintosh Common Lisp, where FRED (FRED resembles emacs deliberately) implements buffers, text editor fields and editor windows in one common substrate). I also would want to use the CLIM mechanisms in an editor (integration into presentations, command tables, menus, ...). >I hope you're not thinking of presenting each character/word. Sure not. But for example on a Symbolics you can do (accept 'some-presentation-type) and get the object from an editor buffer. Once all windows are on the same level, you can use their objects, too. I'm often splitting the screen in a editor and a listener. You also can press suspend in an editor and a listener opens from the top. All editor items are mousable according to the current input context. I cannot imagine why one want to lose the functionality of integrating presentations and presentation parsing from editor buffers. You also could layer a presentation structure on top of an CLIM based Emacs. Some Emacs/XEmacs buffers are providing CLIM-like highlighting and context sensitive mouse-right menus. Very valuable. CLIM already has the infrastructure. Example: Dired could display lines of presentations. > I can >understand implementing a web browser using CLIM but not Emacs. Please >enlighten me! W3 is implemented in Emacs. Once you can have have a Web browser, you want to edit (markup) files. The Symbolics had a Document Examiner for the documentation (with a lot web browser like features) and a Zmacs extension for writing the documentation (Concordia). The latter used a markup view. Integrating this would be interesting. Wysiwyg editor for files with markup (HTML, Scribe, XML, whatever, ...). >>- CLIM Emacs >>-- integrates Editor, Shell, Mail, News, Telnet > > Ouhh! Yuck! That seems like Unix thinking again. Let them be >separate apps that can communicate easily with each other. We don't >have to go the kitchen sink route again! (Things like one common, >global kill ring help to integrate separate apps.) But the Lisp OS is the kitchen sink route. Maximize reuse. The system is a soup of objects. Large units are components. Tell me how the applications will work together? How will classes inherit from other classes? I guess the global kill ring is not a very good communication mechanism. The Mac for example has an infrastructure for interapplications commnunication and scripting: Open Scripting Architecture, AppleEvents, AppleScripts, ... This would be an alternative. Corba? COM? Distributed Objects/Classes? Distributed agents? >>- File Browser >>-- browse directories, rename files, create files, delete files, >> edit files, change properties, find files, open files, >> move and copy files >> > > On my Symbolics, I found that once the Lisp Listener had >presentation types, I hardly ever used the File Editor. (Except to >find out how many free records were left.) It was easier to just do a >:Show Directory in the listener. This often works. Drawbacks: views are not updating themselves(!!), you are generating a lot of views on the same data, you are scrolling a lot around, every command invocation brings your view to the bottom of the listener, etc. An intuitive Finder (ala Macintosh) view often is much more manageable. >>- Inspector >>-- can inspect every Lisp object >>-- provides special views for common object types > > Once again, once you have presentation types in the lisp listener, a >windowed inspector becomes redundant. Just middle click on any lisp >object and it gets described. Right click on one of the slots and get >the chance to modify it. Left click on any other object on the screen >to use that for the new value. Life's good! Again. Having information in place and updating helps navigating in the information. >>- Apropos >>-- search through the various namespaces (variables, functions, packages, >> modules, applications, ...) > > Hmm, I always found (apropos 'foo) to work just fine. Personally I'm preferring (Find Symbol). Very valuable is also the Apropos dialog in MCL. Makes peeking around very easy and convenient. >>- Class Browser >>- Function Browser >>- Package Browser > > All can be done in the lisp listener with presentation types. Again. the Navigation aspect. Also the aspect that you can link tools like in LispWorks, Apple Dylan or SK8. Providing explicit tools with their own windows (still implemented with presentations) makes it more accessible. Don't put everything into the Listener. Once the task is complex enough there is reason to provide a tailored tool. From joswig@lavielle.com Tue, 31 Mar 1998 23:34:52 +0200 Date: Tue, 31 Mar 1998 23:34:52 +0200 From: Rainer Joswig joswig@lavielle.com Subject: LISPOS: My manifesto At 16:08 31.03.98 -0500, Kragen wrote: >On Sat, 28 Mar 1998, cosc19z5@bayou.uh.edu wrote: >> For instance: >> select * from f where condition >> >> Can be modeled in Common Lisp by: >> (select '* :from f :where #'(lambda (x) (condition ...))) Harlequin has a SQL layer for CL. Documentation about that can be read on their web site in the "Harlepedia". From joswig@lavielle.com Tue, 31 Mar 1998 23:55:24 +0200 Date: Tue, 31 Mar 1998 23:55:24 +0200 From: Rainer Joswig joswig@lavielle.com Subject: The Marketing of LispOS? At 13:18 31.03.98 -0800, Reginald S. Perry wrote: >Or pick any one of the cool ideas that people like Rainer Joswig, >Henry Baker and others talk about. If you are interested in making a >profit out of this venture, unsubscribe from the list now, you are >pretty much wasting your time here. Not really. While it is true, that there is enough other stuff to do. Like using description logics for implementing web-based applications on top of CL-HTTP. ;-) But: *** Take care of your tools. *** *** Eat your own dog food *** *** Don' apologize. *** You can only implement your dreams if there is infrastructure for it. A LispOS can be a very valuable infrastructure. Lisp has lost the leading edge without reason, due to lack of infrastructure and decreasing interest. Greetings, Rainer Joswig From mikemac@teleport.com Tue, 31 Mar 1998 14:15:18 -0800 (PST) Date: Tue, 31 Mar 1998 14:15:18 -0800 (PST) From: Mike McDonald mikemac@teleport.com Subject: Make LispM code FREE (fwd) >Date: Tue, 31 Mar 1998 23:32:31 +0200 >To: lispos@math.gatech.edu >From: Rainer Joswig >Subject: Re: Make LispM code FREE (fwd) >At 12:44 31.03.98 -0800, Mike McDonald wrote: > >> CLIM is only portable IF your comercial lisp vender deams to provide >>it for your platform. > >Franz: CLIM 2 on Unix and Windows. >Harlequin: CLIM 2 on Unix and Windows. >Digitool: CLIM 2 on Mac OS, soon. >Symbolics: CLIM 2 on Genera and Open Genera. Unix is a pretty broad sword here! >> And if you can afford it. > >Harlequin's version on Windows is not that expensive. Being a Unix weenie, I'm more interested in that. Last time I checked one of the above vendors for a version for a Unix version, the base implementation was $4000 and CLIM ws another $3000 on top. That's a bit out of my range for toys. (And yes, I'm playing!) >Symbolics Genera 8.3 comes with CLIM source. Digitool might >sell CLIM source for MCL for an additional price. Heck, my XL1201 didn't even come with CLIM period. I had to bug them about it and got a binary only version on a separate CD. No sources for anything! And now that they're belly up again, not which hope of rectifying that either. :-(( >> Why? I'm serious. Why would you want to implement Emacs using CLIM? > >Because I want every editable gadget to be a full Emacs (ala Macintosh >Common Lisp, where FRED (FRED resembles emacs deliberately) >implements buffers, text editor fields and editor windows in >one common substrate). I also would want to use the CLIM mechanisms >in an editor (integration into presentations, command tables, >menus, ...). Ah, you want a emacs-pane. OK, that's good. (I implemented one for Dynamic Windows years ago on the Symbolics for this very reason.) >>I hope you're not thinking of presenting each character/word. > >Sure not. But for example on a Symbolics you can do >(accept 'some-presentation-type) and get the object >from an editor buffer. Once all windows are on the >same level, you can use their objects, too. I'm >often splitting the screen in a editor and a listener. >You also can press suspend in an editor and a >listener opens from the top. All editor items are >mousable according to the current input context. >I cannot imagine why one want to lose the >functionality of integrating presentations and >presentation parsing from editor buffers. You also >could layer a presentation structure on top of an >CLIM based Emacs. Some Emacs/XEmacs buffers are providing >CLIM-like highlighting and context sensitive mouse-right >menus. Very valuable. CLIM already has the infrastructure. >Example: Dired could display lines of presentations. OK, I understand. As long as your going to provide your own presentation parser for the emacs-pane, sounds great. >>>- CLIM Emacs >>>-- integrates Editor, Shell, Mail, News, Telnet >> >> Ouhh! Yuck! That seems like Unix thinking again. Let them be >>separate apps that can communicate easily with each other. We don't >>have to go the kitchen sink route again! (Things like one common, >>global kill ring help to integrate separate apps.) > >But the Lisp OS is the kitchen sink route. Maximize reuse. >The system is a soup of objects. Large units are components. > >Tell me how the applications will work together? How >will classes inherit from other classes? >I guess the global kill ring is not a very good communication >mechanism. The Mac for example has an infrastructure for >interapplications commnunication and scripting: >Open Scripting Architecture, AppleEvents, AppleScripts, ... >This would be an alternative. Corba? COM? >Distributed Objects/Classes? Distributed agents? How about shared memory? All of my LispOS apps a threads running in the same address space. Want to communicate with some app? Call it! > >This often works. Drawbacks: views are not updating themselves(!!), you >are generating a lot of views on the same data, you are >scrolling a lot around, every command invocation brings >your view to the bottom of the listener, etc. An intuitive >Finder (ala Macintosh) view often is much more manageable. > >>>- Inspector >>>-- can inspect every Lisp object >>>-- provides special views for common object types >> >> Once again, once you have presentation types in the lisp listener, a >>windowed inspector becomes redundant. Just middle click on any lisp >>object and it gets described. Right click on one of the slots and get >>the chance to modify it. Left click on any other object on the screen >>to use that for the new value. Life's good! > >Again. Having information in place and updating helps navigating >in the information. True, they do tend to get mixed in with everything else when it's all being done in the lisp listener. I guess that's why I'm a frequent user of :Clear Output History. Windowed versions shouldn't be hard to implement either once you have CLIM in place. >>>- Apropos >>>-- search through the various namespaces (variables, functions, packages, >>> modules, applications, ...) >> >> Hmm, I always found (apropos 'foo) to work just fine. > >Personally I'm preferring (Find Symbol). Very valuable is also >the Apropos dialog in MCL. Makes peeking around very easy >and convenient. Can't wait to see your implementation! :-) > >Again. the Navigation aspect. Also the aspect that you can link tools >like in LispWorks, Apple Dylan or SK8. Providing explicit tools >with their own windows (still implemented with presentations) >makes it more accessible. Don't put everything >into the Listener. Once the task is complex enough there >is reason to provide a tailored tool. Sounds good as long as I can still do basic stuff in the lisp listener too. (Which I should be able to given the use of presentations.) Mike McDonald mikemac@mikemac.com From musman@pc15.imsidc.com Tue, 31 Mar 1998 15:55:53 -0800 Date: Tue, 31 Mar 1998 15:55:53 -0800 From: Scott Musman musman@pc15.imsidc.com Subject: Make LispM code FREE (fwd) >> > So how come there is so little interest in free CLIM??? > > Because most people don't know what they're missing! For a really poor example of what you're missing, let me remind everyone of CLINC that is found on www.cons.org. It's a mostly functional copy of dynamic windows (the original Symbolics UI) that runs under most vendors lisps (e.g. ACL, Liquid) and CLISP. Dynamic windows was the forerunner of CLIM, so the original idea behind updating EW (the Dynamic Windows clone) was that just by changing the top level CLINC/EW API to match CLIM you can use it to do 80% of what you can do in CLIM. Hence the idea was a free CLIM subset that would allow people to play around with CLIM ideas without having to pay for it from a vendor. If anyone has the time to work on it, I still think this is a really simple and great way to get started (unfortunately I don't, which is why I offered up the code). It would be a good stop-gap measure until Mike McDonald gets his CLIM from scratch into shape. -- Scott -- Scott Musman _______________________ Intelligent Systems Division | o | Integrated Management Services, Inc | \o| | 2101 Wilson Blvd, Suite 916 | \_ | Arlington, Va, 22201 | \ \ | (IMSI)703-528-0334x308 musman@imsihq.imsidc.com http://imsidc.com/~musman/ From perry@zso.dec.com Tue, 31 Mar 1998 18:23:55 -0800 Date: Tue, 31 Mar 1998 18:23:55 -0800 From: Reginald S. Perry perry@zso.dec.com Subject: The Marketing of LispOS? >"Ahmed" == cosc19z5@bayou uh edu writes: > I keep seeing messages on this list which hint toward somehow convincing large > numbers of users to use LispOS. > > Whatever happened to doing something because: > > It would be way cool to hack to the metal in Lisp. > This may be one of the motivations for some. Not that I'm all that > fond of using Lisp to hack into the metal. I prefer more elegant > abstractions... I think the term used was "Platonic Programming". > > Wouldn't it be cool to have your virtual memory be Lisp aware? > Only if I can percieve it. Otherwise, what would the point be? For > me, what matters is what I can see and observe directly, which is > why I'm content for a CL Shell in lieu of a full fledged O/S. Let me attempt to explain a little better here. There is this perception that Lisp is slow. Now current Lisps that run on stock hardware interact with an underlying OS. This os, probably written in C, has a lot of built in assumptions. I would like to know how much these assumptions affect the Lisp system and how much difference, if any, would you see from having Lisp assumptions there instead of C assumptions. I would rather work at the application level, but if the foundation is shakey... > > Wouldn't it be way cool to have OS MetaObjects? What would > they look like? > I'd have to think about this. I was looking at the Inside NT book and noticed that they had an Object Manager. I was thinking that if you took the object concept all the way down to the kernel, there are some things you would like to be objects, but for performance reasons, they probably shouldnt have the full CLOS machinery. But you might want a portion of that machinery. This would probably take a couple of passes to get right. > How fast would that dusty 486 sitting in my closet be running > LispOS? > Since I don't have a 486 in my closet, I really couldn't care less. :-) > What makes you think that trying to get LispOS to be accepted > commercially has anything to do with profit, or that it > automatically discounts people enjoying the project for other > reasons? > It just so happens that getting LispOS in a position to be used by > others for profit helps its chances to succeed that much more. It looked to me as if some people were starting to use "popularity" and "acceptance" as design criteria. I think that there are a lot of interesting ideas that have been presented. Most of them look like they will be portable to other Lisp environments and do not need a from-the-metal LispOS. Implement things that fulfill a need or is very interesting. Just like the mainstream wasnt really interested in another Unix clone, its not interested in another OS written in Lisp. But it would be cool to do anyway. > As far as I'm concerned, the state of computing can be summed up as > follows: 1) All mainstream operating systems suck. 2) All > mainstream programming languages suck. > Having a LispOS can help address these two points by providing a > good operating system (or at least O/S interface) for a change, and > since the programming language will naturally be Lisp based, Lisp > will get to ride on its coattails. > For me, this is Lisp advocacy, the attempt to bring a better O/S > (both working to further the sorry state of computing), and the > chance for me to work on a project that is both fun and potentially > significant. I cant disagree with this. I think that there are two perspectives here. One is to design from the top down. We develop the interfaces and envrironment on top of Windows/Unix that allow us to interoperate, embrace and extend. I like this idea, I have Harlequin LispWorks for Unix and Windows so this would work for me. The other is to work from the bottom up we build a small, tight kernel of primitive lisp objects, define a device driver model, interrupt/exception model, memory management model, object and resource management, and other basic OS tidbits. We know this is non-trivial. The question is, is it worth the effort? If I were doing this, I would have initially an Intel version and later an Alpha version (would probably need to abstract the hardware). Now initially I was not interested in this, but I started thinking about memory management and wondered what primitives I would need to define to work on the processor page tables from Lisp. Ive never thought about these things before, so the bright shiny object distracted me. :-) > [...] Don't expect one red cent from anything relating > to LispOS or the applications developed to support it. That way, if > something does happen, which I doubt, it would be a plesant suprise. > > Getting others to use LispOS in a commercial context does not imply > that we will be making money. > My attitude is to make LispOS free, and make the license flexible > enough to allow commercial use. No monetary gain for me. I agree with this but only in the sense that if commercial interests think I am doing something thats interesting to them, then, and only then, would we have to talk about it. Until that time, I toil on my pet project, ignored by the mainstream. That way my priorities are in the correct order. -Reggie From mbpomije@inav.net Tue, 31 Mar 1998 20:51:32 -0600 Date: Tue, 31 Mar 1998 20:51:32 -0600 From: Martin B. Pomije mbpomije@inav.net Subject: Handicaped access to LispOS (was Re: Make LispM code FREE (fwd)) Rainer Joswig wrote: (snip) > > The Lisp Listener mechanisms are central (command loops, menus, etc.). > But I would want the UI of a new Lisp OS much more graphical. > With graphical presentations in the Listener, too. Updating > regions in the Listener. Place a clock in a Listener. It should keep > updating. Same for process listings, etc. Actually > you can change view settings of presented data afterwards > in a Symbolics listener. For example you can change > the sort criteria of a directory listing, after it > has been printed to the listener. I am very new to Lisp, so please be patient with me. One thing that is important to me is computer access for handicapped people. Windows has caused a lot of problems in this area. Does CLIM have mechanisms that make it possible to have a GUI while allowing for a blind person to also have access to information? -- ********************************************* Semi-encrypted email address: m_b_p_o_m_i_j_e_ a_t_ i_n_a_v_ d_o_t_ n_e_t_ All non-solicited commercial email will be billed $1,000. From kragen@pobox.com Tue, 31 Mar 1998 22:48:35 -0500 (EST) Date: Tue, 31 Mar 1998 22:48:35 -0500 (EST) From: Kragen kragen@pobox.com Subject: Make LispM code FREE (fwd) On Wed, 1 Apr 1998, Chris Bitmead wrote: > > Yeah, why create from scratch when there is a load of code out there > > waiting to be pulled in or learned from.....? > > Well, I don't know if it is comparable, but have you ever > compared the source code to PDP-11 UNIX compared to, well say > Linux? I've read bits of both, but only compared them cursorily. > The PDP-11 version makes interesting reading, but not a > single line of code is worth saving. I doubt that. In fact, many lines of code are identical in both. errno.h, for instance. > In fact I'd say very little > of the design is probably worth saving either. Actually, Linux's basic design is very much the same as PDP-11 UNIX. The whole filesystem design, multitasking design, etc., is almost identically replicated in Linux. Linux's design is *much* more similar to V6 UNIX than to MVS, VMS, Windows NT, Amoeba, Mach, Sprite, KeyKOS, etc. Memory management's very different, though. > The MIT lisp code would surely be interesting, but I really doubt > it is going to be much more than a curiousity rather than the > base for a new LispOS. You may be right. But listening to Rainer and others talking about inspectors and listeners, I'm hearing concepts that never before entered my mind, and I expect that many of them will be implemented in the MIT Lisp machine code. Kragen From kragen@pobox.com Tue, 31 Mar 1998 23:25:06 -0500 (EST) Date: Tue, 31 Mar 1998 23:25:06 -0500 (EST) From: Kragen kragen@pobox.com Subject: The Marketing of LispOS? On Tue, 31 Mar 1998, cosc19z5@bayou.uh.edu wrote: > Well, we do need to get this issue settled up front because this > is where the licensing comes in. If folks are going to share > code, then they need to do so with some kind of license in place, > and the license chosen will have impacts on any potential > commercial development. Not necessarily. If you're willing to donate your first-prototype code to the public domain, you don't need to have any license in place at all until you get past that stage. At that point, we'll know who's actually going to be doing the leading, and so we'll know who to listen to if we want good code, instead of just who talks loudest. Kragen From kragen@pobox.com Tue, 31 Mar 1998 23:33:43 -0500 (EST) Date: Tue, 31 Mar 1998 23:33:43 -0500 (EST) From: Kragen kragen@pobox.com Subject: Make LispM code FREE (fwd) On Wed, 1 Apr 1998, Chris Bitmead wrote: > Kragen wrote: > > Actually, Linux's basic design is very much the same as PDP-11 UNIX. > > The whole filesystem design, > > The internals of the file system design are utterly utterly > different. Yes at user level they look the same, but that's not > what I'm talking about. I'm talking about the implementation > design. Not only do they look the same at user level, but directories are implemented as lists of (name, inum) pairs which are ordinary files with a special attribute bit, metadata is stored in `inodes', inodes have pointers to data blocks, an indirect block, and some doubly indirect blocks, and a triply indirect block, etc. The disk is statically partitioned into inodes and data blocks. MS-DOS, VMS, CP/M, NT, and ITS do things *very* differently. > > multitasking design, > > Very different. Much more the same than, say, VMS's multitasking design, or NT's, is the same as Linux. Kragen From cmh@greendragon.com Tue, 31 Mar 1998 22:41:08 -0600 Date: Tue, 31 Mar 1998 22:41:08 -0600 From: Chris Hanson cmh@greendragon.com Subject: Make LispM code FREE (fwd) At 10:05 PM -0600 3/31/98, Chris Bitmead wrote: >The MIT lisp code would surely be interesting, but I really doubt >it is going to be much more than a curiousity rather than the >base for a new LispOS. That all depends how hard it would be to write an emulator for the hardware it ran on... :) From tc@gauss.muc.de 01 Apr 1998 00:00:50 +0200 Date: 01 Apr 1998 00:00:50 +0200 From: Matthias Hoelzl tc tc@gauss.muc.de Subject: Misc ideas & comments strandh@cs.utexas.edu writes: > > 2) The implementation of the stack handling needed to have efficient > > first class continuations seems very difficult to integrate with the > > gcc back end. The possibilities that I see right now are a > > setjmp/longjmp based stack copying approach, suitable only to use > > continuations for error handling; or managing your own runtime stack, > > which would somewhat defeat the aim of using the gcc back end. The > > cleanest approach would probably be to define some additional tree > > codes with corresponding implementation in the gcc back end. However > > this would be a largish undertaking, and since I'm no proficient > > C-hacker I don't think that I can handle this without a lot of support > > from people more familiar with both C and the gcc back end. > > How about using a stack cache and migrating the stack frames to the > heap whenever the cache overflows. You get the advantage of using the > normal stack convention of GCC but call/cc only involves flushing the > cache. I was thinking about Hieb/Dybvig/Bruggeman's implementation of stacks and the thought of using a stack cache simply didn't cross my mind when I wrote the above paragraph. But you are right, I should take them into account. > > I think that calling C from Scheme would not be a problem, > > Right, you just tell the Scheme compiler to generate C compatible > code. > > > but that it > > would be necessary to create stubs for Scheme functions that can be > > called from C because you cannot simply stack-allocate all parameters > > to a Scheme function. > > I don't see why you could not simply stack allocate all parameters to > a Scheme function. Well, I was being unclear. I could stack allocate all parameters, but I want to have some flexibility for Scheme->Scheme calls, so that e.g., the caller can heap-allocate escaping parameters and simply pass a pointer instead of pushing them on the stack and having the callee save them on the heap. The compiler can create a module description file (similar to Dylan) where the calling conventions are recorded for other Scheme modules, but for the C compiler I need to provide a stub function that takes the arguments as described in the function definition. (Another reason why C->Scheme calls probably need stubs is that otherwise the C-caller has to take care of converting the types to boxed/tagged format.) Matthias From joswig@lavielle.com Wed, 01 Apr 1998 00:46:57 +0200 Date: Wed, 01 Apr 1998 00:46:57 +0200 From: Rainer Joswig joswig@lavielle.com Subject: Make LispM code FREE (fwd) At 14:15 31.03.98 -0800, Mike McDonald wrote: >>Harlequin's version on Windows is not that expensive. > > Being a Unix weenie, I'm more interested in that. Last time I >checked one of the above vendors for a version for a Unix version, the >base implementation was $4000 and CLIM ws another $3000 on top. That's >a bit out of my range for toys. (And yes, I'm playing!) True. >>Symbolics Genera 8.3 comes with CLIM source. Digitool might >>sell CLIM source for MCL for an additional price. > > Heck, my XL1201 didn't even come with CLIM period. I had to bug them >about it and got a binary only version on a separate CD. No sources >for anything! And now that they're belly up again, not which hope of >rectifying that either. :-(( My original Genera 8.3 CDROM has CLIM source on it. >>Distributed Objects/Classes? Distributed agents? > > How about shared memory? All of my LispOS apps a threads running in >the same address space. Want to communicate with some app? Call it! Yep. >>>>- Apropos >>>>-- search through the various namespaces (variables, functions, packages, >>>> modules, applications, ...) >>> >>> Hmm, I always found (apropos 'foo) to work just fine. >> >>Personally I'm preferring (Find Symbol). Very valuable is also >>the Apropos dialog in MCL. Makes peeking around very easy >>and convenient. > > Can't wait to see your implementation! :-) O.k., I'll take it. But before that I may have to come up with a CLIM-based UI for CL-HTTP. And before that I have to implement some other stuff like a log analyser for a web server and a browser for web site objects. So don't hold your breath. > Sounds good as long as I can still do basic stuff in the lisp >listener too. (Which I should be able to given the use of >presentations.) The Lisp Listener mechanisms are central (command loops, menus, etc.). But I would want the UI of a new Lisp OS much more graphical. With graphical presentations in the Listener, too. Updating regions in the Listener. Place a clock in a Listener. It should keep updating. Same for process listings, etc. Actually you can change view settings of presented data afterwards in a Symbolics listener. For example you can change the sort criteria of a directory listing, after it has been printed to the listener. From chrisb@Ans.Com.Au Wed, 01 Apr 1998 04:05:50 +0000 Date: Wed, 01 Apr 1998 04:05:50 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: Make LispM code FREE (fwd) > Yeah, why create from scratch when there is a load of code out there > waiting to be pulled in or learned from.....? Well, I don't know if it is comparable, but have you ever compared the source code to PDP-11 UNIX compared to, well say Linux? The PDP-11 version makes interesting reading, but not a single line of code is worth saving. In fact I'd say very little of the design is probably worth saving either. The MIT lisp code would surely be interesting, but I really doubt it is going to be much more than a curiousity rather than the base for a new LispOS. -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From chrisb@Ans.Com.Au Wed, 01 Apr 1998 04:32:40 +0000 Date: Wed, 01 Apr 1998 04:32:40 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: LISPOS: My manifesto > (select '(name) :from users :where (lambda (x) (= (acctnum x) 44833))) > > can't use the primary-key index on users by acctnum, it has to look at > every record and call the lambda function on it. > > This means that what was originally a simple hash-table lookup and > fetch, or possibly a b-tree lookup and fetch, becomes a process that > requires fetching something like 50,000 records from disk and calling a > couple of Scheme functions for each one of them. > > This does not meet my definition of `essentially for free'. That's true, but it would be possible to analyse the lambda expression and do optimisations on it. Pass everything possible off to the database engine and perform the rest yourself. This would not be a trivial excercise to implement, but would be well worth it if you planned to do a lot of random queries. -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From chrisb@Ans.Com.Au Wed, 01 Apr 1998 05:03:58 +0000 Date: Wed, 01 Apr 1998 05:03:58 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: Make LispM code FREE (fwd) Kragen wrote: > > Well, I don't know if it is comparable, but have you ever > > compared the source code to PDP-11 UNIX compared to, well say > > Linux? > > The PDP-11 version makes interesting reading, but not a > > single line of code is worth saving. > > I doubt that. In fact, many lines of code are identical in both. errno.h, > for instance. Ok, some constants are the same. I wouldn't go as far as calling some constants "code". > > In fact I'd say very little > > of the design is probably worth saving either. > > Actually, Linux's basic design is very much the same as PDP-11 UNIX. > The whole filesystem design, The internals of the file system design are utterly utterly different. Yes at user level they look the same, but that's not what I'm talking about. I'm talking about the implementation design. > multitasking design, Very different. > > The MIT lisp code would surely be interesting, but I really doubt > > it is going to be much more than a curiousity rather than the > > base for a new LispOS. > > You may be right. But listening to Rainer and others talking about > inspectors and listeners, I'm hearing concepts that never before > entered my mind, and I expect that many of them will be implemented in > the MIT Lisp machine code. Yes, I'm sure the code will make an interesting read, and will suggest lots of ideas. But as far as actually using any of it.... Well we shall see. -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From chrisb@Ans.Com.Au Wed, 01 Apr 1998 07:52:26 +0000 Date: Wed, 01 Apr 1998 07:52:26 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: Make LispM code FREE (fwd) > > The internals of the file system design are utterly utterly > > different. Yes at user level they look the same, but that's not > > what I'm talking about. I'm talking about the implementation > > design. > > Not only do they look the same at user level, but directories are > implemented as lists of (name, inum) pairs Sure, you can't change that without changing the look from the user level. But even the structure of a directory on disk is different. The original UNIX had fixed length 16 byte entries, Linux has variable length entries in 512 byte blocks. > which are ordinary files > with a special attribute bit, metadata is stored in `inodes', inodes > have pointers to data blocks, an indirect block, and some doubly > indirect blocks, and a triply indirect block, etc. The disk is > statically partitioned into inodes and data blocks. Yeah, that is all basicly still user level details. The keeping track of free blocks is different, the arrangment of the inodes on the disk is different. No code would be salvagable. -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From rideau@ens.fr Wed, 1 Apr 1998 12:12:52 +0200 (CEST) Date: Wed, 1 Apr 1998 12:12:52 +0200 (CEST) From: Fare Rideau rideau@ens.fr Subject: The Marketing of LispOS? >: Ahmed > How many other O/Ses are under development? How many have we heard of? http://www.tunes.org/~tunes/doc/Review/OSes.html http://www.lfbs.rwth-aachen.de/~sven/ http://www.cs.arizona.edu/people/bridges/index.html ## Faré | VN: ĐŁng-Vű Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## ...so this guy walks into a bar. "The usual, Mr. Descartes?" the barman asked. "I think not," Rene replied, and promptly disappeared. From moribund@netgsi.com Wed, 1 Apr 1998 07:45:17 -0500 Date: Wed, 1 Apr 1998 07:45:17 -0500 From: Damond Walker moribund@netgsi.com Subject: Make LispM code FREE (fwd) >> Yeah, why create from scratch when there is a load of code out there >> waiting to be pulled in or learned from.....? > [snip] > >The MIT lisp code would surely be interesting, but I really doubt >it is going to be much more than a curiousity rather than the >base for a new LispOS. > If anything, we could learn from the "mistakes of the elders" so to speak -- it's that whole "...doomed to repeat it..." thing. I've been thinking of starting some GUI stuff once Franz releases CLIM on linux. Anyone care to help in this endeavor? The way I figure, any portable CLIM stuff we do now should sit nicely on top of whatever foundation we have in the future.... Damo From moribund@netgsi.com Wed, 1 Apr 1998 07:55:01 -0500 Date: Wed, 1 Apr 1998 07:55:01 -0500 From: Damond Walker moribund@netgsi.com Subject: LISPOS: My manifesto The lambda way.... >> >> (select '(name) :from users :where (lambda (x) (= (acctnum x) 44833))) >> The "normal" way... >> >> (select '(name) :from users :where '(acctnum = 44833)) >> > >Some compromise should be reached, because I would bitterly >oppose loss of the lambda expression in the where clause >at all costs -- even at the cost of the entire SQL project. > >If it doesn't have lambda, then it isn't worth writing. > Now tell me...how hard would it be to have the package accept *both* ways of doing things. My experience with Lisp has been light but it would seem to me that it was then, and is now, quite possible to wrote the package to accept anything you threw at it. You could easily have :WHERE for "standard" clauses and :WHEREL for the lambda case right? Damo From cosc19z5@bayou.uh.edu Wed, 1 Apr 1998 08:13:18 -0600 (CST) Date: Wed, 1 Apr 1998 08:13:18 -0600 (CST) From: cosc19z5@bayou.uh.edu cosc19z5@bayou.uh.edu Subject: LISPOS: My manifesto > The lambda way.... The true way :) > > >> > >> (select '(name) :from users :where (lambda (x) (= (acctnum x) 44833))) > >> > > > > The "normal" way... The way of the unwashed, toothless masses :) > > >> > >> (select '(name) :from users :where '(acctnum = 44833)) > >> > > > > > > >Some compromise should be reached, because I would bitterly > >oppose loss of the lambda expression in the where clause > >at all costs -- even at the cost of the entire SQL project. > > > >If it doesn't have lambda, then it isn't worth writing. > > > > > > Now tell me...how hard would it be to have the package accept *both* > ways of doing things. My experience with Lisp has been light but it would > seem to me that it was then, and is now, quite possible to wrote the package > to accept anything you threw at it. It should be trivial. > You could easily have :WHERE for "standard" clauses and :WHEREL for the > lambda case right? Actually, we can just have :where for both the "standard" and lambda clauses. That would be the better way to approach it. > > Damo > -- Cya, Ahmed From joswig@lavielle.com Wed, 1 Apr 1998 16:58:15 +0200 Date: Wed, 1 Apr 1998 16:58:15 +0200 From: Rainer Joswig joswig@lavielle.com Subject: The Marketing of LispOS? At 18:23 Uhr -0800 31.03.1998, Reginald S. Perry wrote: >Let me attempt to explain a little better here. There is this >perception that Lisp is slow. Now current Lisps that run on stock >hardware interact with an underlying OS. This os, probably written in >C, has a lot of built in assumptions. I would like to know how much >these assumptions affect the Lisp system and how much difference, if >any, would you see from having Lisp assumptions there instead of C >assumptions. > >I would rather work at the application level, but if the foundation is >shakey... Very true. >objects, but for performance reasons, they probably shouldnt have the >full CLOS machinery. But you might want a portion of that >machinery. This would probably take a couple of passes to get right. I guess for a lot of things the CLOS machinery will be fast enough. A process scheduler sure could be written using full CLOS. The big question comes when you have to deal with many objects. Like in user interfaces. CLIM is CLOS in extreme. Unless you have a fast CLOS you won't have a fast CLIM. The Symbolics is by todays standards slow. Most stuff is written in OO-style and is fast or fast enough. Compiling was dead slow. Compiling CL-HTTP may take 2-3 hours on an 3640 (design from 1985). A fast Mac compiles the same code (some ten thousand lines of heavy Lisp code) in little more than one minute(!!!). Actually I'm pretty sure a Lisp OS without the intermediate C-based layers (see above) (MCL has up to four layers of software when your doing OS stuff: file system, network, graphics, ...) and reduced to one or two layers will result a spectacular performance on todays machines. >...its not interested in another OS written in >Lisp. But it would be cool to do anyway. There could be a plan... I can imagine a state where it starts to get interesting. Actually its applications that matter. Data mining, web server, electronic commerce, mail server, OODBMS, knowledge-based systems... There are a lot of high end applications in Lisp. Provide a good home for them. Make a difference. More productivity. Less barriers. Cool UI. Usable documentation (actually ***few*** systems have usable documentation facilities - the last system might be the Symbolics - I don't like Acrobat, Apple Guide, HTML, etc. for this purpose). Be portable. (Apropos "Be". Look at their OS. Nice, but conventional by todays standards.) Build infrastructures. >I cant disagree with this. I think that there are two perspectives >here. One is to design from the top down. We develop the interfaces >and envrironment on top of Windows/Unix that allow us to interoperate, >embrace and extend. I like this idea, I have Harlequin LispWorks for >Unix and Windows so this would work for me. Me, too. Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041 Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/ From kragen@pobox.com Wed, 1 Apr 1998 12:18:22 -0500 (EST) Date: Wed, 1 Apr 1998 12:18:22 -0500 (EST) From: Kragen kragen@pobox.com Subject: LISPOS: My manifesto On Wed, 1 Apr 1998, cosc19z5@bayou.uh.edu wrote: > > >> (select '(name) :from users :where '(acctnum = 44833)) > > >Some compromise should be reached, because I would bitterly > > >oppose loss of the lambda expression in the where clause > > >at all costs -- even at the cost of the entire SQL project. Oh, surely, I agree! > > You could easily have :WHERE for "standard" clauses and :WHEREL for the > > lambda case right? > > Actually, we can just have :where for both the "standard" > and lambda clauses. That would be the better way to > approach it. You could do something like: (select '(acctnum) :from users :where '(signupdate > 19980101 and filtered-by-lisp-func account-looks-inactive)) Maybe there's a better word than "filtered-by-lisp-func". Kragen From dmason@scs.Ryerson.CA Wed, 1 Apr 1998 13:49:20 -0500 Date: Wed, 1 Apr 1998 13:49:20 -0500 From: Dave Mason dmason@scs.Ryerson.CA Subject: LISPOS: My manifesto Dunno what this has to do with my manifesto, but anyway... Kragen writes: > You could do something like: > (select '(acctnum) :from users > :where '(signupdate > 19980101 and > filtered-by-lisp-func account-looks-inactive)) > > Maybe there's a better word than "filtered-by-lisp-func". Why not (in Scheme): (select '(acctnum) :from users :where `(and (> signupdate 19980101) ,(lambda (rec)....))) Then select could symbolically evaluate simple comparisons and when it saw a function, apply that to the record too. I think it wouldn't be so clean in CL, but hopefully I'm wrong and CL now has some reasonable support for first-class functions (and quasi-quote and unquote). ../Dave From ptw@pobox.com Wed, 1 Apr 1998 14:48:47 -0500 Date: Wed, 1 Apr 1998 14:48:47 -0500 From: P. T. Withington ptw@pobox.com Subject: Make LispM code FREE (fwd) On 3/31/98 23:41, Chris Hanson wrote: >At 10:05 PM -0600 3/31/98, Chris Bitmead wrote: >>The MIT lisp code would surely be interesting, but I really doubt >>it is going to be much more than a curiousity rather than the >>base for a new LispOS. > >That all depends how hard it would be to write an emulator for the hardware >it ran on... :) Can't be much harder than JVM. That's what Symbolics did to make "Open Genera" -- it is a LispM emulator that runs on Alphas. On a top of the line Alpha, it runs many times faster than the custom hardware ever did. (Another way of thinking about it: the Alpha chip is the micro engine and the emulator is the microcode. One reason the emulator runs so fast on the Alpha is that we were very careful to fit the "microcode" and "engine" into the Alpha's on-chip instruction and data caches.) OTOH, the portable C prototype of the emulator ran like a dog... From wlewis@mailbag.com Wed, 01 Apr 1998 14:10:02 -0600 Date: Wed, 01 Apr 1998 14:10:02 -0600 From: William A. Barnett-Lewis wlewis@mailbag.com Subject: Anti-Spam Bill before US Congress Hello all, This may be "somewhat" off topic, but it is an important issue these days. For those of us who are citizens of the US, please contact your senators and representatives and ask them to support House Bill 1748. This bill would amend the law banning junk faxes to include spam email. The full text of the bill follows: ________________________________________________________________________ Netizens Protection Act of 1997 (Introduced in the House) HR 1748 IH 105th CONGRESS 1st Session H. R. 1748 To amend the Communications Act of 1934 to ban the transmission of unsolicited advertisements by electronic mail, and to require that sender identification information be included with electronic mail messages. IN THE HOUSE OF REPRESENTATIVES May 22, 1997 Mr. SMITH of New Jersey introduced the following bill; which was referred to the Committee on Commerce A BILL To amend the Communications Act of 1934 to ban the transmission of unsolicited advertisements by electronic mail, and to require that sender identification information be included with electronic mail messages. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, SECTION 1. SHORT TITLE. This Act may be cited as the `Netizens Protection Act of 1997'. SEC. 2. PROHIBITION ON TRANSMISSION OF UNSOLICITED ADVERTISEMENTS BY ELECTRONIC MAIL. Section 227(b)(1) of the Communications Act of 1934 (47 U.S.C. 227(b)(1)) is amended-- (1) by striking `or' at the end of subparagraph (C); (2) by redesignating subparagraph (D) as subparagraph (E); (3) by inserting after subparagraph (C) the following new subparagraph: `(D) to use any computer or other electronic device to send an unsolicited advertisement to an electronic mail address of an individual with whom such person lacks a preexisting and ongoing business or personal relationship, unless such individual provides express invitation or permission; or'. SEC. 3. ELECTRONIC MAIL SENDER IDENTIFICATION INFORMATION REQUIRED. Section 227(d)(1) of the Communications Act of 1934 (47 U.S.C. 227(d)(1)) is amended-- (1) by striking `or' at the end of subparagraph (A); (2) by striking the period at the end of subparagraph (B) and inserting `; and'; and (3) by inserting at the end the following new subparagraph: `(C) to use a computer or other electronic device to send an unsolicited advertisement to an electronic mail address unless such person clearly provides, at the beginning of such unsolicited advertisement, the date and time the message is sent, the identity of the business, other entity, or individual sending the message, and the return electronic mail address of such business, other entity, or individual.'. William Barnett-Lewis wlewis@mailbag.com -- _______________________________________________ Live without fear; your Creator loves you as a mother. Go in peace to follow the good road and may God's blessing be with you always. St. Claire _______________________________________________ From wlewis@mailbag.com Wed, 01 Apr 1998 14:22:15 -0600 Date: Wed, 01 Apr 1998 14:22:15 -0600 From: William A. Barnett-Lewis wlewis@mailbag.com Subject: Make LispM code FREE (fwd) P. T. Withington wrote: > > On 3/31/98 23:41, Chris Hanson wrote: > > >At 10:05 PM -0600 3/31/98, Chris Bitmead wrote: > >>The MIT lisp code would surely be interesting, but I really doubt > >>it is going to be much more than a curiousity rather than the > >>base for a new LispOS. > > > >That all depends how hard it would be to write an emulator for the hardware > >it ran on... :) > > Can't be much harder than JVM. That's what Symbolics did to make "Open > Genera" -- it is a LispM emulator that runs on Alphas. On a top of the > line Alpha, it runs many times faster than the custom hardware ever did. > (Another way of thinking about it: the Alpha chip is the micro engine > and the emulator is the microcode. One reason the emulator runs so fast > on the Alpha is that we were very careful to fit the "microcode" and > "engine" into the Alpha's on-chip instruction and data caches.) > > OTOH, the portable C prototype of the emulator ran like a dog... OTOH, once we had a (that??? Ah, that'd be fun!) portable C implementation, there are a lot of tricks to optomize it that probably weren't done to that prototype. Instead they went to optimize Alpha assembler instead. Now, if we were to take that C and use it to generate a baseline VM and then translate the VM code into Lisp, we could use the initial VM to bootstrap a better VM. A similar technique is used in Squeak. There is an excellent paper by the Squeak implementation team describing this on my web page. It's a zipped word 95 file. http://www.mailbag.com/users/wlewis/bttf.zip William -- _______________________________________________ Live without fear; your Creator loves you as a mother. Go in peace to follow the good road and may God's blessing be with you always. St. Claire _______________________________________________ From cwg-dated-2064a7dbffa9d7c2@DeepEddy.Com Wed, 01 Apr 1998 14:29:42 -0600 Date: Wed, 01 Apr 1998 14:29:42 -0600 From: Chris Garrigues cwg-dated-2064a7dbffa9d7c2@DeepEddy.Com Subject: LISPOS: My manifesto --==_Exmh_-82614765P Content-Type: text/plain; charset=us-ascii Just thought I'd butt in since there wasn't enough mail from people named "Chris". > From: Dave Mason > Date: Wed, 1 Apr 1998 13:49:20 -0500 > > (select '(acctnum) :from users > :where `(and (> signupdate 19980101) > ,(lambda (rec)....))) > > Then select could symbolically evaluate simple comparisons and when it > saw a function, apply that to the record too. > > I think it wouldn't be so clean in CL, but hopefully I'm wrong and CL > now has some reasonable support for first-class functions (and > quasi-quote and unquote). Something like: (select '(acctnum) :from users :where `(and (> signupdate 19980101) ,#'(lambda (rec)....))) (I think the '(,) syntax may have been in CL before it was in Scheme.) Chris -- Chris Garrigues Deep Eddy Internet Consulting +1 512 432 4046 609 Deep Eddy Avenue O- http://www.DeepEddy.Com/~cwg/ Austin, TX 78703-4513 My email address is an experiment in SPAM elimination: If it starts with cwg-dated..., it is *only* valid for 2 weeks. If it starts with cwg-sender..., *only* the person the message was intended for can reply to it. --==_Exmh_-82614765P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQB1AwUBNSKjtJaQnaaFII2dAQEnNgL7BVk8Ye/ZTDACwmooOsZm711LxdE18Zt3 eixrYpqdaljF90pIidnqaN4maMWxs+F8xdEQXTl0Lejny0vG21G5zxnuc8FDgrTS 6xNBtceJDK8+WCtaOV0z9dYCchQKKvsL =9OLy -----END PGP MESSAGE----- --==_Exmh_-82614765P-- From kragen@pobox.com Wed, 1 Apr 1998 15:53:14 -0500 (EST) Date: Wed, 1 Apr 1998 15:53:14 -0500 (EST) From: Kragen kragen@pobox.com Subject: Make LispM code FREE (fwd) On Wed, 1 Apr 1998, William A. Barnett-Lewis wrote: > Someone wrote: > > OTOH, the portable C prototype of the emulator ran like a dog... Hmm. Is this because the things you want to do for writing a Lisp VM are harder to do in C than in assembler? Kragen From wlewis@mailbag.com Wed, 01 Apr 1998 15:18:04 -0600 Date: Wed, 01 Apr 1998 15:18:04 -0600 From: William A. Barnett-Lewis wlewis@mailbag.com Subject: Make LispM code FREE (fwd) Hummm... No, I'm the one saying that the C version could be used to bootstrap a better VM than the origional C version that was characterized by Mr. Withington as one that "ran like a dog..." William Kragen wrote: > > On Wed, 1 Apr 1998, William A. Barnett-Lewis wrote: > > Someone wrote: > > > OTOH, the portable C prototype of the emulator ran like a dog... > > Hmm. Is this because the things you want to do for writing a Lisp VM > are harder to do in C than in assembler? > > Kragen -- _______________________________________________ Live without fear; your Creator loves you as a mother. Go in peace to follow the good road and may God's blessing be with you always. St. Claire _______________________________________________ From ptw@pobox.com Wed, 1 Apr 1998 16:19:41 -0500 Date: Wed, 1 Apr 1998 16:19:41 -0500 From: P. T. Withington ptw@pobox.com Subject: [may be junkmail -pobox] Re: Make LispM code FREE (fwd) On 4/1/98 15:53, Kragen wrote: >On Wed, 1 Apr 1998, William A. Barnett-Lewis wrote: >> Someone wrote: >> > OTOH, the portable C prototype of the emulator ran like a dog... > >Hmm. Is this because the things you want to do for writing a Lisp VM >are harder to do in C than in assembler? Possibly not today. 4 years ago, scheduling the instructions by hand was the only way to crank every last cycle out of the Alpha. Today, I understand there is an optimization mode for gcc that will use annealing to find the optimal instruction order. [Our job was made easier by doing all the writing in Lisp and using Lisp to translate into assembly. Thus we could use Lisp macros, etc. to make the job of writing assembly much easier, and editor commands such as m-x Show Compiled Code would show a cycle-count annotated assembly, highlighting the instruction dependencies and stalls.] From ptw@pobox.com Wed, 1 Apr 1998 16:19:42 -0500 Date: Wed, 1 Apr 1998 16:19:42 -0500 From: P. T. Withington ptw@pobox.com Subject: Make LispM code FREE (fwd) On 4/1/98 15:22, William A. Barnett-Lewis wrote: >P. T. Withington wrote: >> >> On 3/31/98 23:41, Chris Hanson wrote: >> >> >At 10:05 PM -0600 3/31/98, Chris Bitmead wrote: >> >>The MIT lisp code would surely be interesting, but I really doubt >> >>it is going to be much more than a curiousity rather than the >> >>base for a new LispOS. >> > >> >That all depends how hard it would be to write an emulator for the hardware >> >it ran on... :) >> >> Can't be much harder than JVM. That's what Symbolics did to make "Open >> Genera" -- it is a LispM emulator that runs on Alphas. On a top of the >> line Alpha, it runs many times faster than the custom hardware ever did. >> (Another way of thinking about it: the Alpha chip is the micro engine >> and the emulator is the microcode. One reason the emulator runs so fast >> on the Alpha is that we were very careful to fit the "microcode" and >> "engine" into the Alpha's on-chip instruction and data caches.) >> >> OTOH, the portable C prototype of the emulator ran like a dog... > >OTOH, once we had a (that??? Ah, that'd be fun!) portable C >implementation, there are a lot of tricks to optomize it that probably >weren't done to that prototype. Instead they went to optimize Alpha >assembler instead. Now, if we were to take that C and use it to generate >a baseline VM and then translate the VM code into Lisp, we could use the >initial VM to bootstrap a better VM. A similar technique is used in >Squeak. There is an excellent paper by the Squeak implementation team >describing this on my web page. It's a zipped word 95 file. Well there were several Lisp emulators written: one to emulate the chip at the gate level and one that emulated the chip at the instruction level, both used to debug ported software before the chip was ready. The C and assembly were both inspired by the instruction emulator. The big hit on performance was emulating a 40-bit word on a 32-bit machine. Alpha makes that easier, being a 64-bit machine. And only the core execution engine was in assembly, there was lots of supporting C code -- the VM implementation for instance, was written mostly in C. The tightest assembley was required for memory read/write which on the Lisp hardware does tag checking, invisible pointer following, and gc barriers. In the end, a LispM read took 7 Alpha cycles. From wlewis@mailbag.com Wed, 01 Apr 1998 15:45:56 -0600 Date: Wed, 01 Apr 1998 15:45:56 -0600 From: William A. Barnett-Lewis wlewis@mailbag.com Subject: Make LispM code FREE (fwd) P. T. Withington wrote: > > On 4/1/98 15:22, William A. Barnett-Lewis wrote: > > >P. T. Withington wrote: > >> > >> On 3/31/98 23:41, Chris Hanson wrote: > >> > >> >At 10:05 PM -0600 3/31/98, Chris Bitmead wrote: (CHOMP) > Well there were several Lisp emulators written: one to emulate the chip > at the gate level and one that emulated the chip at the instruction > level, both used to debug ported software before the chip was ready. The > C and assembly were both inspired by the instruction emulator. The big > hit on performance was emulating a 40-bit word on a 32-bit machine. > Alpha makes that easier, being a 64-bit machine. And only the core > execution engine was in assembly, there was lots of supporting C code >-- the VM implementation for instance, was written mostly in C. The > tightest assembley was required for memory read/write which on the Lisp > hardware does tag checking, invisible pointer following, and gc barriers. > In the end, a LispM read took 7 Alpha cycles. Ah. The word size differences; that makes somewhat more sense. Would this allevied by the P2 and PPC being 64 bit internally? They would still be choked by the bus width, but it shouldn't be as big a hit as emulating 40 bits in 32. Perhaps it would be best, overall, to make the jump to a full 64 bit implementation... ! William -- _______________________________________________ Live without fear; your Creator loves you as a mother. Go in peace to follow the good road and may God's blessing be with you always. St. Claire _______________________________________________ From weasel@cs.stanford.edu Wed, 01 Apr 1998 16:10:17 -0800 Date: Wed, 01 Apr 1998 16:10:17 -0800 From: The Weasel weasel@cs.stanford.edu Subject: Make LispM code FREE (fwd) At 01:45 PM 4/1/98 , William A. Barnett-Lewis wrote: >P. T. Withington wrote: >> On 4/1/98 15:22, William A. Barnett-Lewis wrote: >> >P. T. Withington wrote: >> >> On 3/31/98 23:41, Chris Hanson wrote: >> >> >At 10:05 PM -0600 3/31/98, Chris Bitmead wrote: >(CHOMP) [ .. Deletia .. ] >> The big >> hit on performance was emulating a 40-bit word on a 32-bit machine. >> Alpha makes that easier, being a 64-bit machine. >Ah. The word size differences; that makes somewhat more sense. Would >this allevied by the P2 and PPC being 64 bit internally? The PII does not expose 64 bit #'s, and I don't think that any of the common PowerPC's have 64 bit stuff exposed (it has been a while since i looked). >They would >still be choked by the bus width, but it shouldn't be as big a hit as >emulating 40 bits in 32. I think that their buses, however, are wider so that they can do bursting easier. \p -- The game of life is not so much in holding a good hand as in playing a poor hand well. -- H. T. Leslie From chrisb@Ans.Com.Au Thu, 02 Apr 1998 01:15:17 +0000 Date: Thu, 02 Apr 1998 01:15:17 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: LISPOS: My manifesto > Why not (in Scheme): > > (select '(acctnum) :from users > :where `(and (> signupdate 19980101) > ,(lambda (rec)....))) > > Then select could symbolically evaluate simple comparisons and when it > saw a function, apply that to the record too. > > I think it wouldn't be so clean in CL, but hopefully I'm wrong and CL > now has some reasonable support for first-class functions (and > quasi-quote and unquote). This seems like a very neat solution. -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From moribund@netgsi.com Wed, 1 Apr 1998 20:33:29 -0500 (EST) Date: Wed, 1 Apr 1998 20:33:29 -0500 (EST) From: Damond Walker moribund@netgsi.com Subject: LISPOS: My manifesto On Thu, 2 Apr 1998, Chris Bitmead wrote: [snip neato solution to SQL mapping] > This seems like a very neat solution. > So I take it you'll be starting work on a SQL engine? Hell, how hard could it possibly be??? :) Damo From davies@pobox.com Wed, 1 Apr 1998 20:32:34 -0700 Date: Wed, 1 Apr 1998 20:32:34 -0700 From: Byron Davies davies@pobox.com Subject: Speaking of spam ... Pobox's automated spam filter appended "[may be junkmail -pobox]" to the subject of the following email, as shown. Perhaps it's been seeing too many emails with the word "FREE" in capital letters lately. Byron ============== Resent-Date: Wed, 1 Apr 1998 16:20:13 -0500 (EST) Subject: Re: [may be junkmail -pobox] Re: Make LispM code FREE (fwd) Date: Wed, 1 Apr 1998 16:19:41 -0500 x-sender: ptw@spoon-hill.callitrope.thecia.net From: "P. T. Withington" To: "Kragen" , "William A. Barnett-Lewis" cc: Mime-Version: 1.0 Resent-From: lispos@math.gatech.edu X-Mailing-List: archive/latest/2234 X-Loop: lispos@math.gatech.edu Precedence: list Resent-Sender: lispos-request@math.gatech.edu On 4/1/98 15:53, Kragen wrote: >On Wed, 1 Apr 1998, William A. Barnett-Lewis wrote: >> Someone wrote: >> > OTOH, the portable C prototype of the emulator ran like a dog... > >Hmm. Is this because the things you want to do for writing a Lisp VM >are harder to do in C than in assembler? Possibly not today. 4 years ago, scheduling the instructions by hand was the only way to crank every last cycle out of the Alpha. Today, I understand there is an optimization mode for gcc that will use annealing to find the optimal instruction order. [Our job was made easier by doing all the writing in Lisp and using Lisp to translate into assembly. Thus we could use Lisp macros, etc. to make the job of writing assembly much easier, and editor commands such as m-x Show Compiled Code would show a cycle-count annotated assembly, highlighting the instruction dependencies and stalls.] From ptw@pobox.com Thu, 2 Apr 1998 12:19:38 -0500 Date: Thu, 2 Apr 1998 12:19:38 -0500 From: P. T. Withington ptw@pobox.com Subject: Make LispM code FREE (fwd) On 4/1/98 16:45, William A. Barnett-Lewis wrote: >P. T. Withington wrote: >> >> On 4/1/98 15:22, William A. Barnett-Lewis wrote: >> >> >P. T. Withington wrote: >> >> >> >> On 3/31/98 23:41, Chris Hanson wrote: >> >> >> >> >At 10:05 PM -0600 3/31/98, Chris Bitmead wrote: >(CHOMP) > >> Well there were several Lisp emulators written: one to emulate the chip >> at the gate level and one that emulated the chip at the instruction >> level, both used to debug ported software before the chip was ready. The >> C and assembly were both inspired by the instruction emulator. The big >> hit on performance was emulating a 40-bit word on a 32-bit machine. >> Alpha makes that easier, being a 64-bit machine. And only the core >> execution engine was in assembly, there was lots of supporting C code >>-- the VM implementation for instance, was written mostly in C. The >> tightest assembley was required for memory read/write which on the Lisp >> hardware does tag checking, invisible pointer following, and gc barriers. >> In the end, a LispM read took 7 Alpha cycles. > >Ah. The word size differences; that makes somewhat more sense. Would >this allevied by the P2 and PPC being 64 bit internally? They would >still be choked by the bus width, but it shouldn't be as big a hit as >emulating 40 bits in 32. Possibly, but the 64-bit address space was important too. >Perhaps it would be best, overall, to make the jump to a full 64 bit >implementation... ! In the "Virtual Lisp Machine", as we called it, we took advantage of the 64-bit address space two ways: The LispM address space was modelled as two 2^32 arrays: a 32-bit array for data and an 8-bit array for tags. With this arrangement we could almost get parallel data fetch and tag check, like the real hardware. On a 32-bit machine, the address space has to be modelled as a sparse array making load and store quite expensive. In the core micro-engine the stack cache was emulated using a 64-bit array with the tag in the high 32-bits and the data in the low 32-bits. The stack cache was sized to share the on-chip data cache with the micro-engine's instruction cache (which looked like data to the alpha chip). Using combined tag and data for the stack cache meant push, pop, etc. were single alpha instructions when their operands were in the cache. From wlewis@mailbag.com Thu, 02 Apr 1998 11:46:25 -0600 Date: Thu, 02 Apr 1998 11:46:25 -0600 From: William A. Barnett-Lewis wlewis@mailbag.com Subject: Make LispM code FREE (fwd) Hmm, so would the address space -loss- be too significant if one used a 24 bit array for the data and an 8 bit array for the tags? It would seem to me to be an acceptable compromise, since then it would fit into a 32 bit word. IIRC, the LMI K-machine was designed using that compromise. Of course this still wouldn't help the cache design you describe... It seems to me that as things currently stand in the affordable PC realm, ie PPC Macs and x86 PCs, that trading ultimate address size for acceptable performance would be the Gabriel (AKA "Worse is better")thing to do. With proper coding, the 32 bit arrays could be increased when 64 bit systems - both internal and external to the CPU - are available. OTOH, I'm an utter amateur at these issues and may be missing something significant... William P. T. Withington wrote: > > On 4/1/98 16:45, William A. Barnett-Lewis wrote: > > >P. T. Withington wrote: > >> > >> On 4/1/98 15:22, William A. Barnett-Lewis wrote: > >> > >> >P. T. Withington wrote: > >> >> > >> >> On 3/31/98 23:41, Chris Hanson wrote: > >> >> > >> >> >At 10:05 PM -0600 3/31/98, Chris Bitmead wrote: > >(CHOMP) > > > >> Well there were several Lisp emulators written: one to emulate the chip > >> at the gate level and one that emulated the chip at the instruction > >> level, both used to debug ported software before the chip was ready. The > >> C and assembly were both inspired by the instruction emulator. The big > >> hit on performance was emulating a 40-bit word on a 32-bit machine. > >> Alpha makes that easier, being a 64-bit machine. And only the core > >> execution engine was in assembly, there was lots of supporting C code > >>-- the VM implementation for instance, was written mostly in C. The > >> tightest assembley was required for memory read/write which on the Lisp > >> hardware does tag checking, invisible pointer following, and gc barriers. > >> In the end, a LispM read took 7 Alpha cycles. > > > >Ah. The word size differences; that makes somewhat more sense. Would > >this allevied by the P2 and PPC being 64 bit internally? They would > >still be choked by the bus width, but it shouldn't be as big a hit as > >emulating 40 bits in 32. > > Possibly, but the 64-bit address space was important too. > > >Perhaps it would be best, overall, to make the jump to a full 64 bit > >implementation... ! > > In the "Virtual Lisp Machine", as we called it, we took advantage of the > 64-bit address space two ways: The LispM address space was modelled as > two 2^32 arrays: a 32-bit array for data and an 8-bit array for tags. > With this arrangement we could almost get parallel data fetch and tag > check, like the real hardware. On a 32-bit machine, the address space > has to be modelled as a sparse array making load and store quite > expensive. > > In the core micro-engine the stack cache was emulated using a 64-bit > array with the tag in the high 32-bits and the data in the low 32-bits. > The stack cache was sized to share the on-chip data cache with the > micro-engine's instruction cache (which looked like data to the alpha > chip). Using combined tag and data for the stack cache meant push, pop, > etc. were single alpha instructions when their operands were in the cache. -- _______________________________________________ Live without fear; your Creator loves you as a mother. Go in peace to follow the good road and may God's blessing be with you always. St. Claire _______________________________________________ From kem@franz.com Thu, 02 Apr 1998 12:12:21 -0800 Date: Thu, 02 Apr 1998 12:12:21 -0800 From: Kelly Murray kem@franz.com Subject: Project SilkOS I've invested a day putting up a website for my SilkOS project, you can access via http://charlotte.franz.com/silkos Of course, this website is run by my persistent-object-based web server, which is the same web server that has been running www.franz.com for over a year. We need the first volunteer to take over and improve this first public "internet project manager" SilkOS application! I've gone back through my contributions to the LispOS mailing from 8-12 months ago, and combined them all into an "archive" page. This archive represents my ideas and plans a year ago, which is more valid today than ever. I note that the recent JaveONE conference and the Java community in general is now focusing on running Java as a general-purpose server-side dynamic-HTML application. Amazon.com has shown important and key this approach is. The web server-side app, www.hotmail.com, was sold to Microsoft for millions of dollars. I'm sorry to have to say it, but in my opinion, a LispOS project which is a GNUified Lisp Machine clone using CMU-CL and the FluxOS toolkit, with CLIM as the interface will be just another irrelevant failed Lisp project if it ever got anywhere to begin with. I want to work with people who share my goals and vision and who want to make a real difference in the software world. I find it extremely upsetting that something so great as Lisp has been relegated to the backwaters of the computer industry, and have been very frustrated over the last 15 years. I believe we have the "killer app" that is going to make the difference, as I've described in the archive, basically a low-cost distributed-memory multiprocessor server-side web machine. I will succeed building something valuable that may make me and my supporters wealthy, but it won't change the world without support and help from a lot others. I'd like a have a million dollars so I don't have to "work" for a living, but I'd rather change the world. Or better yet, do both, they seem to be related. -Kelly Edward Murray kem@franz.com http://charlotte.franz.com/silkos From gadbois@cyc.com Thu, 2 Apr 1998 14:21:36 -0600 Date: Thu, 2 Apr 1998 14:21:36 -0600 From: David Gadbois gadbois@cyc.com Subject: Make LispM code FREE (fwd) Date: Thu, 02 Apr 1998 11:46:25 -0600 From: "William A. Barnett-Lewis" Hmm, so would the address space -loss- be too significant if one used a 24 bit array for the data and an 8 bit array for the tags? It would seem to me to be an acceptable compromise, since then it would fit into a 32 bit word. IIRC, the LMI K-machine was designed using that compromise. Eight bits worth of tags is a lot. Having a tag for some purpose is justified if you wouldn't otherwise have to read a memory value and if you need to distinguish how to interpret a value. Two- or three-bit tags are "free" (insofar as they do not reduce the maximum addressable space) on byte-addressed 32-bit machines where the system keeps all pointers word-aligned, and it is certainly possible to build a good Lisp system with that few tags. On the other hand, who is going to be running 4GB processes on a PC? A reasonable limitation might be 1GB, which would allow for a couple of extra tag bits. Don't forget, the Symbolics guys were constrained to write an emulator for the Ivory instruction set, and so they had to represent the 40-bit words explicitly. Without that constraint, the argument for 64-bit processors is not so strong. --David Gadbois From coleman@math.gatech.edu Thu, 02 Apr 1998 15:45:04 -0500 Date: Thu, 02 Apr 1998 15:45:04 -0500 From: Richard Coleman coleman@math.gatech.edu Subject: Project LispOS Here here some notes about the current status and goals of the LispOS project. 1) Mike and I have decided on a modified goal for the LispOS project. Initially we are targeting a Common Lisp based environment (based on CMUCL) that sits on top of Unix. We hope to develop a free CLIM (Mike has made good progress on this), as well as port and extend various other CL applications. We hope to bundled all of this in an easy-to-use package. 2) I already have set up a machine that will be the dedicated CVS repository for the LispOS project. The name of the machine is currently "lispos.math.gatech.edu". The machine is not much (currently just a Sparc IPX running OpenBSD), but if things get rolling, I will invest in something larger. 3) Currently, the only people with access will be myself and Mike McDonald. Once we have something to show, we will give read-only anonymous access to the CVS tree. Eventually, a web and ftp site will be created as well. 4) The copyright that Mike and I will be using will be a slightly modified version of the one used by Tcl/Tk. I will include a sample copy at the end of this message. The main rationale for this copyright, is that one of the goals of the LispOS project is the advocacy of lisp technology both to users and business. If someone wishes to commercialize this work, then more power to them. 5) This is a long-term project. Although we hope to leverage existing code as much as possible, don't expect this to be completed in a month or so. But just because you don't hear anything, doesn't mean that there is no progress. -- Richard Coleman coleman@math.gatech.edu Copyright (c) 1997 Richard Coleman All rights reserved. Permission is hereby granted, without written agreement and without license or royalty fees, to use, copy, modify, and distribute this software and to distribute modified versions of this software for any purpose, provided that the above copyright notice and the following two paragraphs appear in all copies of this software. In no event shall Richard Coleman be liable to any party for direct, indirect, special, incidental, or consequential damages arising out of the use of this software and its documentation, even if Richard Coleman has been advised of the possibility of such damage. Richard Coleman specifically disclaims any warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The software provided hereunder is on an "as is" basis, and Richard Coleman has no obligation to provide maintenance, support, updates, enhancements, or modifications. From ptw@pobox.com Thu, 2 Apr 1998 16:52:33 -0500 Date: Thu, 2 Apr 1998 16:52:33 -0500 From: P. T. Withington ptw@pobox.com Subject: Make LispM code FREE (fwd) On 4/2/98 15:21, David Gadbois wrote: >Don't forget, the Symbolics guys were constrained to write an emulator >for the Ivory instruction set, and so they had to represent the 40-bit >words explicitly. Without that constraint, the argument for 64-bit >processors is not so strong. Exactly right. Binary compatibility was an absolute requirement (because the idea of building a new compiler had already been discarded as too costly, and most of the compiler expertise had been laid off). If LispOS are talking about creating a new VM and compiler for that VM, the design space is wide open. From dmason@scs.Ryerson.CA Thu, 2 Apr 1998 21:15:46 -0500 Date: Thu, 2 Apr 1998 21:15:46 -0500 From: Dave Mason dmason@scs.Ryerson.CA Subject: Project SilkOS Kelly Murray writes: > > I've invested a day putting up a website for my SilkOS project, > you can access via http://charlotte.franz.com/silkos All looks cool! I agree with your intent and goals. Unfortunately I won't be able to directly assist, as my path is that of Scheme, at least for the nonce. Nothing wrong with several parallel developments though, apart from a bit of wasted effort. Fortunately, for moderate sized programs, translation between Scheme and CL shouldn't be that difficult, so maybe we can still get some synergy happening. ../Dave From chrisb@Ans.Com.Au Fri, 03 Apr 1998 07:07:35 +0000 Date: Fri, 03 Apr 1998 07:07:35 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: Make LispM code FREE (fwd) Is Open Genera (or whatever it's called) for the DEC Alpha, an operating system unto itself, or does it run as an application under UNIX? -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From reti@wilson.ai.mit.edu Fri, 3 Apr 1998 09:15 -0500 Date: Fri, 3 Apr 1998 09:15 -0500 From: reti@wilson.ai.mit.edu reti@wilson.ai.mit.edu Subject: Make LispM code FREE (fwd) Date: Fri, 3 Apr 1998 02:07 EST From: Chris Bitmead Is Open Genera (or whatever it's called) for the DEC Alpha, an operating system unto itself, or does it run as an application under UNIX? It is an application under Unix. There was talk of extending it to taking over the whole machine, but that has (so far) never been done. Genera, on which it is based, is an entire operating system which runs on (among others) the Ivory chip architecture which Open Genera's emulator emulates. -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From chrisb@Ans.Com.Au Fri, 03 Apr 1998 14:26:16 +0000 Date: Fri, 03 Apr 1998 14:26:16 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: Genera > It is an application under Unix. There was talk of extending it to > taking over the whole machine, but that has (so far) never been done. > > Genera, on which it is based, is an entire operating system which runs > on (among others) the Ivory chip architecture which Open Genera's emulator > emulates. To what extent is the Ivory chip specialized for running Lisp? What features does it have that make running Lisp fast? -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From reti@wilson.ai.mit.edu Fri, 3 Apr 1998 09:48 -0500 Date: Fri, 3 Apr 1998 09:48 -0500 From: reti@wilson.ai.mit.edu reti@wilson.ai.mit.edu Subject: Genera Date: Fri, 3 Apr 1998 09:26 EST From: Chris Bitmead > It is an application under Unix. There was talk of extending it to > taking over the whole machine, but that has (so far) never been done. > > Genera, on which it is based, is an entire operating system which runs > on (among others) the Ivory chip architecture which Open Genera's emulator > emulates. To what extent is the Ivory chip specialized for running Lisp? What features does it have that make running Lisp fast? Most importantly, it carries the 8-bits of tag through the entire datapath and memory interface. The microengine can do tag comparison and dispatch in parallel with an operation, so for example an add instruction can assume that the operands are both fixnums and start doing the addition at the same time that the tag comparison hardware is comparing the tags. If there is a mismatch, that microcycle causes the result not to be stored and a trap to be taken. The tags are not only used to identify datatypes, but also for internal purposes, i.e. the copying garbage collector has GC-FORWARD tags to serve as a placeholder for an object whose contents have been moved but for which there might still be references in virtual memory using the old addresses. CDR-coding, headers for compound structures, locatives, logic-variables, and even the instruction stream all use tag bits, and hence the tag checking hardware that is on the chip. The chip also has hardware support for ephemeral garbage collection, an interface to a co-processor, a way to do efficient burst mode transfers on the memory bus, and a special limited mode (FEP mode) for running some much more stylized Lisp code the load the virtual image, etc. -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From dahlman@cs.colostate.edu Fri, 3 Apr 1998 08:22:03 -0700 (MST) Date: Fri, 3 Apr 1998 08:22:03 -0700 (MST) From: eric dahlman dahlman@cs.colostate.edu Subject: Lisp and VLIW (was Re: Genera) On Fri, 3 Apr 1998 reti@wilson.ai.mit.edu wrote: [snip] > Most importantly, it carries the 8-bits of tag through the entire datapath and > memory interface. The microengine can do tag comparison and dispatch in parallel > with an operation, so for example an add instruction can assume that the operands > are both fixnums and start doing the addition at the same time that the tag > comparison hardware is comparing the tags. If there is a mismatch, that microcycle > causes the result not to be stored and a trap to be taken. Here is a question that I have been kicking around for a little while about this type of thing. How well would lisp compile to a VLIW architecture with predicated execution? The issues of tag comparisons and the such being performed in parallel with the operations seem to be a gimmy source of instruction level parallelism which would be easy to take advantage of on such a processor. Could it be that the next generation of general purpose processors could be a real win for lisp? Has anyone looked into this issue? Just wondering, -Eric From chrisb@Ans.Com.Au Fri, 03 Apr 1998 15:31:39 +0000 Date: Fri, 03 Apr 1998 15:31:39 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: Genera > Most importantly, it carries the 8-bits of tag through the entire datapath and > memory interface. The microengine can do tag comparison and dispatch in parallel > with an operation, so for example an add instruction can assume that the operands > are both fixnums and start doing the addition at the same time that the tag > comparison hardware is comparing the tags. If there is a mismatch, that microcycle > causes the result not to be stored and a trap to be taken. I heard the Sparc architecture has some support for tagged designs. Is it comparable in that respect or not? > The chip also has hardware support for ephemeral garbage collection, an interface > to a co-processor, a way to do efficient burst mode transfers on the memory bus, > and a special limited mode (FEP mode) for running some much more stylized Lisp > code the load the virtual image, etc. How much of the GC is coded in hardware? -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From vogt@computer.org Fri, 3 Apr 1998 09:43:37 -0600 Date: Fri, 3 Apr 1998 09:43:37 -0600 From: Christopher J. Vogt vogt@computer.org Subject: Genera At 8:48 AM -0600 4/3/98, reti@wilson.ai.mit.edu wrote: > Date: Fri, 3 Apr 1998 09:26 EST > From: Chris Bitmead > > > It is an application under Unix. There was talk of extending it to > > taking over the whole machine, but that has (so far) never been done. > > > > Genera, on which it is based, is an entire operating system which runs > > on (among others) the Ivory chip architecture which Open Genera's >emulator > > emulates. > > To what extent is the Ivory chip specialized for running Lisp? > What features does it have that make running Lisp fast? > >Most importantly, it carries the 8-bits of tag through the entire datapath and >memory interface. The microengine can do tag comparison and dispatch in >parallel >with an operation, so for example an add instruction can assume that the >operands >are both fixnums and start doing the addition at the same time that the tag >comparison hardware is comparing the tags. If there is a mismatch, that >microcycle >causes the result not to be stored and a trap to be taken. > >The tags are not only used to identify datatypes, but also for internal >purposes, >i.e. the copying garbage collector has GC-FORWARD tags to serve as a >placeholder >for an object whose contents have been moved but for which there might >still be >references in virtual memory using the old addresses. > >CDR-coding, headers for compound structures, locatives, logic-variables, >and even >the instruction stream all use tag bits, and hence the tag checking >hardware that >is on the chip. > >The chip also has hardware support for ephemeral garbage collection, an >interface >to a co-processor, a way to do efficient burst mode transfers on the >memory bus, >and a special limited mode (FEP mode) for running some much more stylized Lisp >code the load the virtual image, etc. Kalman, did anything ever get published on the I-machine architecture? I can't seem to find anything. Here are a couple of references I dug up about Genera and the 3600 architecture that might be informative to those interested but unfamiliar with the Symbolics hardware/software environment. Symbolics Architecture - IEEE Computer, January 1987 The Symbolics Genera Programming Environment - IEEE Software November 1987 Christopher (Chris) J. Vogt - Computer Consultant - Lisp, AI, Graphics, etc. http://members.home.com/vogt/ From joswig@lavielle.com Fri, 3 Apr 1998 17:52:42 +0200 Date: Fri, 3 Apr 1998 17:52:42 +0200 From: Rainer Joswig joswig@lavielle.com Subject: Project LispOS, who will do what? At 15:45 Uhr -0500 02.04.1998, Richard Coleman wrote: >1) Mike and I have decided on a modified goal for the LispOS > project. Initially we are targeting a Common Lisp based > environment (based on CMUCL) that sits on top of Unix. We > hope to develop a free CLIM (Mike has made good progress on this), > as well as port and extend various other CL applications. > We hope to bundled all of this in an easy-to-use package. Sounds good for me! Who on this list would be supporting this approach? What do we/you have to offer? - I would help with a CLIM based UI for CL-HTTP (preferences, starting, ...). Greetings, Rainer Joswig Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041 Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/ From joswig@lavielle.com Fri, 3 Apr 1998 18:01:28 +0200 Date: Fri, 3 Apr 1998 18:01:28 +0200 From: Rainer Joswig joswig@lavielle.com Subject: Genera At 15:31 Uhr +0000 03.04.1998, Chris Bitmead wrote: >I heard the Sparc architecture has some support for tagged >designs. Is it comparable in that respect or not? Tag support on the SPARC is very limited. There was an article about the Lucid (I think) CL port to SPARC and how it used the SPARC processor (two (?) tag bits on the low bits). Did know about fixnums, references, and other data. An add instruction can work on fixnums, if other data is provided it would select another adding routine. But I guess this was mostly all. The SPARC design is influenced by a Smalltalk chip. >> The chip also has hardware support for ephemeral garbage collection, an interface >> to a co-processor, a way to do efficient burst mode transfers on the memory bus, >> and a special limited mode (FEP mode) for running some much more stylized Lisp >> code the load the virtual image, etc. MCL uses the memory management facility for its ephemeral GC on the 68k. There was an init to set an appropriate page size. There was also an article about GC support in the special ARM chip used in the Newton. But somebody from Apple told me that they didn't use it for the Newton OS. Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041 Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/ From gadbois@cyc.com Fri, 3 Apr 1998 10:43:40 -0600 Date: Fri, 3 Apr 1998 10:43:40 -0600 From: David Gadbois gadbois@cyc.com Subject: Genera Date: Fri, 3 Apr 1998 09:43:37 -0600 From: "Christopher J. Vogt" Kalman, did anything ever get published on the I-machine architecture? I can't seem to find anything. @InProceedings{ivory2, author="Weste, Neil and Terman, Chris and Schrobe, Howard and Sarrazin, David and Tan, David and Reti, Kalman and Nestler, Eric and Minsky, Henry and Corry, Alan and Cherry, Jim and Baker, Clark", title="The Symbolics Ivory Design and Verification Strategy", booktitle="Proceedings of the IEEE International Conference on Computer Design", year="1987", pages"506-511" } @InProceedings{ivory3, author="Baker, Clark and Chan, David and Cherry, Jim and Corry, Alan and Efland, Greg and Edwards, Bruce and Matson, Mark and Minsky, Henry and Nestler, Eric and Reti, Kalman and Sarrazin, David and Sommer, Charles and Tan, David and Weste, Neil", title="The Symbolics Ivory Processor: A 40 Bit Tagged Architecture Lisp Microprocessor", booktitle="Proceedings of the IEEE International Conference on Computer Design", year="1987", pages="512-514" } My BibTeX tags indicate that there is another paper, but I can't find the reference. --David Gadbois From ptw@pobox.com Fri, 3 Apr 1998 12:17:45 -0500 Date: Fri, 3 Apr 1998 12:17:45 -0500 From: P. T. Withington ptw@pobox.com Subject: Make LispM code FREE (fwd) On 4/3/98 02:07, Chris Bitmead wrote: >Is Open Genera (or whatever it's called) for the DEC Alpha, an >operating system unto itself, or does it run as an application >under UNIX? It runs as an app under unix, emulating a Symbolics Ivory-based Lisp Machine, which runs all of Genera which is "an operating system unto itself". The Open Genera machine appears on your net as a separate machine with its own IP address and supports all the facilities normally associated with a Lisp Machine. It utilizes Unix VM to efficiently emulate LispM virtual memory, and the GC is slightly changed to take advantage of that for efficiency (that is, all the GC features of the original chip are _not_ emulated). Another way of viewing it: Symbolics also sold co-processor cards for the Macintosh and Sun VME-based workstations that utilzed the host's peripherals for network, file, and other I/O. Open Genera is essentially a software co-processor. It piggy-backs on the Alpha network, you can assign it file partitions to create LMFS filesystems, it uses X for its console. From ptw@pobox.com Fri, 3 Apr 1998 12:27:50 -0500 Date: Fri, 3 Apr 1998 12:27:50 -0500 From: P. T. Withington ptw@pobox.com Subject: Genera On 4/3/98 10:31, Chris Bitmead wrote: >> Most importantly, it carries the 8-bits of tag through the entire datapath >and >> memory interface. The microengine can do tag comparison and dispatch in >parallel >> with an operation, so for example an add instruction can assume that the >operands >> are both fixnums and start doing the addition at the same time that the tag >> comparison hardware is comparing the tags. If there is a mismatch, that >microcycle >> causes the result not to be stored and a trap to be taken. > >I heard the Sparc architecture has some support for tagged >designs. Is it comparable in that respect or not? The SPARC only supports 2-bit tags and does so by stealing from the 32-bit word. In tagged mode, you only get 30-bit integers. The LispM supports 8-bit tags and full 32-bit integers. >> The chip also has hardware support for ephemeral garbage collection, an >interface >> to a co-processor, a way to do efficient burst mode transfers on the memory >bus, >> and a special limited mode (FEP mode) for running some much more stylized >Lisp >> code the load the virtual image, etc. > >How much of the GC is coded in hardware? The hardware support for GC on the LispM consists of word-granularity read barriers, page-granularity remembered sets, and invisible forwarding pointers. The collector itself is all software. The Open Genera emulator uses techniques similar to: Title: Real-time Concurrent Collection on Stock Multiprocessors Authors: Andrew Appel; John R. Ellis; Kai Li Publisher: Pub. Date: 07/88 Ident: ACM PLDI 88, SIGPLAN Notices 23, 7 (July 88), pp. 11-20 From joswig@lavielle.com Fri, 3 Apr 1998 19:46:07 +0200 Date: Fri, 3 Apr 1998 19:46:07 +0200 From: Rainer Joswig joswig@lavielle.com Subject: Genera At 10:43 Uhr -0600 03.04.1998, David Gadbois wrote: >My BibTeX tags indicate that there is another paper, but I can't find >the reference. Btw., http://www8.informatik.uni-erlangen.de/html/lisp/histlit.html has some ;-) lisp literature pointers. :-) Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041 Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/ From pisati@nichimen.com Fri, 03 Apr 1998 11:47:36 -0800 Date: Fri, 03 Apr 1998 11:47:36 -0800 From: Luca Pisati pisati@nichimen.com Subject: Genera P. T. Withington wrote: > > The hardware support for GC on the LispM consists of word-granularity > read barriers, page-granularity remembered sets, and invisible forwarding > pointers. The collector itself is all software. forwarding-pointers ... not that invisible :-) They gave me a few headaches ... I remember cases (inside of the S-Products) where EQ would fail because of forwarding pointers (I think it was associated to how CHANGE-CLASS was implemented.) -- Luca Pisati Manager of Graphics Software Voice: (310) 577-0518 Nichimen Graphics Fax: (310) 577-0577 12555 W. Jefferson #285 EMail: mailto:pisati@nichimen.com Los Angeles, CA 90066 Web: http://www.nichimen.com From coleman@math.gatech.edu Fri, 03 Apr 1998 16:18:55 -0500 Date: Fri, 03 Apr 1998 16:18:55 -0500 From: Richard Coleman coleman@math.gatech.edu Subject: Any CL software to deal with SGML/XML Does anyone know of any free CL software to handle SGML or XML? If not, are there any volunteers to write some, that would be used for the LispOS project? I have lots of sub-projects that would help speed the LispOS project. If people are interested in doing some hacking, I have lots of ideas. -- Richard Coleman coleman@math.gatech.edu From ptw@pobox.com Fri, 3 Apr 1998 16:58:28 -0500 Date: Fri, 3 Apr 1998 16:58:28 -0500 From: P. T. Withington ptw@pobox.com Subject: Genera On 4/3/98 14:47, Luca Pisati wrote: >P. T. Withington wrote: >> >> The hardware support for GC on the LispM consists of word-granularity >> read barriers, page-granularity remembered sets, and invisible forwarding >> pointers. The collector itself is all software. > >forwarding-pointers ... not that invisible :-) >They gave me a few headaches ... > >I remember cases (inside of the S-Products) where EQ would fail because of >forwarding pointers (I think it was associated to how CHANGE-CLASS was >implemented.) That's a slightly different use of forwarding pointers than what the GC uses. The GC-FORWARD pointer is only ever visible to the GC and is only used to "snap-out" additional references to an object that has already been copied. There are other classes of forwarding pointer, such as STRUCTURE-FORWARD, which is used on structures such as arrays or classes if they change in size to transparently update all old references. Nearly all instructions use memory cycles that will chase the forwarding pointer, so they are invisible. EQ, however, only compares addresses, so if you were to compare an old and new version of the "same" object, they would not compare. You wouldn't want EQ to check for forwarding every time would you? Instead, you must take care when working with objects that might grow. (I don't recall if EQL did the right thing. I do remember stubling across a function SYS:EQ-INCLUDING-FORWARDS in some old code... Other uses for forwarding pointers: When you RPLACD into a cdr-coded list, there is no CDR cell, so you have to invisibly forward the CAR to a new CONS. Dynamic closures used invisible forwarding to dynamically bind the global symbol-value to the captured value. The hardware deep binding cache used forwarding pointers to trigger a deep-binding lookup and to hold the global value. (The Ivory chip could operate in either shallow or deep binding mode, the latter intended for real-time and multi-processor systems.) From joswig@lavielle.com Fri, 03 Apr 1998 23:58:55 +0200 Date: Fri, 03 Apr 1998 23:58:55 +0200 From: Rainer Joswig joswig@lavielle.com Subject: Any CL software to deal with SGML/XML At 16:18 03.04.98 -0500, Richard Coleman wrote: >Does anyone know of any free CL software to handle >SGML or XML? There is an experimental XML parser provided with CL-HTTP. >I have lots of sub-projects that would help speed the >LispOS project. If people are interested in doing some hacking, >I have lots of ideas. Post them. From housel@acm.org Fri, 3 Apr 1998 14:05:04 -0800 Date: Fri, 3 Apr 1998 14:05:04 -0800 From: Peter Housel housel@acm.org Subject: Make LispM code FREE (fwd) Faré Rideau quoted RMS as saying: >The MIT AI lab is already planning to make the MIT Lisp Machine system >free--if they can find a copy of the sources. That may not be easy. >I don't have a copy myself. > >I will forward your message to them. > If the sources are released, they would be for the CONS architecture version of the MIT Lisp Machine, wouldn't they? If I recall correctly, the CONS architecture had fewer tag bits (four) than the Ivory. This would likely make emulation on a 32-bit machine a bit easier. Did the CONS have locatives? -Peter S. Housel- housel@acm.org From ptw@pobox.com Fri, 3 Apr 1998 19:27:53 -0500 Date: Fri, 3 Apr 1998 19:27:53 -0500 From: P. T. Withington ptw@pobox.com Subject: The Lisp Machine I've put two old (unpublished, until now) papers, "The Lisp Machine: Noble Experiment or Fabulous Failure?", and "The Symbolics Virtual Lisp Machine (extended abstract)", which might be amusing to this group, at . From gadbois@cyc.com Sat, 4 Apr 1998 15:08:59 -0600 Date: Sat, 4 Apr 1998 15:08:59 -0600 From: David Gadbois gadbois@cyc.com Subject: The Lisp Machine Date: Fri, 3 Apr 1998 19:27:53 -0500 From: "P. T. Withington" I've put two old (unpublished, until now) papers, "The Lisp Machine: Noble Experiment or Fabulous Failure?", and "The Symbolics Virtual Lisp Machine (extended abstract)", which might be amusing to this group, at . Wow, great papers! Any chance of ever seeing the full VLM paper? It occurs to me that there may be a couple of alternatives to doing the emulator in assembly. (This may have relevance if the MIT lispm sources ever get released.) Clearly, if performance permits, it would be better to do an emulator in a high-level language so as to allow portability and to take advantage of new implementations that have difference optimization characteristics: larger, differently mapped caches, more functional units, register renaming, etc. 1. Reschedule the output of the compiler to better take advantage of the chip's instruction issue regime, and move stuff around (using knowledge of the code) to get better instruction cache behavior. 2. Fix the compiler to do the right thing. Were these (and perhaps other) approaches rejected because doing it by hand made a big enough difference, or was it a time-to-market thing? --David Gadbois From reti@ai.mit.edu Sun, 5 Apr 1998 07:55 -0400 Date: Sun, 5 Apr 1998 07:55 -0400 From: reti@ai.mit.edu reti@ai.mit.edu Subject: Lisp and VLIW (was Re: Genera) Date: Fri, 3 Apr 1998 10:22 EST From: eric dahlman On Fri, 3 Apr 1998 reti@wilson.ai.mit.edu wrote: [snip] > Most importantly, it carries the 8-bits of tag through the entire datapath and > memory interface. The microengine can do tag comparison and dispatch in parallel > with an operation, so for example an add instruction can assume that the operands > are both fixnums and start doing the addition at the same time that the tag > comparison hardware is comparing the tags. If there is a mismatch, that microcycle > causes the result not to be stored and a trap to be taken. Here is a question that I have been kicking around for a little while about this type of thing. How well would lisp compile to a VLIW architecture with predicated execution? I'm not sure what you are asking about. I understand the VLIW part, not the predicated execution part. The issues of tag comparisons and the such being performed in parallel with the operations seem to be a gimmy source of instruction level parallelism which would be easy to take advantage of on such a processor. Could it be that the next generation of general purpose processors could be a real win for lisp? Has anyone looked into this issue? The reason, at least in my mind, for having special hardware for the tag comparisons is that they are very stylized and instead of taking up hardware that could be used for another higher-level operation, it is more efficient to only consume hardware resources commensurate to the task. That being said, it is clear that the VLM emulator gets back at least some of the performance lost to emulation by having a fairly high proportion of dual-issue instructions in the hand-crafter instruction dispatch loop. As Tucker Withington said, when the VLM was designed typical compilers wouldn't necessarily do as well. So, using instruction level parallelism in the hardware can get some of the same effect as having separate hardware. Just wondering, -Eric From ptw@pobox.com Mon, 6 Apr 1998 06:14:01 -0400 Date: Mon, 6 Apr 1998 06:14:01 -0400 From: P. T. Withington ptw@pobox.com Subject: The Lisp Machine On 4/4/98 16:08, David Gadbois wrote: > Date: Fri, 3 Apr 1998 19:27:53 -0500 > From: "P. T. Withington" > > I've put two old (unpublished, until now) papers, "The Lisp > Machine: Noble Experiment or Fabulous Failure?", and "The > Symbolics Virtual Lisp Machine (extended abstract)", which might be > amusing to this group, at . > >Wow, great papers! Any chance of ever seeing the full VLM paper? > >It occurs to me that there may be a couple of alternatives to doing >the emulator in assembly. (This may have relevance if the MIT lispm >sources ever get released.) Clearly, if performance permits, it would >be better to do an emulator in a high-level language so as to allow >portability and to take advantage of new implementations that have >difference optimization characteristics: larger, differently mapped >caches, more functional units, register renaming, etc. > >1. Reschedule the output of the compiler to better take advantage of >the chip's instruction issue regime, and move stuff around (using >knowledge of the code) to get better instruction cache behavior. > >2. Fix the compiler to do the right thing. > >Were these (and perhaps other) approaches rejected because doing it by >hand made a big enough difference, or was it a time-to-market thing? Strictly time-to-market. We didn't have time to build or wait for better compilers. The program to build the VLM was a last ditch effort to save the company. It exceeded our expectations, but it was not enough to overcome the outstanding debts. From dahlman@cs.colostate.edu Mon, 6 Apr 1998 09:39:25 -0600 (MDT) Date: Mon, 6 Apr 1998 09:39:25 -0600 (MDT) From: eric dahlman dahlman@cs.colostate.edu Subject: Lisp and VLIW (was Re: Genera) reti@ai.mit.edu writes: [stuff about VLIW and such cut] >I'm not sure what you are asking about. I understand the VLIW part, >not the predicated execution part. The point that I was trying to get at is that if you are using a VLIW model similar to IBM's ForestalPC you can basically execute multiple branches of a condition in parallel before the test of the condition is completed. When the result of the conditional test is available then the correct path of computation is selected and the others are discarded. (Warning.. what I just wrote was a gross simplification and should be treated as such.) The offshoot of this is that you could compile code which did say a fixnum add, flonum add, unbox + fixnum add, and unbox + flonum add in parallel with checking the operands' tags then keeping the result. I understand that this type of thing was done on the Symbolics where tag comparisons and operations, like addition, were done in parallel. If the tags were wrong the result was discarded. However, my account of the Symbolics' behavior is purely hearsay. >>The issues of tag comparisons and the such being performed in parallel >>with the operations seem to be a gimmy source of instruction level >>parallelism which would be easy to take advantage of on such a >>processor. Could it be that the next generation of general purpose >>processors could be a real win for lisp? Has anyone looked into this >>issue? >The reason, at least in my mind, for having special hardware for the >tag comparisons is that they are very stylized and instead of taking >up hardware that could be used for another higher-level operation, it >is more efficient to only consume hardware resources commensurate to >the task. Conversely, is it also not beneficial to have a general mechanism that can be put to use when possible. For instance, the compiler has proven that the following section of code will only use fixmums so we can use the ALU that "normally" would be doing tag checking for "real" work. >That being said, it is clear that the VLM emulator gets back at least >some of the performance lost to emulation by having a fairly high >proportion of dual-issue instructions in the hand-crafter instruction >dispatch loop. As Tucker Withington said, when the VLM was designed >typical compilers wouldn't necessarily do as well. >So, using instruction level parallelism in the hardware can get some >of the same effect as having separate hardware. That was my impression. What I am really interested is a sort of empirical assessment of the situation. For instance, I would like to compare the performance of a new (fictional) VLIW lisp compiler "Monty" and GCC version 7.3 (equally fictional) which is really good at optimizing C code for VLIW processors. The reason that this comparison is interesting is that there is usually only a bounded amount of parallelism in a given algorithm or problem, and furthermore this amount of parallelism can vary with regard to which part of the algorithm you are in. So lets say that when compiling a given C program GCC is able to use 70% of the parallel resources of the processor. If the Monty compiler was sufficiently smart to fit our "Lisp overhead" into the remaining 30% of the processor's resources we could have our cake and eat it too. "As fast as C performance(tm)" with all the "Cool dynamic Lisp features(tm)". This is all conjecture however since most of these things are simply vaporware. There are lots of smart people trying to come up with ways to get ILP out of C code and they may be good enough to raise C's utilization of the processor's parallel capabilities to 95% where we would not have a chance. However, this is not practical wherever there are a lot of data dependencies in the calculations and in these cases the added costs of Lisp could simply be swept under the rug. Then again this could all just be wishful thinking, -Eric Note: All numbers quoted in the above are entirely fictional and resemblance to numbers living or dead is purely coincidental. From dahlman@cs.colostate.edu Mon, 6 Apr 1998 09:50:19 -0600 (MDT) Date: Mon, 6 Apr 1998 09:50:19 -0600 (MDT) From: eric dahlman dahlman@cs.colostate.edu Subject: Lisp and VLIW (was Re: Genera) eric dahlman writes without proofreading: > > Conversely, is it also not beneficial to have a general mechanism that Oops. It is beneficial not *not* beneficial. > can be put to use when possible. For instance, the compiler has > proven that the following section of code will only use fixmums so we > can use the ALU that "normally" would be doing tag checking for "real" > work. From ptw@pobox.com Mon, 6 Apr 1998 12:34:51 -0400 Date: Mon, 6 Apr 1998 12:34:51 -0400 From: P. T. Withington ptw@pobox.com Subject: Lisp and VLIW (was Re: Genera) On 4/6/98 11:39, eric dahlman wrote: >That was my impression. What I am really interested is a sort of >empirical assessment of the situation. For instance, I would like to >compare the performance of a new (fictional) VLIW lisp compiler >"Monty" and GCC version 7.3 (equally fictional) which is really good The LispM claimed to use 10% additional hardware in support of Lisp. Compiler technology stunk back then, so the solution was to do more in hardware. But that was considered too expensive back then. Now we have the situation were 100% (or 200%, or 300%, etc.) additional hardware is available, because hardware is so cheap. But is it the case that compiler technology is so good that it doesn't need (or can't use) that extra hardware? Or is C so low level that there is no parallelism to discover? Let's bring back lousy compilers for high level languages so we can utilize all this cheap hardware!-). From gadbois@cyc.com Mon, 6 Apr 1998 18:19:46 -0500 Date: Mon, 6 Apr 1998 18:19:46 -0500 From: David Gadbois gadbois@cyc.com Subject: Lisp and VLIW (was Re: Genera) Seen in comp.arch today: VLIW's original origins _was_ from writable control store. VLIW started out as a regularization of the control bits of multiple functional units, to make things easier to control, and things like trace scheduling come from hand techniques for writing microcode. Look up the history of FPS. --David Gadbois From mikemac@teleport.com Mon, 6 Apr 1998 18:27:06 -0700 (PDT) Date: Mon, 6 Apr 1998 18:27:06 -0700 (PDT) From: Mike McDonald mikemac@teleport.com Subject: CLIM 2.0 spec is on-line now I've converted the CLIM 2.0 spec to HTML and it's available as: http://www.mikemac.com/mike/clim/cover.html If you find typo or translation errors, send them to me. I'll make the HTML sources available in a few days. Mike McDonald mikemac@mikemac.com From johan@up2data.se Tue, 7 Apr 1998 21:55:55 +0200 Date: Tue, 7 Apr 1998 21:55:55 +0200 From: Johan Strand (up2data) johan@up2data.se Subject: Lizp This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BD626F.F0B9EB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! =20 I have found your E-mail adress on a lisp related site, and I would like = you to take a look at Lizp at http://www.lizp.com =20 Lizp is an advanced interpreter and compiler for the Win32 environment. = Lizp exposes and extends the Win32 APIs, and is ideal for producing = system and network utilities for Windows NT and Windows 95. =20 On the site you can currently download Lizp v10.750 =20 Sincerely, =20 Johan Strand, up2data Computer Systems, Sweden http://www.up2data.se ------=_NextPart_000_0004_01BD626F.F0B9EB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
 
I have found your E-mail adress on a lisp related = site, and I=20 would like you to take a look at Lizp at http://www.lizp.com
 
Lizp is an advanced interpreter and compiler for the = Win32=20 environment. Lizp exposes and extends the Win32 APIs, and is ideal for = producing=20 system and network utilities for Windows NT and Windows 95.
 
On the site you can currently download Lizp=20 v10.750
 
Sincerely,
 
Johan Strand,
up2data Computer Systems, Sweden
http://www.up2data.se
------=_NextPart_000_0004_01BD626F.F0B9EB10-- From pp@enterprise.net Wed, 8 Apr 1998 07:49:34 +0000 Date: Wed, 8 Apr 1998 07:49:34 +0000 From: Peter Paine pp@enterprise.net Subject: Genera At 3:43 PM +0000 98/4/3, Christopher J. Vogt wrote: >Kalman, did anything ever get published on the I-machine architecture? I >can't >seem to find anything. A UK company, Racal-Norsk, spent some 10 to 20 person years analysing and writing up a formal specification of MIT Zetalisp. The company went into oblivion over a decade ago, but the copies of the spec gather dust under the beds of some of the engineers who wrote it. The document is exhaustive and rigorous and was the foundation of a working implementation of Zetalisp which ran on Norsk Data superminis. It draws together as one whole the disperate contibutions and evolutionary stands which made up MIT Zetalisp. It was not published publically, it was considered the crown jewels of the company. I believe that any lispos work which derives from Zetalisp would find this document extremely valuable (not that I am suggesting that this would or would not be a wise course for lispos). I understand that it is the only formal spec of lispm lisp - which is total wasted were it is. Despite incredulity from the US lisp machine establishment the spec, company and developments were successful - perhaps in part because some of the prime movers cut their teeth at the beginning of the 80s with the CADR, besides having RMS and others on the project. Anyway I suspect that in those days Lisp outside the US was seen only as an sales operation. The company evapourated whilst at full steam and a win (in a Lisp Machine sense) when the joint venture which formed it fell out of bed. At that time, Racal-Norsk (I believe) owned the exclusive rights to MIT Zetalisp in the UK (cheekily (falsely) Symbolics Genera products distributed in the UK claimed that right) and R-N had a worldwide (ex USA) right to Zetalisp distribution. I suspect that neither Racal nor Norsk Data would even recognise the word Lisp today, but if they have residual rights to MIT Zetalisp, might there be a chance through that route to free Lispm Lisp (though I would expect the licences were time limited, but I cannot remember). My copy of the spec is probably not complete, nor in digital form, other are - though their possessors have moved on to other pastures. Of course the really valuable input to the lispos project could be the dormant Lispm movers and shakers from MIT, Symbolics, Xerox, Texas, LMI, etc. A good listing of whose names can be found in the second Symbolics world distribution released after the namespace was introduced (Genera 7.1 ?), by inspecting the namespace instance, you can browse backwards into both Symbolics and MIT's complete namespace data (someone didn't do a good enough house cleaning before shipping). Otherwise what about the simulation built by Symbolics from which to develop the Ivory architecture, I remember hearing some Symbolics heavyweights rave about this. I understood that this worked as an emulator which could model both sides of the interface between hardware and lispm primitive instructions, and in an accessible object oriented manner. Or is this heritage just so much old rope, and what is needed is new minds, new ventures, new designs, ... just as Lispm/Lisp needs a new image, new packaging, new customers/users and uses, perhaps escaping the ivory tower and entering the mainstream. -P2 pp@enterprise.net From kem@franz.com Wed, 08 Apr 1998 11:01:34 -0700 Date: Wed, 08 Apr 1998 11:01:34 -0700 From: Kelly Murray kem@franz.com Subject: Genera > Or is this heritage just so much old rope, and what is needed is new minds, > new ventures, new designs, ... just as Lispm/Lisp needs a new image, new > packaging, new customers/users and uses, perhaps escaping the ivory tower > and entering the mainstream. That is certainly how I feel. Simply repeating the mistakes of the past isn't the answer. But learning from those mistakes and taking a fresh approach in new web world is the way forward. -Kelly From davies@pobox.com Wed, 8 Apr 1998 19:44:49 -0700 Date: Wed, 8 Apr 1998 19:44:49 -0700 From: Byron Davies davies@pobox.com Subject: Education as an application I have become very interested in education as an application domain. I've been doing extensive volunteer work with the Arizona Learning Technology Partnership, an organization whose goal is to foster the use of "learning technology" (computers, software, telecommunications) to improve the quality of education in Arizona K-12 schools. Learning technology is now becoming a major area for federally supported R&D (e.g., http://www.adlnet.org/, http://isx.com/isxcorp/programs/ta.html and http://www.atp.nist.gov/atp/97wp-lt.htm), with money coming from both NIST and DOD. It's possible that there's still too much technical R&D left to do in this area to begin a volunteer effort, but maybe not. If intelligent tutoring requires solving the "AI problem", then we're in trouble. But many successful systems seem to be emerging, without the need for heavy-duty AI capabilities. With Lisp and Linux on my mind, I'm thinking about ways to accelerate the development of educational software in parallel with existing R&D efforts. There's already an IEEE standards effort (P1484) underway at http://www.manta.ieee.org/p1484/, developing an ontology and a reference architecture for learning technology. But even with a set of standards, developing a complete K-12 curriculum suite is a massive undertaking. People are struggling to find a business model by which industry will focus on K-12 software in a major way. Most of the money is going into software for remedial education once graduates reach industry and into DOD-supported computer-based training efforts. What about setting up a Linux-like effort for educational software? I can imagine some months of hacking by a number of people, just replicating the behavior of existing educational software and creating a free library of classes and user interfaces that would feed into the standards efforts and provide the basis for a rapidly evolving body of learning software. Someone could focus on Math Blaster etc., someone else on Pierian Springs software, others on DOD-supported computer-aided instruction, and others on published university research. I envision the effort being based on Lisp, CLIM, and CL-HTTP -- and other Lisp-based tools -- to get the biggest productivity boost. Once it gets started, I can imagine a host of people -- not just programmers but also curriculum developers and teachers -- donating their ideas and talents to create a net-based educational utility. Any interest? Is someone already doing this? Are there enough Lisp programmers with interest in educational software to get this off the ground? Or would a commercial, proprietary effort be a better way to exploit the power of Lisp for educational software? Byron From Ernst.van.Waning@infometrics.nl Thu, 9 Apr 1998 10:27:13 +0200 (MET DST) Date: Thu, 9 Apr 1998 10:27:13 +0200 (MET DST) From: Ernst van Waning Ernst.van.Waning@infometrics.nl Subject: Education as an application This sounds like a great idea to me. Education will only become more important in the future for any of us and an educational system allowing world-wide access is well worth working for. At 19:44 8-04-98 -0700, Byron Davies wrote: >I have become very interested in education as an application domain. I've >been doing extensive volunteer work with the Arizona Learning Technology >Partnership, an organization whose goal is to foster the use of "learning >technology" (computers, software, telecommunications) to improve the >quality of education in Arizona K-12 schools. > > ... > >What about setting up a Linux-like effort for educational software? I can >imagine some months of hacking by a number of people, just replicating the >behavior of existing educational software and creating a free library of >classes and user interfaces that would feed into the standards efforts and >provide the basis for a rapidly evolving body of learning software. >Someone could focus on Math Blaster etc., someone else on Pierian Springs >software, others on DOD-supported computer-aided instruction, and others on >published university research. I envision the effort being based on Lisp, >CLIM, and CL-HTTP -- and other Lisp-based tools -- to get the biggest >productivity boost. > > ... > >Any interest? Is someone already doing this? Are there enough Lisp >programmers with interest in educational software to get this off the >ground? Or would a commercial, proprietary effort be a better way to >exploit the power of Lisp for educational software? Ernst van Waning email: evw@infometrics.nl Infometrics G.H. Breitnerlaan 5, 1399 XD Muiderberg, the Netherlands tel+fax: +31 (0)294 26 24 21 or +31 (0)878 10 00 40 SAG bv Max Euweplein 30, 1017 MB Amsterdam, the Netherlands tel: +31 (0)20 531 26 20; fax: +31 (0)20 639 21 59 From gyro@zeta-soft.com Thu, 9 Apr 1998 15:49:47 -0700 (PDT) Date: Thu, 9 Apr 1998 15:49:47 -0700 (PDT) From: Scott L. Burson gyro@zeta-soft.com Subject: Make LispM code FREE (fwd) From: "Peter Housel" Date: Fri, 3 Apr 1998 14:05:04 -0800 If the sources are released, they would be for the CONS architecture version of the MIT Lisp Machine, wouldn't they? You mean the CADR. This version of the system was also used on the LMI Lambda, and the TI Explorer system diverged from it only slightly. The CONS was only a prototype. Its hardware was recycled to make CADR-1. If I recall correctly, the CONS architecture had fewer tag bits (four) than the Ivory. This would likely make emulation on a 32-bit machine a bit easier. The CADR, Lambda, and Explorer were all 32-bit machines. One could build a hardware emulator for them on a 32-bit RISC machine without horrendous difficulty. Might be an interesting exercise, although if the Open Genera source (or even binary) becomes freely available, I'd just use that; used, if slightly obsolete, Alphas are not too expensive these days. Did the CADR have locatives? Yes. -- Scott From gyro@zeta-soft.com Thu, 16 Apr 1998 14:27:07 -0700 (PDT) Date: Thu, 16 Apr 1998 14:27:07 -0700 (PDT) From: Scott L. Burson gyro@zeta-soft.com Subject: Test message Hello? Did the list really go suddenly quiet a week ago, or is there a technical problem? -- Scott From mikemac@teleport.com Thu, 16 Apr 1998 14:51:29 -0700 (PDT) Date: Thu, 16 Apr 1998 14:51:29 -0700 (PDT) From: Mike McDonald mikemac@teleport.com Subject: Test message >From lispos-request@math.gatech.edu Thu Apr 16 14:50:12 1998 >Resent-Date: Thu, 16 Apr 1998 17:27:24 -0400 (EDT) >Date: Thu, 16 Apr 1998 14:27:07 -0700 (PDT) >From: "Scott L. Burson" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >To: LispOS@math.gatech.edu >Subject: Test message >Resent-Message-ID: <"Vg2tR3.0.Wn6.xUdDr"@math> >Resent-From: lispos@math.gatech.edu >X-Mailing-List: archive/latest/2281 >X-Loop: lispos@math.gatech.edu >Resent-Sender: lispos-request@math.gatech.edu > >Hello? Did the list really go suddenly quiet a week ago, or is there a >technical problem? > >-- Scott > We're all hacking away! Mike McDonald mikemac@mikemac.com (Yes, it's gotten very quite!) From kclark@superfly.ntlug.org Wed, 22 Apr 1998 09:39:26 -0500 Date: Wed, 22 Apr 1998 09:39:26 -0500 From: Kendall Clark kclark@superfly.ntlug.org Subject: object stores On Wed, Apr 22, 1998 at 10:50:34AM -0400, Kragen wrote: >Frontier, a scripting language for the Mac (and now for Win32), has >popularized the idea of persistent object stores among some >developers. Casbah started as an attempt to duplicate Frontier's >functionality on Linux with Perl, and will include the same feature. And even more pertinent to this list, Casbah is going to use Guile (basically, GNU's Scheme) to extend this object store. Once the language translators are written for Guile, we'll be able to offer scripters their choice: Scheme, CTAX, Perl, Python, TCL, even elisp. It's a fun project. If you have Scheme experience, or even if you don't, and are interested in building a content management system, you may want to look at http://www.ntlug.org/casbah/ Best, Kendall Clark -- It is the business of the future to be dangerous. - Alfred North Whitehead From kragen@pobox.com Wed, 22 Apr 1998 10:50:34 -0400 (EDT) Date: Wed, 22 Apr 1998 10:50:34 -0400 (EDT) From: Kragen kragen@pobox.com Subject: object stores Frontier, a scripting language for the Mac (and now for Win32), has popularized the idea of persistent object stores among some developers. Casbah started as an attempt to duplicate Frontier's functionality on Linux with Perl, and will include the same feature. Kragen From joswig@lavielle.com Wed, 22 Apr 1998 18:40:07 +0200 Date: Wed, 22 Apr 1998 18:40:07 +0200 From: Rainer Joswig joswig@lavielle.com Subject: object stores >Frontier, a scripting language for the Mac (and now for Win32), has >popularized the idea of persistent object stores among some >developers. Casbah started as an attempt to duplicate Frontier's >functionality on Linux with Perl, and will include the same feature. Symbolics sold Statice. Itasca is another commercial option. MCL has WOOD (used in some applications like Apple Dylan, ...) included. Heiko Kirschke has developed Plob!. Etc. Franz has written a Web server based on an object store and ACL. Etc. Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041 Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.com/~joswig/ From kragen@pobox.com Wed, 22 Apr 1998 13:19:35 -0400 (EDT) Date: Wed, 22 Apr 1998 13:19:35 -0400 (EDT) From: Kragen kragen@pobox.com Subject: object stores On Wed, 22 Apr 1998, Rainer Joswig wrote: > >Frontier, a scripting language for the Mac (and now for Win32), has > >popularized the idea of persistent object stores among some > >developers. Casbah started as an attempt to duplicate Frontier's > >functionality on Linux with Perl, and will include the same feature. > > Symbolics sold Statice. > Itasca is another commercial option. > MCL has WOOD (used in some applications like Apple Dylan, ...) included. > Heiko Kirschke has developed Plob!. > Franz has written a Web server based on an object store and ACL. I didn't mean to imply that Dave Winer invented object stores. I meant that Frontier is extremely popular (and useful), and it is likely that Casbah will be, too. So this may play a major role in getting the software out to the people. Worse is better. Kragen From cmh@greendragon.com Wed, 22 Apr 1998 21:32:25 -0500 Date: Wed, 22 Apr 1998 21:32:25 -0500 From: Chris Hanson cmh@greendragon.com Subject: object stores I don't see Frontier's back-end really as an "object database." I think a better term for it would be "hierarchical database." My understanding of an object database is that it (transparently) allows instances to be persistent. Is that the case, or am I totally off-base? From papresco@technologist.com Thu, 23 Apr 1998 11:18:25 -0400 Date: Thu, 23 Apr 1998 11:18:25 -0400 From: Paul Prescod papresco@technologist.com Subject: [Fwd: [ANNOUNCE] JOS Project 1998 Q1 Report] This is a multi-part message in MIME format. --------------F9DA1D23EABC2CDA12FA513F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Perhaps this is of interest, just to see how others are approaching similar projects. -- Paul Prescod - http://itrc.uwaterloo.ca/~papresco "Perpetually obsolescing and thus losing all data and programs every 10 years (the current pattern) is no way to run an information economy or a civilization." - Stewart Brand, founder of the Whole Earth Catalog http://www.wired.com/news/news/culture/story/10124.html --------------F9DA1D23EABC2CDA12FA513F Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from calum.csclub.uwaterloo.ca (root@calum.csclub.uwaterloo.ca [129.97.134.11]) by itrc.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id KAA25248 for ; Thu, 23 Apr 1998 10:31:03 -0400 (EDT) Received: from mx03.globecomm.net ([207.51.48.30] EHLO mx03.globecomm.net ident: NO-IDENT-SERVICE [port 58566]) by calum.csclub.uwaterloo.ca with ESMTP id <205096-11552>; Thu, 23 Apr 1998 10:30:56 -0400 Received: from top.spin.de (top.spin.de [194.112.98.248]) by mx03.globecomm.net (8.8.8/8.8.0) with ESMTP id KAA09165; Thu, 23 Apr 1998 10:22:18 -0400 (EDT) Received: (from majordomo@localhost) by top.spin.de (8.8.4/8.8.4) id NAA04400 for jos-announce-outgoing; Thu, 23 Apr 1998 13:55:10 +0200 Received: from god.hq.spin.de (u1.spin.wwl.de [194.195.130.176]) by top.spin.de (8.8.4/8.8.4) with ESMTP id NAA04370 for ; Thu, 23 Apr 1998 13:55:05 +0200 Received: from warpnt (warpnt [192.168.1.2]) by god.hq.spin.de (8.8.5/8.8.5) with SMTP id OAA23990 for ; Thu, 23 Apr 1998 14:06:44 +0200 Message-ID: <05aa01bd6eb6$ea0a78e0$0201a8c0@warpnt.hq.spin.de> From: "Markus Peter" To: Subject: [ANNOUNCE] JOS Project 1998 Q1 Report Date: Thu, 23 Apr 1998 14:54:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7BIT X-MIME-Autoconverted: from quoted-printable to 8bit by top.spin.de id NAA04392 Sender: owner-jos-announce@spin.de Precedence: bulk The JOS Project (tm) 1998 First Quarter Status Report TABLE OF CONTENTS ~~~~~~~~~~~~~~~~~ * Overview * Major Items * Project Summaries * 1Q 1998 Meeting Minutes * Contribution Summary * Second Quarter Goals OVERVIEW ~~~~~~~~ The JOS Project(tm) is a collaborative undertaking by an international group of programmers and enthusiasts aimed at the creation of a free and open Java(tm) based operating system. The end product will be an operating system that will run 100% Java(tm) applications on a Intel 386/486 class machine with 8MB memory and a 60 MB hard drive. JOS intends to support built-in networking, remote administration, multi-user support, and other world class operating system features. The stretch goal includes multiple VM support to allow seamless integration of future operating system ideals such as distributed computing and orthogonal persistence. Members of the design team are also looking into CORBA support for inter-vm and distributed communication for foreign system compatibility. The JOS Project had a respectable first quarter growth rate with over 2000 hours donated by experienced architects and programmers. This was double the 1997 fourth quarter contribution. Project hours were spent focusing on infrastructure, analysis, design and implementation. JOS is a ground floor opportunity for dedicated, creative individuals interested in impacting the software world. MAJOR ITEMS ~~~~~~~~~~~ Infrastructure: The Wiki has been refined to provide control and support for related industry groups interested in joint collaboration and development. The Wiki has tripled in size and now contains over 700 pages of discussions relating but not limited to analysis, design, specifications, and references. A chat server was added to the web site for real time conferences and group meetings. In order to centrally manage JOS code a source server has been put into production. These combined infrastructure investments allow JOS the capability of hosting a scalable, highly productive distributed development team. Operating System Kernel: The JOS Project consented on using the RTEMS real-time executive kernel as a working seed to implement the operating system around. RTEMS provides immediate access to i386, PowerPC, 68k, and other processor architectures. This allows JOS to scale from small embedded systems to large multi-user installations. Notes: RTEMS is a free-software kernel developed and maintained by OAR Corporation (www.oarcorp.com). PROJECT SUMMARIES ~~~~~~~~~~~~~~~~~ A) FILE SYSTEM A working Pure Java File System has been developed: * Pluggable File System architecture (VFAT is here, ext2fs in preparation) * GUI test environment (JosScout) * Native disk drivers are in preparation B) DRIVER INTERFACE We have started to develop a driver interface to allow for Java base drivers. C) KERNEL We have a bootable program which says "Welcome to JOS". We also have a minimal 100K program, built on top of RTEMS, which says "Hello World". These two building blocks provide the seed for our kernel. D) BROWSER We are building a Java WWW Browser (JoZilla) that will support Java, CORBA IIOP via JacORB, and ECMAScript. E) XML FRAMEWORK The XAS group will provide XML parsing, Object Tree Factories, and Java Bean Application Frameworks. The XML Framework will provide an infrastructure for XML based applications. F) JOS APPLICATIONS AND UTILITIES We are working on applications and system utilities such as a plain text editor, system resource monitoring utility, internationalization resource utility, user based customization registry, and many other key user level programs that will make JOS a success. G) YOUR PROJECT GOES HERE We are always open for more project ideas and a brilliant person like yourself to make it happen. 1Q 1998 MEETING MINUTES ~~~~~~~~~~~~~~~~~~~~~~~~ JFA JOS applauds the JavaLobby's effort to advance and support free software. RTEMS Kaffe is discussed briefly. It needs serious hacking before it will be useful to us. Japhar is mentioned, but none present seem to know much about it. Japhar discussion should start on the kernel list. KERNEL/GENERAL The idea of hacking Linux to provide a development platform was explored. This gives us a working platform to build off of now, so non kernel work can get started. Also discussed is an RTEMS based development platform, with Linux drivers. JosDevelopmentPlatform is started to discuss such things. It looks like JOS will be using the RTEMS kernel. JVM There is an existing port of Kaffe to RTEMS, but it needs some work still. A Java Virtual Machine Group will be formed. CONTRIBUTERS FOR 1Q 1998 ~~~~~~~~~~~~~~~~~~~~~~~~ Name Hours Comments ------------------------ ----- --------------------------------------------- Stephan Borg 350 Admin, Application Utility, Plain Text Editor Clark Evans 240 Admin, Kernel *Thomas Winzig 240 Source Server *Markus Peter 240 Admin, Kernel Robert Fitzsimons 200 Loaders, managers, drivers, loader *Ray Shpeley 180 Kernel Stefan Reich 125 FileSystem, API, General Discussion *Jeroen C. van Gelderen 120 Kernel, Security Dmitri Kondratiev 100 XML Framework, Kernel Brad Neuberg 70 Admin, XML Framework Omega Baphomet 60 JoZilla, Registry *Chris Bergstresser 60 Admin, Shell *Pehr Anderson 60 Kernel, Networks *Maxim Kizub 60 Kernel *John D. DeCuir 60 Discussion Bill Rehm 50 Garbage Collection, VM design *Lee Daniel Crocker 30 Discussion *Augusto Sellhorn 30 Discussion *Ian Davis 30 VM Design *Ben Knowles 20 Licensing, Admin Linus Larsson 20 Open Doc, DocSet, XML Kristopher Foster 12 HTTP,CSI, Command Line Utilities Matthew Caswell 10 Admin,Multi-Process emulator 1Q 1998 APPX. TOTAL 2367 HOURS * Times not reported, Clark Evans estimated. CONTRIBUTERS FOR 4Q 1997 ~~~~~~~~~~~~~~~~~~~~~~~~ Bill Rehm , Chris Bergstresser , Clark Evans , Dmitri Kondratiev , Ian Davis , Joubin , Lee Daniel Crocker , Markus Peter , Maxim Kizub , Ray Shpeley , Stephan Borg , Stefan Reich , Thomas Winzig , Tim Taylor 4Q 1997 APPX. TOTAL 1000 HOURS SECOND QUARTER GOALS ~~~~~~~~~~~~~~~~~~~~ JVM - We would like a minimal Java Virtual Machine to run on top of RTEMS. We expect that it will support Java Byte Codes and some of the java.lang.* package. Administrative - We would like to formalize our license and create our legal organizational structure. Adding revision control to the source server and allowing image uploads to the Wiki web are also high priority items. Applications - More applications are on the way. -- Clark Evans ( clark.evans@jos.org ) and Markus Peter ( warpi@jos.org ) --------------F9DA1D23EABC2CDA12FA513F-- From chrisb@Ans.Com.Au Fri, 24 Apr 1998 02:49:35 +0000 Date: Fri, 24 Apr 1998 02:49:35 +0000 From: Chris Bitmead chrisb@Ans.Com.Au Subject: object stores Chris Hanson wrote: > > I don't see Frontier's back-end really as an "object database." I think a > better term for it would be "hierarchical database." > > My understanding of an object database is that it (transparently) allows > instances to be persistent. Is that the case, or am I totally off-base? No, an object database is not defined by transparency. An object database is one which supports the object model. i.e. object relationships, inheritence etc etc. Some object databases might have a C++ interface, but they don't cease to be an object database when you choose to use the C interface (which naturally is not transparent). Of course, most sensible object databases make themselves as transparent as possible. -- Chris Bitmead http://www.ans.com.au/~chrisb mailto:chrisb@ans.com.au From lucameyer@yahoo.com Sat, 25 Apr 1998 21:27:56 -0400 (EDT) Date: Sat, 25 Apr 1998 21:27:56 -0400 (EDT) From: lucameyer@yahoo.com lucameyer@yahoo.com Subject: On-line survey: I need your assistance ***************************************************************** DISCLAIMER: This is a one-time invitation to participate to an academic market research project. In order to draw a representative sample of Internet user your email address was randomly generated. Should this email be most unwelcome to you, I truly apologise and I inform you that you shall not receive any other solicitation from myself. ***************************************************************** I am a graduate student at the Katholieke Universiteit Leuven in Belgium and I am conducting a survey on preference of courier services among businesses operating on the Internet. If you are employed or run your own business, please take the time to answer to my on-line questionnaire by visiting one of the following Web sites: http://sp20.cc.kuleuven.ac.be:8093/index.htm http://users.skynet.be/lmc/kul_project/index.htm or by writing an email to lucameyer@yahoo.com to require an electronic or paper version of the questionnaire. As a small taken of my appreciation for your assistance with this project and thanks to the sponsoring of a professional organisation in the international postal services business, I will draw 10 cash prizes worth 100 US$ each among all the completed surveys. Sincerely yours, Luca Meyer International Study Program of Statistics Katholieke Universiteit Leuven lucameyer@yahoo.com From dwighth@ipa.net Mon, 27 Apr 1998 00:10:36 -0500 Date: Mon, 27 Apr 1998 00:10:36 -0500 From: Dwight Hughes dwighth@ipa.net Subject: the "standard" development platform? Since I haven't quite caught up with the recent LispOS mail, I wanted to be clear about what will be the "standard" development platform -- if I read the right messages this would seem to be FreeBSD and CMUCL. Correct? Also, it would seem that the ultimate questions of what to base the initial LispOS kernel development on and what the kernel might look like have been postponed until we actually have some code to _run_ on it. (I direct this primarily to Richard Coleman or Mike McDonald.) -- Dwight From mikemac@teleport.com Mon, 27 Apr 1998 10:28:20 -0700 (PDT) Date: Mon, 27 Apr 1998 10:28:20 -0700 (PDT) From: Mike McDonald mikemac@teleport.com Subject: the "standard" development platform? >From lispos-request@math.gatech.edu Sun Apr 26 22:30:32 1998 >Resent-Date: Mon, 27 Apr 1998 01:06:52 -0400 (EDT) >From: "Dwight Hughes" >To: "LispOS Project" >Subject: the "standard" development platform? >Date: Mon, 27 Apr 1998 00:10:36 -0500 >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >Resent-Message-ID: <"LEj1b2.0.MA2.h91Hr"@math> >Resent-From: lispos@math.gatech.edu >X-Mailing-List: archive/latest/2291 >X-Loop: lispos@math.gatech.edu >Resent-Sender: lispos-request@math.gatech.edu > >Since I haven't quite caught up with the recent LispOS mail, >I wanted to be clear about what will be the "standard" >development platform -- if I read the right messages this >would seem to be FreeBSD and CMUCL. Correct? I believe Richard has chosen Linux and CMUCL. (Linux or FreeDSB shouldn't make much difference, at least in the early stages.) I'm using ACL under Linux for my initial developement work on CLIM. (CMUCL doesn't have CLOS based streams yet. One of the guys on the cmucl-imp team is working on that.) >Also, it would seem that the ultimate questions of what to >base the initial LispOS kernel development on and what the >kernel might look like have been postponed until we actually >have some code to _run_ on it. > >(I direct this primarily to Richard Coleman or Mike McDonald.) > >-- Dwight Lots and lots of stuff should be generic Common Lisp so it should run on any CL platform. Mike McDonald mikemac@mikemac.com From coleman@math.gatech.edu Mon, 27 Apr 1998 23:56:09 -0400 Date: Mon, 27 Apr 1998 23:56:09 -0400 From: Richard Coleman coleman@math.gatech.edu Subject: the "standard" development platform? > >Since I haven't quite caught up with the recent LispOS mail, > >I wanted to be clear about what will be the "standard" > >development platform -- if I read the right messages this > >would seem to be FreeBSD and CMUCL. Correct? > > I believe Richard has chosen Linux and CMUCL. (Linux or FreeDSB > shouldn't make much difference, at least in the early stages.) Actually, I'm using FreeBSD 2.2.5 and CMUCL. But as Mike said, that doesn't really make a difference at the moment. My progress has been slowed down somewhat, since I've had trouble building CMUCL from source. But I think I've got that licked now, with some help from Ray. > I'm using ACL under Linux for my initial developement work on CLIM. (CMUCL > doesn't have CLOS based streams yet. One of the guys on the cmucl-imp > team is working on that.) > > >Also, it would seem that the ultimate questions of what to > >base the initial LispOS kernel development on and what the > >kernel might look like have been postponed until we actually > >have some code to _run_ on it. > > > >(I direct this primarily to Richard Coleman or Mike McDonald.) > > > Lots and lots of stuff should be generic Common Lisp so it should > run on any CL platform. > > Mike McDonald > mikemac@mikemac.com > From dwighth@ipa.net Mon, 27 Apr 1998 23:46:28 -0500 Date: Mon, 27 Apr 1998 23:46:28 -0500 From: Dwight Hughes dwighth@ipa.net Subject: the "standard" development platform? | From: Richard Coleman [--snip--] | |Actually, I'm using FreeBSD 2.2.5 and CMUCL. But as Mike said, |that doesn't really make a difference at the moment. | |My progress has been slowed down somewhat, since I've had trouble |building CMUCL from source. But I think I've got that licked now, |with some help from Ray. Is there a good how-to on building CMUCL on Linux or FreeBSD available anywhere? I expect to be doing this in about a week and I could use the help. Thanks. -- Dwight From kragen@pobox.com Tue, 28 Apr 1998 18:17:27 -0400 (EDT) Date: Tue, 28 Apr 1998 18:17:27 -0400 (EDT) From: Kragen kragen@pobox.com Subject: Linux and GC One particularly interesting garbage-collection method involves copying the entire VM of a process, scanning it for garbage while the program continues to run, then communicating back to the process what objects were discovered to be garbage, so they can be freed. In Linux (or Unix in general), you can copy the entire VM of a process by calling fork(). In Linux, this is fast, because the memory doesn't actually get copied until it's written to. In other Unices, it is often not so fast, especially for processes with a lot of data. This is a way of doing incremental GC that seems to avoid most of the hairy problems incremental GC usually has. The parent and child need only share some small communication window though which they can talk about garbage; when the child finishes, it can exit. What are some disadvantages of this method? Kragen From abw97@doc.ic.ac.uk Tue, 28 Apr 1998 23:41:53 +0100 Date: Tue, 28 Apr 1998 23:41:53 +0100 From: Alaric B. Williams abw97@doc.ic.ac.uk Subject: Linux and GC Kragen wrote: > This is a way of doing incremental GC that seems to avoid most of the > hairy problems incremental GC usually has. The parent and child need > only share some small communication window though which they can talk > about garbage; when the child finishes, it can exit. > What are some disadvantages of this method? It's known in the literature as using a "write barrier", IIRC... it's been studied already with some success, I think. > Kragen ABW -- Al Williams abw97@doc.ic.ac.uk ICQ#5129948 Pager +44 4325 325477 PGP: D8F3 FA8E 32A3 2F3B 13A9 B3DF DB50 1FE9 9913 1E3E http://www.abwillms.demon.co.uk/ Could anybody love him... ...or was it just a crazy dream?