\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,  3 Aug 2013 22:29:01 -0400 (EDT)
From: Tim Daly
To: Camm Maguire
Subject: Axiom build logs

I checked the Axiom build log and it appears to be clean.

Tim Daly

>Hi Matt!  Have not forgotten about this.  I think odds are good that my
>last 2.6.9 commit was made yesterday.  Things are a little ambiguous
>because Debian just made a release, and the autobuilders are building in
>a somewhat unstable environment, so my usual testing of the
>maxima/axiom/acl2/hol88 builds across all those architectures show some
>failures which might or might not be GCL's fault, and need chasing
>down.  If interested, you can see the progress at
>
>https://buildd.debian.org/status/package.php?p=gcl&suite=sid
>https://buildd.debian.org/status/package.php?p=maxima&suite=sid
>https://buildd.debian.org/status/package.php?p=acl2&suite=sid
>https://buildd.debian.org/status/package.php?p=hol88&suite=sid
>https://buildd.debian.org/status/package.php?p=axiom&suite=sid
>
>Once there are no gcl related failures, I will
>
>1) tag Version_2_6_8 and Version_2_6_9 in cvs and git
>2) push gcl_2.6.8.tar.gz and gcl_2.6.9.tar.gz to the download area at
>gnu.org
>3) update the website with this announcement
>4) proceed henceforward with the master and experimental branches in
>git, as this appears to be what the users want.
>

\start
Date: Mon, 05 Aug 2013 14:17:56 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom build logs

Greetings!  Thanks for checking!  I am working with the latest axiom
release, right?

Take care,

Tim Daly writes:

> Camm,
>
> I checked the Axiom build log and it appears to be clean.
>
> Tim Daly
>
>>Hi Matt!  Have not forgotten about this.  I think odds are good that my
>>last 2.6.9 commit was made yesterday.  Things are a little ambiguous
>>because Debian just made a release, and the autobuilders are building in
>>a somewhat unstable environment, so my usual testing of the
>>maxima/axiom/acl2/hol88 builds across all those architectures show some
>>failures which might or might not be GCL's fault, and need chasing
>>down.  If interested, you can see the progress at
>>
>>https://buildd.debian.org/status/package.php?p=gcl&suite=sid
>>https://buildd.debian.org/status/package.php?p=maxima&suite=sid
>>https://buildd.debian.org/status/package.php?p=acl2&suite=sid
>>https://buildd.debian.org/status/package.php?p=hol88&suite=sid
>>https://buildd.debian.org/status/package.php?p=axiom&suite=sid
>>
>>Once there are no gcl related failures, I will
>>
>>1) tag Version_2_6_8 and Version_2_6_9 in cvs and git
>>2) push gcl_2.6.8.tar.gz and gcl_2.6.9.tar.gz to the download area at
>>gnu.org
>>3) update the website with this announcement
>>4) proceed henceforward with the master and experimental branches in
>>git, as this appears to be what the users want.
>>

\start
Date: Mon, 05 Aug 2013 17:49:10 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom build logs

>Greetings!  Thanks for checking!  I am working with the latest axiom
>release, right?

"The latest Axiom release" is something of a meaningless concept at
the moment. There are very few user visible changes because I'm 
spending a lot of time creating a computer algebra test suite and a
massive rewrite of the lisp code. 

I grabbed the git repo and I'll do a build with it sometime soon.

\start
Date: Tue, 06 Aug 2013 09:07:16 -0400
From: Eugene Surowitz
To: Gabriel Dos Reis
Subject: Re: [fricas-devel] Noweb and literate programming

Your efforts are not for nought;
however, you missed the same thing that Knuth missed:

The AXIOM/FRICAS/OpenAXIOM situation is the inverse problem
to working with an already literate program.

The panAXIOM problem is how to create a literate program from
an pre-literate one.  Knuth fudged this with the comment (somewhere)
that you throw the first version away; NOT an panAxiom option.
Knuth really had no way of starting with a massive program in many files
and deriving the literate result.  Which is roughly the equivalent
to finding your self in a 747 at 35,000 feet and needing to change out
an engine without maintenance manuals.

What you have described is analytic phases rather than
synthetic and synoptic operations: disassembling existing
pamphlets into sub-component files and directories.

