From: Pete Grant
Subject: Re: Managing large LISP code
Date: 
Message-ID: <1993Oct30.225236.3520@pentagon-gw.army.mil>
In article <··········@festival.ed.ac.uk> ····@festival.ed.ac.uk (J W Dalton) writes:
>····@eng.umd.edu (Charles Lin) writes:
>
>>   Is there any standard technique for managing large amounts
>>of Lisp code?

Jeff mentioned DEFSYSTEM in his response.  On Symbolics machines 
(Genera), DEFSYSTEM is a small part of the System Construction
Tool (SCT), which would more appropriately be named System
Maintenance Facility.  It is similar to MAKE utility on Unix
and DOS platforms in that it provides automatic checking of which
source files have been modified since last compilation.  It also
uses the file date stamps in its operation.

SCT also has a patch mechanism which permits the compilation and
installation of incremental changes consisting of only those functions
that have actually changed.  This is superior to recompiling entire
files as sometimes source files can grow large as development
continues.

SCT also almost automatically provides the means of distributing
large (or small) systems easily.  The distribution system is menu
driven and the defaults are logically set.  I find this a most
useful tool in distributing systems as well as patches and
even data.  The system almost automatically ensures that the 
distributed files are placed in correct director.

Too bad SCT is available only on the Symbolics.  But, it's just
another reason why Symbolics Genera is the "Cadillac" of Lisp
systems.  :-)

Pete.

From: Marco Antoniotti
Subject: DEFSYSTEM (Was: Re: Managing large LISP code)
Date: 
Message-ID: <MARCOXA.93Nov3102006@butsomi.cs.nyu.edu>
Hello Lispers!

This discussion about how to manage large projects and the recent RFD
made me wonder about the future of DEFSYSTEM.

I normally use CMUCL with Mark Kantrowitz's DEFSYSTEM and I am very
happy with it. I also used it (though in a limited way) with CLISP and
it still seems to work fine.

Now, this DEFSYSTEM (beyond being portable over many CL
implementations) is a sharp departure from the one found in GENERA. MK
DEFSYSTEM uses a "structural" description of the system, while GENERA
uses a "procedural" description (as pointed out in the MK DEFSYSTEM
manual).

I would like to see the MK DEFSYSTEM offered by the Lisp vendors as a
standard tool. This would make *my* life easier and, I believe, also
that of many other Lisp Users.

Bye
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab		| room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU	| e-mail: ·······@cs.nyu.edu

...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
				B. Brecht
From: Arun Welch
Subject: Re: DEFSYSTEM (Was: Re: Managing large LISP code)
Date: 
Message-ID: <WELCH.93Nov4123510@valhalla.cis.ohio-state.edu>
In article <····················@butsomi.cs.nyu.edu> ·······@butsomi.cs.nyu.edu (Marco Antoniotti) writes:

   I would like to see the MK DEFSYSTEM offered by the Lisp vendors as a
   standard tool. 

Why? People don't expect their C compiler vendors to pre-build every
bit of net.software, people don't expect their OS vendors to pre-build
every bit of net.software, but for some odd reason everyone expects
the Lisp vendors to do so, and to provide updates. This is generally
followed by bitches about the Lisp distribution being bloated or too
expensive. Recompiling the LispUsers distribution for a new release
used to take me 2 weeks when I was at the LAIR, until I got smart and
stopped distributing the compiled versions. Life is much easier now.

...arun
---------------------------------------------------------------------------
Arun Welch					1224 Kinnear Rd
Network Engineer				Columbus, OH 43212
OARnet						·····@oar.net
From: Marco Antoniotti
Subject: Re: DEFSYSTEM (Was: Re: Managing large LISP code)
Date: 
Message-ID: <MARCOXA.93Nov8094023@butsomi.cs.nyu.edu>
In article <··················@valhalla.cis.ohio-state.edu> ·····@valhalla.cis.ohio-state.edu (Arun Welch) writes:

   From: ·····@valhalla.cis.ohio-state.edu (Arun Welch)
   Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
   Date: 4 Nov 1993 12:35:16 -0500
   Xref: slinky.cs.nyu.edu comp.lang.lisp:1029 comp.lang.lisp.mcl:719

   In article <····················@butsomi.cs.nyu.edu> ·······@butsomi.cs.nyu.edu (Marco Antoniotti) writes:

      I would like to see the MK DEFSYSTEM offered by the Lisp vendors as a
      standard tool. 

   Why? People don't expect their C compiler vendors to pre-build every
   bit of net.software, people don't expect their OS vendors to pre-build
   every bit of net.software, but for some odd reason everyone expects
   the Lisp vendors to do so, and to provide updates. This is generally
   followed by bitches about the Lisp distribution being bloated or too
   expensive.
   ....

My point was slightly different. In the recent RFD for comp.std.lisp
(and comp.org.lisp-user) it was mentioned that one of the next
discussion topics about Lisp standardization will be DEFSYSTEM (and
multithreading and FFI's).

It seems to me that Mark Kantrowitz's DEFSYSTEM (somebody mentioned
the 'defunits' package, but I am not familiar with it) is the only one
that currently works under *all* major implementations. Besides it is
*not* a huge piece of software (~120K of source code, ~177K compiled
with CMUCL - gnu make is 303K compiled on a Sparc).

Most important, if the vendors agree on some piece of software that is
already available they will benefit in the long run (as it happened -
it is useless to negate it - with PCL/CLOS), as will benefit the free
implementation with sporadic support as CMUCL, AKCL and CLISP.

Some time ago I made a similar comment about FFI's, but here the case
for adopting the publicly available piece of software is much
stronger.

Happy Lisping
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab		| room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU	| e-mail: ·······@cs.nyu.edu

...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
				B. Brecht