From: Fredrik Sandstr�m
Subject: Making executables with CMUCL
Date: 
Message-ID: <slrn75b7rc.106.fredrik@infa.abo.fi>
I'm getting started with CMU Common Lisp, and I'm wondering if there's
any way to create an executable file from the .x86f object files that
the compiler generates, so the program can be executed on a system that
doesn't have the CMUCL system installed.

The documentation doesn't mention this as far as I can see...


                Fredrik Sandstrom | "I have never let my schooling
              ·······@infa.abo.fi |  interfere with my education."
      http://infa.abo.fi/~fredrik |                   - Mark Twain

From: Martin Cracauer
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <734n1q$n1u$1@counter.bik-gmbh.de>
·······@infa.abo.fi (Fredrik Sandstr�m) writes:

>I'm getting started with CMU Common Lisp, and I'm wondering if there's
>any way to create an executable file from the .x86f object files that
>the compiler generates, so the program can be executed on a system that
>doesn't have the CMUCL system installed.

CMUCL doesn't have that capabilty, although all kinds of Unix
workarounds are imaginable:

- Deliver a shellscript that has an uuencoded tarfile in it that
  unpacks the full CMUCL to /tmp unless its already there.
- Turn the whole thing into static C statements like the scheme48/scsh
  static loader does.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer - for email address see a search engine.
There is a business like showbusiness: www.microsoft.com
http://www.freebsd.org/  -  Where you want to go. Today.
From: Pierre Mai
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <873e7djjpk.fsf@dent.isdn.cs.tu-berlin.de>
········@not.mailable (Martin Cracauer) writes:

> CMUCL doesn't have that capabilty, although all kinds of Unix
> workarounds are imaginable:
> 
> - Deliver a shellscript that has an uuencoded tarfile in it that
>   unpacks the full CMUCL to /tmp unless its already there.
> - Turn the whole thing into static C statements like the scheme48/scsh
>   static loader does.

Well, the simplest solution IMHO is to dump a new image and distribute 
exactly 3 pieces in a .tar.gz file (which again might be encapsulated
by a shell-script to automate installation, but this is another
matter):

- The dumped image file (depending on the loaded things ~ 20Meg)
- The standard /usr/bin/lisp distributed with CMUCL (~ 80K)
- A small shell-script (or executable, if you don't want to show),
  which executes "/usr/bin/lisp -core myapp.core" (<< 1K)

This can all be compressed down to a .tar.gz of about 7Megs using gzip 
-9 .  

Since most applications delivered will need an archive anyhow (you'll
like to include documentation, READMEs, ...), this is in no way
different to normal application delivery.  And compared to Java, where 
the JDK and Swing each use 15Megs in a *.tar.gz file, you are using at 
the most half as much space in delivery mode... ;)

For another summary of this, reread my message in this group from the
8th Oct, message-id <··············@dent.isdn.cs.tu-berlin.de> ...

Regs, Pierre.

-- 
Pierre Mai <····@acm.org>               http://home.pages.de/~trillian/
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Rainer Joswig
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <joswig-2111982039460001@194.163.195.67>
In article <··············@dent.isdn.cs.tu-berlin.de>, Pierre Mai
<····@acm.org> wrote:

> - The dumped image file (depending on the loaded things ~ 20Meg)

Why is it so large?

-- 
http://www.lavielle.com/~joswig
From: Pierre Mai
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <8767c5ji6k.fsf@dent.isdn.cs.tu-berlin.de>
······@lavielle.com (Rainer Joswig) writes:

> In article <··············@dent.isdn.cs.tu-berlin.de>, Pierre Mai
> <····@acm.org> wrote:
> 
> > - The dumped image file (depending on the loaded things ~ 20Meg)
> 
> Why is it so large?

Since no one more knowledgable about CMU CL has answered yet, I'll
give it a shot.  First of: Much of the following is guesswork from
an outsider, since I'm not intimate with either the CMU CL project
history or implementation strategies.  Maybe one of the current or
past developers can comment more specifically and/or correct me...

So why is it so large?  Probably for a number of reasons.  Underlying
them might be the origins of the CMU CL project.  Since CMU CL was
always targeted at workstations, being small was probably never much
of a priority. OTOH speed and optimization were, which is reflected in
CMU CL's current compiler, Python[1].  Python is a large, complex
beast, but does much type inferencing, source and internal
transformations, etc. Also Python is based on a flexible virtual
machine representation, which made it possible to retarget the
compiler to as diverse architecture as IBM's RT-PC, HPPA, MIPS, SPARC,
DEC Alpha and the iA32 (i.e. i386 and upwards).

Since the dumped image contains the full CL environment, i.e. complete 
with compiler, PCL, etc.,  the image is quite large.  There was/is a
possibility to not include the compiler in an image, but this is
pretty pointless with a PCL-based CLOS subsystem, since PCL depends on 
the availability of the compiler at load/runtime, so CLOS was also
excluded.  In the 17f release (which was the last official CMU release 
from 1994), the runtime-core was around a third of the normal core,
with a size of 5.3MB vs. 15MB for the whole distribution with a normal 
core.

But since memory is even cheaper nowadays, there is not much incentive 
to make current runtime images, since it would require reimplementing
much of PCL, with a dubious gain.  There are many more pressing
problems to attack IMHO...  And if image size is a premium for
someone, there are already a number of CL implementations out there,
that have much smaller footprints, because of other trade-offs
chosen...

Regs, Pierre (who is considering getting a cheap Mac, just for getting 
to play with MCL ;)

Regs, Pierre.

Footnotes: 
[1]  For future readers via Deja News:  Python here is the name of CMU 
CL's compiler, and has no connection whatsoever with the currently hip 
scripting language called Python!

-- 
Pierre Mai <····@acm.org>               http://home.pages.de/~trillian/
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Rainer Joswig
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <joswig-2411981553110001@pbg3.lavielle.com>
In article <··············@dent.isdn.cs.tu-berlin.de>, Pierre Mai
<····@acm.org> wrote:

> Since the dumped image contains the full CL environment, i.e. complete 
> with compiler, PCL, etc.,  the image is quite large.  There was/is a
> possibility to not include the compiler in an image, but this is
> pretty pointless with a PCL-based CLOS subsystem, since PCL depends on 
> the availability of the compiler at load/runtime, so CLOS was also
> excluded.  In the 17f release (which was the last official CMU release 
> from 1994), the runtime-core was around a third of the normal core,
> with a size of 5.3MB vs. 15MB for the whole distribution with a normal 
> core.

MCL on PPC:
 1.5 MB Executable
 2.9 MB Library (shared)
 0.4 MB Compiler (shared)
 0.2 MB Kernel (shared)

This sums up to 5 MB which also can be converted into one file.
It also includes much of the UI for the development environment
(editor, debugger, inspector, backtrace, apropos, trace,
listener, ...).

> But since memory is even cheaper nowadays, there is not much incentive 
> to make current runtime images, since it would require reimplementing
> much of PCL, with a dubious gain.  There are many more pressing
> problems to attack IMHO...  And if image size is a premium for
> someone, there are already a number of CL implementations out there,
> that have much smaller footprints, because of other trade-offs
> chosen...

I guess it might help when you want to run multiple Lisps
at the same time. Another added bonus is less work for the
GC (less memory to scan) and it may be much more friendly to caches.


> Regs, Pierre (who is considering getting a cheap Mac, just for getting 
> to play with MCL ;)

get atleast a G3-based machine...

-- 
http://www.lavielle.com/~joswig
From: Marco Antoniotti
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <lw3e796pv7.fsf@copernico.parades.rm.cnr.it>
······@lavielle.com (Rainer Joswig) writes:

> In article <··············@dent.isdn.cs.tu-berlin.de>, Pierre Mai
> <····@acm.org> wrote:
> 
> > Since the dumped image contains the full CL environment, i.e. complete 
> > with compiler, PCL, etc.,  the image is quite large.  There was/is a
> > possibility to not include the compiler in an image, but this is
> > pretty pointless with a PCL-based CLOS subsystem, since PCL depends on 
> > the availability of the compiler at load/runtime, so CLOS was also
> > excluded.  In the 17f release (which was the last official CMU release 
> > from 1994), the runtime-core was around a third of the normal core,
> > with a size of 5.3MB vs. 15MB for the whole distribution with a normal 
> > core.
> 
> MCL on PPC:
>  1.5 MB Executable
>  2.9 MB Library (shared)
>  0.4 MB Compiler (shared)
>  0.2 MB Kernel (shared)
> 
> This sums up to 5 MB which also can be converted into one file.
> It also includes much of the UI for the development environment
> (editor, debugger, inspector, backtrace, apropos, trace,
> listener, ...).

MCL is a wonderful thing. However, when it comes to size, I understand
that the small footprint is due to the Mac libraries, plus the fact
that a lot of MCL was actually developed in assembly code.  I remember
running Coral Lisp (the direct predecessor) on a Mac Plus with 4
Mb. The image size was then ~700 Kb.

All the other CL's have rather large footprint and/or library size.

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Rainer Joswig
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <joswig-2411981752100001@pbg3.lavielle.com>
In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti
<·······@copernico.parades.rm.cnr.it> wrote:

> > MCL on PPC:
> >  1.5 MB Executable
> >  2.9 MB Library (shared)
> >  0.4 MB Compiler (shared)
> >  0.2 MB Kernel (shared)
> > 
> > This sums up to 5 MB which also can be converted into one file.
> > It also includes much of the UI for the development environment
> > (editor, debugger, inspector, backtrace, apropos, trace,
> > listener, ...).
> 
> MCL is a wonderful thing.

Yep. ;-)

> However, when it comes to size, I understand
> that the small footprint is due to the Mac libraries,

MCL also provides an OO-layer over some of these libraries,
or even reimplements these (like the table dialog items).

> plus the fact
> that a lot of MCL was actually developed in assembly code.

Not that true anymore. Much of the previously 68k coded
Lisp stuff has been coded in Lisp for the PowerMac port.

-- 
http://www.lavielle.com/~joswig
From: David B. Lamkins
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <99C62.9679$Sz4.5247639@news.teleport.com>
In article <··············@copernico.parades.rm.cnr.it> , Marco Antoniotti
<·······@copernico.parades.rm.cnr.it>  wrote:

>
>······@lavielle.com (Rainer Joswig) writes:
>
[snip]
>> MCL on PPC:
>>  1.5 MB Executable
>>  2.9 MB Library (shared)
>>  0.4 MB Compiler (shared)
>>  0.2 MB Kernel (shared)
>> 
>> This sums up to 5 MB which also can be converted into one file.
>> It also includes much of the UI for the development environment
>> (editor, debugger, inspector, backtrace, apropos, trace,
>> listener, ...).
>
>MCL is a wonderful thing. However, when it comes to size, I understand
>that the small footprint is due to the Mac libraries, plus the fact
>that a lot of MCL was actually developed in assembly code.  I remember
>running Coral Lisp (the direct predecessor) on a Mac Plus with 4
>Mb. The image size was then ~700 Kb.
>

Judging from comments in the available interfaces and documentation -- the
kernel source is not provided to customers -- MCL (and earlier, CCL) have
always had portions of the kernel written in C and/or assembler. 
Presumably, this code includes the subprimitives and a small amount of
boilerplate code to let MCL run in the Mac OS.

Up through MCL 2.0, speed-critical portions of the UI (especially the
editor) were written in 68K LAP.  When Digitool ported to the PPC
architecture, they moved as much code as they could from LAP to Lisp, so
they wouldn't have to maintain large bodies of 68K LAP and PPC LAP in
parallel.  In the current release (4.2) there remains a very small amount of
LAP code conditionalized by platform.

Of course, shared libraries simply put MCL on an even footing with other
implementation languages.  Mac apps would be much larger if they had to be
statically linked.

I suspect that the growth of image size since then is mostly a result of new
features.  Also, RISC (PPC) code tends to be more voluminous than CISC (68K)
code.

>All the other CL's have rather large footprint and/or library size.

I attended an MCL user's group meeting at MIT a long time ago; this may have
been in the days before Digitool.  Anyhow, one of the MIT folks (a Macsyma
developer or maintainer, IIRC) pointed out that MCL produced by far the
smallest code when compiling Macsyma.

---
David B. Lamkins <http://www.teleport.com/~dlamkins/>
From: John Wiseman
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <arx1zmsqq5r.fsf@gargoyle.cs.uchicago.edu>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> MCL is a wonderful thing. However, when it comes to size, I understand
> that the small footprint is due to the Mac libraries, plus the fact
> that a lot of MCL was actually developed in assembly code.

I have heard other people mention the same thing concerning "Mac
libraries" in relation to the size of MCL, and I don't know what they
mean.  It's not like the Mac has Lisp utility functions built in at
the OS level.  If anything the Mac OS is smaller than Windows and
probably has less functionality (in terms of size/number of APIs).


John Wiseman
From: Peter Van Eynde
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <slrn75o4bj.3k0.pvaneynd@mail.inthan.be>
On Wed, 25 Nov 1998 05:48:00 GMT, John Wiseman wrote:
>> that the small footprint is due to the Mac libraries, plus the fact
>> that a lot of MCL was actually developed in assembly code.
>
>I have heard other people mention the same thing concerning "Mac
>libraries" in relation to the size of MCL, and I don't know what they
>mean.  It's not like the Mac has Lisp utility functions built in at
>the OS level.  If anything the Mac OS is smaller than Windows and
>probably has less functionality (in terms of size/number of APIs).

More is not better.

Actually it seems that Microsoft thinks that the number of API calls is
a metric that should only go up. Why else would they have multiple,
incompatible API's for the same stuff? 

Groetjes, Peter

-- 
It's logic Jim, but not as we know it. | ········@debian.org for pleasure,
"God, root, what is difference?",Pitr  | ········@inthan.be for more pleasure!
From: David B. Lamkins
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <K2X62.10771$Sz4.5845633@news.teleport.com>
In article <···············@gargoyle.cs.uchicago.edu> ,
·······@cs.uchicago.edu (John Wiseman) wrote:

>Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>>
>> MCL is a wonderful thing. However, when it comes to size, I understand
>> that the small footprint is due to the Mac libraries, plus the fact
>> that a lot of MCL was actually developed in assembly code.
>
>I have heard other people mention the same thing concerning "Mac
>libraries" in relation to the size of MCL, and I don't know what they
>mean.  It's not like the Mac has Lisp utility functions built in at
>the OS level.  If anything the Mac OS is smaller than Windows and
>probably has less functionality (in terms of size/number of APIs).

I think that the implied point about the MCL libraries is that they are
separate from the distributed image.  Therefore they don't count _directly_
toward the size of an MCL application, because the cost (size) of the
libraries can be amortized across all of the MCL apps that reside on your
system.  

---
David B. Lamkins <http://www.teleport.com/~dlamkins/>

Wintel is the Yugo of the computer world: cheap to buy, costly to keep.
From: Juliusz Chroboczek
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <dh3yaoyh7ou.fsf@iolla.dcs.ed.ac.uk>
In article <·······················@pbg3.lavielle.com>,
  ······@lavielle.com (Rainer Joswig) writes:

RJ> MCL on PPC:
RJ>  1.5 MB Executable
RJ>  2.9 MB Library (shared)
RJ>  0.4 MB Compiler (shared)
RJ>  0.2 MB Kernel (shared)

Very impressive.

RJ> I guess [having a small footprint] might help when you want to run
RJ> multiple Lisps at the same time. Another added bonus is less work
RJ> for the GC (less memory to scan)

Not really.  Most of the startup image is put into `pure' (immutable)
memory, which on any decent OS will be shared between processes (on
many systems impure memory will be shared too, until it is first
mutated).  Pure memory is also not scanned by the GC (someone once
called it a ``poor man's generational GC'').

I would guess that one reason for the large image design of CMUCL was
that Fahlman's group were targeting Mach, which has had proper memory
management from day one.

RJ> it may be much more friendly to caches.

That's likely.

                                        J.
From: Rainer Joswig
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <joswig-2611981542330001@pbg3.lavielle.com>
In article <···············@iolla.dcs.ed.ac.uk>, Juliusz Chroboczek
<···@dcs.ed.ac.uk> wrote:

> In article <·······················@pbg3.lavielle.com>,
>   ······@lavielle.com (Rainer Joswig) writes:
> 
> RJ> MCL on PPC:
> RJ>  1.5 MB Executable
> RJ>  2.9 MB Library (shared)
> RJ>  0.4 MB Compiler (shared)
> RJ>  0.2 MB Kernel (shared)
> 
> Very impressive.

I just checked somebodies commercial MCL application.
It was 3.4 (!!!) MB (no libraries, nothing, just the application).
It was really doing complex UI stuff.
Now we are talking.

-- 
http://www.lavielle.com/~joswig
From: Rainer Joswig
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <joswig-2611981553510001@pbg3.lavielle.com>
In article <·······················@pbg3.lavielle.com>,
······@lavielle.com (Rainer Joswig) wrote:

> In article <···············@iolla.dcs.ed.ac.uk>, Juliusz Chroboczek
> <···@dcs.ed.ac.uk> wrote:
> 
> > In article <·······················@pbg3.lavielle.com>,
> >   ······@lavielle.com (Rainer Joswig) writes:
> > 
> > RJ> MCL on PPC:
> > RJ>  1.5 MB Executable
> > RJ>  2.9 MB Library (shared)
> > RJ>  0.4 MB Compiler (shared)
> > RJ>  0.2 MB Kernel (shared)
> > 
> > Very impressive.
> 
> I just checked somebodies commercial MCL application.
> It was 3.4 (!!!) MB (no libraries, nothing, just the application).
> It was really doing complex UI stuff.
> Now we are talking.

Correction. The app uses the Library and the Kernel shared libraries.

-- 
http://www.lavielle.com/~joswig
From: Marco Antoniotti
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <lw7lwoyohy.fsf@copernico.parades.rm.cnr.it>
·······@infa.abo.fi (Fredrik Sandstr�m) writes:

> I'm getting started with CMU Common Lisp, and I'm wondering if there's
> any way to create an executable file from the .x86f object files that
> the compiler generates, so the program can be executed on a system that
> doesn't have the CMUCL system installed.
> 
> The documentation doesn't mention this as far as I can see...
> 

Er.... I may sound kind of arrogant here, but would you distribute an
X Window application to a system with no X libraries installed?
How about a C based application to a system which does not have libc?

The only reasons you would like to do so in the case of CMUCL, is that
you do not want to get your code "inspected". But CMUCL is PD, so
anybody could downloaded it and circumvent your precautions.

On top of that, installing (not recompiling!!!) CMUCL is very easy
(although not automatic). So ship CMUCL along with your system and
help spreading Common Lisp.

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Fredrik Sandstr�m
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <slrn75l4i2.693.fredrik@infa.abo.fi>
On 22 Nov 1998 12:07:37 +0100, Marco Antoniotti
<·······@copernico.parades.rm.cnr.it> wrote:
>Er.... I may sound kind of arrogant here, but would you distribute an
>X Window application to a system with no X libraries installed?

Why not? If this is the only X application that will be used on the
machine, making a statically linked executable might be a better
choice than installing the X libraries.  Early releases of Netscape
for Linux came statically linked against libc, X11R5, and Motif.

>How about a C based application to a system which does not have libc?

Well, if I make a C program that makes use of some glibc2 feature not
found in Linux libc5, I might want to make a statically linked
executable so libc5-based systems can run it without having to install
the entire glibc2.

>The only reasons you would like to do so in the case of CMUCL, is that
>you do not want to get your code "inspected".

Hrmpf. How insulting. I would never distribute a program without source.

>On top of that, installing (not recompiling!!!) CMUCL is very easy
>(although not automatic). So ship CMUCL along with your system and
>help spreading Common Lisp.

CMUCL is of course not terribly big, but it still seems a bit wasteful
having to install it just to run a single app or two. Most people
don't run any Lisp programs at all (except for Emacs) and they might
not feel warranted to install CMUCL just because I chose an obscure
language. ;-)


                Fredrik Sandstrom | "I have never let my schooling
              ·······@infa.abo.fi |  interfere with my education."
      http://infa.abo.fi/~fredrik |                   - Mark Twain
From: Pierre Mai
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <87d86djjz6.fsf@dent.isdn.cs.tu-berlin.de>
·······@infa.abo.fi (Fredrik Sandström) writes:

> CMUCL is of course not terribly big, but it still seems a bit wasteful
> having to install it just to run a single app or two. Most people
> don't run any Lisp programs at all (except for Emacs) and they might
> not feel warranted to install CMUCL just because I chose an obscure
> language. ;-)

Well, with Java they already have to do that, and the JDK (+ Swing
which most apps seem to use nowadays) are a bit bigger than CMU CL.
And with CMU CL you can legally choose to redistribute parts of CMU CL 
only (like I sketched out in previous postings).  With Sun's JDK I'm
not so sure (never bothered to read the licence in detail, since Java
gives me the shudders[1] and is slow as hell on my home machine).

Why is it so difficult to dump an image, and redistribute the lisp
binary stub (80K) and a small shell-script together with this image?
This is very similar to static linking, since the dumped image can
often not be reused by other applications.  Installing a complete CMU
CL (i.e. the dynamic solution) is more efficient in this regard, when
more than one application is going to be installed, and it enables the 
user to recompile your application from source, should you choose to
distribute it...

With "modern" Unix systems, like Debian/Linux and FreeBSD, you could
even get away with putting a dependency on your application package,
and CMU CL can be magically installed from the nearest site <g>

Regs, Pierre.


Footnotes: 
[1]  Java is IMHO another example of a "Syntax/Semantics mismatch".
C's syntax is ok for C, but it doesn't extend well to Java's features
and semantics, IMHO.  So no matter how often it's iterated that Java
is in fact Smalltalk or Lisp in disguise (see closures, etc.), it
still is C syntax, and this makes using advanced idioms painful, IMHO.

-- 
Pierre Mai <····@acm.org>               http://home.pages.de/~trillian/
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Marco Antoniotti
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <lw1zmt6pje.fsf@copernico.parades.rm.cnr.it>
·······@infa.abo.fi (Fredrik Sandstr�m) writes:

> On 22 Nov 1998 12:07:37 +0100, Marco Antoniotti
> <·······@copernico.parades.rm.cnr.it> wrote:
> >Er.... I may sound kind of arrogant here, but would you distribute an
> >X Window application to a system with no X libraries installed?
> 
> Why not? If this is the only X application that will be used on the
> machine, making a statically linked executable might be a better
> choice than installing the X libraries.  Early releases of Netscape
> for Linux came statically linked against libc, X11R5, and Motif.

So? Distribute a CMUCL dumped image. This is equivalent to
distributing a statically linked application.
> 
> >How about a C based application to a system which does not have libc?

> Well, if I make a C program that makes use of some glibc2 feature not
> found in Linux libc5, I might want to make a statically linked
> executable so libc5-based systems can run it without having to install
> the entire glibc2.

Seems to me that the same argument applies.

> >The only reasons you would like to do so in the case of CMUCL, is that
> >you do not want to get your code "inspected".
> 
> Hrmpf. How insulting. I would never distribute a program without source.
> 

Fine.

> >On top of that, installing (not recompiling!!!) CMUCL is very easy
> >(although not automatic). So ship CMUCL along with your system and
> >help spreading Common Lisp.
> 
> CMUCL is of course not terribly big, but it still seems a bit wasteful
> having to install it just to run a single app or two. Most people
> don't run any Lisp programs at all (except for Emacs) and they might
> not feel warranted to install CMUCL just because I chose an obscure
> language. ;-)

It turns out that if you install Netscape, you install Java as
well. My suggestion is not to tell people that you use an "obscure
language" and just ship the application.

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
From: Fredrik Sandstr�m
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <slrn75o487.t8p.fredrik@infa.abo.fi>
On 24 Nov 1998 17:09:25 +0100, Marco Antoniotti
<·······@copernico.parades.rm.cnr.it> wrote:
>So? Distribute a CMUCL dumped image. This is equivalent to
>distributing a statically linked application.

Except that a dumped image will include a *lot* of code that is never
used, whereas statically linking a C program only includes the
relevant parts of the library. Of course, because of the nature of
Lisp it's difficult to tell what is needed and what isn't...

>My suggestion is not to tell people that you use an "obscure
>language" and just ship the application.

Yes, I realize it's not that big a problem. Fortunately the size of
CMUCL is managable.


                Fredrik Sandstrom | "I have never let my schooling
              ·······@infa.abo.fi |  interfere with my education."
      http://infa.abo.fi/~fredrik |                   - Mark Twain
From: Pierre Mai
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <87pvabd9ca.fsf@dent.isdn.cs.tu-berlin.de>
·······@infa.abo.fi (Fredrik Sandström) writes:

> Except that a dumped image will include a *lot* of code that is never
> used, whereas statically linking a C program only includes the
> relevant parts of the library. Of course, because of the nature of
> Lisp it's difficult to tell what is needed and what isn't...

Well, this is not true in the strictest sense:  The statically linked
C program will include all _object files_ of which _any_ symbol has
been referenced.  So whether or not your statically linked C program
will include non-relevant code depends largely on the granularity
which the library developer chose, which can sometimes be quite large
;).

There have been approaches to down-size lisp images, like
tree-shakers, which have met with limited success.  But on modern
machines (>64MB RAM, >4GB Hard-drives _at the least_), even CMU CL's
image (around 20MB) seems just tiny, and so IMHO it's not worth the
bother to try to reduce these sizes[1].  In CMU CL we'd rather need a
nice CLIM implementation than a tree-shaker of some sort IMHO...

> Yes, I realize it's not that big a problem. Fortunately the size of
> CMUCL is managable.

Extremely so, I'd say ;)

Regs, Pierre.

Footnotes: 
[1]  In areas like distributed computation, with severely restricted
throughput, size does of course matter.  But in those areas you will
usually want to put as much as possible on each machine to start with
(see Java!!!), so that you only need to communicate the little bits
which are new.  In those settings Lisp is also very competitive (look
at *.lisp file sizes, or the corresponding compiled file sizes: they
are quite small!), which out of the box is only missing security
features... 

-- 
Pierre Mai <····@acm.org>               http://home.pages.de/~trillian/
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Kelly Murray
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <k7lwj6okj.fsf@www.intellimarket.com>
> machines (>64MB RAM, >4GB Hard-drives _at the least_), even CMU CL's
> image (around 20MB) seems just tiny, and so IMHO it's not worth the
> bother to try to reduce these sizes[1].  In CMU CL we'd rather need a
> nice CLIM implementation than a tree-shaker of some sort IMHO...

20mb isn't much, unless you're selling a product in which
your competitors system is only 200K.  i.e. apache vs CL-HTTP

20mb doesn't include CLIM.  Load in CLIM, and then tell me
how big it is...

-kelly murray  ···@intellimarket.com
From: Daniel R Barlow
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <73k6tt$d4t@fishy.ox.compsoc.net>
In article <·············@www.intellimarket.com>,
Kelly Murray  <···@www.intellimarket.com> wrote:
>
>> machines (>64MB RAM, >4GB Hard-drives _at the least_), even CMU CL's
>> image (around 20MB) seems just tiny, and so IMHO it's not worth the
>> bother to try to reduce these sizes[1].  In CMU CL we'd rather need a
>> nice CLIM implementation than a tree-shaker of some sort IMHO...
>
>20mb isn't much, unless you're selling a product in which
>your competitors system is only 200K.  i.e. apache vs CL-HTTP

A fairer comparison would be against "apache with an embedded interpreter
of some sort" -- eg Apache + mod_perl.  On disk, that's 2Mb of apache 
binary and 13Mb of /usr/local/lib/perl5, or in memory it's 10 processes
of 8-10Mb each.  Most of that is shared between all the processes, of 
course.

-dan
From: Kelly Murray
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <365EF44F.1BD0EC5F@IntelliMarket.Com>
Daniel R Barlow wrote:
> 
> In article <·············@www.intellimarket.com>,
> Kelly Murray  <···@www.intellimarket.com> wrote:
> >
> >> machines (>64MB RAM, >4GB Hard-drives _at the least_), even CMU CL's
> >> image (around 20MB) seems just tiny, and so IMHO it's not worth the
> >> bother to try to reduce these sizes[1].  In CMU CL we'd rather need a
> >> nice CLIM implementation than a tree-shaker of some sort IMHO...
> >
> >20mb isn't much, unless you're selling a product in which
> >your competitors system is only 200K.  i.e. apache vs CL-HTTP
> 
> A fairer comparison would be against "apache with an embedded interpreter
> of some sort" -- eg Apache + mod_perl.  On disk, that's 2Mb of apache
> binary and 13Mb of /usr/local/lib/perl5, or in memory it's 10 processes
> of 8-10Mb each.  Most of that is shared between all the processes, of
> course.
> 
> -dan

That would be a fairer comparison, but the real world isn't fair..

My point is really that image and memory footprint does matter in the
competitive marketplace of customer-installed software products,
but perhaps more to the point is that we (the lisp community)
can't just fool ourselves that it isn't an issue.
Now let me say it is "fighting the last war" trying to get standalone
lisp apps down to under 1mb levels.  We already lost that war a long
time ago, and the battlground has dramatically changed.
However, for server-based applications, the size really doesn't matter
if one big lisp process is actually doing lots of valuable work.
But that doesn't mean we are now free to create 128mb bloated lisp
server applications...

In any case, on my linux machine, httpd is only 120K
[···@www]$ ls -l /usr/sbin/httpd
-rwxr-xr-x   1 root     root       120064 Dec 24  1996 /usr/sbin/httpd
And while it's running, it's taken up 572K, 440K shared:
29695 nobody     0   0   572  564   440 S       0  0.0  0.4   0:00 httpd

Perl is only 400K 
[···@www]$ ls -l /usr/bin/perl*
-rwxr-xr-x   2 root     root       401200 Dec  4  1996 /usr/bin/perl


My Charlotte web server running with my OODB for hatsales.com
(running ACL/Linux) has a 24mb footprint, 8.8mb shareable:

27092 root       0   0 24588 16100  8824 S      32  0.0 12.6  93:45 lisp

Charlotte running allegrostore supporting falconparts.com on
a Sun Solaris machine ACL4.3, is 47M + 14M of objectstore:
 1993 nobody   47M   43M sleep  42.7H  1.79% 17.36% charlotte.exe
  189 root     14M 8528K sleep 430:03  0.38%  2.56% osserver
From: David Steuber "The Interloper
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <365ec079.4343826@news.newsguy.com>
On 25 Nov 1998 17:29:41 +0100, Pierre Mai <····@acm.org> claimed or
asked:

% There have been approaches to down-size lisp images, like
% tree-shakers, which have met with limited success.  But on modern
% machines (>64MB RAM, >4GB Hard-drives _at the least_), even CMU CL's
% image (around 20MB) seems just tiny, and so IMHO it's not worth the
% bother to try to reduce these sizes[1].  In CMU CL we'd rather need a
% nice CLIM implementation than a tree-shaker of some sort IMHO...

Even middle of the range laptop/portable computers are now exceeding
these memory and disk sizes.

While I was annoyed at the size of a CMUCL image file just a month or
two ago, I am now looking at doing most of my development work on a
Gateway Solo computer so that I don't have to be tied to any one
location to do my work.

Another justification I can use for large Lisp image size is that one
of my program requirements is that it can be extended by loading lisp
files.  I don't have to invent a scripting language.  The Python
compiler's understanding of Common Lisp is already there.  That is a
lot of effort saved on my part right there.

The most wonderful feature of CMUCL is that it is public domain.  It
doesn't have that restrictive GPL hanging off of it.  This is not to
say that I wouldn't go with an open source model of development once
I've worked out the basic architecture (see "The Cathedral and the
Bazaar" at www.opensource.org).

--
David Steuber (ver 1.31.3a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

May the source be with you...
From: Marco Antoniotti
Subject: Re: Making executables with CMUCL
Date: 
Message-ID: <lwiug225xz.fsf@copernico.parades.rm.cnr.it>
·······@infa.abo.fi (Fredrik Sandstr�m) writes:

> On 24 Nov 1998 17:09:25 +0100, Marco Antoniotti
> <·······@copernico.parades.rm.cnr.it> wrote:
> >So? Distribute a CMUCL dumped image. This is equivalent to
> >distributing a statically linked application.
> 
> Except that a dumped image will include a *lot* of code that is never
> used, whereas statically linking a C program only includes the
> relevant parts of the library. Of course, because of the nature of
> Lisp it's difficult to tell what is needed and what isn't...

This is indeed a problem, albeit now only a nuisance.  In the case of
CMUCL the main problem is the size of the compiler. It might be
worthwhile to have a (CMUCL) build method for an application that
would make sure that everything needed is compiled and that would dump
an image without the compiler.

This is something that already came up recently.


> 
> >My suggestion is not to tell people that you use an "obscure
> >language" and just ship the application.
> 
> Yes, I realize it's not that big a problem. Fortunately the size of
> CMUCL is managable.
> 

Times have indeed changed.  Let's thank Micorsoft and all the HUGE
programs it ships. :) Memory is cheap, CMUCL is now "small" :)


-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it