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

[Vadim V. Zhytnikov]

Camm Maguire wrote:

> Greetings!
>
> "Vadim V. Zhytnikov" <address@hidden> writes:
>
> > Camm Maguire wrote:
> >
> > > Greetings!  First, thanks all for the contributions!  I will commit
> > > this as soon as we get it into a rudimentary state.  Also would like
> > > feedback on its implications on image size, especially as it may
> > > affect maxima.  Should we have pcl .o files, separate from the main
> > > image, like tkl.o?
> >
> > Please don't hurry with committing. We have to sort out new
> > basic CL package and check how Maxima works with
> > renewed GCL setup.
> >
>
> OK
>
> > As for image it depends on what is our primary goal.
> > If we want ANSI compliance we must load PCL and CLCS
> > into GCL image.  Now some concrete figures for i586 with gcc 2.95.3
> > raw_gcl - 1912242, gcl - 3294522, gcl+pcl - 6939800,
> > gcl+pcl+clcs - 8070366.  Do we really care about image size
> > growth?  In my opinion not much. It seems to me that the only area
> > where such growth may be significant it is some handheld
> > computers.
> >
>
> 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.  It seems that lisp started out assuming that
> it was the entire OS for a single user, or something.  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?
>

Well Common Lisp in general doesn't look like compact system -
hundreds of  bult-in functions and symbols.  Such stuff could not
have small footprint.  On the other hand it seems that now
CL is the only Lisp which (a) is standardized, (b) is alive
(many real users, vast codebase).  There were attempts to
standardize and promote other much smaller and compact
Lisps (e.g. so called Standard Lisp).  Probably in vain.

Moving large portion of the program into shared library is great
idea
bu I worry that it is far beyond our immediate goals.  Is it to
accomplish?
I really have no idea.

I think that GCL will start attracting users other than Maxima's
ones as soon as
(a) some reasonable level of ANSI CL compliance is achieved;
(b) GCL portability is improved.
So we are on the right track ;-) !

>
> > Presently Maxima don't use PCL and CLCS but Maxima moves
> > toward CL compliance and we may need more various standard CL
> > features for the forthcoming Maxima releases. It already started to
> > happen with recent numerical Maxima updates.
> >
> > Maybe the best way is to build full GCL with PCL, CLCS and
> > possible with other extensions by default and provide lightweight
> > old style GCL as special configure option.
> >
>
> This sounds good.
>
> >
> > Yes all this package rearrangement must be done right before image is saved
> > or earlier.
> >
>
> Better than autoloading as needed at runtime?

Please forgive my ignorance but does GCL have any autoloding
machinery already?  I mean that some portion of code foo resides
in
extrenal *.o file which is automatically loaded only when
we call (foo ...).

> >
> > We really do not know INT's purpose.  The simple fact that INT is
> > listed in lsp/stdlisp.lsp indicates that GCL authors were aware of it but 
> > they
> > did not removed it from GCL completely due to some reason.
> > So let it be in LISP package. LISP is no longer standard CL package
> > and may contain various nonstandard symbols like INT.
> > We just don't want it in COMMON-LISP and COMMON-LISP-USER.
> >
>
> OK
>
> >
> > Well when why CLISP and CMUCL behavior differs?  One of them must be wrong.
> > But I still don't quite understand what is the right behavior.
> > Tests stops due to unbound NIL.
> >
>
> I agree that one must be in error, but I thought CMUCL were the gods
> of lisp....
>
> >
> > I have cl::nil (nil as internal symbol in common-lisp inherited from lisp)
> > but cl:nil (nil as external symbol in common-lisp) always gives error
> > inspite of (export ...).
> >
> >
> > cl-user::nil is bound
> >
> >
> > cl-user::nil is unbound.
>
> OK, it seems you're on the trail here.  When you get to a point where
> you have identified that something is not right and can state it
> clearly, please let me know, and I'll try to implement what we want at
> the C level.
>
> >
> > --
> >      Vadim V. Zhytnikov
> >
> >       <address@hidden>
> >     <address@hidden>
> >      <address@hidden>
> >
>
> Take care,
>
> --
> Camm Maguire                                            address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah

X-Mozilla-Status: 0009tnikov

      <address@hidden>
    <address@hidden>
     <address@hidden>