How can I make my lisp program executable?
Luke Higgins
I have just VERY recently started my interest in lisp. I downloaded
and installed CMU CL on my Solaris (5.5) Sun 4 machine (where I am an
end user). I have been reading various code and much of the info
found all over the web. I see the option to byte compile code but how
can I make an executable from my code? I see that there are tools
like CLiCC to convert to C compiled code but is there a different
route to take to get an executable? Thanks for any and all help you
can give to one of the newest lisp enthusiasts.
Thanks,
Luke
--
Luke A. Higgins lu...@math.rutgers.edu 835 Davidson Rd, Piscataway, NJ 08854
Martin Cracauer
lu...@fermat.rutgers.edu (Luke Higgins) writes:
>I have just VERY recently started my interest in lisp. I downloaded
>and installed CMU CL on my Solaris (5.5) Sun 4 machine (where I am an
>end user). I have been reading various code and much of the info
>found all over the web. I see the option to byte compile code but how
>can I make an executable from my code? I see that there are tools
>like CLiCC to convert to C compiled code but is there a different
>route to take to get an executable? Thanks for any and all help you
>can give to one of the newest lisp enthusiasts.
To get executables under Lisp you have to use an implementation that
supports this, it is no normal functionality. CMUCL's executable is
just a little program that load the whole Common Lisp image which is
not an executable.
What is the exact reason you want an exectable for? Of course, in
CMUCL, you can write a Unix shell script for each "program". Some
variants of Scheme (and CLISP?) even allows you to use them directly
as a shell (#!/usr/local/schemename).
There are free Lisps that allow you to save a "real" executable, but
the drawback is of course that the executables may be very big. A
solution is WCL, which uses shared libraries for its Common Lisp
library. Don't know if CLiCC can use shared libs.
If the reason you want an executable is that you want one single
self-containing binary files that can be moved aross machines without
supporting files, that CMUCL is not an option.
P.S. CMUCL is a compiler towards real machine code. It has a bytecode
system, too, but your normal compilation process is producing native
code for the target platform, not bytecode.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
Erik Naggum
* Martin Cracauer
| There are free Lisps that allow you to save a "real" executable, but the
| drawback is of course that the executables may be very big. A solution is
| WCL, which uses shared libraries for its Common Lisp library. Don't know
| if CLiCC can use shared libs.
I have tried WCL. it uses shared libraries for the Lisp system and the
executable is indeed small. however, firing up the smallest WCL executable
requires 15M of virtual memory (as reported by pstat -s), and starting up
CMUCL with a dumped image running the same code requires about 2M of
virtual memory, although the disk footprint is at least 10M. this goes to
show that if you optimize for the disk footprint, you may get excellent
disk footprint statistics, but you won't get any better _system_ statistics
unless you have some other common situations, like always having the shared
libraries in memory, which is the case for most of the other _actually_
shared libraries on my system (C, X11).
just because the disk image is huge doesn't mean the memory image or usage
will be. a system designed under the presumtion that it cannot know what
you will need until runtime, does not _have_ to waste your system resources
with what you won't need until you actually need it. somebody clever
enough to find a way to be prepared for those needs at very low cost will
have been in thta situation before you. e.g., paging will reduce the
startup time of your applications if it can page in only those pages that
are actually referenced during initialization and they are few in number.
however, if your program needs all of its pages on startup, paging will
cost more than it saves. in the same vein, paging will often preallocate
the system resources necessary to hold all the memory you might page in,
even though you will never need all of them simultaneously. if the pager
doesn't know that, however, it can't help you and must be prepared for the
worst case. if, however, code is written such that it can be loaded into
memory anywhere, you can do your own "paging" and not need to preallocate
virtual memory. this appears to be what CMUCL does.
many people seem to think that when they can see a problem, nobody has seen
it before them and thus it is still unsolved. the converse is often true:
people have already solved problems others don't see! and neither will
they see them, solved as they are. the joy I find in using a major system,
from operating systems and Lisp systems to subway systems and airline
ticket reservations systems, is in trying to find as many _solved_ problems
as I can. I tend to find unsolved problems here and there, but only after
I have gained an appreciation of what has been solved before I ever started
to look at it.
for instance, it recently became clear to me just how much planning and
intelligence is required to ensure that traffic will flow smoothly while a
large number of people are at work changing some component of a traffic
system, building a major traffic machine, repairing roads, or just plain
rerouting traffic after a major disaster. most people curse at the
problems they see, but (probably by virtue of not driving myself!) I find
pleasure in seeing how some incredibly competent people can keep half a
million cars cross a bridge every single day when that brigde is being
completely replaced during a whole year of work on it. such things have
been an inspiration for me to create software systems that keep running
even though they are being repaired.
hmmm. sorry for being so unabashedly enthusiastic (I must be annoying a
_lot_ of people!), but I'm having too much fun to share it only with my
friends and my cat.
#\Erik
--
"He didn't care."
"They never do."