Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site yetti.UUCP Path: utzoo!utcs!mnetor!yetti!mike From: mike@yetti.UUCP (Mike Clarkson ) Newsgroups: net.lang.lisp Subject: Vax/VMS Common Lisp : Version 1.1 Message-ID: <259@yetti.UUCP> Date: Fri, 4-Oct-85 01:07:11 EDT Article-I.D.: yetti.259 Posted: Fri Oct 4 01:07:11 1985 Date-Received: Fri, 4-Oct-85 08:41:16 EDT Reply-To: mike@yetti.UUCP (Mike Clarkson ) Organization: York University Computer Science Lines: 54 Keywords: VMS, Common Lisp Summary: Never use Version 1.xx of anything. [nibble, nibble.] Digital has a Common Lisp implementation on Vax/VMS. We have just received it (the first site in Canada), and have yet to receive its documentation so my exposure to it is rather cursory, but I thought I might pass on some initial impressions. It comes complete with an EMACS style editor, and appears to be a complete implementation of Common Lisp. It's *BIG*. The kernel is about 300 Vax pages (1 page = 512 bytes), and then it boots the rest of it which is in a Lisp complied format. The rest of it is > 6500 pages (>3 MEG!). It requires 8600 pages (~4.5 MEG!) of virtual memory to run. (In VMS this is the paging file quota.) It's *SLOW*. We're running a Vax 8600 with 12 Meg memory, and under normal load (50-60 users) it can take ~2 minutes just to load! Garbage collections on an 8600 at 3 a.m. with the system virtually user-free can take 2-3 minutes. (All timings very approximate.) It's not bug free. A number of simple things will make it turf its cookies and die. For example if you go into the editor and ask it to add a line to one of the buffers using the GROW-WINDOW command, all works well and the buffer is made one line larger. However a subsequent GROW-WINDOW command results in a fatal internal error in the screen editor function GROW-WINDOW-HEIGHT routine as a result of hitting a bad block address (SPR has been submitted). This is version 1.1 so given that one should never use version 1.x of anything I can't fault Dec (yet?). However there's one thing I feel is a major fault: unlike Franz Lisp which I am more familiar with, this Common Lisp does not dynamically load, or "autoload" functions that it doesn't have in it on an as-required basis. This may be common to Common Lisp, or maybe Dec didn't want source code lying around, but the result is that it boots fully loaded, all dressed, and is slow even if you don't need the whole works. This strikes me as a poor idea. In passing, I am very curious to know why Franz Lisp was not included in the set of languages that Common Lisp comprises, and what are the real philosophical differences that distinguish Common Lisp and Franz Lisp. Were there reasons why the people at Bezerkeley felt it would not be advantageous to be a part of the Common Lisp "standard", or did they feel that it would be better or simpler to add Common Lisp to Franz, rather than changing Franz to conform to Common Lisp? If anyone at Franz Inc. has could shed any light on this question I would be very interested. Either post replies, or mail to me and I'll summarise to the net. I would also be interested in hearing about other people's experiences with Vax/VMS Common Lisp. allegra \ Mike Clarkson, BITNET: decvax \ CRESS, York University, FS300013@YUSOL ihnp4 > !utzoo!yetti!mike 4700 Keele Street, linus / North York, Ontario, AT&T^G: watmath / CANADA M3J 1P3. (416) 667-3954