Re: [Gcl-devel] clocc defsystem and gcl

[Camm Maguire]

Greetings!

James Amundson <address@hidden> writes:

> On Mon, 2003-11-10 at 20:46, Camm Maguire wrote:
> > Greetings, and thanks so much for doing this!  In brief, at least 1, 3
> > and 4 are items which will eventually be supported in the ansi build.
> 
> OK. I just wanted to make sure I wasn't missing something.
> 
> > I thought 2 was correct, but maybe not.
> 
> As I said, I am not a Lisp language lawyer. However, I just verified
> that ignore-errors is in the common-lisp package in all of (cmucl, sbcl
> and clisp.)
> 

OK, I see now in the spec that we need to export this.  Will try to
get to it.

> >  In any case, I think it would
> > be nice not to have to require the ansi build for maxima because of
> > these few items.  Perhaps the right reader macro would be something
> > like (and :gcl (not :ansi)).  Alternatively, perhaps these items are
> > simple and non-invasive enough that we can just add them to the
> > traditional image and be done with it.  Comments?
> 
> Ah. Here is a topic worth discussing. Now that the gcl ansi build is in
> pretty good shape, I am really much happier requiring it. My concern is

Are we in good shape in your opinion?  I have no objections to people
using the ANSI build, but it will obviously be changing much faster
than the traditional build.  I can promise that the ansi build will
not go away, and that the list of ansi test suite failures will only
get smaller modulo newly added tests, but other than that its likely
to be quite a moving target.

> not a few lines in defsystem. My concern is really with code that is
> being added to Maxima. Many of the developers are only familiar with
> ansi common lisp. I think working around deficiencies in the gcl ansi
> build is much easier than having them write code that also works in the
> language implemented in the gcl traditional build. Does that fit with
> your vision of gcl development?
> 

Sure -- GCL is not going to abandon the ANSI effort if that's what you
mean.  From maxima's point of view, I think the issue is really if
contributers really want to include CLOS/pcl.  Some may like the OO
programming style, but it is more complex, and does add significantly
to the image size.  PCL bugs are among the most difficult to track
down.  And at this moment, for some unknown reason our Windows build
(alone) cannot build PCL from lisp source, having to rely instead on
precompiled C files generated on Linux.  This is likely not a
difficult issue to resolve but may prove time consuming as we simply
do not have enough people with access to Windows MYSYS development
boxes working on this port.  We'd be completely lost without the
heroic efforts of Mike Thomas.  If you know of volunteers please send
them our way.

> > The :system-p flag is currently only required for the alt-link option.
> > In actuality, only the first of three items toggled by this flag are
> > required, uniquely named init functions, reference to an external
> > header cmpinclude.h, and human readable (i.e. non-bytecode) .data
> > files.  At some point we might just adopt the first across the
> > board, but for now you can avoid patching defsystem if you set the
> > variable compiler::*default-system-p* to t somewhere in advance.
> 
> It sounds like setting the compiler::*default-system-p* flag is the much
> better option. Thanks.
> 

Just a clarification, this is only strictly required when the
--gcl-alt-link option is chosen.

Take care,

> Best,
> Jim
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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