Re: [Gcl-devel] HEAD Maxima and HEAD trad GCL

[Camm Maguire]

Hi Mike!  Welcome back from the holidays!

Mike Thomas <address@hidden> writes:

> Hi all..
> 
> Camm wrote:
> 
>  > The maxima developers have decided to require our ansi
>  > build, and cvs head reflects this, to my understanding.
> 
> OK, but defpackage in the HEAD CLtL1 build is missing.
> .....

Yes, in HEAD I've restored the cltl1 build to the original lsp and
cmpnew files only, and separated out our non-pcl and non-clcs
additions into a mod/ directory, which gets built only when ansi is
configured in.  The idea being to give legacy apps the smallest core
to which they have been accustomed.  

We could rethink this two image approach at some point and consider a
shipping a small core with autoloadable modules.  This is of course
down the road.

>  >(apropos "defpackage")
>  >
> .....
> 
> The stable branch seems OK in this regard however.
> 

Yes, see above.  Do you need defpackage when you don't need ansi?


> 
> Jim wrote:
> 
>  > Camm is correct. There was a brief discussion on this point on the
>  > various mailing lists in the past few months. I didn't see a compelling
>  > reason to continue to fight to keep maxima compatible with the cltl1 gcl
>  > build. If you forsee a problem with that decision, please say so.
> 
> Sorry; I had delivery of the Maxima list turned off until yesterday and 
> missed that discussion
> while I was away. I think that movement towards ANSI standardisation of the 
> Lisp dialect is a good
> move for Maxima.  I also agree that you shouldn't have to struggle to support 
> two versions of the
> "same" compiler. If we don't fix the Windows ANSI build of GCL in time for 
> the next Maxima release,
> CLISP is still a valid option for hard core Maxima users on Windows.   So 
> that everyone is clear on

I would really not like to cede the windows ground to clisp.

> this, I can't get CVS HEAD Maxima built with any combination of HEAD or 
> STABLE and CLtL1 or ANSI on
> Windows today.  Focusing on ANSI GCL, there seems to be a string handling 
> problem with ANSI GCL:
> 
> ........
> ;    - Compiling module "utilities"
> ;      - Source file e:/cvs/maxima/src/e:/cvs/maxima/src/j/opers.lisp and
> ;        binary file binary-gcl/opers.o not found, not loading.
> Source file "e:/cvs/maxima/src/e:/cvs/maxima/src/j/opers.lisp" and binary 
> file "
> binary-gcl/opers.o" do not exist.
> .........

Vadim, did you see something similar?  I think you had resolved this, no?

> 
> There are also other issues - the fact that we need to use a workaround to 
> build ANSI GCL on
> Windows and the fact that the resulting build is unstable when it comes to 
> error handling which

The fast-link issue, right?  We should definitely get to the bottom of
this.  Vadim had done some work in this regard, but I think most of
the fruit of that labor was the expansion of the heap size.  (Speaking
of which, we really should integrate unexw32.c at some point.)  I had
suspected that the core was growing into already used areas, but this
seems less likely now.  We may be overruning the *link-array* or
otherwise corrupting the C stack at the offending function call.  In
any case, I need a refresher on this.  If you and/or Vadim could post
a gdb backtrace (again) at the point of segfault with fast-links left
on, do a frame 1, disassemble, and report the register contents at the
point of the call to the offending function, this would be a start.
If memory serves, we had pinned the problem down to the very function
call itself with our printf/format debugging.  I'm guessing now that
somehow a bad value is getting written to the function pointers stored
in compiled lisp files via the link-array.  (The way this works
basically is that these pointers are initially set to stubs present in
the same generated C file, which in turn call call_or_link et.al. with
the address to the original function pointer as one argument.  When
fast-linking is on, the function pointer is reset from the stub to the
real function address which call_or_link finds, so that call_or_link
is invoked only once, with subsequent calls going straight to the
intended function as in C.)

> often leads to a bind stack overflow.  Having said that I was able to use it 
> to build and run both

I've occasionally run into these as well, so this may not be Windows
specific.  If you find a reproducible instance which does not appear
on Linux, I'd be interested.  In general, these almost invariably
result from invoking an error while processing another, e.g. running
out of memory to format the error string as one example.  We need to
determine a minimal set of root nodes, and set a static variable in
each to prevent such recursion.

> Jim's Maxima source snapshot from a few months ago and the ACL2 current 
> source release during the
> week, so there is some hope for the future.
> 

I'd be very alarmed if at least this behavior were not attainable.
Nothing should have changed to make this impossible at present.

Take care,

> Cheers
> 
> Mike Thomas.
> 
> PS: I'm struggling with Netscape Communicator to reply here (I normally use 
> Outlook Express) so
> please let me know if this email has HTML turned on or anything else 
> unsociable.
> 
> 
> 
> 
> James Amundson wrote:
> 
> >On Fri, 2004-01-02 at 09:57, Camm Maguire wrote:
> >
> >>Take care,
> >>
> >>Mike Thomas <address@hidden> writes:
> >>
> >>
> >>>Hi Camm.
> >>>
> >>>I notice that the GCL HEAD traditional CLtL1 build (on Windows at
> >>>least) doesn't build HEAD Maxima:
> >>>
> >>>
> >
> >--Jim
> >
> >
> >
> 
> 
> 
> 

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