I've read that a program can be a conforming subset implementation of CL in
the case that any programs written in that subset will run as intended,
unmodified, on a fully conforming CL implementation. The primary advantage
that I can see to this sort of thing is to optimize the size of the runtime
required for deployment (disk/memory footprint, startup times). In fact,
given the right subset, it might be possible to do development on a full
version of CL and then deploy with the subset. For instance, the majority
of programs could run fine without a compiler or debugger (or EVAL) in the
final image. Many small ones could make do without various other features
(the reader, the condition system), although some would be harder to take
out or modularize than others.
I think there are probably quite a few people developing small systems
intended for widespread, casual use, that would voluntarily choose to use
such an implementation--sacrificing the more dynamic features of the
language in a conscious effort to create smaller distributables. In the
case of COMPILE and friends, they wouldn't be giving up much at all.
Some of the comments in
http://www.nhplace.com/kent/CL/Public-Review-PRobertson.html
seem to be particularly apt here.
Now, it seems the most obvious way to implement this sort of thing is to
have flags in the source of a full implementation that exclude different
portions of the runtime. For instance, one might specify:
./configure --no-compiler --no-reader --simple-conditions \
--sources foo.fasl bar.fasl --entry-point bar-main
... where the fasls were compiled with a full version of the same
implementation, and the resulting executable (possibly multiple files)
would jump straight to that code. Do any free implementations have this
capability, or anything like it? If not, are there any separate
implementations being maintained that only implement a sizable subset of
CL?
-- Flamebait --
Perhaps a good answer to this question would help to bridge the culture gap
and satisfy the newbies with the perennial "HOW DO I COMPILE AN EXE WITH
LISP" question. It might make lisp more suitable for lightweight,
non-serious tasks that attract hobbyists who have the time to write the
sort of neat, *little*, libraries for various things that make a language
less intimidating for newbies and pragmatists with small requirements.
After playing with Lisp for several months, the thing that still strikes me
the most about it is its monolithic nature. And it doesn't really strike me
as necessary, either. I see nothing essential to the spirit of Common Lisp
that makes the sort of runtime we have available in most implementations
necessary. I think that's a shame. It may be (and it wouldn't surprise me)
that I'm woefully underestimating the technical difficulty of putting this
sort of functionality into an implementation, but don't tar and compress me
for that.
I tend to agree with Paul Graham (as I read him) in that a language that's
good for free-time projects of little consequence is the best kind for
becoming a great language for hackers. Take that as you will.
Chris Capel
Chris Capel wrote:
> I think there are probably quite a few people developing small
systems
> intended for widespread, casual use, that would voluntarily choose to
use
> such an implementation--sacrificing the more dynamic features of the
> language in a conscious effort to create smaller distributables. In
the
> case of COMPILE and friends, they wouldn't be giving up much at all.
It seems like megabytes get smaller all the time. Broadband internet is
becoming more widespread, hard drives are always getting bigger, and
Lisp doesn't add *that* much overhead, really.
For example, Corman Lisp adds slightly over a megabyte of overhead to a
statically linked exe file, despite having aspirations of being an
ANSI-conforming Common Lisp implementation. That doesn't feel like a
whole lot to me. Other implementations might have more overhead (I
believe the SBCL core is something like 6 MB), and you might have
something to gain there, but I prefer to think that the hardware fairy
will come and put a solution under my pillow, and I can just keep on
writing plain Common Lisp code and not worrying about restricted
subsets.
> I tend to agree with Paul Graham (as I read him) in that a language
that's
> good for free-time projects of little consequence is the best kind
for
> becoming a great language for hackers. Take that as you will.
Little one-off projects often stay around longer than you anticipate. A
few days ago, I wrote a quick little program to do some regexp-based
web scraping to get information on reservoirs monitored by the Army
Corps of Engineers and do something with it. The regular expression was
written (and subsequently debugged) with the help of the Regex Coach
(if you use regexps, you need it), then copied and pasted into my
program. I used wget to download the page in question. The web page is
updated once a day, so the program can be run as a cron job to update
its own generated pages.
I wanted a language that would let me do this easily. I suppose Perl
would have been a decent choice, but I decided to go with lisp. I
haven't regretted it; defstruct and a few functions let me isolate the
regexp monstrosity, and the rest of my code is much easier to maintain
than it would have been otherwise.
Lisp didn't slow me down. Lisp wasn't too heavy. It could be used just
fine in traditional Unix-style tasks. If you want lightweight Lisp, get
Corman or CLISP. I think you're solving a non-problem.
-Peter
·········@gmail.com wrote:
> For example, Corman Lisp adds slightly over a megabyte of overhead to a
> statically linked exe file, despite having aspirations of being an
> ANSI-conforming Common Lisp implementation. That doesn't feel like a
> whole lot to me.
Nor me. I didn't know it was quite that slim.
> Other implementations might have more overhead (I
> believe the SBCL core is something like 6 MB),
~ $ ls /usr/local/lib/sbcl/sbcl.core -l
-rw-r--r-- 1 root root 23220224 Nov 14 02:10
/usr/local/lib/sbcl/sbcl.core
I don't know about you, but 23 MB for the default core seems a bit big to
me. Or maybe I'm just being a Unix newbie ... ?
Chris Capel
In article <···············@corp.supernews.com>,
Chris Capel <······@iba.nktech.net> wrote:
> ·········@gmail.com wrote:
>
> > For example, Corman Lisp adds slightly over a megabyte of overhead to a
> > statically linked exe file, despite having aspirations of being an
> > ANSI-conforming Common Lisp implementation. That doesn't feel like a
> > whole lot to me.
>
> Nor me. I didn't know it was quite that slim.
>
> > Other implementations might have more overhead (I
> > believe the SBCL core is something like 6 MB),
>
> ~ $ ls /usr/local/lib/sbcl/sbcl.core -l
> -rw-r--r-- 1 root root 23220224 Nov 14 02:10
> /usr/local/lib/sbcl/sbcl.core
>
> I don't know about you, but 23 MB for the default core seems a bit big to
> me. Or maybe I'm just being a Unix newbie ... ?
Is the file size the problem for you? Or the size of used
memory at runtime? The size of resident non-sharable memory
at runtime? For one Lisp or do you start several
independent Lisp processes?
SBCL is not known for small and compact code. Since
SBCL is an SBCL application ;-) , it is quite
big itself.
Many people had that problem over the time. Some
commercial Lisps also have their own answers to it.
LispWorks for example allows you to create
applications by supporting some mechanisms of making
the runtime smaller - though LispWorks is surely not the
smallest Lisp. The Delivery User Guide
(http://www.lispworks.com/reference/lw43/DV/html/deluser.htm)
explains it in detail.
> Chris Capel
Is that 23MB SBCL core shareable if you start more than one SBCL?
How much is that at runtime?
How about ECL? CLISP? GCL? On the Mac, OpenMCL is also
relatively small.
There were several Lisps that tried to be smaller and/or
especially for delivery (WCL, ThinLisp, earlier versions
of XLisp, CLICC) pluss they tried to be atleast somehow compatible
with Common Lisp.
Rainer Joswig wrote:
> In article <···············@corp.supernews.com>,
> Chris Capel <······@iba.nktech.net> wrote:
>
>> ·········@gmail.com wrote:
>>
>> > Other implementations might have more overhead (I
>> > believe the SBCL core is something like 6 MB),
>>
>> ~ $ ls /usr/local/lib/sbcl/sbcl.core -l
>> -rw-r--r-- 1 root root 23220224 Nov 14 02:10
>> /usr/local/lib/sbcl/sbcl.core
>>
>> I don't know about you, but 23 MB for the default core seems a bit big to
>> me. Or maybe I'm just being a Unix newbie ... ?
>
> Is the file size the problem for you? Or the size of used
> memory at runtime? The size of resident non-sharable memory
> at runtime? For one Lisp or do you start several
> independent Lisp processes?
[snip]
> Is that 23MB SBCL core shareable if you start more than one SBCL?
> How much is that at runtime?
Well, aside from the overcommitment of memory, which causes my process
monitors to say SBCL takes up 864 MB of virtual (for every process), the
whole 23.6 of the core is shared, while it adds an additional 8.9 resident.
An additional process adds 2.3 MB to total usage immediately--somewhat
contradictory, as it also reports 8.9 resident. But I probably don't know
how to read these things.
Now, this isn't a problem for a server or a development machine or a
high-end workstation that many commercially developed lisp programs would
be running on. But would you say that SBCL's (and CMUCL's) size is an
anomaly? I have little experience with other implementations, and now that
I look, CLISP indeed only takes up a few megabytes in memory, most of that
shared. That's less that twice as much as bash.
Can anyone speak as to whether there are difficulties with performance when
using CLISP to write non-algorithm-intensive, interactive programs? I
wouldn't imagine, on modern machines, that the difference would be
noticable, especially for I/O bound applications, or foreign-library
intensive ones.
> How about ECL? CLISP? GCL? On the Mac, OpenMCL is also
> relatively small.
>
> There were several Lisps that tried to be smaller and/or
> especially for delivery (WCL, ThinLisp, earlier versions
> of XLisp, CLICC) pluss they tried to be atleast somehow compatible
> with Common Lisp.
But the problem with CLISP, and far worse with GCL and ECL, is the poor
library support and non ANSI-ness. I looked into GCL today, and found it
couldn't be used in SLIME! (Though I understand the maintainers aren't
happy about this, but not exactly rolling in free-time or
listener-supported motivation :-).) Now, as a target for deployment, that
may not be such a big issue, and seeing as how GCL was based on gcc, I
thought "Hey, maybe it supports some cool embeddable things like compiling
to linkable libraries or taking out the compiler". It may be that that
would be a solution for a past problem, when machines were smaller, but
then GCL's been around for a while, hasn't it?
Now that you've pointed it out, ECL and WCL seem to be up the alley I was
referring to in my OP. But--and this is my curiosity here--they seem to be
almost entirely absent from the general CL culture. While you'll find Cliki
entries for them, they aren't mentioned much in other Cliki pages. You
won't find them on many libraries' "supported" list (unless I've been
selectively blind). They aren't mentioned in blogs, they aren't mentioned
in usenet, they aren't mentioned much in #lisp. What's the reason for this?
Do they have the some sort of incompleteness/weirdness/ obseleteness? Or
maybe their users are just too happy to ever complain. :-) Maybe they have
a separate culture...
Is there a link for WCL that's more informative than http://wcl.kontiki.com/
? That page is rather sparse.
> Many people had that problem over the time. Some
> commercial Lisps also have their own answers to it.
> LispWorks for example allows you to create
> applications by supporting some mechanisms of making
> the runtime smaller - though LispWorks is surely not the
> smallest Lisp. The Delivery User Guide
> (http://www.lispworks.com/reference/lw43/DV/html/deluser.htm)
> explains it in detail.
My head hurts thinking about all these issues. That and I've been trying to
understand Arch (tla). Overload. Woah.
I keep hearing about Lispwork's nice deployment and GUI and stuff. The Regex
Coach is deployed using Lispworks, right? I may have to break down and buy
a copy one of these days ... thought it'd be best if I could find a project
at work to sneak it in for ...
So, the sort of modularity I referred to in my OP is desirable, right?
Perhaps not a top priority, and perhaps increasingly irrelevant, and
perhaps not something that will actually make it into any implementation,
but ...
Thanks for you time.
Chris Capel
In article <···············@corp.supernews.com>,
Chris Capel <······@iba.nktech.net> wrote:
> Rainer Joswig wrote:
>
> > In article <···············@corp.supernews.com>,
> > Chris Capel <······@iba.nktech.net> wrote:
> >
> >> ·········@gmail.com wrote:
> >>
> >> > Other implementations might have more overhead (I
> >> > believe the SBCL core is something like 6 MB),
> >>
> >> ~ $ ls /usr/local/lib/sbcl/sbcl.core -l
> >> -rw-r--r-- 1 root root 23220224 Nov 14 02:10
> >> /usr/local/lib/sbcl/sbcl.core
> >>
> >> I don't know about you, but 23 MB for the default core seems a bit big to
> >> me. Or maybe I'm just being a Unix newbie ... ?
> >
> > Is the file size the problem for you? Or the size of used
> > memory at runtime? The size of resident non-sharable memory
> > at runtime? For one Lisp or do you start several
> > independent Lisp processes?
>
> [snip]
>
> > Is that 23MB SBCL core shareable if you start more than one SBCL?
> > How much is that at runtime?
>
> Well, aside from the overcommitment of memory, which causes my process
> monitors to say SBCL takes up 864 MB of virtual (for every process), the
> whole 23.6 of the core is shared, while it adds an additional 8.9 resident.
> An additional process adds 2.3 MB to total usage immediately--somewhat
> contradictory, as it also reports 8.9 resident. But I probably don't know
> how to read these things.
>
> Now, this isn't a problem for a server or a development machine or a
> high-end workstation that many commercially developed lisp programs would
> be running on. But would you say that SBCL's (and CMUCL's) size is an
> anomaly?
All Lisp systems are different.
a) Lisps that have extensive development environments, large libraries,
lots of extensions to ANSI CL. These tend to provide rich
options for delivery. Compilation is native. The Lisps tend to
be not really small. Generated code might be largish.
Lots of bells and whistles. Can generate code with good performance.
Commercial.
Allegro CL, LispWorks.
b) Lisps that don't have that good performance, but small footprint.
They either use byte-codes or compile to (often not that efficient)
compact code.
OpenMCL, MCL, CLisp, Corman CL, ...
c) special purpose Lisps for embedding and/or delivery.
Means you can develop with them, but it might be
useful to have another Lisp for development.
CLICC (dead), WCL (dead), ECL (actively maintained), ThinLisp
(?)
d) native compiling Lisps with often excellent performance
ACL, LispWorks, CMUCL, SBCL, ...
e) Lisps for the Windows platform with special support
Corman Lisp, Golden Common Lisp, Allegro CL for Windows, LispWorks for Windows
f) Lisps for the Mac OS X platform with special support
MCL, OpenMCL, LispWorks for Macintosh
g) cross-platform Lisps
CLisp, GCL, CMUCL, SBCL, ACL, LispWorks, ...
h) Lisps for multiprocessor machines
Scieneer Common Lisp, OpenMCL, Corman CL (?), ...
i) 64bit Lisps
Scieneer Common Lisp, Allegro CL, ...
j) Lisps on top of a Lisp operating system
Xerox Common Lisp, Symbolics Common Lisp, TI CL, ...
and so on.
Coming back to your question, yes, there are other Lisps that
tend to be generate large code and take quite a bit
of memory.
> I have little experience with other implementations, and now that
> I look, CLISP indeed only takes up a few megabytes in memory, most of that
> shared. That's less that twice as much as bash.
Yes, CLISP is small. So is OpenMCL on the Mac. IIRC you can compile
code with GCL to be relatively small.
>
> Can anyone speak as to whether there are difficulties with performance when
> using CLISP to write non-algorithm-intensive, interactive programs? I
> wouldn't imagine, on modern machines, that the difference would be
> noticable, especially for I/O bound applications, or foreign-library
> intensive ones.
CLisp runs Lisp either interpreted or compiled to byte-code.
For some applications that can be advantage. Usually other
Lisps will generate much faster running code. CLISP
has fast bignums.
>
> > How about ECL? CLISP? GCL? On the Mac, OpenMCL is also
> > relatively small.
> >
> > There were several Lisps that tried to be smaller and/or
> > especially for delivery (WCL, ThinLisp, earlier versions
> > of XLisp, CLICC) pluss they tried to be atleast somehow compatible
> > with Common Lisp.
>
> But the problem with CLISP, and far worse with GCL and ECL, is the poor
> library support and non ANSI-ness.
Depends. Often libraries can be ported to CLISP.
Plus in everyday programming not-so-perfect ANSI-CL-compliance
does not really matter. Make sure you find a CL-USER
and a COMMON-LISP package and then go. ;-)
Something not to underestimate is that applications are
the drivers for the development of the Lisp systems.
Your requests, input, feedback, money (!!!) gives the
Lisp system implementor/vendor the feedback/motives
to develop his/her system...
> I looked into GCL today, and found it
> couldn't be used in SLIME! (Though I understand the maintainers aren't
> happy about this, but not exactly rolling in free-time or
> listener-supported motivation :-).)
The GCL is currently quite active. So it might be possible
that there will be something like that some time. In the meantime
just use ILISP...
> Now, as a target for deployment, that
> may not be such a big issue, and seeing as how GCL was based on gcc, I
> thought "Hey, maybe it supports some cool embeddable things like compiling
> to linkable libraries or taking out the compiler". It may be that that
> would be a solution for a past problem, when machines were smaller, but
> then GCL's been around for a while, hasn't it?
Sure. GCL is based on earlier Lisps that spawned a whole family
of implementations (KCL, AKCL, GCL, ... wasn't ECL earlier also
in the KCL-family?).
>
> Now that you've pointed it out, ECL and WCL seem to be up the alley I was
> referring to in my OP. But--and this is my curiosity here--they seem to be
> almost entirely absent from the general CL culture.
There is not a general CL culture (see above).
>While you'll find Cliki
> entries for them, they aren't mentioned much in other Cliki pages. You
> won't find them on many libraries' "supported" list (unless I've been
> selectively blind). They aren't mentioned in blogs, they aren't mentioned
> in usenet, they aren't mentioned much in #lisp. What's the reason for this?
> Do they have the some sort of incompleteness/weirdness/ obseleteness? Or
> maybe their users are just too happy to ever complain. :-) Maybe they have
> a separate culture...
WCL is mostly dead I think.
ECL is active, but not that widely used I would think.
> Is there a link for WCL that's more informative than http://wcl.kontiki.com/
> ? That page is rather sparse.
>
> > Many people had that problem over the time. Some
> > commercial Lisps also have their own answers to it.
> > LispWorks for example allows you to create
> > applications by supporting some mechanisms of making
> > the runtime smaller - though LispWorks is surely not the
> > smallest Lisp. The Delivery User Guide
> > (http://www.lispworks.com/reference/lw43/DV/html/deluser.htm)
> > explains it in detail.
>
> My head hurts thinking about all these issues. That and I've been trying to
> understand Arch (tla). Overload. Woah.
>
> I keep hearing about Lispwork's nice deployment and GUI and stuff. The Regex
> Coach is deployed using Lispworks, right? I may have to break down and buy
> a copy one of these days ... thought it'd be best if I could find a project
> at work to sneak it in for ...
Right. LispWorks has been used for the Regex Coach by Edi Weitz.
This should give you an impression what a small application
of LispWorks would look like.
Xanalys has another application written in LispWorks: Link Explorer -
which was 'Watson' in early times.
(http://www.xanalys.com/solutions/linkexplorer.html).
You can also do interesting applications for Windows with Allegro CL.
Franz has written an NFS server (!!!) for Windows in Allegro Common Lisp.
http://www.nfsforwindows.com/
Source is here: http://opensource.franz.com/nfs/
> So, the sort of modularity I referred to in my OP is desirable, right?
> Perhaps not a top priority, and perhaps increasingly irrelevant, and
> perhaps not something that will actually make it into any implementation,
> but ...
>
> Thanks for you time.
>
> Chris Capel
I think what the OP, and many like him, are asking for is a high-performance
free implementation like SBCL. But he wants to *deliver* "crippled"
stand-alone apps with no run-time compiler and with no unnecessary
functions linked in in the final executable.
Neo-LISPer wrote:
> I think what the OP, and many like him, are asking for is a
> high-performance free implementation like SBCL. But he wants to *deliver*
> "crippled" stand-alone apps with no run-time compiler and with no
> unnecessary functions linked in in the final executable.
Those desires were based primarily on the misconception that most lisps had
footprints of tens of megabytes, which turns out to be true in less than
all cases. So if I try hard enough, I could get my app to deploy in GCL, or
CLISP if it's fast enough, which should be sufficient for the target
market. Although I would like to hear people's opinions on the usability of
these various "lesser"--smaller--implementations for these purposes.
Chris Capel
Chris Capel wrote:
>>For example, Corman Lisp adds slightly over a megabyte of overhead to a
>>statically linked exe file, despite having aspirations of being an
>>ANSI-conforming Common Lisp implementation. That doesn't feel like a
>>whole lot to me.
This sounds very good, is Corman Lisp close to ANSI-compability? And is
it in much active use (compared to other Win-Lisps)?
> ~ $ ls /usr/local/lib/sbcl/sbcl.core -l
> -rw-r--r-- 1 root root 23220224 Nov 14 02:10
> /usr/local/lib/sbcl/sbcl.core
>
> I don't know about you, but 23 MB for the default core seems a bit big to
> me. Or maybe I'm just being a Unix newbie ... ?
Does anyone know the reason for a CMUCL/SBCL having a core of this size?
I read about trimming the core with tree-shakes and stripping out
documentation-strings somewhere. I would believe the latter would be the
easier part.
A quick check with:
| vequess:% strings /usr/local/bin/lisp.core > strings-in-core.txt
| vequess:% ls -s strings-in-core.txt
| 2272 strings-in-core.txt
| vequess:%
shows about 2,2 MB's of strings in the core (most that aren't
documentation strings I suppose). Assuming half of these could be
removed, the core size is reduced by 5%, but still a way-big core-file.
btw. clisp has amazingly small memory-dumps. A "null-test" (starting
clisp and doing nothing before saving the core) produces a core of about
1MB, also it can read gzipped cores, wich ends up with cores of about
500KB. The interpreter is 8KB, and depends solely on libc it seems.
--
�yvin
Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> wrote:
> Does anyone know the reason for a CMUCL/SBCL having a core of this size?
Several reasons, most of which boild down to shrinking core-sizes not being
very high on the list of priorities:
* No code-compaction techniques are being used.
* No tree shaker, so unused machinery remains in the core.
* Debugging information in the core.
(Which is just another way of saing what Edi said, about SBCL and CMUCL
producing largish code.)
Otoh, I seem to recall hearing that someone was able to bundle the CMUCL core
with the runtime using some heavyhanded ld-magic, and subsequently turn this
into a 3Mb executable with gzexe; of course, if your problem is the virtual
memory allocation then this will not help.
The question remains: when are you requirements?
Cheers,
-- Nikodemus
Nikodemus Siivola wrote:
> Otoh, I seem to recall hearing that someone was able to bundle the
> CMUCL core with the runtime using some heavyhanded ld-magic, and
> subsequently turn this into a 3Mb executable with gzexe; of course,
> if your problem is the virtual memory allocation then this will not
> help.
Yes, that was me. Too non-portable though.
Actually you can get a CMUCL runtime that's pretty small by doing the
following:
(pushnew :runtime *features*)
(pushnew :small *features*)
(pushnew :no-pcl *features*)
You can't use PCL of course because you won't have a compiler.
The resulting core is 5Mb in size. It doesn't do anything of course,
but you could put your application in (as long as it doesn't use the
compiler while running). I once got Hemlock, the CMUCL emacs clone,
to run in a 9Mb core. That includes the runtime, a non-PCL CLX, and
Hemlock itself. Then I did my "Lisp executable" thing and ran gzexe
on the result and got the entire thing so it was just a bit larger
than my Emacs executable.
To make a non-PCL CLX, you have to build a CMUCL without PCL, then do
(pushnew :no-pcl-clx *features*)
and build the utilities. (The CLM package won't build, of course).
There's also a problem in that Hemlock uses some function from the
compiler (I forget what) to call the compiler of the slave Lisp
process. But if you don't do that it will work, or you could steal
that function and then you could use a lightweight CMUCL core with
Hemlock as an editor and some other full-blown Lisp core as a slave
Lisp to do your development.
I don't know how much longer building CMUCL runtimes will work, since
nobody uses it that I know of.
--
Fred Gilham ······@csl.sri.com
We have a two party system. One party wants to drive the country
full-speed off a cliff. The other party wants to drive off the same
cliff, but insists on obeying the posted speed-limit.
On 22 Nov 2004 14:48:19 GMT, Nikodemus Siivola <········@sokeri.niksula.hut.fi> wrote:
> (Which is just another way of saing what Edi said, about SBCL and
> CMUCL producing largish code.)
Huh? I wasn't even part of this thread up until now... :)
(But, yes, they do, and, no, I usually don't care. It's fine with me.)
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> wrote:
> > (Which is just another way of saing what Edi said, about SBCL and
> > CMUCL producing largish code.)
> Huh? I wasn't even part of this thread up until now... :)
My bad, it was Rainer Joswig. This is what happens when I trust my memory.
Cheers,
-- Nikodemus
Oyvin Halfdan Thuv <·····@no.spam.oyvins.net> writes:
> btw. clisp has amazingly small memory-dumps. A "null-test" (starting
> clisp and doing nothing before saving the core) produces a core of
> about 1MB, also it can read gzipped cores, wich ends up with cores of
> about 500KB. The interpreter is 8KB, and depends solely on libc it
> seems.
No, bin/clisp is a wrapper, the real virtual machine (clisp doesn't
contain (only) an interpreter, it has a *compiler* too!) is
lib/clisp/*/lisp.run which is less than 2MB:
1.6M 2004-01-25 04:25 /local/languages/clisp-2.32/lib/clisp/base/lisp.run*
1.8M 2004-01-25 04:25 /local/languages/clisp-2.32/lib/clisp/full/lisp.run*
clisp doesn't have documentation strings for its packages. But this is
still much smaller than sbcl or cmucl.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.