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

[Camm Maguire]

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?

> 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?

> 
> 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