Re: questions and comments

[Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU]

    I was using a structure as a CLOS class.  This does not work because PCL
    does not support this.  However, there are patches on parcftp.xerox.com
    that (claim to) give this capability to PCL.  Unfortunately, the patches
    appear to be specialized for Lucid and KCL.  Are there any plans to get
    this to work for CMU Lisp?

Yes, this is on the list, and I'll check out these patches.

      Some of the packages do not appear to have the nicknames claimed by
      the user documentation.  Specifically, PCL is not given the nickname
      "CLOS".  (The doc also implies that CLOS is the real name and PCL is
      the nickname.)

Sounds likely.  Currently our package structure is something of a mess.
Probably all the CLOS symbols should really come from COMMON-LISP, etc.

   - 9 Meg is a lot to FTP all at once.  It would make for easier FTP-ing
     if the tar files were broken up into 1 Meg pieces.

We'll probably split future releases, as this is a popular request.

   - 20 Meg is a huge image.  Is there any way to get a smaller image
     with some of the modules stripped out?

Yes.  Without CLX and Hemlock, it is about 11 meg.  The compiler is itself
rather large.

 - Can an image be built from the sources?

If you know how...

   Is it intended that we be able to do so?  There is no build
   documentation, but in the sources there is a directory with several
   promising looking shell and lisp scripts.

It isn't intended that it be impossible, but probably only the madly
intuitive can figure it out themselves.  There are a few hints in
doc/system-notes.txt in the release and in
/afs/cs/project/clisp/ram/docs/internals/architecture.tex.

   - I have found an apparent bug with the generation of ldb/Makefile.
     When cpp is run, all the filenames in the dependancy section that have
     the substring "sparc" in their names get mangled.

I never got that to work either.  Perhaps William can comment.

   - There seems to be a circular dependancy between ldb/lisp.h and
     ldb/ldb.map that causes bootstrapping problems.  How do I get around
     this problem? 

Probably the easiest (the only?) way is to steal an existing lisp.h,
compile ldb, build lisp.map, run genesis and generate a new lisp.h (if
necessary).  Recompile ldb, and iterate as needed.

   - The name "sun4c_41" sort of implies that it only runs on SparcStations
     running SunOS 4.1.  However, the binaries seem to work on a Sun 4/260
     running SunOS 4.0.3.  Are there any hidden pitfalls and can I expect
     this to state of affairs to continue?

Any pitfalls are hidden to us as well.  The name is what our local
facilities staff decided to call that particular hardware/software
configuration.

    * (setq x 1)

Yeah, yeah...  I'm probably the only person in the world who likes it.  I
added a switch which allows you to choose whether you want to be warned
always (as now), once (the new default) or never.

  Rob