\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Sat, 31 Aug 2013 22:49:01 -0400 (EDT)
From: Paul Selick
To: list
Subject: compiling in Axiom

Hello,

I used AXIOM a number of years ago, and I think at that time I understood 
the difference between a  *.as  and *.spad   file, but have since 
forgotten.

I had written  *.as  files.

Recently I tried to run some of my old code unsuccessfully in the modern 
AXIOM.
I used to use the command line
     axiomxl -laxllib -Fx filename.as
although I understand the this method of producing a standalone executable
is no longer supported (no   axiomxl  command)
So I started the interpreter and typed
     )co filename.as
and got an error message saying
"Only AXIOM source files with file extensions .as, .ao, .al, or .spad
       can be compiled."

My file WAS named  something.as   and although my syntax in the file may 
need modernizing, I got the impression that the compiler didn't look into 
file beyond the name.

Can you tell me what I am doing wrong and what would need to be done to 
get on old  *.as  file to compile in the modern AXIOM ?
Thanks,

\start
Date: Sun, 01 Sep 2013 15:59:35 +0200
From: Ralf Hemmecke <ralf@hemmecke.org>
To: list
Subject: Re: compiling in Axiom

> So I started the interpreter and typed
>     )co filename.as
> and got an error message saying
> "Only AXIOM source files with file extensions .as, .ao, .al, or .spad
>       can be compiled."

> Can you tell me what I am doing wrong and what would need to be done to
> get on old  *.as  file to compile in the modern AXIOM ?

>From all the panaxiom flavours (to my knowledge) currently only FriCAS
allows the connection to Aldor, i.e. compilation of .as files and use of
the result inside FriCAS.

For that, you would have to compile libaxiom.al locally on your
computer, it's not in the distribution. But also for FriCAS it is
currently in a "transition state" (I would say). My fricas-aldor-local
branch (https://github.com/hemmecke/fricas/commits/fricas-aldor-local)
should work together with the latest aldor
(https://github.com/pippijn/aldor), but I didn't have time to really
check everything and integrate it back into FriCAS mainline. Aldor is
currently getting a lot of patches and it's a bit hard to keep track.

Anyway, it's not possible to use the aldor compiler and produce stand
alone programs that use the Axiom library.

\start
Date: Sun, 1 Sep 2013 16:10:56 +0200
From: Aage Andersen
To: list
Subject: start

Just downloaded axiom and installed succesfully. But how do I start it?

\start
Date: Wed, 4 Sep 2013 16:22:14 -0500
From: Matt Kaufmann
To: Camm Maguire
Subject: Re: GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki

Hi, Camm --

Should we expect 2.6.8 and 2.6.9 to support ANSI builds (i.e., using
configure option --enable-ansi)?

Thanks -
-- Matt
   From: Camm Maguire
   Date: Tue, 27 Aug 2013 11:48:24 -0400

   Greetings!  The GCL team is happy to announce a pair of stable releases
   at

   ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.8.tar.gz
   and
   ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.9.tar.gz

   Please also see the homepage and release notes at

   http://www.gnu.org/software/gcl.

   The 2.6.8 release represents several years worth of fixes and
   enhancements, notably a great extension of GCL's native object file
   relocation support.  

   2.6.9 is released concurrently as it contains a number of structural
   improvements which, while passing all our tests, may cause issues for
   some people.  These improvements are chiefly a two word cons, immediate
   fixnum support, word sized fixnums (64bits on 64bit machines), and a
   'dynamic maxpage' implementation, which removes all compile time limits
   to the heap size and auxiliary typing and marking tables.  2.6.9 will
   attempt to manage the heap given the apparent constraints of the running
   system, with the goal of eliminating allocation failures and handling
   out of memory conditions in advance with a modicum of grace.  As this
   involves a runtime startup probe of brk, which has varying degrees of
   significance in different operating systems, one might still experience
   overallocation of memory (notably on hurd).  In such cases, 

   gcl -eval '(si::set-log-maxpage-bound x)'

   will limit the heap to 2^x bytes as a workaround.

   All gcl, maxima, acl2, axiom, and hol88 builds and self tests pass for
   the following platforms, with noted exceptions(*) itemized below:

   debian: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64
   kfreebsd-i386 mips mipsel powerpc s390 s390x sparc

   debian-ports: alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32

   macosx, windows

   *exceptions

   1) all systems use native object relocation by default now but ia64 and
   ppc64, which use dlopen.  Thus there is a typical limit of 1024 files
   that can be loaded, and the current acl2 build exceeds this limit.  As
   this bound is runtime configurable with root access, this is not an
   insurmountable obstacle.

   2) kfreebsd-i386 systems do not appear to allow one to brk more than
   500M of memory, and the acl2 certification process needs 1Gb.  A
   solution here is as yet unknown but may be forthcoming shortly.

   3) windows builds have been performed on win95.  There is an as yet
   unidentified runtime error running the 2.6.9 images on win7.  More
   information here will be forthcoming shortly.

   Windows installers can be found at ftp://ftp.gnu.org/gnu/gcl.

   4) macosx builds have been tested on snow leopard.  More recent versions
   appear to have a linker bug which prevents configure from detecting the
   provided profil() routine.  A workaround here should be to 

   echo "#undef NO_PROFILE >>h/config.h" 

   after configure and before make.


   GCL has moved to the git version control system.  The 2.6.8 and 2.6.9
   branches and tags are identical in cvs and git.  Henceforward,
   modifications will be made to git only.  As of the present writing, git
   contains a merge of experimental into master, and a port of most 2.6.x
   improvements into master.  This will form the basis of a 2.7.0 release
   sometime in the future.

   For those unfamiliar with git:

   git clone git://git.sv.gnu.org/gcl.git
   cd gcl
   git checkout master, or git checkout Version_2_6_9, etc.
   cd gcl
   ./configure && make

   git can of course provide much more.  I'm currently using Egg, an emacs
   interface to git, with increasing success.  Merging, logging, bisecting,
   branching, and uploading appear much simpler.  I recommend this tool to
   would-be gcl contributors.

   Feedback as always most welcome!

