[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] conditions/clos/gcl unified build patch and instruct

From: Camm Maguire
Subject: Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions.
Date: 07 Jun 2002 18:28:06 -0400

Greetings, and thanks for your informative reply!

"Thomas F. Burdick" <address@hidden> writes:

> Camm Maguire writes:
>  > I really need some intelligent commentary here from people wanting to
>  > make real use of gcl, if any.  From my own limited perspective, I
>  > cannot see how lisp could ever be used for anything *simple* if each
>  > binary will be at least 8 meg.  This would seem to limit gcl to large
>  > maxima-sized projects.  Not to mention using these programs in a
>  > multi-user environment.
> Well, if you ship a core plus compiled lisp files, the same core can
> be used for many programs.  An 8 Mo dependency for *one* small program
> might be a bit much, but if someone were to start writing small, free
> systems in Lisp, I assume they'd write more than one.  As it is, you
> could make a small program in Lisp, and make a Debian package of it
> that requires the gcl package, and just have your application load its
> fasl files into the gcl image.  It'll be a bit slower to load than a
> custom image, but this is generally how Unix works nowadays --
> libraries that are linked-in dynamically.

I guess you're right.  Its just the model that's reversed -- the
toplevel is installed as a "system library" with individual programs
being .o objects, as opposed to tiny programs with only a main()
linking against libc which can do nothing by itself.  Of course, one
must in lisp still redirect the default toplevel for a custom program,
but I assume that can be done with an -exec command line switch to gcl
or some such.

>  > It seems that lisp started out assuming that it was the entire OS
>  > for a single user, or something.
> Well, this is how Lisp Machines worked.  But that's not how all lisp
> systems work/worked.  As far as I know, MACLISP expected each user to
> be running an image, and I /know/ that's how CMUCL works and worked.


>  > I've never understood this -- perhaps someone could enlighten me.
>  > At very least, as much as possible of this image should be in a
>  > shared lib, no?
> Right, the way modern Unixes work, if you already have one user
> running the lisp image, additional users running it come essentially
> for free.  It might be worthwhile to break the standard library into
> pieces (like streams, maths, CLOS, formatted i/o, etc) that can be
> loaded on use.  That way, a simple string-munging utility, for
> example, will only link to the base core and some of the fasl's, but
> there's no need for even one copy of CLOS to be loaded into memory.

OK, so how is this implemented?  Does each user need their own lisp
heap, as it moves around unpredictably under gc with use?  Isn't that
the majority of the footprint?  How much does CMUCL wind up sharing?

Thanks again!

> This is the approach we're taking on the CMUCL-derived proprietary
> system I'm working on.
> -- 
>            /|_     .-----------------------.                        
>          ,'  .\  / | No to Imperialist war |                        
>      ,--'    _,'   | Wage class war!       |                        
>     /       /      `-----------------------'                        
>    (   -.  |                               
>    |     ) |                               
>   (`-.  '--.)                              
>    `. )----'                               

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]