The pieces that are missing and that need to be added do the opposite,
as well as more of the the direction that you were going.

The synoptic view requires creation of a single data base of everything
needed to build the system that has been analyzed down to, at least,
the syllabic level; it needs to contain every reference
to every character string down to every syllable.
A click/select operation needs to be able to display all lines of text
of a particular object/character string utterly independent of "language"
since large codebases are multilingual.

Cheers, Gene

On 8/6/2013 4:06 AM, Martin Baker wrote:
> On 5 August 2013 14:20, Waldek Hebisch wrote:
>
>  >> I think that we should get rid of noweb and declare
>  >> past attempt at literate programming as a failure.
>  >> More precisely, noweb markup is causing troubles.
>  >> They are not big troubles, but AFAICS we are getting
>  >> essentially no value from noweb so why bother with
>  >> it?
>
> On 06/08/13 03:06, Bill Page wrote:
>
>  > Before giving up entirely on the goal of better documentation however
>  > I think we need to  consider alternatives.

> Some time back I started an attempt at an IDE for FriCAS
> http://www.euclideanspace.com/prog/es/ There wasn't any interest so
> I didn't take it any further, however one part of the code may be of
> some interest here.

> There is some code, shown here:
> http://www.euclideanspace.com/prog/es/user/ which was intended to be
> a one-off pre-processor so that I could attempt to parse SPAD, what
> this pre-processor does is:

> 1) Go through a directory (such as fricas/src/algebra) looking for files called
> *.spad.pamphlet
> 2) If if finds a match then create a directory of the same name.
> 3) Then scan through the file.
> 4) When it finds category, domain or package code (starting like:
> <<package NONE1 NoneFunctions1>>= and ending with @) it puts them in
> separate .SPAD files in the directory it has just created.
> 5) Everything else in the file is assumed to be modified latex and converted to HTML.

> So the end result is a directory, for each pamphlet file, containing
> multiple SPAD files and one HTML file.

> (The preprossessor can also do other stuff like adding curly brackets and
> substituting macroes, which you probably don't want, but that can be disabled).

> I am just putting this forward as a possible stepping stone to
> better documentation, I would be happy to develop the code if you
> thought it might help. From here I think it would be good to add
> diagrams and make the structure more hierarchical.

> I really do believe in better documentation, I would be sad if I
> inadvertently contributed to a path which lead to worse
> documentation. I do feel that the literate programming movement has
> the right goals, its just the mechanisms that don't work for me. I
> would like FriCAS to try to enforce better documentation.

> Martin

\start
Date: Tue, 27 Aug 2013 11:48:24 -0400
From: Camm Maguire
To: Matt Kaufmann, Gabriel Dos Reis, Donald Winiecki
Subject: GCL 2.6.8 and 2.6.9 are released

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, 28 Aug 2013 05:37:22 -0700
From: Henry Baker
To: Camm Maguire
Subject: Re: [Maxima] GCL 2.6.8 and 2.6.9 are released
Cc: Donald Winiecki, Gabriel Dos Reis, Matt Kaufmann

Thanks very much to you & the GCL team!

Q: What about maximum _bind stack_ size on Windows & other platforms?

I recently ran up against the size of this "bind stack", and was told that
its size was compiled in.

Here's how to fix stack overflow problems in SBCL, but it doesn't work for GCL:
-----
I found an obscure Cygwin utility called 'peflags' that can be used to change the amount of stack for _any_ Windows executable -- not just Cygwin exectables.

Thus, I was able to change the stack size for SBCL Lisp with the following command in the appropriate directory under 'Program Files':

   Query the current stack-reserve setting

peflags --stack-reserve sbcl.exe
sbcl.exe: stack reserve size    : 2097152 (0x200000) bytes

   Provide a new stack-reserve setting

peflags --stack-reserve=0x1000000 sbcl.exe
sbcl.exe: stack reserve size    : 16777216 (0x1000000) bytes

Note that sbcl.exe is a relatively small program which loads the main
sbcl.core image.  Nevertheless, sbcl.exe sets the amount of stack for
the whole program.

'peflags' can also adjust other settings, as well, including heap size, etc.

I have no idea if 'peflags' will work correctly on 64-bit applications, though.
-----

At 08:48 AM 8/27/2013, Camm Maguire wrote:
>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.



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