[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: |
06 Jun 2002 17:18:56 -0400 |
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
- [Gcl-devel] conditions/clos/gcl unified build patch and instructions., John Jorgensen, 2002/06/04
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., John Jorgensen, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Camm Maguire, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Vadim V. Zhytnikov, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Camm Maguire, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., John Jorgensen, 2002/06/07
- Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions., Camm Maguire, 2002/06/08