\start
Date: Thu, 14 Jul 2011 13:39:47 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: GCL and GMP

Axiom does not use OpenMath.
You can remove the library.

On Thu, 2011-07-14 at 11:12 -0400, Camm Maguire wrote:
> Greetings!  And please excuse the delay.
> 
> Tim Daly writes:
> 
> > Camm,
> >
> > It seems that GCL has captured the path used during the
> > build process. When Axiom tries to compile on a different
> > platform I get an error message that includes the original
> > build path from the original platform.
> >
> > Is there a way to stop or override this behavior?
> >
> 
> Yes, see #'si::reset-sys-paths.
> 
> Separately, what should be done about this?
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630846                                                                                   
> 
> Take care,
> 
> > Tim
> >
> > On Mon, 2011-05-16 at 14:25 -0400, Camm Maguire wrote:
> >> Greetings!  Please excuse my not having seen this earlier.
> >> 
> >> Tim Daly writes:
> >> 
> >> >  I have an OLPC XO box running fedora.
> >> > It has gmp4 installed on the system.
> >> > GCL looks for gmp.h which does not exist
> >> > and therefore the build is failing.
> >> > The internal version of gmp3 does not have
> >> > gmp.h either but the build seems to require
> >> > a file "gmp.h".
> >> >
> >> > Why is this test there?
> >> >
> >> 
> >> GCL sould use an external gmp if available, and if not automatically
> >> fall back to building the local copy, which is now gmp4.  gmp.h is
> >> needed for compiling programs using gmp, so you need the gmp-dev
> >> package in addition to the gmp package to build gcl.  If the build
> >> fails because of the lack of the -dev, then the fallback is not
> >> working, and that is a bug.  It would be great if this still is an
> >> issue if you could post the configure and make logs.

\start
Date: Thu, 14 Jul 2011 15:16:01 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: GCL and GMP

Thanks!

Tim Daly writes:

> Axiom does not use OpenMath.
> You can remove the library.
>
> Tim
>
> On Thu, 2011-07-14 at 11:12 -0400, Camm Maguire wrote:
>> Greetings!  And please excuse the delay.
>> 
>> Tim Daly writes:
>> 
>> > Camm,
>> >
>> > It seems that GCL has captured the path used during the
>> > build process. When Axiom tries to compile on a different
>> > platform I get an error message that includes the original
>> > build path from the original platform.
>> >
>> > Is there a way to stop or override this behavior?
>> >
>> 
>> Yes, see #'si::reset-sys-paths.
>> 
>> Separately, what should be done about this?
>> 
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630846                                                                                   
>> 
>> Take care,
>> 
>> > Tim
>> >
>> > On Mon, 2011-05-16 at 14:25 -0400, Camm Maguire wrote:
>> >> Greetings!  Please excuse my not having seen this earlier.
>> >> 
>> >> Tim Daly writes:
>> >> 
>> >> >  I have an OLPC XO box running fedora.
>> >> > It has gmp4 installed on the system.
>> >> > GCL looks for gmp.h which does not exist
>> >> > and therefore the build is failing.
>> >> > The internal version of gmp3 does not have
>> >> > gmp.h either but the build seems to require
>> >> > a file "gmp.h".
>> >> >
>> >> > Why is this test there?
>> >> >
>> >> 
>> >> GCL sould use an external gmp if available, and if not automatically
>> >> fall back to building the local copy, which is now gmp4.  gmp.h is
>> >> needed for compiling programs using gmp, so you need the gmp-dev
>> >> package in addition to the gmp package to build gcl.  If the build
>> >> fails because of the lack of the -dev, then the fallback is not
>> >> working, and that is a bug.  It would be great if this still is an
>> >> issue if you could post the configure and make logs.

\start
Date: Fri, 29 Jul 2011 01:37:27 -0500
From: Tim Daly
To: list
Subject: Axiom July 2011 release

July 2011 Release

The prior release had a bug that caused it to remember the build location.
This was a change introduced by the underlying lisp. This was fixed.

This release continues treeshaking the compiler. 
The modemap.lisp file has been merged and no longer exists.

This release continues to treeshake the interpreter. 
The axext_l.lisp file has been removed.

Makefile.pamphlet
  add BUILD=full / BUILD=fast switch

Book Volume 5 (Interpreter)
  treeshake interpreter

Book Volume 9 (Compiler)
  treeshake compiler

Book Volume 10.3 (Domains)
  help and unit tests for RewriteRule

axiom.sty
  add /refsdollar and /defsdollar for better cross references

src/interp/Makefile
  add (si::reset-sys-paths) per Camm
  remove axext_l aldor support file
  remove modemap.lisp

\start
Date: Fri, 29 Jul 2011 23:44:46 -0400
From: Tim Daly
To: Camm Maguire
Subject: odd looping behavior

Camm,

I am seeing some odd behavior in loops.

If I write

(let (result)
  (setq a 
    (do ((x somelist (cdr x)) (result nil))
        ((atom x) (reverse result))
      (setq result (cons (fn x) result)))))

or, in a simple form as
(let (result)
  (setq a
   (dolist (x somelist (nreverse result))
     (setq result (cons (fn x) result)))))

I do not get the same behavior as
(setq a 
 (prog ()
  (return
   (do ((x somelist (cdr x)) (result nil))
       ((atom x) (reverse result))
    (setq result (cons (fn x) result))))))

That is, if the result is scoped outside of the
setq and used in a loop then I appear to get 
different results than if it has prog scope locally.

The failure is stable no matter what I do to the
inner loop. I have tried it using the loop macro.
Nothing seems to change the result.

Unfortunately the failure is deep within the build
process of Axiom and hard to isolate. I am trying to
get a test case.

The version I am using is at:
http://github.com/daly/axiom/blob/master/zips/gcl-2.6.8pre4.tgz






