WCL version 2.14 is now available for anonymous FTP from
sunrise.stanford.edu. This release fixes all bugs reported since
release 2.1.
A WCL mailing list called ···@sunrise.stanford.edu has also been
created to circulate information about new releases, bug reports, etc.
If you would like to be on this list, please send your name to
···········@sunrise.stanford.edu.
WCL is an implementation of Common Lisp for SPARC based workstations
A paper describing WCL was published in the proceedings of the 1992
Lisp and Functional Programming Conference. The abstract for
the paper follows:
Common Lisp implementations for Unix have
traditionally provided a rich development environment at the expense
of an inefficient delivery environment. The goal of WCL is to allow
hundreds of Lisp applications to be realistically available at once,
while allowing several of them to run concurrently. WCL accomplishes
this by providing Common Lisp as a Unix shared library that can be
linked with Lisp and C code to produce efficient applications. For
example, the executable for a Lisp version of the canonical ``Hello
World!'' program requires only 40k bytes under SunOS 4.1 for SPARC.
WCL also supports a full development environment, including dynamic
file loading and debugging. A modified version of GDB
the GNU Debugger, is used to debug WCL programs, providing support for
mixed language debugging.
WCL is not a 100% complete Common Lisp, and some of the more obscure
functions are not fully implemented. However, WCL does provide CLX R5
as a shared library, and comes with PCL as well as a few other utilities.
After connecting to sunrise.stanford.edu via anonymous FTP, the following
files can be obtained from the pub/wcl directory:
wcl-2.14.tar.Z - WCL distribution, including CLX and PCL.
wgdb-4.2.tar.Z - a version of GDB modified to understand Lisp debugging
gcc-2.1.tar.Z - GNU C compiler (not required, but *very* desirable)
NOTE: GCC 2.2.2 has a bug which prevents it from
working with WCL.
lfp-paper.ps - PostScript for the WCL paper.
More information about WCL is available in the documentation directory
of the WCL distribution. Please direct any questions or bug reports
to ···@sunrise.stanford.edu.
I picked up Hennessey's paper and read it. His ideas for producing
small executables using dynamic loading seem to solve the problem of
large lisp executables very nicely. Do the major lisp vendors have any
opinions / comments / plans to implement these ideas?
······@cs.toronto.edu ("Bryan M. Kramer") writes:
>I picked up Hennessey's paper and read it. His ideas for producing
>small executables using dynamic loading seem to solve the problem of
>large lisp executables very nicely. Do the major lisp vendors have any
>opinions / comments / plans to implement these ideas?
I'm not exactly a *major* lisp vendor, but I've been pursuing this
concept since the release of HP-UX 8.0, when shared libraries were first
made available to me. Although I'm just a tiny HP-VAB, I'd really be
surprised if the major Lisp vendors to which you refer weren't also
working on an implementation utilizing shared libs.
This technique does not solve *all* the problems associated with large Lisp
executables, but it's clearly far more efficient than using the old archive
library model (libxxx.a). Mr. Hennessey should certainly be applauded for
proving that PIC **is** the Lisp/Unix solution!
-jpf
--
__________________________________________________________________________
WaveStar Technology WaveStar Common Lisp John P. Flanagan
W344 N6855 Bayberry Court ANSI-12.24, X3J13/92 (414) 367-5014
Oconomowoc, WI 53066 HPUX-800/700/400/300 ···@wstar.mixcom.com
In article <·····················@wstar.mixcom.com> ···@wstar.mixcom.com (John P. Flanagan) writes:
······@cs.toronto.edu ("Bryan M. Kramer") writes:
>I picked up Hennessey's paper and read it. His ideas for producing
>small executables using dynamic loading seem to solve the problem of
>large lisp executables very nicely. Do the major lisp vendors have any
>opinions / comments / plans to implement these ideas?
I'm not exactly a *major* lisp vendor, but I've been pursuing this
concept since the release of HP-UX 8.0, when shared libraries were first
made available to me. Although I'm just a tiny HP-VAB, I'd really be
surprised if the major Lisp vendors to which you refer weren't also
working on an implementation utilizing shared libs.
This technique does not solve *all* the problems associated with large Lisp
executables, but it's clearly far more efficient than using the old archive
library model (libxxx.a). Mr. Hennessey should certainly be applauded for
proving that PIC **is** the Lisp/Unix solution!
Once upon a time I worked at Prime on our end of a contract with Lucid
to provide Common LISP on the 50 series. Shared libraries weren't a
new concept to PRIMOS, and they were used for both the runtime and
development environments. What this bought us was a reduction in
working set for the second and subsequent users of about 2 Mb with
the first user's working set of 4 Mb. Essentially all subsequent
users paid for the heap and linkage. I imagine similar things
have been done on VMS with, presumably, similar results.
Getting the working set much below a couple of megabytes would depend
more on the ability to efficiently link a small executable. LISP
isn't the only offender in this regard. Consider that any dynamic
interpreter (EVAL in LISP's case) has the problem of possibly
requiring all objects to be available.
--
Douglas S. Rand <·····@osf.org> OSF/Motif Dev.
Snail: 11 Cambridge Center, Cambridge, MA 02142
Disclaimer: I don't know if OSF agrees with me... let's vote on it.
Amateur Radio: KC1KJ