dove@savax.UUCP (webster dove) (04/30/87)
We are trying to use LUCID 2.0 on a Sun 3/110 with their window package, and it seems that the least trivial error will leave a window on the screen blocking the other windows and essentially wedge the lisp (^C gets ignored etc.). On the Symbolics, one could click right to get a menu and kill the current window or hit ctrl-abort and get a lisp stream. With this Lucid environment, things seem much less friendly. Also, the paging with 4 MBytes of ram is outrageous. It is bad enough that I am considering having people use C instead of Lisp just to get the project done. This surprises me because I was quite happy with software development on the Symbolics, and had made the assumption that Lisp was at the root of that contentment. Now it seems that the implementation of things like the window system (doesn't use flavors under Lucid), condition handling (non-existant under Lucid), the debugging facilities (not window oriented/mouseable under Lucid), the multi-process nature of the Symbolics and the polish of their system (things like command line editing aren't available under Lucid) were what I really liked about using the Symbolics. Have others had this experience? Am I using Lucid improperly? Should I have bought some utilities to assist me on the Sun?
mckay@bigburd.PRC.Unisys.COM (Donald P McKay) (05/02/87)
Lucid Common Lisp is recommended to be run on a Sun with at least 8MB of physical memory I believe (don't have my brochure handy). On some other newsgroups and perhaps this one, others have noted that one should always opt for a workstation with the most physical memory one can afford in order to be able to run Common Lisps with other things, like the editor, mail, windows, etc. without waiting for the system to page. This is especially sensitive for diskless workstations which have to page over a network. In your case, check with Sun as to how much physcial memory is really required vs what you can limp along with. I think the recommendation is really along the lines of "at least 8MB of physical memory". As for the windowing environments and uses of windows integral to a Lisp system, well the non-Lisp machine environments are just lagging behind. Lucid Common Lisp on a Sun is just not like Zeta Lisp on a Symbolics or a ....
rcp@milano.UUCP (05/02/87)
In article <611@savax.UUCP> dove@savax.UUCP (webster dove) writes:
;We are trying to use LUCID 2.0 on a Sun 3/110 with their window
;package, and it seems that the least trivial error will leave a window
;on the screen blocking the other windows and essentially wedge the
;lisp (^C gets ignored etc.).
There are at least 3 window packages for Lucid on the sun (incuding:
the Lucid window toolkit, common windows, Suns sunview interface).
Interfaces which are via the foreign function interface to "c" tend to
be fragile when an error occurs. This robustness of ffi needs to be
improved.
;On the Symbolics, one could click right to get a menu and kill the
;current window or hit ctrl-abort and get a lisp stream. With this
;Lucid environment, things seem much less friendly.
Common Lisp does not define a standard process model for lightweight
processes sharing the same lisp environment. This is an important
missing ingredient for the type of interaction you describe above.
;Also, the paging with 4 MBytes of ram is outrageous.
Have you tried using a lisp machine with only 4MB of RAM? Actually
common lisps on unix systems seem to need more physical memory than on
a lisp machine. 8MB seems marginal on either machine. 16MB gives
good performance on either.
;This surprises me because I was quite happy with software development
;on the Symbolics, and had made the assumption that Lisp was at the
;root of that contentment.
;
;Now it seems that the implementation of things like the window system
;(doesn't use flavors under Lucid), condition handling (non-existant
;under Lucid), the debugging facilities (not window oriented/mouseable
;under Lucid), the multi-process nature of the Symbolics and the polish
;of their system (things like command line editing aren't available
;under Lucid) were what I really liked about using the Symbolics.
All of these are good points. We have had good success using gnu
emacs as a support environment for common lisp development on the Sun.
It was easy to add such features as common lisp documentation,
function name completion, and package support. In most regards I
consider the gnu emacs editor support we have for lisp to be better
than zmacs on the lisp machine. Now that there is a Common Lisp
Object System specification, I expect that reasonable vendor support
for the items you mention isn't too far away. There will always be
an advantage to debugging on a tagged architecture machine, but in
most respects there is no reason why the development environment can't
be as good.
-Rob
ps: these are purely my personal opinions of course ...
--
Robert C. Pettengill, MCC Software Technology Program
P. O. Box 200195, Austin, Texas 78720
ARPA: rcp@mcc.com PHONE: (512) 338-3533
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcpssh@esl.UUCP (Sam) (05/05/87)
->rcp@milano.UUCP sez -> -> We have had good success using gnu ->emacs as a support environment for common lisp development on the Sun. ->It was easy to add such features as common lisp documentation, ->function name completion, and package support. In most regards I ->consider the gnu emacs editor support we have for lisp to be better ->than zmacs on the lisp machine. ->-Rob -> Does your Sun gnumacs have mouse support? -- Sam (4087382888x4126)
ehj@mordor.s1.gov (Eric H Jensen) (05/06/87)
I share your frustrations. Paging on an 8 meg 3/75 is outrageous.
Things get satisfactory with at least 16 meg of real memory. I suspect
that Sun's paging algorithm may be partially to blame here - I have
seen brain dead paging behaviour on other large programs.
The lack of condition handling is also a real lose - I hope they
supply something soon.
As for an environment, I wrote an extensive sub-process interface for
GNU emacs some time ago and that allows command history, installing a
new defun, runing the lisp process on a variety of servers and other
small features. I haven't been spoiled by a lisp machine environment
so I guess I don't know what I am missing.
Why did they have to invent yet another window interface ?? How I wish
they provided a well integrated X interface.
Among the bugs I've come across the following is one I find most
intriguing.
Occasionally I have problems with the garbage collector. Once in
a while it gets wedged in a loop that seems to cons garbage as fast as
it can, gc and then cons again. When I send an interupt and then
backtrace I get something like
SOMETHING <- WRITE-* <- unnamed-function
(where * means I forget what was there) when I know my stack should be
much bigger and I haven't been doing any writing to streams. A simple
abort makes everybody happy again. This behaviour has happened in two
cases. The first case is in reading a form during a load that is ~
80,000 characters. This problem went away with the inclusion of a
reader macro that read the subforms printing out a little progress
blurb. The second case was applying nconc to a large list of lists.
This bug also went away with the insertion of diagnostic code. Any
body else seen this behaviour or have some insight as to why it
occurs?rcp@milano.UUCP (05/07/87)
In article <430@esl.UUCP> ssh@esl.UUCP (Sam) writes:
;->rcp@milano.UUCP sez ->
;-> We have had good success using gnu
;->emacs as a support environment for common lisp development on the Sun.
;Does your Sun gnumacs have mouse support? -- Sam (4087382888x4126)
The the version 18 distribution of gnu emacs includes mouse support
for Suns running both X and Suntools window systems.
-rob
--
Robert C. Pettengill, MCC Software Technology Program
P. O. Box 200195, Austin, Texas 78720
ARPA: rcp@mcc.com PHONE: (512) 338-3533
UUCP: {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp