From: Sandeep Koranne
Subject: Req. for light version of CMUCL
Date: 
Message-ID: <3CE36B7E.9040802@spam.adelphia.net>
Hi All,
For application delivery I am thinking of constructing a light weight 
version of CMUCL core file which won't have the compiler, PCL, 
gray-stream etc which I don't use, and don't expect my application's 
user to use also.

I tried compiling CMUCL 18d from the sources, but got nowhere as my lisp 
executable always brought me to the ldb> prompt.

Has some one already done this ?? if so can you describe your procedure.

TIA
Sandeep

From: Eric Marsden
Subject: Re: Req. for light version of CMUCL
Date: 
Message-ID: <wzi1yccjhik.fsf@melbourne.laas.fr>
>>>>> "sk" == Sandeep Koranne <········@spam.adelphia.net> writes:

  sk> For application delivery I am thinking of constructing a light
  sk> weight version of CMUCL core file which won't have the compiler,
  sk> PCL, gray-stream etc which I don't use, and don't expect my
  sk> application's user to use also.

I don't think that it's possible to build a CMUCL without a compiler;
this used to be possible, but you'll run into problems with EVAL-WHEN
if you try to build a runtime image. What's more, you can't use CLOS
without the compiler being present.

However, it isn't very difficult to produce images that are much
smaller than those in the distribution tarballs. On x86, building with
the :small feature (which causes more parts of the system to be built
as byte-code instead of native code) takes you from 19.8MB to 12.4MB,
and to 9.9MB without CLOS. Removing further stuff such as
documentation strings, introspection tools like INSPECT, DESCRIBE,
TRACE, PROFILE, the wire and remote facilities takes you to 11.9MB or
9.5MB without CLOS.

  sk> I tried compiling CMUCL 18d from the sources, but got nowhere as
  sk> my lisp executable always brought me to the ldb> prompt. Has
  sk> some one already done this ?? if so can you describe your
  sk> procedure.

there is a document explaining how to rebuild CMUCL, and some scripts
that partially automate the process, at

   <URL:http://www.laas.fr/~emarsden/tmp/cmucl-rebuild/>

Also see article <··············@orion.bln.pmsf.de> from Pierre Mai,
dated 2002-05-06, which describes the build process that he uses,
which has some advantages over the one that I use (such as allowing
parallel builds), but currently less documentation.
     
-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>
From: Pierre R. Mai
Subject: Re: Req. for light version of CMUCL
Date: 
Message-ID: <87n0uz4y78.fsf@orion.bln.pmsf.de>
Eric Marsden <········@laas.fr> writes:

> >>>>> "sk" == Sandeep Koranne <········@spam.adelphia.net> writes:
> 
>   sk> For application delivery I am thinking of constructing a light
>   sk> weight version of CMUCL core file which won't have the compiler,
>   sk> PCL, gray-stream etc which I don't use, and don't expect my
>   sk> application's user to use also.
> 
> I don't think that it's possible to build a CMUCL without a compiler;
> this used to be possible, but you'll run into problems with EVAL-WHEN
> if you try to build a runtime image. What's more, you can't use CLOS
> without the compiler being present.

The EVAL-WHEN problem was only caused by bogus read-time contionals.
I've just committed a fix to that, so that building runtime images
should again be possible (i.e. it works for me).

> However, it isn't very difficult to produce images that are much
> smaller than those in the distribution tarballs. On x86, building with
> the :small feature (which causes more parts of the system to be built
> as byte-code instead of native code) takes you from 19.8MB to 12.4MB,
> and to 9.9MB without CLOS. Removing further stuff such as
> documentation strings, introspection tools like INSPECT, DESCRIBE,
> TRACE, PROFILE, the wire and remote facilities takes you to 11.9MB or
> 9.5MB without CLOS.

It might be useful to find a set of "only-useful for developers"
facilities, that can be safely excluded from a core, and
conditionalize those in the genesis/world-load process, probably with
:runtime also implying :no-devel-tools (or whatever we'd call the
feature), or something like that.

> Also see article <··············@orion.bln.pmsf.de> from Pierre Mai,
> dated 2002-05-06, which describes the build process that he uses,
> which has some advantages over the one that I use (such as allowing
> parallel builds), but currently less documentation.

I'm currently working on the latter part, and also on including a
workable cross-compilation script in the collection.  Stay tuned.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein
From: Eric Marsden
Subject: Re: Req. for light version of CMUCL
Date: 
Message-ID: <wzin0uzhsms.fsf@melbourne.laas.fr>
>>>>> "prm" == Pierre R Mai <····@acm.org> writes:

  ecm> I don't think that it's possible to build a CMUCL without a compiler;
  ecm> this used to be possible, but you'll run into problems with EVAL-WHEN
  ecm> if you try to build a runtime image. What's more, you can't use CLOS
  ecm> without the compiler being present.

  prm> The EVAL-WHEN problem was only caused by bogus read-time contionals.
  prm> I've just committed a fix to that, so that building runtime images
  prm> should again be possible (i.e. it works for me).

nice work, with this image size on x86 is reduced to 5.1MB, or 4.9MB
with development-only stuff stripped; a few 100kB more on UltraSPARC.
Compare with 23MB for the JRE:

   23036  /opt/j2sdk1.4.0/jre/lib/rt.jar
   7248   /opt/j2sdk1.4.0/jre/lib/i386/server/libjvm.so

Of course that's not a fair comparison: the Java runtime contains
multiple kitchen sinks, plus support for CORBA, Swing, AWT, LDAP,
Kerberos, X.509, MIDI.

-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>