\start
Date: Wed, 4 Sep 2013 15:32:02 -0600
From: Donald Winiecki
To: Matt Kaufmann
Subject: Re: GCL 2.6.8 and 2.6.9 are released
Cc: Camm Maguire

Hi Matt,

Right now, both 2.6.8 builds both CLtL1 and ANSI on my Ubuntu 12.10
and WinXP, WinVista and Win7.

2.6.9 builds CLtL1 and ANSI on WinXP, but not yet on WinVista or Win7.

On Wed, Sep 4, 2013 at 3:22 PM, Matt Kaufmann wrote:
> Hi, Camm --
>
> Should we expect 2.6.8 and 2.6.9 to support ANSI builds (i.e., using
> configure option --enable-ansi)?
>
> Thanks -
> -- Matt
>    From: Camm Maguire
>    Date: Tue, 27 Aug 2013 11:48:24 -0400
>
>    Greetings!  The GCL team is happy to announce a pair of stable releases
>    at
>
>    ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.8.tar.gz
>    and
>    ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.9.tar.gz
>
>    Please also see the homepage and release notes at
>
>    http://www.gnu.org/software/gcl.
>
>    The 2.6.8 release represents several years worth of fixes and
>    enhancements, notably a great extension of GCL's native object file
>    relocation support.
>
>    2.6.9 is released concurrently as it contains a number of structural
>    improvements which, while passing all our tests, may cause issues for
>    some people.  These improvements are chiefly a two word cons, immediate
>    fixnum support, word sized fixnums (64bits on 64bit machines), and a
>    'dynamic maxpage' implementation, which removes all compile time limits
>    to the heap size and auxiliary typing and marking tables.  2.6.9 will
>    attempt to manage the heap given the apparent constraints of the running
>    system, with the goal of eliminating allocation failures and handling
>    out of memory conditions in advance with a modicum of grace.  As this
>    involves a runtime startup probe of brk, which has varying degrees of
>    significance in different operating systems, one might still experience
>    overallocation of memory (notably on hurd).  In such cases,
>
>    gcl -eval '(si::set-log-maxpage-bound x)'
>
>    will limit the heap to 2^x bytes as a workaround.
>
>    All gcl, maxima, acl2, axiom, and hol88 builds and self tests pass for
>    the following platforms, with noted exceptions(*) itemized below:
>
>    debian: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64
>    kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
>
>    debian-ports: alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32
>
>    macosx, windows
>
>    *exceptions
>
>    1) all systems use native object relocation by default now but ia64 and
>    ppc64, which use dlopen.  Thus there is a typical limit of 1024 files
>    that can be loaded, and the current acl2 build exceeds this limit.  As
>    this bound is runtime configurable with root access, this is not an
>    insurmountable obstacle.
>
>    2) kfreebsd-i386 systems do not appear to allow one to brk more than
>    500M of memory, and the acl2 certification process needs 1Gb.  A
>    solution here is as yet unknown but may be forthcoming shortly.
>
>    3) windows builds have been performed on win95.  There is an as yet
>    unidentified runtime error running the 2.6.9 images on win7.  More
>    information here will be forthcoming shortly.
>
>    Windows installers can be found at ftp://ftp.gnu.org/gnu/gcl.
>
>    4) macosx builds have been tested on snow leopard.  More recent versions
>    appear to have a linker bug which prevents configure from detecting the
>    provided profil() routine.  A workaround here should be to
>
>    echo "#undef NO_PROFILE >>h/config.h"
>
>    after configure and before make.
>
>
>    GCL has moved to the git version control system.  The 2.6.8 and 2.6.9
>    branches and tags are identical in cvs and git.  Henceforward,
>    modifications will be made to git only.  As of the present writing, git
>    contains a merge of experimental into master, and a port of most 2.6.x
>    improvements into master.  This will form the basis of a 2.7.0 release
>    sometime in the future.
>
>    For those unfamiliar with git:
>
>    git clone git://git.sv.gnu.org/gcl.git
>    cd gcl
>    git checkout master, or git checkout Version_2_6_9, etc.
>    cd gcl
>    ./configure && make
>
>    git can of course provide much more.  I'm currently using Egg, an emacs
>    interface to git, with increasing success.  Merging, logging, bisecting,
>    branching, and uploading appear much simpler.  I recommend this tool to
>    would-be gcl contributors.
>
>    Feedback as always most welcome!

\start
Date: Wed, 4 Sep 2013 16:37:02 -0500
From: Matt Kaufmann
To: Donald Winiecki
Subject: Re: GCL 2.6.8 and 2.6.9 are released
Cc: Camm Maguire

Thank you, Don.  If there's a complete list of platforms for which
ANSI builds are expected to work for 2.6.9, and if possible one for
2.6.8 as well, I'd be interested.  In particular, it would be nice to
know whether 2.6.9 ANSI builds on Linux are expected to work.

Thanks --
-- Matt

   Right now, both 2.6.8 builds both CLtL1 and ANSI on my Ubuntu 12.10
   and WinXP, WinVista and Win7.

   2.6.9 builds CLtL1 and ANSI on WinXP, but not yet on WinVista or Win7.

\start
Date: Wed, 04 Sep 2013 15:26:17 -0700
From: Henry Baker
To: Matt Kaufmann
Subject: Re: [Gcl-devel] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki, Camm Maguire

Terrific job!  Thanks!

I just looked through the release notes.  Do any versions of GCL support UTF8 ?

At 02:22 PM 9/4/2013, Matt Kaufmann wrote:
>Hi, Camm --
>
>Should we expect 2.6.8 and 2.6.9 to support ANSI builds (i.e., using
>configure option --enable-ansi)?
>
>Thanks -
>-- Matt
>   From: Camm Maguire
>   Date: Tue, 27 Aug 2013 11:48:24 -0400
>
>   Greetings!  The GCL team is happy to announce a pair of stable releases
>   at
>
>   ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.8.tar.gz
>   and
>   ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.9.tar.gz
>
>   Please also see the homepage and release notes at
>
>   http://www.gnu.org/software/gcl.
>
>   The 2.6.8 release represents several years worth of fixes and
>   enhancements, notably a great extension of GCL's native object file
>   relocation support.  
>
>   2.6.9 is released concurrently as it contains a number of structural
>   improvements which, while passing all our tests, may cause issues for
>   some people.  These improvements are chiefly a two word cons, immediate
>   fixnum support, word sized fixnums (64bits on 64bit machines), and a
>   'dynamic maxpage' implementation, which removes all compile time limits
>   to the heap size and auxiliary typing and marking tables.  2.6.9 will
>   attempt to manage the heap given the apparent constraints of the running
>   system, with the goal of eliminating allocation failures and handling
>   out of memory conditions in advance with a modicum of grace.  As this
>   involves a runtime startup probe of brk, which has varying degrees of
>   significance in different operating systems, one might still experience
>   overallocation of memory (notably on hurd).  In such cases, 
>
>   gcl -eval '(si::set-log-maxpage-bound x)'
>
>   will limit the heap to 2^x bytes as a workaround.
>
>   All gcl, maxima, acl2, axiom, and hol88 builds and self tests pass for
>   the following platforms, with noted exceptions(*) itemized below:
>
>   debian: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64
>   kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
>
>   debian-ports: alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32
>
>   macosx, windows
>
>   *exceptions
>
>   1) all systems use native object relocation by default now but ia64 and
>   ppc64, which use dlopen.  Thus there is a typical limit of 1024 files
>   that can be loaded, and the current acl2 build exceeds this limit.  As
>   this bound is runtime configurable with root access, this is not an
>   insurmountable obstacle.
>
>   2) kfreebsd-i386 systems do not appear to allow one to brk more than
>   500M of memory, and the acl2 certification process needs 1Gb.  A
>   solution here is as yet unknown but may be forthcoming shortly.
>
>   3) windows builds have been performed on win95.  There is an as yet
>   unidentified runtime error running the 2.6.9 images on win7.  More
>   information here will be forthcoming shortly.
>
>   Windows installers can be found at ftp://ftp.gnu.org/gnu/gcl.
>
>   4) macosx builds have been tested on snow leopard.  More recent versions
>   appear to have a linker bug which prevents configure from detecting the
>   provided profil() routine.  A workaround here should be to 
>
>   echo "#undef NO_PROFILE >>h/config.h" 
>
>   after configure and before make.
>
>
>   GCL has moved to the git version control system.  The 2.6.8 and 2.6.9
>   branches and tags are identical in cvs and git.  Henceforward,
>   modifications will be made to git only.  As of the present writing, git
>   contains a merge of experimental into master, and a port of most 2.6.x
>   improvements into master.  This will form the basis of a 2.7.0 release
>   sometime in the future.
>
>   For those unfamiliar with git:
>
>   git clone git://git.sv.gnu.org/gcl.git
>   cd gcl
>   git checkout master, or git checkout Version_2_6_9, etc.
>   cd gcl
>   ./configure && make
>
>   git can of course provide much more.  I'm currently using Egg, an emacs
>   interface to git, with increasing success.  Merging, logging, bisecting,
>   branching, and uploading appear much simpler.  I recommend this tool to
>   would-be gcl contributors.
>
>   Feedback as always most welcome!

\start
Date: Wed, 4 Sep 2013 17:52:08 -0500
From: Matt Kaufmann
To: John Lapeyre
Subject: Re: [Maxima] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki

Thanks.  I'm afraid my question wasn't clear (sorry).  I know about
the --enable-ansi switch (but I appreciate the information about what
has been seen to work with it).  However, in past years, ACL2 failed
badly when build on top of a GCL that had been built with that switch.
The good news is that in recent months I've worked with Camm to iron
out most or all such issues.  What I don't know, though, is whether
fixes for those issues were incorporated into 2.6.8, 2.6.9, both
(which is my guess), or neither (perhaps waiting for 2.7.0 to
incorporate fixes).  Since over the years I have sometimes experienced
GCL errors that are intermittent, I figured I'd just ask rather than
do testing that could be incomplete.

Anyhow, I hope that clarifies.  Thanks to everyone who is contributing
to GCL!  I'm very happy to see the progress.

Regards,
Matt
   Date: Thu, 05 Sep 2013 00:44:30 +0200
   From: John Lapeyre
   CC: Donald Winiecki,  ,
	   gcl-devel@gnu.org, open-axiom-devel@lists.sf.net,
	   maxima@math.utexas.edu, list

   This is a multi-part message in MIME format.
   --------------060608030209050904060606
   Content-Type: text/plain; charset=ISO-8859-1; format=flowed
   Content-Transfer-Encoding: 7bit

   On 09/04/2013 11:37 PM, Matt Kaufmann wrote:
   >  Thank you, Don. If there's a complete list of platforms for which
   >  ANSI builds are expected to work for 2.6.9, and if possible one for
   >  2.6.8 as well, I'd be interested. In particular, it would be nice to
   >  know whether 2.6.9 ANSI builds on Linux are expected to work.

   On x86_64 linux, I built gcl 2.6.8, and 2.6.9 with

   ./configure --enable-readline --enable-ansi 
   --prefix=/usr/local/gcl-2.6.8 (9)

   and maxima with

   export GCL_ANSI=y
   ./configure --enable-gcl --prefix=/usr/local/maxima-5.31.0-gcl-2.6.8 (9) 
   --with-gcl=/usr/local/bin/gcl-2.6.8 (9)

   Maxima passed all tests, for each of 2.6.8 and 2.6.9

   I'm not sure what the flag does, but the doc says.

     --enable-ansi builds a large gcl aiming for ansi compliance

   I built Maxima with the latest stable versions gcl,ccl,cmucl,clisp,sbcl,ecl,
   and gcl (2.6.8 and 2.6.9 ) is the only one that still fails to load asdf.


   >
   >  Thanks --
   >  -- Matt
   >  From: Donald Winiecki
   >  Date: Wed, 4 Sep 2013 15:32:02 -0600
   >  Cc: Camm Maguire,
   >  "GCL-devel@gnu.org" <gcl-devel@gnu.org>, maxima@math.utexas.edu,
   >   ,
   >  list,
   >  open-axiom-devel@lists.sf.net
   >
   >  Hi Matt,
   >
   >  Right now, both 2.6.8 builds both CLtL1 and ANSI on my Ubuntu 12.10
   >  and WinXP, WinVista and Win7.
   >
   >  2.6.9 builds CLtL1 and ANSI on WinXP, but not yet on WinVista or Win7.
   >
   >  Best,
   >
   >  _don
   >
   >
   >
   >  On Wed, Sep 4, 2013 at 3:22 PM, Matt Kaufmann 
   wrote:
   >  > Hi, Camm --
   >  >
   >  > Should we expect 2.6.8 and 2.6.9 to support ANSI builds (i.e., using
   >  > configure option --enable-ansi)?
   >  >
   >  > Thanks -
   >  > -- Matt
   >  > From: Camm Maguire
   >  > Date: Tue, 27 Aug 2013 11:48:24 -0400
   >  >
   >  > Greetings! The GCL team is happy to announce a pair of stable releases
   >  > at
   >  >
   >  > ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.8.tar.gz
   >  > and
   >  > ftp://ftp.gnu.org/gnu/gcl/gcl_2.6.9.tar.gz
   >  >
   >  > Please also see the homepage and release notes at
   >  >
   >  > http://www.gnu.org/software/gcl.
   >  >
   >  > The 2.6.8 release represents several years worth of fixes and
   >  > enhancements, notably a great extension of GCL's native object file
   >  > relocation support.
   >  >
   >  > 2.6.9 is released concurrently as it contains a number of structural
   >  > improvements which, while passing all our tests, may cause issues for
   >  > some people. These improvements are chiefly a two word cons, immediate
   >  > fixnum support, word sized fixnums (64bits on 64bit machines), and a
   >  > 'dynamic maxpage' implementation, which removes all compile time limits
   >  > to the heap size and auxiliary typing and marking tables. 2.6.9 will
   >  > attempt to manage the heap given the apparent constraints of the running
   >  > system, with the goal of eliminating allocation failures and handling
   >  > out of memory conditions in advance with a modicum of grace. As this
   >  > involves a runtime startup probe of brk, which has varying degrees of
   >  > significance in different operating systems, one might still experience
   >  > overallocation of memory (notably on hurd). In such cases,
   >  >
   >  > gcl -eval '(si::set-log-maxpage-bound x)'
   >  >
   >  > will limit the heap to 2^x bytes as a workaround.
   >  >
   >  > All gcl, maxima, acl2, axiom, and hol88 builds and self tests pass for
   >  > the following platforms, with noted exceptions(*) itemized below:
   >  >
   >  > debian: amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64
   >  > kfreebsd-i386 mips mipsel powerpc s390 s390x sparc
   >  >
   >  > debian-ports: alpha hppa m68k powerpcspe ppc64 sh4 sparc64 x32
   >  >
   >  > macosx, windows
   >  >
   >  > *exceptions
   >  >
   >  > 1) all systems use native object relocation by default now but ia64 and
   >  > ppc64, which use dlopen. Thus there is a typical limit of 1024 files
   >  > that can be loaded, and the current acl2 build exceeds this limit. As
   >  > this bound is runtime configurable with root access, this is not an
   >  > insurmountable obstacle.
   >  >
   >  > 2) kfreebsd-i386 systems do not appear to allow one to brk more than
   >  > 500M of memory, and the acl2 certification process needs 1Gb. A
   >  > solution here is as yet unknown but may be forthcoming shortly.
   >  >
   >  > 3) windows builds have been performed on win95. There is an as yet
   >  > unidentified runtime error running the 2.6.9 images on win7. More
   >  > information here will be forthcoming shortly.
   >  >
   >  > Windows installers can be found at ftp://ftp.gnu.org/gnu/gcl.
   >  >
   >  > 4) macosx builds have been tested on snow leopard. More recent versions
   >  > appear to have a linker bug which prevents configure from detecting the
   >  > provided profil() routine. A workaround here should be to
   >  >
   >  > echo "#undef NO_PROFILE >>h/config.h"
   >  >
   >  > after configure and before make.
   >  >
   >  >
   >  > GCL has moved to the git version control system. The 2.6.8 and 2.6.9
   >  > branches and tags are identical in cvs and git. Henceforward,
   >  > modifications will be made to git only. As of the present writing, git
   >  > contains a merge of experimental into master, and a port of most 2.6.x
   >  > improvements into master. This will form the basis of a 2.7.0 release
   >  > sometime in the future.
   >  >
   >  > For those unfamiliar with git:
   >  >
   >  > git clone git://git.sv.gnu.org/gcl.git
   >  > cd gcl
   >  > git checkout master, or git checkout Version_2_6_9, etc.
   >  > cd gcl
   >  > ./configure && make
   >  >
   >  > git can of course provide much more. I'm currently using Egg, an emacs
   >  > interface to git, with increasing success. Merging, logging, bisecting,
   >  > branching, and uploading appear much simpler. I recommend this tool to
   >  > would-be gcl contributors.

\start
Date: Wed, 4 Sep 2013 18:47:19 -0600
From: Donald Winiecki
To: Matt Kaufmann
Subject: Re: [Maxima] GCL 2.6.8 and 2.6.9 are released
Cc: John Lapeyre

We'll wait on Camm for a definitive response to your question.

On Wed, Sep 4, 2013 at 4:52 PM, Matt Kaufmann wrote:
> Thanks.  I'm afraid my question wasn't clear (sorry).  I know about
> the --enable-ansi switch (but I appreciate the information about what
> has been seen to work with it).  However, in past years, ACL2 failed
> badly when build on top of a GCL that had been built with that switch.
> The good news is that in recent months I've worked with Camm to iron
> out most or all such issues.  What I don't know, though, is whether
> fixes for those issues were incorporated into 2.6.8, 2.6.9, both
> (which is my guess), or neither (perhaps waiting for 2.7.0 to
> incorporate fixes).  Since over the years I have sometimes experienced
> GCL errors that are intermittent, I figured I'd just ask rather than
> do testing that could be incomplete.
>
> Anyhow, I hope that clarifies.  Thanks to everyone who is contributing
> to GCL!  I'm very happy to see the progress.
>
> Regards,
> Matt

\start
Date: Thu, 05 Sep 2013 00:44:30 +0200
From: John Lapeyre
To: Matt Kaufmann
Subject: Re: [Maxima] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winieck

On 09/04/2013 11:37 PM, Matt Kaufmann wrote:
>  Thank you, Don. If there's a complete list of platforms for which
>  ANSI builds are expected to work for 2.6.9, and if possible one for
>  2.6.8 as well, I'd be interested. In particular, it would be nice to
>  know whether 2.6.9 ANSI builds on Linux are expected to work.

On x86_64 linux, I built gcl 2.6.8, and 2.6.9 with

./configure --enable-readline --enable-ansi 
--prefix=/usr/local/gcl-2.6.8 (9)

and maxima with

export GCL_ANSI=y
./configure --enable-gcl --prefix=/usr/local/maxima-5.31.0-gcl-2.6.8 (9) 
--with-gcl=/usr/local/bin/gcl-2.6.8 (9)

Maxima passed all tests, for each of 2.6.8 and 2.6.9

I'm not sure what the flag does, but the doc says.

  --enable-ansi builds a large gcl aiming for ansi compliance

I built Maxima with the latest stable versions gcl,ccl,cmucl,clisp,sbcl,ecl,
and gcl (2.6.8 and 2.6.9 ) is the only one that still fails to load asdf.

>
>  Thanks --
>  -- Matt
>  From: Donald Winiecki
>  Date: Wed, 4 Sep 2013 15:32:02 -0600
>  Cc: Camm Maguire,
>  "GCL-devel@gnu.org" <gcl-devel@gnu.org>, maxima@math.utexas.edu,
>   ,
>  list,
>  open-axiom-devel@lists.sf.net
>
>  Hi Matt,
>
>  Right now, both 2.6.8 builds both CLtL1 and ANSI on my Ubuntu 12.10
>  and WinXP, WinVista and Win7.
>
>  2.6.9 builds CLtL1 and ANSI on WinXP, but not yet on WinVista or Win7.
>

\start
Date: Fri, 06 Sep 2013 10:35:01 -0400
From: Camm Maguire
To: Matt Kaufmann
Subject: Re: [Maxima] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki, John Lapeyre

Matt, AFAICS, all the acl2/ansi work is in both 2.6.8 and 2.6.9.  These
are (approximately)

symbol exports
:dynamic-extent decls
fast #= support
dispatch macro char fix
with-standard-io-syntax

In addition, one feature requested by Jared is in 2.6.9 only:

-- command line argument support

Please let me know if I've forgotten anything.

Take care,

Matt Kaufmann writes:

> Thanks.  I'm afraid my question wasn't clear (sorry).  I know about
> the --enable-ansi switch (but I appreciate the information about what
> has been seen to work with it).  However, in past years, ACL2 failed
> badly when build on top of a GCL that had been built with that switch.
> The good news is that in recent months I've worked with Camm to iron
> out most or all such issues.  What I don't know, though, is whether
> fixes for those issues were incorporated into 2.6.8, 2.6.9, both
> (which is my guess), or neither (perhaps waiting for 2.7.0 to
> incorporate fixes).  Since over the years I have sometimes experienced
> GCL errors that are intermittent, I figured I'd just ask rather than
> do testing that could be incomplete.
>
> Anyhow, I hope that clarifies.  Thanks to everyone who is contributing
> to GCL!  I'm very happy to see the progress.
>
> Regards,
> Matt

\start
Date: Fri, 06 Sep 2013 10:41:45 -0400
From: Camm Maguire
To: John Lapeyre
Subject: Re: [Maxima] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki, Matt Kaufmann

Greetings, and thanks for the testing!

John Lapeyre writes:

> On 09/04/2013 11:37 PM, Matt Kaufmann wrote:
>> Thank you, Don. If there's a complete list of platforms for which
>> ANSI builds are expected to work for 2.6.9, and if possible one for
>> 2.6.8 as well, I'd be interested. In particular, it would be nice to
>> know whether 2.6.9 ANSI builds on Linux are expected to work.
>
> On x86_64 linux, I built gcl 2.6.8, and 2.6.9 with
>
> ./configure --enable-readline --enable-ansi --prefix=/usr/local/gcl-2.6.8 (9)
>
> and maxima with
>
> export GCL_ANSI=y
> ./configure --enable-gcl --prefix=/usr/local/maxima-5.31.0-gcl-2.6.8 (9) --with-gcl=/usr/local/bin/gcl-2.6.8 (9)
>

Just wanted to point out here that the Debian/Ubuntu gcl package
actually ships 4 images:

Cltl1
Cltl1 with gprof support
ANSI
ANSI with gprof support

When the package is installed (gcl ... .deb), these images are toggled
with the environment variables

GCL_ANSI
GCL_PROF

When set, gcl should report what image is running in the startup banner.


If you build your own gcl, you are naturally getting just one image, so
the GCL_ANSI environment variable does nothing.

> Maxima passed all tests, for each of 2.6.8 and 2.6.9
>
> I'm not sure what the flag does, but the doc says.
>
>  --enable-ansi builds a large gcl aiming for ansi compliance
>

maxima requires ansi, up until now acl2 required cltl1 (now can use
either).  If I recall axiom can run on either as well.

> I built Maxima with the latest stable versions gcl,ccl,cmucl,clisp,sbcl,ecl,
> and gcl (2.6.8 and 2.6.9 ) is the only one that still fails to load asdf.
>

I suppose I should look at this at some point.  I never really
understood it.  I always wondered why it had to be so complex, and what
was wrong with make.

\start
Date: Fri, 06 Sep 2013 10:42:28 -0400
From: Camm Maguire
To: Henry Baker
Subject: Re: [Gcl-devel] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki, Matt Kaufmann

Greetings!  And thanks for your feedback!

Henry Baker writes:

> Terrific job!  Thanks!
>
> I just looked through the release notes.  Do any versions of GCL support UTF8 ?
>

Not yet.  Is this important?

\start
Date: Fri, 06 Sep 2013 10:54:45 -0400
From: Camm Maguire
To: Tim Daly
Subject: Call for Windows Vista/7 MINGW remote vnc access
Cc: Donald Winiecki, Matt Kaufmann

Hi Tim!  Please excuse the large cc list, but this has come up
elsewhere.

Don writes:

> Right now, both 2.6.8 builds both CLtL1 and ANSI on my Ubuntu 12.10
> and WinXP, WinVista and Win7.

> 2.6.9 builds CLtL1 and ANSI on WinXP, but not yet on WinVista or Win7.

We have attempted a remote gdb session, and will continue, but gdb
raw_pre_gcl.exe is not even getting to main, so I suspect something
about the static memory setup.  2.6.9 works on Wine, and I'm taking this
as evidence that my use of wine to emulate windows is only reliable up
through WinXP.  Alas, Don cannot get permission for remote vnc access.

You did very helpfully provide me with vnc access some time ago, and
write now:

Tim Daly writes:

> I changed out the hard drive and put in Windows 7.
> Unfortunatly I cannot figure out how to enable a
> remote desktop. Damn MS moved all the settings.
> Ideas?
>
> Tim

Alas, I know nothing of Windows.  Perhaps someone here can help?  Does
anyone else already have vnc access to a win vista/mingw machine or
higher?

\start
Date: Fri, 06 Sep 2013 11:23:10 -0400
From: Camm Maguire
To: Matt Kaufmann
Subject: Re: GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki

Matt Kaufmann writes:

> Thank you, Don.  If there's a complete list of platforms for which
> ANSI builds are expected to work for 2.6.9, and if possible one for
> 2.6.8 as well, I'd be interested.  In particular, it would be nice to
> know whether 2.6.9 ANSI builds on Linux are expected to work.
>

I've already tried a stab at this in the release announcement, but just
a note that ANSI works and is available wherever gcl is available in any
flavor.   This includes a very large list of GNU/Linux and BSD
distributions/processor combinations  -- gcl even still supports Motorola
68k processors -- windows and mac.  

Smooth support is very correlated to 24/7 remote access to a development
machine.  This inevitably rises and falls as tastes change over time.
I've taken the perspective that if such a machine cannot be provided,
then the platform either does not want to be supported or is dying.
There is no sense to waste limited human time chasing such situations,
but for the record here are some of the latest developments:

last available hppa machine dropped by the gcc compile farm.
one remaining ia64 machine has no gdb support
solaris available through a kind friend sporadically on request, and at
  considerable personal expense to him.
no access to latest macosx (2?) version(s)
no access to latest 3 windows versions or working emulators.
sporadic access by request to a few of the linux debian-ports targets

\start
Date: Fri, 06 Sep 2013 08:50:29 -0700
From: Henry Baker
To: Camm Maguire
Subject: Re: [Gcl-devel] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki, Matt Kaufmann

UTF8 isn't 'critical', but not having it means that interfacing with
file systems & documents that utilize UTF8 is quite difficult.

At 07:42 AM 9/6/2013, Camm Maguire wrote:
>Greetings!  And thanks for your feedback!
>
>Henry Baker writes:
>
>> Terrific job!  Thanks!
>>
>> I just looked through the release notes.  Do any versions of GCL support UTF8 ?
>
>Not yet.  Is this important?

\start
Date: Fri, 6 Sep 2013 18:02:40 GMT
From: Leo Butler
To: Henry Baker
Subject: Re: [Maxima] [Gcl-devel] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki, Camm Maguire, Matt Kaufmann

   From: Henry Baker

   UTF8 isn't 'critical', but not having it means that interfacing with
   file systems & documents that utilize UTF8 is quite difficult.

Henry, I don't know if the following answers your question, but I do
suspect you and Camm have different ideas of what 'handling' utf8
means. It may be that for your purposes, it handles them well enough.

This is from gcl 2.6.9 ansi from the debian testing repo:

>(with-open-file (=CF=87-stream "=CE=B1=CE=B2=CE=B3.txt" :direction :outp=
ut :if-exists :supersede :if-does-not-exist :create) (format =CF=87-strea=
m "=CE=B1=CE=B2=CE=B3"))

NIL

>(with-open-file (=CF=87-stream "=CE=B1=CE=B2=CE=B3.txt" :direction :inpu=
t) (read-line =CF=87-stream nil nil))

"=CE=B1=CE=B2=CE=B3"
T

>(coerce (symbol-name '=CF=87) 'list)

(#\\317 #\\207)

SBCL, by contrast, yields:

* (coerce (symbol-name '=CF=87) 'list)

(#\GREEK_CAPITAL_LETTER_CHI)

In case the mail server or client corrupts the message, gcl is
interning a symbol with a non-ascii char and it is creating a file
with non-ascii chars in its name and successfully writing to and
reading from that file.

I have been using maxima+{gcl,ecl,sbcl,cmucl} plus this hack

https://github.com/leo-butler/utf8-hack

to use utf8 chars in maxima. This works fine in emacs and (sort of) in
xmaxima.  Wxmaxima does not display wide chars correctly and I have
not chased a solution.

\start
Date: Wed, 18 Sep 2013 15:59:02 -0400
From: Camm Maguire
To: Matt Kaufmann, Donald Winiecki
Subject: Version_2_6_10pre

Greetings!  This branch contains some quick fixups to the 2.6.9 release:

* - Version_2_6_10pre origin/Version_2_6_10pre 0a9a24cf lintian fix to VirtualFree call in unexnt.c
* ---------------------- Version_2_6_10pre@{1} 3003336c rehardwire heap start address on windows
* ---------------------- Version_2_6_10pre@{2} 690d58cd try not fixing heap start address on windws
* ---------------------- Version_2_6_10pre@{3} 9a54f6a0 try for up to 2 Gb heap on windows
* ---------------------- Version_2_6_10pre@{4} 1fb921b5 try to fix deallocation in windows heap probe
* ---------------------- Version_2_6_10pre@{5} 3e2d5445 clean windows heap size probe
* ---------------------- Version_2_6_10pre@{6} 59792fe5 don't rely on errno on macosx heap size probe
* ---------------------- Version_2_6_10pre@{7} df46f8d3 try to probe heap size on windows
* ---------------------- Version_2_6_10pre@{8} 4b8dd9b8 Use brk wrapper around sbrk to consolidate behavior when latter is emulated
* ---------------------- Version_2_6_10pre@{9} ca15eecc probe heap size up to 32Gb on macosx
* --------------------- Version_2_6_10pre@{10} 57dedec1 allocate gcl_zone_body in static area, as malloc_create_zone returns a pointer to read-only memory in macosx 10.8
* -------------------------------------------- 8d89bd77 work around unlinkable profile prototype in macosx 10.8 64bit
* -------------------------------------------- 946fa113 clear prototype mismatch warning
* -------------------------------------------- 2d456775 Set windows heap start to stable 0x10100000 of 2.6.8 for now
* -------------------------------------------- cbf12e7b place parenthesis around argument to cast in make_fixnum, fix invalid lvalue
* -------------------------------------------- 01a959cc support for empty filenames following -f on command line
* -------------------------------------------- 0eb71c71 fix documentation formatting errors
* -------------------------------------------- b9c3f3e9 zero firstword in set_type_of macro to handle C stack objects
* ------ origin/Version_2_6_9pre Version_2_6_9 b75be097 fix allocate functions

Primarily this fixes the builds on win7 and higher, and macosx 10.7 and
higher.  There is also a fix to an obscure bug revealed by acl2, as well
as a syntax error blocking fricas trunk.  Heap sizes are also dynamic on
windows and macosx, making available much more memory.

I'd like to release this ASAP.  However, I've been informed by the
fricas people that 2.6.9 is much slower for them than 2.6.8.  I haven't
had the time to look into this, and have not experienced this with other
software.  Nevertheless, if someone might isolate any performance
degradation issues in the next few days, I'll try to get a fix in to
2.6.10. 


\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
