\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: Mon, 1 Nov 2004 09:51:22 -0500
From: Tim Daly
To: Mark Murray
Subject: PREFIX question

Mark,

I'm working on your patches. I notice that you use ${PREFIX}.
Where is this set?

+COMMAND=${PREFIX}/bin/axiom
+COMMAND1=${PREFIX}/bin/AXIOMsys
+TANGLE=notangle

\start
Date: Mon, 01 Nov 2004 17:01:06 +0000
From: Mark Murray
To: Tim Daly
Subject: Re: PREFIX question 

Tim Daly writes:
> Mark,
> 
> I'm working on your patches. I notice that you use ${PREFIX}.
> Where is this set?
> 
> +COMMAND=${PREFIX}/bin/axiom
> +COMMAND1=${PREFIX}/bin/AXIOMsys
> +TANGLE=notangle

Ah. I pass it into the build environmewnt with something along
the lines of

gmake PREFIX=/usr/local <whatever>


I guess it would make sense to have a

PREFIX?=/usr/local

line in Makefile.pamplet or some other such useful place.

Hmm. Junst thinking. It may also make sense to have

TANGLE?=/your/path/to/tangle

note the '?=' to make it command-line overridable; and it
would be useful to have similar constructs for some of the
other things that the sysadmin may want to tweak in the
build/install.


\start
Date: Mon, 1 Nov 2004 19:20:13 +0100
From: Magnus Larsson
To: list
Subject: Axiom cvs 2004-10-31 (gcl-2.6.5) gcc/binutils dependency?

Hello Axiom-developer,

FYI,

Building Axiom cvs 2004-10-31 using:

gcc-3.4.2 + binutils 2.15.92.0.2 (beta) or
gcc-3.3.1 + binutils 2.15.92.0.2 (beta)
 
fails with a reference to "_raw_size" while making gcl-2.6.5:
...
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
-I/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gcl-tk 
init_pari.c
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
-I/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gcl-tk 
nsocket.c
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
-I/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gcl-tk 
sfasl.c
In file included from sfasl.c:40:
sfaslbfd.c: In function `fasload':
sfaslbfd.c:266: error: structure has no member named `_raw_size'
sfaslbfd.c:291: error: structure has no member named `_raw_size'
sfaslbfd.c:356: error: structure has no member named `_raw_size'
make[4]: *** [sfasl.o] Error 1
make[4]: Leaving directory 
`/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o'
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory 
`/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5'
/bin/sh: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory `/home/magnus/usr/source/axiom/axiom-test/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/home/magnus/usr/source/axiom/axiom-test'
make: *** [all] Error 2
magnus@lfs:~/usr/source/axiom/axiom-test>          

I managed to build Axiom cvs 2004-10-31 using 
gcc-3.3.1 and binutils 2.15.90.0.3 20040415.

Downgrading to binutils 2.15.90.0.3 20040415 allowed sfaslbfd.c to pick up a 
bfd.h with "_raw_size" defined. The more recent binutils 2.15.92.0.2 (beta) 
uses "rawsize" instead.

host system:
Linux lfs 2.6.9 #2 Sun Oct 24 18:52:20 CEST 2004 i686 athlon i386 GNU/Linux

\start
Date: Mon, 1 Nov 2004 19:24:35 +0100
From: Magnus Larsson
To: list
Subject: Axiom cvs 2004-10-31 (gcl-2.6.5) gcc/binutils dependency?

Hello Axiom-developer,

=46YI,

Building Axiom cvs 2004-10-31 using:

gcc-3.4.2 + binutils 2.15.92.0.2 (beta) or
gcc-3.3.1 + binutils 2.15.92.0.2 (beta)
=A0
fails with a reference to "_raw_size" while making gcl-2.6.5:
=2E..
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer =
=A0
=2DI/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gc=
l-tk 
init_pari.c
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer =
=A0
=2DI/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gc=
l-tk 
nsocket.c
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer =
=A0
=2DI/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gc=
l-tk 
sfasl.c
In file included from sfasl.c:40:
sfaslbfd.c: In function `fasload':
sfaslbfd.c:266: error: structure has no member named `_raw_size'
sfaslbfd.c:291: error: structure has no member named `_raw_size'
sfaslbfd.c:356: error: structure has no member named `_raw_size'
make[4]: *** [sfasl.o] Error 1
make[4]: Leaving directory 
`/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o'
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory 
`/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5'
/bin/sh: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory `/home/magnus/usr/source/axiom/axiom-test/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/home/magnus/usr/source/axiom/axiom-test'
make: *** [all] Error 2
magnus@lfs:~/usr/source/axiom/axiom-test> =A0 =A0 =A0 =A0 =A0

I managed to build Axiom cvs 2004-10-31 using 
gcc-3.3.1 and binutils 2.15.90.0.3 20040415.

Downgrading to binutils 2.15.90.0.3 20040415 allowed sfaslbfd.c to pick up =
a 
bfd.h with "_raw_size" defined. The more recent binutils 2.15.92.0.2 (beta)=
 
uses "rawsize" instead.

host system:
Linux lfs 2.6.9 #2 Sun Oct 24 18:52:20 CEST 2004 i686 athlon i386 GNU/Linux

\start
Date: Fri, 29 Oct 2004 18:48:20 +0100
From: Mark Murray
To: Tim Daly
Subject: FreeBSD patches 

root writes:
> ok, clearly i've missed a patch. sorry about that.  do you happen to
> have the email that contained the patches you're expecting? i'll look
> to merging them this weekend if i can.

Hi

This set of patches does quite a bit. It has Makefile.MACOSX and
Makefile.freebsd enhancements. It also has some path changes to things
like tangle(1), which in FreeBSD's case is preinstalled by the ports
system. FreeBSD also uses a preinstalled GCL. Some of this will no
doubt not be of universal appeal, and I'm happy to keep them as local
diffs.

I have attempted to clean up the MACOSX stuff a bit. Lots of your
changes that were marked as MACOSX requirements are actually
BSD/POSIX, and I've tried to make the changes as universal as
possible. I don't have a MACOSX box, but I've done my best to
make the changes sane.

Note that MACOS/BSD/POSIX do not have an malloc.h include. It is
an error to assume that the kernel malloc.h in sys/ is a substitute.
It bst this achieves nothing, and at worst it will pollute your
namespace with erronious malloc()/free() prototypes. MACOS/BSD/POSIX
get their malloc() definition from stdlib.h.

I haven't looked too hard at the headers, but I have seen that the
order that some of them are included in is rather strange. For
example, it makes little sense to #include <sys/types.h> after other
standard headers, because those headers often depend on <sys/types.h>.
You can often get away with it, but it can be dodgy.

The Axiom library code gets intalled in a place that is way off the
usual ${PATH}, so I've modified the install to create an "axiom"
script in ${PREFIX}/bin, where ${PREFIX} is usually /usr/local, but
can be reset to anything the sysadmin wants. I've also created an
"AXIOMsys" script in ${PREFIX}/bin that launches the binary of the
same name without having to get the user to set all sorts of
environment variables. This makes TeXmacs work in Axiom mode with
no extra work.

I've fixed some warnings, and I've tried to fix "make clean" so that
it removes more generated files, mainly "Makefile" and "Makefile.dvi".

Much of the clever stuff to make the external GCL work is done by
Camm, so if there are lisp-related questions, please ask him.

My offer of a FreeBSD box to test this stuff on still stands.

Thanks!

M

Index: Makefile
===================================================================
RCS file: /cvsroot/axiom/axiom/Makefile,v
retrieving revision 1.12
diff -u -d -r1.12 Makefile
--- Makefile	22 Aug 2004 09:19:32 -0000	1.12
+++ Makefile	29 Oct 2004 13:46:12 -0000
@@ -9,7 +9,8 @@
 #GCLVERSION=gcl-2.6.2
 #GCLVERSION=gcl-2.6.2a
 #GCLVERSION=gcl-2.6.3
-GCLVERSION=gcl-2.6.5
+#GCLVERSION=gcl-2.6.5
+GCLVERSION=gcl-system
 AWK=gawk
 GCLDIR=${LSP}/${GCLVERSION}
 SRC=${SPD}/src
@@ -22,8 +23,9 @@
 INC=${SPD}/src/include
 CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
 INSTALL=/usr/local/axiom
-COMMAND=${INSTALL}/mnt/${SYS}/bin/axiom
-TANGLE=${SPADBIN}/lib/notangle
+COMMAND=${PREFIX}/bin/axiom
+COMMAND1=${PREFIX}/bin/AXIOMsys
+TANGLE=notangle
 
 NOISE="-o ${TMP}/trace"
 
@@ -71,6 +73,7 @@
 	@mkdir -p ${OBJ}/noweb
 	@mkdir -p ${TMP}
 	@mkdir -p ${MNT}/${SYS}/bin/lib
+ifneq "${SYS}" "freebsd"
 	@( cd ${OBJ}/noweb ; \
 	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
 	cd ${OBJ}/noweb/src ; \
@@ -82,6 +85,7 @@
 	${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/${SYS}/bin/lib \
                 MAN=${MNT}/${SYS}/bin/man \
                 TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
+endif
 	@echo The file marks the fact that noweb has been made > noweb
 
 nowebclean:
@@ -98,9 +102,24 @@
 	@echo 78 installing Axiom in ${INSTALL}
 	@mkdir -p ${INSTALL}
 	@cp -pr ${MNT} ${INSTALL}
-	@echo AXIOM=${INSTALL}/mnt/${SYS} >${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND}
+	@echo export AXIOM >>${COMMAND}
+	@echo DAASE='$${AXIOM}' >>${COMMAND}
+	@echo export DAASE >>${COMMAND}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND}
+	@echo export PATH >>${COMMAND}
 	@cat ${SRC}/etc/axiom >>${COMMAND}
 	@chmod +x ${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND1}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND1}
+	@echo export AXIOM >>${COMMAND1}
+	@echo DAASE='$${AXIOM}' >>${COMMAND1}
+	@echo export DAASE >>${COMMAND1}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND1}
+	@echo export PATH >>${COMMAND1}
+	@echo '$${AXIOM}/bin/AXIOMsys' '$$@' >>${COMMAND1}
+	@chmod +x ${COMMAND1}
 	@echo 79 Axiom installation finished.
 	@echo
 	@echo Please add $(shell dirname ${COMMAND}) to your PATH variable
@@ -123,5 +142,5 @@
 	@ ${ENV} $(MAKE) -f Makefile.${SYS} clean
 	@ rm -f noweb 
 	@ rm -f *~
-	@echo 9 finished system build on `date` | tee >lastBuildDate
+	@ rm -f Makefile.${SYS}
 
Index: Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/Makefile.pamphlet,v
retrieving revision 1.27
diff -u -d -r1.27 Makefile.pamphlet
--- Makefile.pamphlet	27 Oct 2004 01:10:41 -0000	1.27
+++ Makefile.pamphlet	29 Oct 2004 13:46:16 -0000
@@ -50,7 +50,7 @@
 	@ ${ENV} $(MAKE) -f Makefile.${SYS} clean
 	@ rm -f noweb 
 	@ rm -f *~
-	@echo 9 finished system build on `date` | tee >lastBuildDate
+	@ rm -f Makefile.${SYS}
 
 @
 
@@ -185,8 +185,9 @@
 INC=${SPD}/src/include
 CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
 INSTALL=/usr/local/axiom
-COMMAND=${INSTALL}/mnt/${SYS}/bin/axiom
-TANGLE=${SPADBIN}/lib/notangle
+COMMAND=${PREFIX}/bin/axiom
+COMMAND1=${PREFIX}/bin/AXIOMsys
+TANGLE=notangle
 
 NOISE="-o ${TMP}/trace"
 
@@ -268,6 +269,7 @@
 	@mkdir -p ${OBJ}/noweb
 	@mkdir -p ${TMP}
 	@mkdir -p ${MNT}/${SYS}/bin/lib
+ifneq "${SYS}" "freebsd"
 	@( cd ${OBJ}/noweb ; \
 	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
 	cd ${OBJ}/noweb/src ; \
@@ -279,6 +281,7 @@
 	${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/${SYS}/bin/lib \
                 MAN=${MNT}/${SYS}/bin/man \
                 TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
+endif
 	@echo The file marks the fact that noweb has been made > noweb
 
 nowebclean:
@@ -337,6 +340,9 @@
 libspadclean:
 	@echo 17 cleaning ${OBJ}/${SYS}/lib	
 	@rm -rf ${OBJ}/${SYS}/lib	
+	@( cd src ; ${SPADBIN}/document ${NOISE} Makefile )
+	@( cd src ; ${ENV} ${MAKE} clean )
+	@rm -f ${SPD}/src/Makefile ${SPD}/src/Makefile.dvi
 
 @
 
@@ -398,6 +404,7 @@
 	@rm -rf ${INT}/ccl
 	@rm -rf ${OBJ}/${SYS}/ccl
 	@rm -rf ${LSP}/gcldir
+	@rm -f ${LSP}/Makefile ${LSP}/Makefile.dvi
 
 @
 \subsection{install}
@@ -406,9 +413,24 @@
 	@echo 78 installing Axiom in ${INSTALL}
 	@mkdir -p ${INSTALL}
 	@cp -pr ${MNT} ${INSTALL}
-	@echo AXIOM=${INSTALL}/mnt/${SYS} >${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND}
+	@echo export AXIOM >>${COMMAND}
+	@echo DAASE='$${AXIOM}' >>${COMMAND}
+	@echo export DAASE >>${COMMAND}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND}
+	@echo export PATH >>${COMMAND}
 	@cat ${SRC}/etc/axiom >>${COMMAND}
 	@chmod +x ${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND1}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND1}
+	@echo export AXIOM >>${COMMAND1}
+	@echo DAASE='$${AXIOM}' >>${COMMAND1}
+	@echo export DAASE >>${COMMAND1}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND1}
+	@echo export PATH >>${COMMAND1}
+	@echo '$${AXIOM}/bin/AXIOMsys' '$$@' >>${COMMAND1}
+	@chmod +x ${COMMAND1}
 	@echo 79 Axiom installation finished.
 	@echo
 	@echo Please add $(shell dirname ${COMMAND}) to your PATH variable
@@ -550,6 +572,11 @@
 optimizations for function calling in Axiom. This is handled automatically
 by changing this variable.
 
+If GCLVERSION is ``gcl-system'', then no GCL is not built locally,
+and it is assumed that the ``gcl'' command is available off the
+path. If this GCL is unsuitable for building Axiom, then very bad
+things will happen.
+
 NOTE WELL: IF YOU CHANGE THIS YOU SHOULD ERASE THE lsp/Makefile FILE.
 This will cause the build to remake the lsp/Makefile from the
 lsp/Makefile.pamphlet file and get the correct version. If you
@@ -563,7 +590,8 @@
 #GCLVERSION=gcl-2.6.2
 #GCLVERSION=gcl-2.6.2a
 #GCLVERSION=gcl-2.6.3
-GCLVERSION=gcl-2.6.5
+#GCLVERSION=gcl-2.6.5
+GCLVERSION=gcl-system
 @
 
 \subsection{Makefile.axposf1v3}
@@ -859,6 +887,60 @@
 <<clean>>
 
 @
+\subsection{Makefile.freebsd}
+On FreeBSD the POSIX [[SIGCHLD]] signal is used in preference to
+the SYSV [[SIGCLD]].
+
+Annoyingly enough it seems that GCL uses a default extension of
+.lsp rather than .lisp so we add the {\bf LISP} variable here. We
+need to depend on the default extension behavior because the system
+build will load either the interpreted or compiled form of a file
+depending on which is available. This varies at different stages
+of the build.
+
+Also FreeBSD does not include gawk or nawk by default so we change
+the [[AWK]] variable to use [[awk]].
+<<Makefile.freebsd>>=
+# System dependent Makefile for the freebsd platform
+# Platform variable
+PLF:=FREEBSDplatform
+# C compiler flags
+CCF:="-O -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11R6/include -I/usr/local/include"
+# Loader flags
+LDF:="-L/usr/X11R6/lib -L/usr/local/lib"
+# C compiler to use
+CC:=gcc 
+AWK=awk
+RANLIB=ranlib
+TOUCH=touch
+TAR=tar
+AXIOMXLROOT=${AXIOM}/compiler
+O=o
+BYE=bye
+LISP=lsp
+DAASE=${SRC}/share
+# where the libXpm.a library lives
+XLIB=/usr/X11R6/lib
+
+ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
+    TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
+    LISP=${LISP} DAASE=${DAASE} XLIB=${XLIB} TANGLE=${TANGLE}
+
+all: rootdirs srcsetup lspdir srcdir
+	@echo 45 Makefile.freebsd called
+	@echo 46 Environment : ${ENV} 
+	@echo 47 finished system build on `date` | tee >lastBuildDate
+
+<<rootdirs>>
+<<noweb>>
+<<literate commands>>
+<<srcsetup>>
+<<src>>
+<<lsp>>
+<<document>>
+<<clean>>
+
+@
 \subsection{Makefile.linux}
 Annoyingly enough it seems that GCL uses a default extension of .lsp
 rather than .lisp so we add the {\bf LISP} variable here. We need to
@@ -1333,24 +1415,24 @@
 
 @
 \subsection{Makefile.MACOSX}
-On the MAC OSX someone decided (probably a BSDism) to rename the
-[[SIGCLD]] signal to [[SIGCHLD]]. In order to handle this in the 
-low level C socket code (in particular, in [[src/lib/fnct_key.c]])
-we change the platform variable to be [[MACOSXplatform]] and create
-this new stanza.
+On MAC OSX the POSIX [[SIGCHLD]] signal is used in preference to
+the SYSV [[SIGCLD]].
 
-Also it appears that the MAC OSX does not include gawk or nawk by 
-default so we change the [[AWK]] variable to use [[awk]].
+Annoyingly enough it seems that GCL uses a default extension of
+.lsp rather than .lisp so we add the {\bf LISP} variable here. We
+need to depend on the default extension behavior because the system
+build will load either the interpreted or compiled form of a file
+depending on which is available. This varies at different stages
+of the build.
 
-We need to add [[-I/usr/include/sys]] because [[malloc.h]] has been
-moved on this platform.
+Also it appears that MAC OSX does not include gawk or nawk by default
+so we change the [[AWK]] variable to use [[awk]].
 <<Makefile.MACOSX>>=
 # System dependent Makefile for the MAC OSX platform
 # Platform variable
 PLF:=MACOSXplatform
 # C compiler flags
-CCF:="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include \
-     -I/usr/include/sys"
+CCF:="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
 #CCF:=-g -fno-strength-reduce -Wall -D_GNU_SOURCE  -D${PLF} -I/usr/X11/include
 # Loader flags
 LDF:= -L/usr/X11R6/lib 
@@ -1395,7 +1477,5 @@
 Bath BA2 5QR UK Tel. +44-1225-837430 
 {\bf http://www.codemist.co.uk}
 \bibitem{4} \$SPAD/zips/noweb-2.10a.tgz, the noweb source tree
-\bibitem{5} \$SPAD/zips/advi-1.2.0.tar.gz, the advi source tree
 \end{thebibliography}
 \end{document}
-
Index: lsp/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/lsp/Makefile.pamphlet,v
retrieving revision 1.11
diff -u -d -r1.11 Makefile.pamphlet
--- lsp/Makefile.pamphlet	15 Oct 2004 23:58:22 -0000	1.11
+++ lsp/Makefile.pamphlet	29 Oct 2004 13:46:22 -0000
@@ -830,6 +830,39 @@
 	  echo 20 applying toploop patch to unixport/init_gcl.lsp ; \
 	  patch <${SPD}/zips/${GCLVERSION}.unixport.init_gcl.lsp.patch )
 @ 
+\subsection{GCL already installed}
+<<gcl-system>>=
+# locally installed GCL
+OUT=${OBJ}/${SYS}/bin
+
+all:
+	@echo 21 building ${LSP} ${GCLVERSION}
+
+gcldir: 
+	@echo 22 building for ${GCLVERSION}
+	echo '(compiler::link nil "${OUT}/lisp" (format nil "(progn (let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))(setq compiler::*default-system-p* t))" si::*system-directory* (quote (list ".lsp"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
+	@echo 23 finished gcl build on `date` | tee >gcldir
+
+ccldir: ${LSP}/ccl/Makefile
+	@echo 21 building CCL
+	@mkdir -p ${INT}/ccl
+	@mkdir -p ${OBJ}/${SYS}/ccl
+	@( cd ccl ; ${ENV} ${MAKE} )
+
+${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
+	@echo 22 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
+	@( cd ccl ; ${SPADBIN}/document ${NOISE} Makefile )
+
+document:
+	@echo 23 making docs in ${LSP}
+	@mkdir -p ${INT}/doc/lsp/ccl
+	@( cd ccl ; ${ENV} ${MAKE} document )
+
+clean:
+	@echo 24 cleaning ${LSP}/ccl
+	@( cd ccl ; ${ENV} ${MAKE} clean )
+@
+\eject
 <<*>>=
 # gcl version 2.4.1
 OUT=${OBJ}/${SYS}/bin
Index: src/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/Makefile.pamphlet,v
retrieving revision 1.11
diff -u -d -r1.11 Makefile.pamphlet
--- src/Makefile.pamphlet	15 Jul 2004 03:45:11 -0000	1.11
+++ src/Makefile.pamphlet	29 Oct 2004 13:46:26 -0000
@@ -24,10 +24,15 @@
 
 <<environment>>=
 SETUP=scriptsdir libdir
-DIRS=bootdir interpdir sharedir algebradir inputdir etcdir clefdir docdir \
-     graphdir
+DIRSINITIAL=bootdir interpdir sharedir algebradir
+DIRSCOMPLETE=${DIRSINITIAL} inputdir etcdir clefdir docdir graphdir
+ifeq ($(PASS1),)
+DIRS=${DIRSCOMPLETE}
+else
+DIRS=${DIRSINITIAL}
+endif
 DOCS=scriptsdocument libdocument ${DIRS:dir=document} 
-CLNS=scriptsclean libclean ${DIRS:dir=clean} 
+CLNS=scriptsclean libclean ${DIRSCOMPLETE:dir=clean}
 
 @
 \subsection{The scripts directory}
@@ -55,6 +60,7 @@
 scriptsclean: ${SRC}/scripts/Makefile
 	@echo 4 cleaning ${SRC}/scripts
 	@( cd scripts ; ${ENV} ${MAKE} clean )
+	@rm -f ${SRC}/scripts/Makefile ${SRC}/scripts/Makefile.dvi
 
 
 @
@@ -79,6 +85,7 @@
 clefclean: ${SRC}/clef/Makefile
 	@echo 8 cleaning ${SRC}/clef
 	@( cd clef ; ${ENV} ${MAKE} clean )
+	@ rm -f ${SRC}/clef/Makefile ${SRC}/clef/Makefile.dvi
 
 
 @
@@ -105,6 +112,7 @@
 shareclean: ${SRC}/share/Makefile
 	@echo 12 cleaning ${SRC}/share
 	@( cd share ; ${ENV} ${MAKE} clean )
+	@rm -f ${SRC}/share/Makefile ${SRC}/share/Makefile.dvi
 
 
 @
@@ -163,6 +171,7 @@
 	@echo 20 cleaning ${SRC}/lib
 	@( cd lib ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/lib
+	@rm -f ${SRC}/input/Makefile ${SRC}/input/Makefile.dvi
 
 @
 \subsection{The boot directory}
@@ -196,6 +205,7 @@
 	@echo 24 cleaning ${SRC}/boot
 	@( cd boot ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/boot
+	@rm -f ${SRC}/boot/Makefile ${SRC}/boot/Makefile.dvi
 
 @
 \subsection{The interp directory}
@@ -229,6 +239,7 @@
 	@echo 28 cleaning ${SRC}/interp
 	@( cd interp ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/interp
+	@rm -f ${SRC}/interp/Makefile ${SRC}/interp/Makefile.dvi
 
 @
 \subsection{The algebra directory}
@@ -268,7 +279,7 @@
 	@echo 32 cleaning ${SRC}/algebra
 	@( cd algebra ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/algebra
-
+	@rm -f ${SRC}/algebra/Makefile ${SRC}/algebra/Makefile.dvi
 @
 \subsection{The input directory}
 The input directory contains code used for examples, regression
@@ -306,6 +317,7 @@
 	@echo 36 cleaning ${SRC}/input
 	@( cd input ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/input
+	@rm -f ${SRC}/input/Makefile ${SRC}/input/Makefile.dvi
 
 @
 \subsection{The etc directory}
@@ -335,6 +347,7 @@
 	@echo 40 cleaning ${SRC}/etc
 	@( cd etc ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/etc
+	@rm -f ${SRC}/etc/Makefile ${SRC}/etc/Makefile.dvi
 
 @
 \subsection{The doc directory}
@@ -360,6 +373,7 @@
 	@echo 44 cleaning ${SRC}/doc
 	@( cd doc ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/doc
+	@rm -f ${SRC}/doc/Makefile ${SRC}/doc/Makefile.dvi
 
 @
 \subsection{The graph directory}
@@ -385,6 +399,7 @@
 	@rm -rf ${INT}/graph
 	@rm -rf ${OBJ}/${SYS}/graph
 	@rm -rf ${MNT}/${SYS}/graph
+	@rm -f ${SRC}/graph/Makefile ${SRC}/graph/Makefile.dvi
 
 @
 \section{The Makefile}
@@ -422,7 +437,7 @@
 	@echo 50 making docs in ${SRC}
 
 clean: ${CLNS}
-	@echo 51 cleaning ${SRC}
+	@echo 51 cleaning ${SRC} ${CLNS}
 
 @
 \eject
Index: src/algebra/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/algebra/Makefile.pamphlet,v
retrieving revision 1.10
diff -u -d -r1.10 Makefile.pamphlet
--- src/algebra/Makefile.pamphlet	3 Jul 2004 19:06:29 -0000	1.10
+++ src/algebra/Makefile.pamphlet	29 Oct 2004 13:49:24 -0000
@@ -40940,6 +40940,8 @@
 
 <<axiom.sty (OUT from IN)>>
 
+clean:
+
 @
 \eject
 \begin{thebibliography}{99}
Index: src/booklets/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/booklets/Makefile.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 Makefile.pamphlet
--- src/booklets/Makefile.pamphlet	28 Aug 2003 12:15:28 -0000	1.1
+++ src/booklets/Makefile.pamphlet	29 Oct 2004 13:49:26 -0000
@@ -19,6 +19,7 @@
 clean:
 	@echo 2 cleaning ${INT}/docs/src/booklets
 	@rm -rf ${INT}/docs/src/booklets
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/booklets/Sorting.booklet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/booklets/Sorting.booklet,v
retrieving revision 1.1
diff -u -d -r1.1 Sorting.booklet
--- src/booklets/Sorting.booklet	28 Aug 2003 12:15:28 -0000	1.1
+++ src/booklets/Sorting.booklet	29 Oct 2004 13:49:40 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{/home/axiomgnu/new/mnt/linux/bin/tex/noweb}
+\usepackage{noweb}
 \begin{document}
 \title{Sorting Facilities}
 \author{Timothy Daly}
Index: src/boot/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/boot/Makefile.pamphlet,v
retrieving revision 1.6
diff -u -d -r1.6 Makefile.pamphlet
--- src/boot/Makefile.pamphlet	27 Jun 2004 15:00:58 -0000	1.6
+++ src/boot/Makefile.pamphlet	29 Oct 2004 13:49:47 -0000
@@ -1151,7 +1151,7 @@
 expansion. Adding a single quote symbol will break this expansion.
 
 <<environment>>= 
-CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
+CMD0=	(compiler::link (quote (${OBJS1})) "${SAVESYS}" (format nil "(let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t)) (when (fboundp (quote si::sgc-on)) (si::sgc-on t)) (setq compiler::*default-system-p* t)" si::*system-directory* (quote  (list ".lsp"))))
  
 @
 \subsection{boothdr.lisp \cite{1}}
@@ -1615,6 +1615,7 @@
 clean:
 	@echo 43 cleaning ${OUT}
 	@rm -f ${OUT}
+	@rm -f Makefile Makefile.dvi
 
 @
 \section{The Makefile}
Index: src/clef/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/clef/Makefile.pamphlet,v
retrieving revision 1.3
diff -u -d -r1.3 Makefile.pamphlet
--- src/clef/Makefile.pamphlet	27 Jun 2004 15:00:58 -0000	1.3
+++ src/clef/Makefile.pamphlet	29 Oct 2004 13:49:47 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{../../mnt/linux/bin/axiom}
+\usepackage{axiom}
 \begin{document}
 \title{\$SPAD/src/clef Makefile}
 \author{Timothy Daly}
@@ -57,6 +57,9 @@
 	@ ${CC} ${CLEFOBJS} -o ${OUT}/clef
 
 <<edible>>
+
+clean:
+
 @
 \eject
 \begin{thebibliography}{99}
Index: src/clef/edible.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/clef/edible.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 edible.c.pamphlet
--- src/clef/edible.c.pamphlet	30 Jul 2004 16:45:33 -0000	1.4
+++ src/clef/edible.c.pamphlet	29 Oct 2004 13:49:50 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{../../mnt/linux/bin/axiom}
+\usepackage{axiom}
 \begin{document}
 \title{\$SPAD/src/clef edible.c}
 \author{The Axiom Team}
Index: src/doc/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/doc/Makefile.pamphlet,v
retrieving revision 1.7
diff -u -d -r1.7 Makefile.pamphlet
--- src/doc/Makefile.pamphlet	27 Jun 2004 15:00:59 -0000	1.7
+++ src/doc/Makefile.pamphlet	29 Oct 2004 13:49:50 -0000
@@ -105,6 +105,7 @@
 
 clean:
 	@echo 4 cleaning ${SRC}/doc
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/doc/axiom.bib.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/doc/axiom.bib.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 axiom.bib.pamphlet
--- src/doc/axiom.bib.pamphlet	28 Aug 2003 12:28:30 -0000	1.1
+++ src/doc/axiom.bib.pamphlet	29 Oct 2004 13:50:47 -0000
@@ -12231,7 +12231,7 @@
 \subsection{Makefile}
 <<Makefile>>=
 @MISC{Makefile,
-   path=./mnt/linux/bin/Makefile.pamphlet
+   path=./mnt/${SYS}/bin/Makefile.pamphlet
 }
 
 @
Index: src/etc/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/etc/Makefile.pamphlet,v
retrieving revision 1.6
diff -u -d -r1.6 Makefile.pamphlet
--- src/etc/Makefile.pamphlet	27 Jun 2004 15:00:59 -0000	1.6
+++ src/etc/Makefile.pamphlet	29 Oct 2004 13:50:49 -0000
@@ -91,6 +91,7 @@
 	@rm -rf ${MID}
 	@echo 4 cleaning ${DOC}
 	@rm -rf ${DOC}
+	@rm -f Makefile Makefile.dvi
 
 @
 \eject
Index: src/etc/axiom
===================================================================
RCS file: /cvsroot/axiom/axiom/src/etc/axiom,v
retrieving revision 1.3
diff -u -d -r1.3 axiom
--- src/etc/axiom	7 Feb 2004 03:24:24 -0000	1.3
+++ src/etc/axiom	29 Oct 2004 13:50:49 -0000
@@ -1,8 +1,10 @@
-export AXIOM
 
 system=`uname -s`
 
 case "$system" in
+    FreeBSD) clef -e $AXIOM/bin/AXIOMsys "$@"
+        ;;
+    
     Linux) clef -e $AXIOM/bin/AXIOMsys "$@"
         ;;
     
Index: src/graph/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/graph/Makefile.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 Makefile.pamphlet
--- src/graph/Makefile.pamphlet	27 Jun 2004 15:00:59 -0000	1.1
+++ src/graph/Makefile.pamphlet	29 Oct 2004 13:50:51 -0000
@@ -414,7 +414,7 @@
 
 ${DOC}/viewports:
 	@ echo 25 making ${DOC}/viewports from ${IN}/viewports 
-	@ cp -pr ${IN}/viewports ${DOC}
+	@ echo XXXXXX cp -pr ${IN}/viewports ${DOC}
 
 <<viewmandir>>
 <<Gdrawsdir>>
Index: src/graph/viewman/cleanup.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/graph/viewman/cleanup.c.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 cleanup.c.pamphlet
--- src/graph/viewman/cleanup.c.pamphlet	27 Jun 2004 15:01:22 -0000	1.1
+++ src/graph/viewman/cleanup.c.pamphlet	29 Oct 2004 13:50:53 -0000
@@ -53,7 +53,9 @@
 #include <stdlib.h>
 #include <unistd.h>
 #include <stdio.h>
+#if !defined(FREEBSDplatform) && !defined(MACOSXplatform)
 #include <malloc.h>
+#endif
 #include <assert.h>
 #include <signal.h>
 #include <sys/wait.h>
Index: src/graph/viewman/sselect.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/graph/viewman/sselect.c.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 sselect.c.pamphlet
--- src/graph/viewman/sselect.c.pamphlet	27 Jun 2004 15:01:24 -0000	1.1
+++ src/graph/viewman/sselect.c.pamphlet	29 Oct 2004 13:50:53 -0000
@@ -104,7 +104,11 @@
 	/* flush(spadSock); */
         /* send_int(spadSock,1);   acknowledge to spad */
         checkClosedChild = no;
+#if defined(FREEBSDplatform) || defined(MACOSXplatform)
+        bsdSignal(SIGCHLD,endChild,DontRestartSystemCalls);
+#else
         bsdSignal(SIGCLD,endChild,DontRestartSystemCalls);
+#endif
       }
     }
     ret_val = select(n, (void *)rd, (void *)wr, (void *)ex, (void *)timeout);
Index: src/graph/viewman/viewman.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/graph/viewman/viewman.c.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 viewman.c.pamphlet
--- src/graph/viewman/viewman.c.pamphlet	27 Jun 2004 15:01:24 -0000	1.1
+++ src/graph/viewman/viewman.c.pamphlet	29 Oct 2004 13:50:55 -0000
@@ -116,7 +116,11 @@
   int keepLooking,code;
   
   bsdSignal(SIGPIPE,brokenPipe,DontRestartSystemCalls);
+#if defined(FREEBSDplatform) || defined(MACOSXplatform)
+  bsdSignal(SIGCHLD,endChild,RestartSystemCalls);
+#else
   bsdSignal(SIGCLD,endChild,RestartSystemCalls);
+#endif
   bsdSignal(SIGTERM,goodbye,DontRestartSystemCalls);
   
   /* Connect up to AXIOM server */
Index: src/include/useproto.h
===================================================================
RCS file: /cvsroot/axiom/axiom/src/include/useproto.h,v
retrieving revision 1.3
diff -u -d -r1.3 useproto.h
--- src/include/useproto.h	27 Oct 2004 01:10:41 -0000	1.3
+++ src/include/useproto.h	29 Oct 2004 13:50:55 -0000
@@ -34,7 +34,7 @@
 #ifndef _USEPROTO_H_
 #define _USEPROTO_H_ 1
 
-#if defined(SGIplatform)||defined(LINUXplatform)||defined(HPplatform) ||defined(RIOSplatform) ||defined(RIOS4platform) || defined(SUN4OS5platform) || defined(MACOSXplatform)
+#if defined(SGIplatform) || defined(LINUXplatform) || defined(HPplatform) || defined(RIOSplatform) || defined(RIOS4platform) || defined(SUN4OS5platform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
 #ifdef _NO_PROTO
 #undef _NO_PROTO
 #endif
Index: src/input/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/input/Makefile.pamphlet,v
retrieving revision 1.10
diff -u -d -r1.10 Makefile.pamphlet
--- src/input/Makefile.pamphlet	15 Jul 2004 03:45:11 -0000	1.10
+++ src/input/Makefile.pamphlet	29 Oct 2004 13:51:28 -0000
@@ -6880,6 +6880,7 @@
 	@rm -rf ${MID}
 	@echo 7 cleaning ${OUT}
 	@rm -rf ${OUT}
+	@rm -f Makefile Makefile.dvi
 
 <<algaggr>>
 <<algbrbf>>
Index: src/interp/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/Makefile.pamphlet,v
retrieving revision 1.11
diff -u -d -r1.11 Makefile.pamphlet
--- src/interp/Makefile.pamphlet	27 Jun 2004 15:01:27 -0000	1.11
+++ src/interp/Makefile.pamphlet	29 Oct 2004 13:52:07 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{../../src/scripts/tex/axiom}
+\usepackage{axiom}
 \begin{document}
 \title{\$SPAD/src/interp Makefile}
 \author{Timothy Daly}
@@ -616,8 +616,29 @@
 	@ echo '(load "${OUT}/c-util")' >> ${OUT}/makedep.lisp
 	@ echo '(unless (probe-file "${OUT}/g-util.${O}") (compile-file "${OUT}/g-util.${LISP}" :output-file "${OUT}/g-util.${O}"))' >> ${OUT}/makedep.lisp
 	@ echo '(load "${OUT}/g-util")' >> ${OUT}/makedep.lisp
-	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))' | ${LISPSYS})
+	@ (cd ${OBJ}/${SYS}/bin ; \
+	   echo '(progn \
+		(setq si::*collect-binary-modules* t) \
+		(load "${OUT}/makedep.lisp") \
+		(compiler::link \
+			(remove-duplicates si::*binary-modules* :test (quote equal)) \
+			"$(DEPSYS)" \
+			(format nil "\
+				(setq si::*collect-binary-modules* t) \
+				(let ((si::*load-path* (cons ~S si::*load-path*))\
+					(si::*load-types* ~S))\
+					(compiler::emit-fn t))\
+				(load \"$(OUT)/makedep.lisp\")\
+				(gbc t)\
+				(when si::*binary-modules* \
+					(error si::*binary-modules*))\
+				(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+				(gbc t)\
+				(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+				(setq compiler::*default-system-p* t)\
+			" si::*system-directory* (quote (list ".lsp")))\
+			"" \
+			nil))' | $(LISPSYS))
 	@ echo 4 ${DEPSYS} created
 
 @
@@ -670,7 +691,33 @@
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' >> ${OUT}/makeint.lisp
 	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	  echo '(progn \
+			(setq si::*collect-binary-modules* t)\
+			(setq x si::*system-directory*)\
+			(load "${OUT}/makeint.lisp")\
+			(setq si::*system-directory* x)\
+			(unintern (quote x))\
+			(compiler::link \
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(SAVESYS)" \
+				(format nil "\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+						(si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					 (setq si::*collect-binary-modules* t)\
+					 (setq x si::*system-directory*)\
+					 (load \"$(OUT)/makeint.lisp\")\
+					 (setq si::*system-directory* x)\
+					 (unintern (quote x))\
+					 (when si::*binary-modules* \
+						(error si::*binary-modules*))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+			"$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" \
+			nil))' | $(LISPSYS))
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
@@ -6262,6 +6309,7 @@
 <<Makefile.dvi (DOC from IN)>>=
 ${DOC}/Makefile.dvi: ${IN}/Makefile.pamphlet ${DOC}/axiom.sty
 	@echo 613 making ${DOC}/Makefile.dvi from ${IN}/Makefile.pamphlet
+	@touch ${IN}/Makefile.dvi
 	@cp ${IN}/Makefile.dvi ${DOC}
 
 @
@@ -7112,6 +7160,9 @@
 <<document>>
 
 <<axiom.sty (OUT from IN)>>
+
+clean:
+
 @
 pp
 \eject
Index: src/interp/debugsys.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/debugsys.lisp.pamphlet,v
retrieving revision 1.2
diff -u -d -r1.2 debugsys.lisp.pamphlet
--- src/interp/debugsys.lisp.pamphlet	24 May 2004 22:53:51 -0000	1.2
+++ src/interp/debugsys.lisp.pamphlet	29 Oct 2004 13:52:09 -0000
@@ -79,7 +79,7 @@
       (thesymb "/int/interp/buildom.clisp")
       (thesymb "/int/interp/cattable.clisp")
       (thesymb "/int/interp/cformat.clisp")
-      (thesymb "/obj/linux/interp/cfuns.o")
+      (thesymb "/obj/${SYS}/interp/cfuns.o")
       (thesymb "/int/interp/clam.clisp")
       (thesymb "/int/interp/clammed.clisp")
       (thesymb "/int/interp/comp.lisp")
@@ -152,7 +152,7 @@
       (thesymb "/int/interp/sfsfun.clisp")
       (thesymb "/int/interp/simpbool.clisp")
       (thesymb "/int/interp/slam.clisp")
-      (thesymb "/obj/linux/interp/sockio.o")
+      (thesymb "/obj/${SYS}/interp/sockio.o")
       (thesymb "/int/interp/spad.lisp")
       (thesymb "/int/interp/spaderror.lisp")
       (thesymb "/int/interp/template.clisp")
@@ -232,13 +232,13 @@
    ())
   (list 
    (thesymb "/int/interp/ax.clisp"))
-  "/mnt/linux"
+  "/mnt/${SYS}"
   "/lsp"
   "/src"
   "/int"
   "/obj"
   "/mnt"
-  "linux")
+  "${SYS}")
 (in-package "SCRATCHPAD-COMPILER")
 (boot::set-restart-hook)
 (in-package "BOOT")
@@ -247,7 +247,7 @@
 (load (user::thepath "/int/interp/obey.lsp"))
 ;(si::multiply-bignum-stack 10)
 (si::gbc-time 0)
-(setq si::*system-directory* (user::thepath "/mnt/linux/bin/"))
+(setq si::*system-directory* (user::thepath "/mnt/${SYS}/bin/"))
 (gbc t)
 
 @
Index: src/interp/nlib.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/nlib.lisp.pamphlet,v
retrieving revision 1.3
diff -u -d -r1.3 nlib.lisp.pamphlet
--- src/interp/nlib.lisp.pamphlet	24 May 2004 22:53:55 -0000	1.3
+++ src/interp/nlib.lisp.pamphlet	29 Oct 2004 13:52:12 -0000
@@ -295,7 +295,15 @@
 (defun rpackfile (filespec)
   (setq filespec (make-filename filespec))
   (if (string= (pathname-type filespec) "NRLIB")
-      (recompile-lib-file-if-necessary (concat (namestring filespec) "/code.lsp"))
+      (let* ((base (pathname-name filespec))
+	     (code (concatenate 'string (namestring filespec) "/code.lsp"))
+	     (temp (concatenate 'string (namestring filespec) "/" base ".lsp"))
+	     (o (make-pathname :type "o")))
+	(si::system (format nil "cp ~S ~S" code temp))
+	(recompile-lib-file-if-necessary temp)
+	(si::system (format nil "mv ~S ~S~%" 
+			    (namestring (merge-pathnames o temp))
+			    (namestring (merge-pathnames o code)))))
   ;; only pack non libraries to avoid lucid file handling problems    
     (let* ((rstream (rdefiostream (list (cons 'file filespec) (cons 'mode 'input))))
 	   (nstream nil)
Index: src/interp/util.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/util.lisp.pamphlet,v
retrieving revision 1.5
diff -u -d -r1.5 util.lisp.pamphlet
--- src/interp/util.lisp.pamphlet	24 May 2004 22:54:05 -0000	1.5
+++ src/interp/util.lisp.pamphlet	29 Oct 2004 13:52:20 -0000
@@ -77,6 +77,16 @@
 ;     (compile-file collectfn))
 ;   (load collectfn)
 ;   (compiler::emit-fn t)
+;
+;  (let ((collectfn (concatenate 'string si::*system-directory* "../cmpnew/gcl_collectfn.lsp"))
+;       (collectfn1 (concatenate 'string obj "/" sys "/interp/collectfn")))
+;   (with-open-file (st collectfn :direction :input)
+;      (with-open-file (st1 (concatenate 'string collectfn1 ".lsp") :direction :output)
+;       (si::copy-stream st st1)))
+;   (unless (probe-file (concatenate 'string collectfn1 ".o"))
+;     (compile-file collectfn1))
+;   (load collectfn1)
+;
    (mapcar
      #'load
      (directory (concatenate 'string obj "/" sys "/interp/*.fn")))
@@ -813,7 +823,7 @@
 This function will do that. A correct call looks like:
 \begin{verbatim}
 (in-package "BOOT")
-(recompile-all-libs "/spad/mnt/linux/algebra")
+(recompile-all-libs "/spad/mnt/${SYS}/algebra")
 \end{verbatim}
 <<recompile-all-libs>>=
 (defun recompile-all-libs (dir)
@@ -838,11 +848,11 @@
 Note that it will build a pathname from the current {\bf AXIOM}
 shell variable. So if the {\bf AXIOM} shell variable had the value
 \begin{verbatim}
-/spad/mnt/linux
+/spad/mnt/${SYS}
 \end{verbatim}
 then the wildcard expands to
 \begin{verbatim}
-/spad/mnt/linux/nalg/*.spad
+/spad/mnt/${SYS}/nalg/*.spad
 \end{verbatim}
 and all of the matching files would be recompiled.
 <<recompile-all-algebra-files>>=
@@ -879,7 +889,7 @@
 before compiling this file. A correct call looks like:
 \begin{verbatim}
 (in-package "BOOT")
-(reroot "/spad/mnt/linux")
+(reroot "/spad/mnt/${SYS}")
 \end{verbatim}
 <<reroot>>=
 (defun reroot (dir)
Index: src/lib/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/Makefile.pamphlet,v
retrieving revision 1.8
diff -u -d -r1.8 Makefile.pamphlet
--- src/lib/Makefile.pamphlet	27 Jun 2004 15:01:39 -0000	1.8
+++ src/lib/Makefile.pamphlet	29 Oct 2004 13:52:23 -0000
@@ -490,10 +490,15 @@
 clean:
 	@echo 70 cleaning ${IN}
 	@rm -rf ${MID} ${OUT} ${DOCINT} ${DOCMNT}
+	@rm -f Makefile Makefile.dvi
 
 @
 \subsection{Makefile documentation}
 <<Makefile.dvi>>=
+${IN}/Makefile.dvi:
+	@echo 71a Bodging ${IN}/Makefile.dvi
+	@touch ${IN}/Makefile.dvi
+
 ${DOCMNT}/Makefile.dvi: ${IN}/Makefile.dvi
 	@echo 71 making ${DOCMNT}/Makefile.dvi from ${IN}/Makefile.dvi
 	@cp ${IN}/Makefile.dvi ${DOCMNT}/Makefile.dvi 
Index: src/lib/XDither.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/XDither.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 XDither.c.pamphlet
--- src/lib/XDither.c.pamphlet	27 Jun 2004 15:01:41 -0000	1.4
+++ src/lib/XDither.c.pamphlet	29 Oct 2004 13:52:25 -0000
@@ -51,7 +51,9 @@
 
 #include <stdio.h>
 #include <stdlib.h>
+#if !defined(FREEBSDplatform) && !defined(MACOSXplatform)
 #include <malloc.h>
+#endif
 
 #include <X11/Xlib.h>
 #include <X11/Xutil.h>
Index: src/lib/XShade.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/XShade.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 XShade.c.pamphlet
--- src/lib/XShade.c.pamphlet	27 Jun 2004 15:01:42 -0000	1.4
+++ src/lib/XShade.c.pamphlet	29 Oct 2004 13:52:25 -0000
@@ -50,8 +50,10 @@
 #include "useproto.h"
 
 #include <stdio.h>
-#include <malloc.h>
 #include <stdlib.h>
+#if !defined(FREEBSDplatform) && !defined(MACOSXplatform)
+#include <malloc.h>
+#endif
 
 #include <X11/Xlib.h>
 #include <X11/Xutil.h>
Index: src/lib/bsdsignal.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/bsdsignal.c.pamphlet,v
retrieving revision 1.7
diff -u -d -r1.7 bsdsignal.c.pamphlet
--- src/lib/bsdsignal.c.pamphlet	27 Oct 2004 01:10:41 -0000	1.7
+++ src/lib/bsdsignal.c.pamphlet	29 Oct 2004 13:52:25 -0000
@@ -9,13 +9,6 @@
 \eject
 \tableofcontents
 \eject
-\section{MAC OSX platform change}
-We needed to change [[SIGCLD]] to [[SIGCHLD]] for the [[MAC OSX]] platform
-and we need to create a new platform variable. This change is made to 
-propogate that platform variable.
-<<mac osx platform change>>=
-#if defined(LINUXplatform) || defined (ALPHAplatform)|| defined(RIOSplatform) || defined(SUN4OS5platform) ||defined(SGIplatform) ||defined(HP10platform) || defined(MACOSXplatform)
-@
 \section{License}
 <<license>>=
 /*
@@ -74,7 +67,7 @@
   struct sigaction in,out;
   in.sa_handler = action;
   /* handler is reinstalled - calls are restarted if restartSystemCall */
-<<mac osx platform change>>
+#if defined(LINUXplatform) || defined (ALPHAplatform) || defined(RIOSplatform) || defined(SUN4OS5platform) || defined(SGIplatform) || defined(HP10platform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
   if(restartSystemCall) in.sa_flags = SA_RESTART;
   else in.sa_flags = 0;
 #elif defined(SUNplatform)
Index: src/lib/cfuns-c.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/cfuns-c.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 cfuns-c.c.pamphlet
--- src/lib/cfuns-c.c.pamphlet	27 Jun 2004 15:01:43 -0000	1.4
+++ src/lib/cfuns-c.c.pamphlet	29 Oct 2004 13:52:27 -0000
@@ -52,9 +52,11 @@
 #include <unistd.h>
 #include <stdlib.h>
 #include <string.h>
-#include <malloc.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#if !defined(FREEBSDplatform) && !defined(MACOSXplatform)
+#include <malloc.h>
+#endif
 
 #include "cfuns-c.H1"
 
Index: src/lib/fnct_key.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/fnct_key.c.pamphlet,v
retrieving revision 1.5
diff -u -d -r1.5 fnct_key.c.pamphlet
--- src/lib/fnct_key.c.pamphlet	27 Oct 2004 01:10:41 -0000	1.5
+++ src/lib/fnct_key.c.pamphlet	29 Oct 2004 13:52:27 -0000
@@ -9,18 +9,6 @@
 \eject
 \tableofcontents
 \eject
-\section{MAC OSX port}
-On the MAC OSX the signal [[SIGCLD]] has been renamed to [[SIGCHLD]].
-In order to handle this change we need to ensure that the platform
-variable is set properly and that the platform variable is changed
-everywhere.
-<<mac os signal rename>>=
-#if defined(MACOSXplatform)
-        bsdSignal(SIGCHLD, null_fnct,RestartSystemCalls);
-#else
-        bsdSignal(SIGCLD, null_fnct,RestartSystemCalls);
-#endif
-@
 \section{License}
 <<license>>=
 /*
@@ -364,7 +352,11 @@
                 close(fd);
             }
         }
-<<mac os signal rename>>
+#if defined(FREEBSDplatform) || defined(MACOSXplatform)
+        bsdSignal(SIGCHLD, null_fnct, RestartSystemCalls);
+#else
+        bsdSignal(SIGCLD, null_fnct, RestartSystemCalls);
+#endif
         switch (id = fork()) {
           case -1:
             perror("Special key");
Index: src/lib/openpty.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/openpty.c.pamphlet,v
retrieving revision 1.8
diff -u -d -r1.8 openpty.c.pamphlet
--- src/lib/openpty.c.pamphlet	27 Oct 2004 01:10:41 -0000	1.8
+++ src/lib/openpty.c.pamphlet	29 Oct 2004 13:52:29 -0000
@@ -9,16 +9,6 @@
 \eject
 \tableofcontents
 \eject
-\section{MAC OSX platform changes}
-Since we have no other information we are adding the [[MACOSXplatform]] variable
-to the list everywhere we find [[LINUXplatform]]. This may not be correct but
-we have no way to know yet.
-<<mac osx platform change 1>>=
-#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(MACOSXplatform)
-@
-<<mac osx platform change 2>>=
-#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform)
-@
 \section{License}
 <<license>>=
 /*
@@ -33,7 +23,7 @@
       notice, this list of conditions and the following disclaimer.
 
     - Redistributions in binary form must reproduce the above copyright
-     notice, this list of conditions and the following disclaimer in
+      notice, this list of conditions and the following disclaimer in
       the documentation and/or other materials provided with the
       distribution.
 
@@ -102,7 +92,7 @@
 #endif
 
 {
-#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) 
+#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) || defined(AIX370platform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
   int looking = 1, i;
   int oflag = O_RDWR;                  /* flag for opening the pty */
   
@@ -145,7 +135,7 @@
   return(fdm);
 #endif
 
-<<mac osx platform change 1>>
+#if defined(SUN4OS5platform) || defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
 extern int grantpt(int);
 extern int unlockpt(int);
 extern char* ptsname(int);
@@ -214,7 +204,7 @@
 	sprintf(serv, "/dev/ttyp%02x", channelNo);
 	channelNo++;
 #endif
-<<mac osx platform change 2>>
+#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
 	static int channelNo = 0;
 	static char group[] = "pqrstuvwxyzPQRST";
 	static int groupNo = 0;
Index: src/lib/pixmap.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/pixmap.c.pamphlet,v
retrieving revision 1.5
diff -u -d -r1.5 pixmap.c.pamphlet
--- src/lib/pixmap.c.pamphlet	27 Oct 2004 01:10:41 -0000	1.5
+++ src/lib/pixmap.c.pamphlet	29 Oct 2004 13:52:31 -0000
@@ -369,8 +369,7 @@
 write_pixmap_file(Display *dsp, int scr, char  *fn, Window wid, int x, int y, int width,int height)
 #endif
 {
-  XpmAttributes attr;
-  XImage *xi,*xireturn;
+  XImage *xi;
   int status;
   
   /* reads image structure in ZPixmap format */
Index: src/lib/wct.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/wct.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 wct.c.pamphlet
--- src/lib/wct.c.pamphlet	27 Jun 2004 15:01:44 -0000	1.4
+++ src/lib/wct.c.pamphlet	29 Oct 2004 13:52:33 -0000
@@ -287,7 +287,7 @@
   printTime((long *)&(pwct->ftime));
   cc = skimString(pwct->fimage, pwct->fsize, NHEAD, NTAIL);
   printf("%s", "            " + (cc - (NHEAD + NTAIL)));
-  printf(" [%d w, %d c]", pwct->wordc, pwct->fsize);
+  printf(" [%d w, %ld c]", pwct->wordc, (long)pwct->fsize);
   printf("\n");
 
 #ifdef SHOW_WORDS
Index: src/scripts/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/scripts/Makefile.pamphlet,v
retrieving revision 1.2
diff -u -d -r1.2 Makefile.pamphlet
--- src/scripts/Makefile.pamphlet	27 Jun 2004 15:01:44 -0000	1.2
+++ src/scripts/Makefile.pamphlet	29 Oct 2004 13:52:33 -0000
@@ -19,6 +19,10 @@
 	@cp -pr * ${OUT}
 	@mkdir -p ${OUT}/tex
 	@rm -f ${OUT}/Makefile*
+
+clean:
+	@echo 2 cleaning ${SRC}/scripts
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/scripts/document
===================================================================
RCS file: /cvsroot/axiom/axiom/src/scripts/document,v
retrieving revision 1.3
diff -u -d -r1.3 document
--- src/scripts/document	12 Nov 2003 11:16:15 -0000	1.3
+++ src/scripts/document	29 Oct 2004 13:52:33 -0000
@@ -1,12 +1,14 @@
 #!/bin/sh
+
 latex=`which latex`
 if [ "$latex" = "" ] ; then
   echo document ERROR You must install latex first
   exit 0
 fi
 
-tangle=$AXIOM/bin/lib/notangle
-weave=$AXIOM/bin/lib/noweave
+tangle=notangle
+weave=noweave
+
 if [ "$#" = "3" ]; then
  REDIRECT=$2
  FILE=`basename $3 .pamphlet`
Index: src/share/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/share/Makefile.pamphlet,v
retrieving revision 1.3
diff -u -d -r1.3 Makefile.pamphlet
--- src/share/Makefile.pamphlet	27 Jun 2004 15:01:46 -0000	1.3
+++ src/share/Makefile.pamphlet	29 Oct 2004 13:52:33 -0000
@@ -31,6 +31,9 @@
 	@ echo 2 finished ${IN}
 
 <<util.ht>>
+
+clean:
+
 @
 \eject
 \begin{thebibliography}{99}


\start
Date: Sat, 30 Oct 2004 10:12:53 +0100
From: Mark Murray
To: list
Subject: FreeBSD patches

This is a multipart MIME message.

--==_Exmh_-7609217490

Hi

Sorry if this is a repeat. I sent this lot yesterday, and didn't see it
on the list.

This set of patches does quite a bit. It has Makefile.MACOSX and
Makefile.freebsd enhancements. It also has some path changes to things
like tangle(1), which in FreeBSD's case is preinstalled by the ports
system. FreeBSD also uses a preinstalled GCL. Some of this will no doubt
not be of universal appeal, and I'm happy to keep them as local diffs.

I have attempted to clean up the MACOSX stuff a bit. Lots of your
changes that were marked as MACOSX requirements are actually BSD/POSIX,
and I've tried to make the changes as universal as possible. I don't
have a MACOSX box, but I've done my best to make the changes sane.

Note that MACOS/BSD/POSIX do not have an malloc.h include. It is an
error to assume that the kernel malloc.h in sys/ is a substitute. It bst
this achieves nothing, and at worst it will pollute your namespace with
erronious malloc()/free() prototypes. MACOS/BSD/POSIX get their malloc()
definition from stdlib.h.

I haven't looked too hard at the headers, but I have seen that the
order that some of them are included in is rather strange. For example,
it makes little sense to #include <sys/types.h> after other standard
headers, because those headers often depend on <sys/types.h>. You can
often get away with it, but it can be dodgy.

The Axiom library code gets intalled in a place that is way off the
usual ${PATH}, so I've modified the install to create an "axiom"
script in ${PREFIX}/bin, where ${PREFIX} is usually /usr/local, but
can be reset to anything the sysadmin wants. I've also created an
"AXIOMsys" script in ${PREFIX}/bin that launches the binary of the same
name without having to get the user to set all sorts of environment
variables. This makes TeXmacs work in Axiom mode with no extra work.

I've fixed some warnings, and I've tried to fix "make clean" so that it
removes more generated files, mainly "Makefile" and "Makefile.dvi".

Much of the clever stuff to make the external GCL work is done by Camm,
so if there are lisp-related questions, please ask him.

My offer of a FreeBSD box to test this stuff on still stands.

Thanks!

M
--
Mark Murray
iumop ap!sdn w,I idlaH


--==_Exmh_-7609217490

Index: Makefile
===================================================================
RCS file: /cvsroot/axiom/axiom/Makefile,v
retrieving revision 1.12
diff -u -d -r1.12 Makefile
--- Makefile	22 Aug 2004 09:19:32 -0000	1.12
+++ Makefile	29 Oct 2004 13:46:12 -0000
@@ -9,7 +9,8 @@
 #GCLVERSION=gcl-2.6.2
 #GCLVERSION=gcl-2.6.2a
 #GCLVERSION=gcl-2.6.3
-GCLVERSION=gcl-2.6.5
+#GCLVERSION=gcl-2.6.5
+GCLVERSION=gcl-system
 AWK=gawk
 GCLDIR=${LSP}/${GCLVERSION}
 SRC=${SPD}/src
@@ -22,8 +23,9 @@
 INC=${SPD}/src/include
 CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
 INSTALL=/usr/local/axiom
-COMMAND=${INSTALL}/mnt/${SYS}/bin/axiom
-TANGLE=${SPADBIN}/lib/notangle
+COMMAND=${PREFIX}/bin/axiom
+COMMAND1=${PREFIX}/bin/AXIOMsys
+TANGLE=notangle
 
 NOISE="-o ${TMP}/trace"
 
@@ -71,6 +73,7 @@
 	@mkdir -p ${OBJ}/noweb
 	@mkdir -p ${TMP}
 	@mkdir -p ${MNT}/${SYS}/bin/lib
+ifneq "${SYS}" "freebsd"
 	@( cd ${OBJ}/noweb ; \
 	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
 	cd ${OBJ}/noweb/src ; \
@@ -82,6 +85,7 @@
 	${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/${SYS}/bin/lib \
                 MAN=${MNT}/${SYS}/bin/man \
                 TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
+endif
 	@echo The file marks the fact that noweb has been made > noweb
 
 nowebclean:
@@ -98,9 +102,24 @@
 	@echo 78 installing Axiom in ${INSTALL}
 	@mkdir -p ${INSTALL}
 	@cp -pr ${MNT} ${INSTALL}
-	@echo AXIOM=${INSTALL}/mnt/${SYS} >${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND}
+	@echo export AXIOM >>${COMMAND}
+	@echo DAASE='$${AXIOM}' >>${COMMAND}
+	@echo export DAASE >>${COMMAND}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND}
+	@echo export PATH >>${COMMAND}
 	@cat ${SRC}/etc/axiom >>${COMMAND}
 	@chmod +x ${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND1}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND1}
+	@echo export AXIOM >>${COMMAND1}
+	@echo DAASE='$${AXIOM}' >>${COMMAND1}
+	@echo export DAASE >>${COMMAND1}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND1}
+	@echo export PATH >>${COMMAND1}
+	@echo '$${AXIOM}/bin/AXIOMsys' '$$@' >>${COMMAND1}
+	@chmod +x ${COMMAND1}
 	@echo 79 Axiom installation finished.
 	@echo
 	@echo Please add $(shell dirname ${COMMAND}) to your PATH variable
@@ -123,5 +142,5 @@
 	@ ${ENV} $(MAKE) -f Makefile.${SYS} clean
 	@ rm -f noweb 
 	@ rm -f *~
-	@echo 9 finished system build on `date` | tee >lastBuildDate
+	@ rm -f Makefile.${SYS}
 
Index: Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/Makefile.pamphlet,v
retrieving revision 1.27
diff -u -d -r1.27 Makefile.pamphlet
--- Makefile.pamphlet	27 Oct 2004 01:10:41 -0000	1.27
+++ Makefile.pamphlet	29 Oct 2004 13:46:16 -0000
@@ -50,7 +50,7 @@
 	@ ${ENV} $(MAKE) -f Makefile.${SYS} clean
 	@ rm -f noweb 
 	@ rm -f *~
-	@echo 9 finished system build on `date` | tee >lastBuildDate
+	@ rm -f Makefile.${SYS}
 
 @
 
@@ -185,8 +185,9 @@
 INC=${SPD}/src/include
 CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
 INSTALL=/usr/local/axiom
-COMMAND=${INSTALL}/mnt/${SYS}/bin/axiom
-TANGLE=${SPADBIN}/lib/notangle
+COMMAND=${PREFIX}/bin/axiom
+COMMAND1=${PREFIX}/bin/AXIOMsys
+TANGLE=notangle
 
 NOISE="-o ${TMP}/trace"
 
@@ -268,6 +269,7 @@
 	@mkdir -p ${OBJ}/noweb
 	@mkdir -p ${TMP}
 	@mkdir -p ${MNT}/${SYS}/bin/lib
+ifneq "${SYS}" "freebsd"
 	@( cd ${OBJ}/noweb ; \
 	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
 	cd ${OBJ}/noweb/src ; \
@@ -279,6 +281,7 @@
 	${MAKE} BIN=${MNT}/${SYS}/bin/lib LIB=${MNT}/${SYS}/bin/lib \
                 MAN=${MNT}/${SYS}/bin/man \
                 TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
+endif
 	@echo The file marks the fact that noweb has been made > noweb
 
 nowebclean:
@@ -337,6 +340,9 @@
 libspadclean:
 	@echo 17 cleaning ${OBJ}/${SYS}/lib	
 	@rm -rf ${OBJ}/${SYS}/lib	
+	@( cd src ; ${SPADBIN}/document ${NOISE} Makefile )
+	@( cd src ; ${ENV} ${MAKE} clean )
+	@rm -f ${SPD}/src/Makefile ${SPD}/src/Makefile.dvi
 
 @
 
@@ -398,6 +404,7 @@
 	@rm -rf ${INT}/ccl
 	@rm -rf ${OBJ}/${SYS}/ccl
 	@rm -rf ${LSP}/gcldir
+	@rm -f ${LSP}/Makefile ${LSP}/Makefile.dvi
 
 @
 \subsection{install}
@@ -406,9 +413,24 @@
 	@echo 78 installing Axiom in ${INSTALL}
 	@mkdir -p ${INSTALL}
 	@cp -pr ${MNT} ${INSTALL}
-	@echo AXIOM=${INSTALL}/mnt/${SYS} >${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND}
+	@echo export AXIOM >>${COMMAND}
+	@echo DAASE='$${AXIOM}' >>${COMMAND}
+	@echo export DAASE >>${COMMAND}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND}
+	@echo export PATH >>${COMMAND}
 	@cat ${SRC}/etc/axiom >>${COMMAND}
 	@chmod +x ${COMMAND}
+	@echo '#!/bin/sh -' >${COMMAND1}
+	@echo AXIOM=${INSTALL}/mnt/${SYS} >>${COMMAND1}
+	@echo export AXIOM >>${COMMAND1}
+	@echo DAASE='$${AXIOM}' >>${COMMAND1}
+	@echo export DAASE >>${COMMAND1}
+	@echo PATH='$${PATH}':'$${AXIOM}/bin' >>${COMMAND1}
+	@echo export PATH >>${COMMAND1}
+	@echo '$${AXIOM}/bin/AXIOMsys' '$$@' >>${COMMAND1}
+	@chmod +x ${COMMAND1}
 	@echo 79 Axiom installation finished.
 	@echo
 	@echo Please add $(shell dirname ${COMMAND}) to your PATH variable
@@ -550,6 +572,11 @@
 optimizations for function calling in Axiom. This is handled automatically
 by changing this variable.
 
+If GCLVERSION is ``gcl-system'', then no GCL is not built locally,
+and it is assumed that the ``gcl'' command is available off the
+path. If this GCL is unsuitable for building Axiom, then very bad
+things will happen.
+
 NOTE WELL: IF YOU CHANGE THIS YOU SHOULD ERASE THE lsp/Makefile FILE.
 This will cause the build to remake the lsp/Makefile from the
 lsp/Makefile.pamphlet file and get the correct version. If you
@@ -563,7 +590,8 @@
 #GCLVERSION=gcl-2.6.2
 #GCLVERSION=gcl-2.6.2a
 #GCLVERSION=gcl-2.6.3
-GCLVERSION=gcl-2.6.5
+#GCLVERSION=gcl-2.6.5
+GCLVERSION=gcl-system
 @
 
 \subsection{Makefile.axposf1v3}
@@ -859,6 +887,60 @@
 <<clean>>
 
 @
+\subsection{Makefile.freebsd}
+On FreeBSD the POSIX [[SIGCHLD]] signal is used in preference to
+the SYSV [[SIGCLD]].
+
+Annoyingly enough it seems that GCL uses a default extension of
+.lsp rather than .lisp so we add the {\bf LISP} variable here. We
+need to depend on the default extension behavior because the system
+build will load either the interpreted or compiled form of a file
+depending on which is available. This varies at different stages
+of the build.
+
+Also FreeBSD does not include gawk or nawk by default so we change
+the [[AWK]] variable to use [[awk]].
+<<Makefile.freebsd>>=
+# System dependent Makefile for the freebsd platform
+# Platform variable
+PLF:=FREEBSDplatform
+# C compiler flags
+CCF:="-O -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11R6/include -I/usr/local/include"
+# Loader flags
+LDF:="-L/usr/X11R6/lib -L/usr/local/lib"
+# C compiler to use
+CC:=gcc 
+AWK=awk
+RANLIB=ranlib
+TOUCH=touch
+TAR=tar
+AXIOMXLROOT=${AXIOM}/compiler
+O=o
+BYE=bye
+LISP=lsp
+DAASE=${SRC}/share
+# where the libXpm.a library lives
+XLIB=/usr/X11R6/lib
+
+ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
+    TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE} \
+    LISP=${LISP} DAASE=${DAASE} XLIB=${XLIB} TANGLE=${TANGLE}
+
+all: rootdirs srcsetup lspdir srcdir
+	@echo 45 Makefile.freebsd called
+	@echo 46 Environment : ${ENV} 
+	@echo 47 finished system build on `date` | tee >lastBuildDate
+
+<<rootdirs>>
+<<noweb>>
+<<literate commands>>
+<<srcsetup>>
+<<src>>
+<<lsp>>
+<<document>>
+<<clean>>
+
+@
 \subsection{Makefile.linux}
 Annoyingly enough it seems that GCL uses a default extension of .lsp
 rather than .lisp so we add the {\bf LISP} variable here. We need to
@@ -1333,24 +1415,24 @@
 
 @
 \subsection{Makefile.MACOSX}
-On the MAC OSX someone decided (probably a BSDism) to rename the
-[[SIGCLD]] signal to [[SIGCHLD]]. In order to handle this in the 
-low level C socket code (in particular, in [[src/lib/fnct_key.c]])
-we change the platform variable to be [[MACOSXplatform]] and create
-this new stanza.
+On MAC OSX the POSIX [[SIGCHLD]] signal is used in preference to
+the SYSV [[SIGCLD]].
 
-Also it appears that the MAC OSX does not include gawk or nawk by 
-default so we change the [[AWK]] variable to use [[awk]].
+Annoyingly enough it seems that GCL uses a default extension of
+.lsp rather than .lisp so we add the {\bf LISP} variable here. We
+need to depend on the default extension behavior because the system
+build will load either the interpreted or compiled form of a file
+depending on which is available. This varies at different stages
+of the build.
 
-We need to add [[-I/usr/include/sys]] because [[malloc.h]] has been
-moved on this platform.
+Also it appears that MAC OSX does not include gawk or nawk by default
+so we change the [[AWK]] variable to use [[awk]].
 <<Makefile.MACOSX>>=
 # System dependent Makefile for the MAC OSX platform
 # Platform variable
 PLF:=MACOSXplatform
 # C compiler flags
-CCF:="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include \
-     -I/usr/include/sys"
+CCF:="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -I/usr/X11/include"
 #CCF:=-g -fno-strength-reduce -Wall -D_GNU_SOURCE  -D${PLF} -I/usr/X11/include
 # Loader flags
 LDF:= -L/usr/X11R6/lib 
@@ -1395,7 +1477,5 @@
 Bath BA2 5QR UK Tel. +44-1225-837430 
 {\bf http://www.codemist.co.uk}
 \bibitem{4} \$SPAD/zips/noweb-2.10a.tgz, the noweb source tree
-\bibitem{5} \$SPAD/zips/advi-1.2.0.tar.gz, the advi source tree
 \end{thebibliography}
 \end{document}
-
Index: lsp/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/lsp/Makefile.pamphlet,v
retrieving revision 1.11
diff -u -d -r1.11 Makefile.pamphlet
--- lsp/Makefile.pamphlet	15 Oct 2004 23:58:22 -0000	1.11
+++ lsp/Makefile.pamphlet	29 Oct 2004 13:46:22 -0000
@@ -830,6 +830,39 @@
 	  echo 20 applying toploop patch to unixport/init_gcl.lsp ; \
 	  patch <${SPD}/zips/${GCLVERSION}.unixport.init_gcl.lsp.patch )
 @ 
+\subsection{GCL already installed}
+<<gcl-system>>=
+# locally installed GCL
+OUT=${OBJ}/${SYS}/bin
+
+all:
+	@echo 21 building ${LSP} ${GCLVERSION}
+
+gcldir: 
+	@echo 22 building for ${GCLVERSION}
+	echo '(compiler::link nil "${OUT}/lisp" (format nil "(progn (let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))(setq compiler::*default-system-p* t))" si::*system-directory* (quote (list ".lsp"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
+	@echo 23 finished gcl build on `date` | tee >gcldir
+
+ccldir: ${LSP}/ccl/Makefile
+	@echo 21 building CCL
+	@mkdir -p ${INT}/ccl
+	@mkdir -p ${OBJ}/${SYS}/ccl
+	@( cd ccl ; ${ENV} ${MAKE} )
+
+${LSP}/ccl/Makefile: ${LSP}/ccl/Makefile.pamphlet
+	@echo 22 making ${LSP}/ccl/Makefile from ${LSP}/ccl/Makefile.pamphlet
+	@( cd ccl ; ${SPADBIN}/document ${NOISE} Makefile )
+
+document:
+	@echo 23 making docs in ${LSP}
+	@mkdir -p ${INT}/doc/lsp/ccl
+	@( cd ccl ; ${ENV} ${MAKE} document )
+
+clean:
+	@echo 24 cleaning ${LSP}/ccl
+	@( cd ccl ; ${ENV} ${MAKE} clean )
+@
+\eject
 <<*>>=
 # gcl version 2.4.1
 OUT=${OBJ}/${SYS}/bin
Index: src/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/Makefile.pamphlet,v
retrieving revision 1.11
diff -u -d -r1.11 Makefile.pamphlet
--- src/Makefile.pamphlet	15 Jul 2004 03:45:11 -0000	1.11
+++ src/Makefile.pamphlet	29 Oct 2004 13:46:26 -0000
@@ -24,10 +24,15 @@
 
 <<environment>>=
 SETUP=scriptsdir libdir
-DIRS=bootdir interpdir sharedir algebradir inputdir etcdir clefdir docdir \
-     graphdir
+DIRSINITIAL=bootdir interpdir sharedir algebradir
+DIRSCOMPLETE=${DIRSINITIAL} inputdir etcdir clefdir docdir graphdir
+ifeq ($(PASS1),)
+DIRS=${DIRSCOMPLETE}
+else
+DIRS=${DIRSINITIAL}
+endif
 DOCS=scriptsdocument libdocument ${DIRS:dir=document} 
-CLNS=scriptsclean libclean ${DIRS:dir=clean} 
+CLNS=scriptsclean libclean ${DIRSCOMPLETE:dir=clean}
 
 @
 \subsection{The scripts directory}
@@ -55,6 +60,7 @@
 scriptsclean: ${SRC}/scripts/Makefile
 	@echo 4 cleaning ${SRC}/scripts
 	@( cd scripts ; ${ENV} ${MAKE} clean )
+	@rm -f ${SRC}/scripts/Makefile ${SRC}/scripts/Makefile.dvi
 
 
 @
@@ -79,6 +85,7 @@
 clefclean: ${SRC}/clef/Makefile
 	@echo 8 cleaning ${SRC}/clef
 	@( cd clef ; ${ENV} ${MAKE} clean )
+	@ rm -f ${SRC}/clef/Makefile ${SRC}/clef/Makefile.dvi
 
 
 @
@@ -105,6 +112,7 @@
 shareclean: ${SRC}/share/Makefile
 	@echo 12 cleaning ${SRC}/share
 	@( cd share ; ${ENV} ${MAKE} clean )
+	@rm -f ${SRC}/share/Makefile ${SRC}/share/Makefile.dvi
 
 
 @
@@ -163,6 +171,7 @@
 	@echo 20 cleaning ${SRC}/lib
 	@( cd lib ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/lib
+	@rm -f ${SRC}/input/Makefile ${SRC}/input/Makefile.dvi
 
 @
 \subsection{The boot directory}
@@ -196,6 +205,7 @@
 	@echo 24 cleaning ${SRC}/boot
 	@( cd boot ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/boot
+	@rm -f ${SRC}/boot/Makefile ${SRC}/boot/Makefile.dvi
 
 @
 \subsection{The interp directory}
@@ -229,6 +239,7 @@
 	@echo 28 cleaning ${SRC}/interp
 	@( cd interp ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/interp
+	@rm -f ${SRC}/interp/Makefile ${SRC}/interp/Makefile.dvi
 
 @
 \subsection{The algebra directory}
@@ -268,7 +279,7 @@
 	@echo 32 cleaning ${SRC}/algebra
 	@( cd algebra ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/algebra
-
+	@rm -f ${SRC}/algebra/Makefile ${SRC}/algebra/Makefile.dvi
 @
 \subsection{The input directory}
 The input directory contains code used for examples, regression
@@ -306,6 +317,7 @@
 	@echo 36 cleaning ${SRC}/input
 	@( cd input ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/input
+	@rm -f ${SRC}/input/Makefile ${SRC}/input/Makefile.dvi
 
 @
 \subsection{The etc directory}
@@ -335,6 +347,7 @@
 	@echo 40 cleaning ${SRC}/etc
 	@( cd etc ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/etc
+	@rm -f ${SRC}/etc/Makefile ${SRC}/etc/Makefile.dvi
 
 @
 \subsection{The doc directory}
@@ -360,6 +373,7 @@
 	@echo 44 cleaning ${SRC}/doc
 	@( cd doc ; ${ENV} ${MAKE} clean )
 	@rm -rf ${OBJ}/${SYS}/doc
+	@rm -f ${SRC}/doc/Makefile ${SRC}/doc/Makefile.dvi
 
 @
 \subsection{The graph directory}
@@ -385,6 +399,7 @@
 	@rm -rf ${INT}/graph
 	@rm -rf ${OBJ}/${SYS}/graph
 	@rm -rf ${MNT}/${SYS}/graph
+	@rm -f ${SRC}/graph/Makefile ${SRC}/graph/Makefile.dvi
 
 @
 \section{The Makefile}
@@ -422,7 +437,7 @@
 	@echo 50 making docs in ${SRC}
 
 clean: ${CLNS}
-	@echo 51 cleaning ${SRC}
+	@echo 51 cleaning ${SRC} ${CLNS}
 
 @
 \eject
Index: src/algebra/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/algebra/Makefile.pamphlet,v
retrieving revision 1.10
diff -u -d -r1.10 Makefile.pamphlet
--- src/algebra/Makefile.pamphlet	3 Jul 2004 19:06:29 -0000	1.10
+++ src/algebra/Makefile.pamphlet	29 Oct 2004 13:49:24 -0000
@@ -40940,6 +40940,8 @@
 
 <<axiom.sty (OUT from IN)>>
 
+clean:
+
 @
 \eject
 \begin{thebibliography}{99}
Index: src/booklets/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/booklets/Makefile.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 Makefile.pamphlet
--- src/booklets/Makefile.pamphlet	28 Aug 2003 12:15:28 -0000	1.1
+++ src/booklets/Makefile.pamphlet	29 Oct 2004 13:49:26 -0000
@@ -19,6 +19,7 @@
 clean:
 	@echo 2 cleaning ${INT}/docs/src/booklets
 	@rm -rf ${INT}/docs/src/booklets
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/booklets/Sorting.booklet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/booklets/Sorting.booklet,v
retrieving revision 1.1
diff -u -d -r1.1 Sorting.booklet
--- src/booklets/Sorting.booklet	28 Aug 2003 12:15:28 -0000	1.1
+++ src/booklets/Sorting.booklet	29 Oct 2004 13:49:40 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{/home/axiomgnu/new/mnt/linux/bin/tex/noweb}
+\usepackage{noweb}
 \begin{document}
 \title{Sorting Facilities}
 \author{Timothy Daly}
Index: src/boot/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/boot/Makefile.pamphlet,v
retrieving revision 1.6
diff -u -d -r1.6 Makefile.pamphlet
--- src/boot/Makefile.pamphlet	27 Jun 2004 15:00:58 -0000	1.6
+++ src/boot/Makefile.pamphlet	29 Oct 2004 13:49:47 -0000
@@ -1151,7 +1151,7 @@
 expansion. Adding a single quote symbol will break this expansion.
 
 <<environment>>= 
-CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
+CMD0=	(compiler::link (quote (${OBJS1})) "${SAVESYS}" (format nil "(let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t)) (when (fboundp (quote si::sgc-on)) (si::sgc-on t)) (setq compiler::*default-system-p* t)" si::*system-directory* (quote  (list ".lsp"))))
  
 @
 \subsection{boothdr.lisp \cite{1}}
@@ -1615,6 +1615,7 @@
 clean:
 	@echo 43 cleaning ${OUT}
 	@rm -f ${OUT}
+	@rm -f Makefile Makefile.dvi
 
 @
 \section{The Makefile}
Index: src/clef/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/clef/Makefile.pamphlet,v
retrieving revision 1.3
diff -u -d -r1.3 Makefile.pamphlet
--- src/clef/Makefile.pamphlet	27 Jun 2004 15:00:58 -0000	1.3
+++ src/clef/Makefile.pamphlet	29 Oct 2004 13:49:47 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{../../mnt/linux/bin/axiom}
+\usepackage{axiom}
 \begin{document}
 \title{\$SPAD/src/clef Makefile}
 \author{Timothy Daly}
@@ -57,6 +57,9 @@
 	@ ${CC} ${CLEFOBJS} -o ${OUT}/clef
 
 <<edible>>
+
+clean:
+
 @
 \eject
 \begin{thebibliography}{99}
Index: src/clef/edible.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/clef/edible.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 edible.c.pamphlet
--- src/clef/edible.c.pamphlet	30 Jul 2004 16:45:33 -0000	1.4
+++ src/clef/edible.c.pamphlet	29 Oct 2004 13:49:50 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{../../mnt/linux/bin/axiom}
+\usepackage{axiom}
 \begin{document}
 \title{\$SPAD/src/clef edible.c}
 \author{The Axiom Team}
Index: src/doc/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/doc/Makefile.pamphlet,v
retrieving revision 1.7
diff -u -d -r1.7 Makefile.pamphlet
--- src/doc/Makefile.pamphlet	27 Jun 2004 15:00:59 -0000	1.7
+++ src/doc/Makefile.pamphlet	29 Oct 2004 13:49:50 -0000
@@ -105,6 +105,7 @@
 
 clean:
 	@echo 4 cleaning ${SRC}/doc
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/doc/axiom.bib.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/doc/axiom.bib.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 axiom.bib.pamphlet
--- src/doc/axiom.bib.pamphlet	28 Aug 2003 12:28:30 -0000	1.1
+++ src/doc/axiom.bib.pamphlet	29 Oct 2004 13:50:47 -0000
@@ -12231,7 +12231,7 @@
 \subsection{Makefile}
 <<Makefile>>=
 @MISC{Makefile,
-   path=./mnt/linux/bin/Makefile.pamphlet
+   path=./mnt/${SYS}/bin/Makefile.pamphlet
 }
 
 @
Index: src/etc/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/etc/Makefile.pamphlet,v
retrieving revision 1.6
diff -u -d -r1.6 Makefile.pamphlet
--- src/etc/Makefile.pamphlet	27 Jun 2004 15:00:59 -0000	1.6
+++ src/etc/Makefile.pamphlet	29 Oct 2004 13:50:49 -0000
@@ -91,6 +91,7 @@
 	@rm -rf ${MID}
 	@echo 4 cleaning ${DOC}
 	@rm -rf ${DOC}
+	@rm -f Makefile Makefile.dvi
 
 @
 \eject
Index: src/etc/axiom
===================================================================
RCS file: /cvsroot/axiom/axiom/src/etc/axiom,v
retrieving revision 1.3
diff -u -d -r1.3 axiom
--- src/etc/axiom	7 Feb 2004 03:24:24 -0000	1.3
+++ src/etc/axiom	29 Oct 2004 13:50:49 -0000
@@ -1,8 +1,10 @@
-export AXIOM
 
 system=`uname -s`
 
 case "$system" in
+    FreeBSD) clef -e $AXIOM/bin/AXIOMsys "$@"
+        ;;
+    
     Linux) clef -e $AXIOM/bin/AXIOMsys "$@"
         ;;
     
Index: src/graph/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/graph/Makefile.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 Makefile.pamphlet
--- src/graph/Makefile.pamphlet	27 Jun 2004 15:00:59 -0000	1.1
+++ src/graph/Makefile.pamphlet	29 Oct 2004 13:50:51 -0000
@@ -414,7 +414,7 @@
 
 ${DOC}/viewports:
 	@ echo 25 making ${DOC}/viewports from ${IN}/viewports 
-	@ cp -pr ${IN}/viewports ${DOC}
+	@ echo XXXXXX cp -pr ${IN}/viewports ${DOC}
 
 <<viewmandir>>
 <<Gdrawsdir>>
Index: src/graph/viewman/cleanup.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/graph/viewman/cleanup.c.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 cleanup.c.pamphlet
--- src/graph/viewman/cleanup.c.pamphlet	27 Jun 2004 15:01:22 -0000	1.1
+++ src/graph/viewman/cleanup.c.pamphlet	29 Oct 2004 13:50:53 -0000
@@ -53,7 +53,9 @@
 #include <stdlib.h>
 #include <unistd.h>
 #include <stdio.h>
+#if !defined(FREEBSDplatform) && !defined(MACOSXplatform)
 #include <malloc.h>
+#endif
 #include <assert.h>
 #include <signal.h>
 #include <sys/wait.h>
Index: src/graph/viewman/sselect.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/graph/viewman/sselect.c.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 sselect.c.pamphlet
--- src/graph/viewman/sselect.c.pamphlet	27 Jun 2004 15:01:24 -0000	1.1
+++ src/graph/viewman/sselect.c.pamphlet	29 Oct 2004 13:50:53 -0000
@@ -104,7 +104,11 @@
 	/* flush(spadSock); */
         /* send_int(spadSock,1);   acknowledge to spad */
         checkClosedChild = no;
+#if defined(FREEBSDplatform) || defined(MACOSXplatform)
+        bsdSignal(SIGCHLD,endChild,DontRestartSystemCalls);
+#else
         bsdSignal(SIGCLD,endChild,DontRestartSystemCalls);
+#endif
       }
     }
     ret_val = select(n, (void *)rd, (void *)wr, (void *)ex, (void *)timeout);
Index: src/graph/viewman/viewman.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/graph/viewman/viewman.c.pamphlet,v
retrieving revision 1.1
diff -u -d -r1.1 viewman.c.pamphlet
--- src/graph/viewman/viewman.c.pamphlet	27 Jun 2004 15:01:24 -0000	1.1
+++ src/graph/viewman/viewman.c.pamphlet	29 Oct 2004 13:50:55 -0000
@@ -116,7 +116,11 @@
   int keepLooking,code;
   
   bsdSignal(SIGPIPE,brokenPipe,DontRestartSystemCalls);
+#if defined(FREEBSDplatform) || defined(MACOSXplatform)
+  bsdSignal(SIGCHLD,endChild,RestartSystemCalls);
+#else
   bsdSignal(SIGCLD,endChild,RestartSystemCalls);
+#endif
   bsdSignal(SIGTERM,goodbye,DontRestartSystemCalls);
   
   /* Connect up to AXIOM server */
Index: src/include/useproto.h
===================================================================
RCS file: /cvsroot/axiom/axiom/src/include/useproto.h,v
retrieving revision 1.3
diff -u -d -r1.3 useproto.h
--- src/include/useproto.h	27 Oct 2004 01:10:41 -0000	1.3
+++ src/include/useproto.h	29 Oct 2004 13:50:55 -0000
@@ -34,7 +34,7 @@
 #ifndef _USEPROTO_H_
 #define _USEPROTO_H_ 1
 
-#if defined(SGIplatform)||defined(LINUXplatform)||defined(HPplatform) ||defined(RIOSplatform) ||defined(RIOS4platform) || defined(SUN4OS5platform) || defined(MACOSXplatform)
+#if defined(SGIplatform) || defined(LINUXplatform) || defined(HPplatform) || defined(RIOSplatform) || defined(RIOS4platform) || defined(SUN4OS5platform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
 #ifdef _NO_PROTO
 #undef _NO_PROTO
 #endif
Index: src/input/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/input/Makefile.pamphlet,v
retrieving revision 1.10
diff -u -d -r1.10 Makefile.pamphlet
--- src/input/Makefile.pamphlet	15 Jul 2004 03:45:11 -0000	1.10
+++ src/input/Makefile.pamphlet	29 Oct 2004 13:51:28 -0000
@@ -6880,6 +6880,7 @@
 	@rm -rf ${MID}
 	@echo 7 cleaning ${OUT}
 	@rm -rf ${OUT}
+	@rm -f Makefile Makefile.dvi
 
 <<algaggr>>
 <<algbrbf>>
Index: src/interp/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/Makefile.pamphlet,v
retrieving revision 1.11
diff -u -d -r1.11 Makefile.pamphlet
--- src/interp/Makefile.pamphlet	27 Jun 2004 15:01:27 -0000	1.11
+++ src/interp/Makefile.pamphlet	29 Oct 2004 13:52:07 -0000
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{../../src/scripts/tex/axiom}
+\usepackage{axiom}
 \begin{document}
 \title{\$SPAD/src/interp Makefile}
 \author{Timothy Daly}
@@ -616,8 +616,29 @@
 	@ echo '(load "${OUT}/c-util")' >> ${OUT}/makedep.lisp
 	@ echo '(unless (probe-file "${OUT}/g-util.${O}") (compile-file "${OUT}/g-util.${LISP}" :output-file "${OUT}/g-util.${O}"))' >> ${OUT}/makedep.lisp
 	@ echo '(load "${OUT}/g-util")' >> ${OUT}/makedep.lisp
-	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))' | ${LISPSYS})
+	@ (cd ${OBJ}/${SYS}/bin ; \
+	   echo '(progn \
+		(setq si::*collect-binary-modules* t) \
+		(load "${OUT}/makedep.lisp") \
+		(compiler::link \
+			(remove-duplicates si::*binary-modules* :test (quote equal)) \
+			"$(DEPSYS)" \
+			(format nil "\
+				(setq si::*collect-binary-modules* t) \
+				(let ((si::*load-path* (cons ~S si::*load-path*))\
+					(si::*load-types* ~S))\
+					(compiler::emit-fn t))\
+				(load \"$(OUT)/makedep.lisp\")\
+				(gbc t)\
+				(when si::*binary-modules* \
+					(error si::*binary-modules*))\
+				(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+				(gbc t)\
+				(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+				(setq compiler::*default-system-p* t)\
+			" si::*system-directory* (quote (list ".lsp")))\
+			"" \
+			nil))' | $(LISPSYS))
 	@ echo 4 ${DEPSYS} created
 
 @
@@ -670,7 +691,33 @@
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' >> ${OUT}/makeint.lisp
 	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	  echo '(progn \
+			(setq si::*collect-binary-modules* t)\
+			(setq x si::*system-directory*)\
+			(load "${OUT}/makeint.lisp")\
+			(setq si::*system-directory* x)\
+			(unintern (quote x))\
+			(compiler::link \
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(SAVESYS)" \
+				(format nil "\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+						(si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					 (setq si::*collect-binary-modules* t)\
+					 (setq x si::*system-directory*)\
+					 (load \"$(OUT)/makeint.lisp\")\
+					 (setq si::*system-directory* x)\
+					 (unintern (quote x))\
+					 (when si::*binary-modules* \
+						(error si::*binary-modules*))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+			"$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" \
+			nil))' | $(LISPSYS))
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
@@ -6262,6 +6309,7 @@
 <<Makefile.dvi (DOC from IN)>>=
 ${DOC}/Makefile.dvi: ${IN}/Makefile.pamphlet ${DOC}/axiom.sty
 	@echo 613 making ${DOC}/Makefile.dvi from ${IN}/Makefile.pamphlet
+	@touch ${IN}/Makefile.dvi
 	@cp ${IN}/Makefile.dvi ${DOC}
 
 @
@@ -7112,6 +7160,9 @@
 <<document>>
 
 <<axiom.sty (OUT from IN)>>
+
+clean:
+
 @
 pp
 \eject
Index: src/interp/debugsys.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/debugsys.lisp.pamphlet,v
retrieving revision 1.2
diff -u -d -r1.2 debugsys.lisp.pamphlet
--- src/interp/debugsys.lisp.pamphlet	24 May 2004 22:53:51 -0000	1.2
+++ src/interp/debugsys.lisp.pamphlet	29 Oct 2004 13:52:09 -0000
@@ -79,7 +79,7 @@
       (thesymb "/int/interp/buildom.clisp")
       (thesymb "/int/interp/cattable.clisp")
       (thesymb "/int/interp/cformat.clisp")
-      (thesymb "/obj/linux/interp/cfuns.o")
+      (thesymb "/obj/${SYS}/interp/cfuns.o")
       (thesymb "/int/interp/clam.clisp")
       (thesymb "/int/interp/clammed.clisp")
       (thesymb "/int/interp/comp.lisp")
@@ -152,7 +152,7 @@
       (thesymb "/int/interp/sfsfun.clisp")
       (thesymb "/int/interp/simpbool.clisp")
       (thesymb "/int/interp/slam.clisp")
-      (thesymb "/obj/linux/interp/sockio.o")
+      (thesymb "/obj/${SYS}/interp/sockio.o")
       (thesymb "/int/interp/spad.lisp")
       (thesymb "/int/interp/spaderror.lisp")
       (thesymb "/int/interp/template.clisp")
@@ -232,13 +232,13 @@
    ())
   (list 
    (thesymb "/int/interp/ax.clisp"))
-  "/mnt/linux"
+  "/mnt/${SYS}"
   "/lsp"
   "/src"
   "/int"
   "/obj"
   "/mnt"
-  "linux")
+  "${SYS}")
 (in-package "SCRATCHPAD-COMPILER")
 (boot::set-restart-hook)
 (in-package "BOOT")
@@ -247,7 +247,7 @@
 (load (user::thepath "/int/interp/obey.lsp"))
 ;(si::multiply-bignum-stack 10)
 (si::gbc-time 0)
-(setq si::*system-directory* (user::thepath "/mnt/linux/bin/"))
+(setq si::*system-directory* (user::thepath "/mnt/${SYS}/bin/"))
 (gbc t)
 
 @
Index: src/interp/nlib.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/nlib.lisp.pamphlet,v
retrieving revision 1.3
diff -u -d -r1.3 nlib.lisp.pamphlet
--- src/interp/nlib.lisp.pamphlet	24 May 2004 22:53:55 -0000	1.3
+++ src/interp/nlib.lisp.pamphlet	29 Oct 2004 13:52:12 -0000
@@ -295,7 +295,15 @@
 (defun rpackfile (filespec)
   (setq filespec (make-filename filespec))
   (if (string= (pathname-type filespec) "NRLIB")
-      (recompile-lib-file-if-necessary (concat (namestring filespec) "/code.lsp"))
+      (let* ((base (pathname-name filespec))
+	     (code (concatenate 'string (namestring filespec) "/code.lsp"))
+	     (temp (concatenate 'string (namestring filespec) "/" base ".lsp"))
+	     (o (make-pathname :type "o")))
+	(si::system (format nil "cp ~S ~S" code temp))
+	(recompile-lib-file-if-necessary temp)
+	(si::system (format nil "mv ~S ~S~%" 
+			    (namestring (merge-pathnames o temp))
+			    (namestring (merge-pathnames o code)))))
   ;; only pack non libraries to avoid lucid file handling problems    
     (let* ((rstream (rdefiostream (list (cons 'file filespec) (cons 'mode 'input))))
 	   (nstream nil)
Index: src/interp/util.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/util.lisp.pamphlet,v
retrieving revision 1.5
diff -u -d -r1.5 util.lisp.pamphlet
--- src/interp/util.lisp.pamphlet	24 May 2004 22:54:05 -0000	1.5
+++ src/interp/util.lisp.pamphlet	29 Oct 2004 13:52:20 -0000
@@ -77,6 +77,16 @@
 ;     (compile-file collectfn))
 ;   (load collectfn)
 ;   (compiler::emit-fn t)
+;
+;  (let ((collectfn (concatenate 'string si::*system-directory* "../cmpnew/gcl_collectfn.lsp"))
+;       (collectfn1 (concatenate 'string obj "/" sys "/interp/collectfn")))
+;   (with-open-file (st collectfn :direction :input)
+;      (with-open-file (st1 (concatenate 'string collectfn1 ".lsp") :direction :output)
+;       (si::copy-stream st st1)))
+;   (unless (probe-file (concatenate 'string collectfn1 ".o"))
+;     (compile-file collectfn1))
+;   (load collectfn1)
+;
    (mapcar
      #'load
      (directory (concatenate 'string obj "/" sys "/interp/*.fn")))
@@ -813,7 +823,7 @@
 This function will do that. A correct call looks like:
 \begin{verbatim}
 (in-package "BOOT")
-(recompile-all-libs "/spad/mnt/linux/algebra")
+(recompile-all-libs "/spad/mnt/${SYS}/algebra")
 \end{verbatim}
 <<recompile-all-libs>>=
 (defun recompile-all-libs (dir)
@@ -838,11 +848,11 @@
 Note that it will build a pathname from the current {\bf AXIOM}
 shell variable. So if the {\bf AXIOM} shell variable had the value
 \begin{verbatim}
-/spad/mnt/linux
+/spad/mnt/${SYS}
 \end{verbatim}
 then the wildcard expands to
 \begin{verbatim}
-/spad/mnt/linux/nalg/*.spad
+/spad/mnt/${SYS}/nalg/*.spad
 \end{verbatim}
 and all of the matching files would be recompiled.
 <<recompile-all-algebra-files>>=
@@ -879,7 +889,7 @@
 before compiling this file. A correct call looks like:
 \begin{verbatim}
 (in-package "BOOT")
-(reroot "/spad/mnt/linux")
+(reroot "/spad/mnt/${SYS}")
 \end{verbatim}
 <<reroot>>=
 (defun reroot (dir)
Index: src/lib/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/Makefile.pamphlet,v
retrieving revision 1.8
diff -u -d -r1.8 Makefile.pamphlet
--- src/lib/Makefile.pamphlet	27 Jun 2004 15:01:39 -0000	1.8
+++ src/lib/Makefile.pamphlet	29 Oct 2004 13:52:23 -0000
@@ -490,10 +490,15 @@
 clean:
 	@echo 70 cleaning ${IN}
 	@rm -rf ${MID} ${OUT} ${DOCINT} ${DOCMNT}
+	@rm -f Makefile Makefile.dvi
 
 @
 \subsection{Makefile documentation}
 <<Makefile.dvi>>=
+${IN}/Makefile.dvi:
+	@echo 71a Bodging ${IN}/Makefile.dvi
+	@touch ${IN}/Makefile.dvi
+
 ${DOCMNT}/Makefile.dvi: ${IN}/Makefile.dvi
 	@echo 71 making ${DOCMNT}/Makefile.dvi from ${IN}/Makefile.dvi
 	@cp ${IN}/Makefile.dvi ${DOCMNT}/Makefile.dvi 
Index: src/lib/XDither.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/XDither.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 XDither.c.pamphlet
--- src/lib/XDither.c.pamphlet	27 Jun 2004 15:01:41 -0000	1.4
+++ src/lib/XDither.c.pamphlet	29 Oct 2004 13:52:25 -0000
@@ -51,7 +51,9 @@
 
 #include <stdio.h>
 #include <stdlib.h>
+#if !defined(FREEBSDplatform) && !defined(MACOSXplatform)
 #include <malloc.h>
+#endif
 
 #include <X11/Xlib.h>
 #include <X11/Xutil.h>
Index: src/lib/XShade.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/XShade.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 XShade.c.pamphlet
--- src/lib/XShade.c.pamphlet	27 Jun 2004 15:01:42 -0000	1.4
+++ src/lib/XShade.c.pamphlet	29 Oct 2004 13:52:25 -0000
@@ -50,8 +50,10 @@
 #include "useproto.h"
 
 #include <stdio.h>
-#include <malloc.h>
 #include <stdlib.h>
+#if !defined(FREEBSDplatform) && !defined(MACOSXplatform)
+#include <malloc.h>
+#endif
 
 #include <X11/Xlib.h>
 #include <X11/Xutil.h>
Index: src/lib/bsdsignal.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/bsdsignal.c.pamphlet,v
retrieving revision 1.7
diff -u -d -r1.7 bsdsignal.c.pamphlet
--- src/lib/bsdsignal.c.pamphlet	27 Oct 2004 01:10:41 -0000	1.7
+++ src/lib/bsdsignal.c.pamphlet	29 Oct 2004 13:52:25 -0000
@@ -9,13 +9,6 @@
 \eject
 \tableofcontents
 \eject
-\section{MAC OSX platform change}
-We needed to change [[SIGCLD]] to [[SIGCHLD]] for the [[MAC OSX]] platform
-and we need to create a new platform variable. This change is made to 
-propogate that platform variable.
-<<mac osx platform change>>=
-#if defined(LINUXplatform) || defined (ALPHAplatform)|| defined(RIOSplatform) || defined(SUN4OS5platform) ||defined(SGIplatform) ||defined(HP10platform) || defined(MACOSXplatform)
-@
 \section{License}
 <<license>>=
 /*
@@ -74,7 +67,7 @@
   struct sigaction in,out;
   in.sa_handler = action;
   /* handler is reinstalled - calls are restarted if restartSystemCall */
-<<mac osx platform change>>
+#if defined(LINUXplatform) || defined (ALPHAplatform) || defined(RIOSplatform) || defined(SUN4OS5platform) || defined(SGIplatform) || defined(HP10platform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
   if(restartSystemCall) in.sa_flags = SA_RESTART;
   else in.sa_flags = 0;
 #elif defined(SUNplatform)
Index: src/lib/cfuns-c.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/cfuns-c.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 cfuns-c.c.pamphlet
--- src/lib/cfuns-c.c.pamphlet	27 Jun 2004 15:01:43 -0000	1.4
+++ src/lib/cfuns-c.c.pamphlet	29 Oct 2004 13:52:27 -0000
@@ -52,9 +52,11 @@
 #include <unistd.h>
 #include <stdlib.h>
 #include <string.h>
-#include <malloc.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#if !defined(FREEBSDplatform) && !defined(MACOSXplatform)
+#include <malloc.h>
+#endif
 
 #include "cfuns-c.H1"
 
Index: src/lib/fnct_key.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/fnct_key.c.pamphlet,v
retrieving revision 1.5
diff -u -d -r1.5 fnct_key.c.pamphlet
--- src/lib/fnct_key.c.pamphlet	27 Oct 2004 01:10:41 -0000	1.5
+++ src/lib/fnct_key.c.pamphlet	29 Oct 2004 13:52:27 -0000
@@ -9,18 +9,6 @@
 \eject
 \tableofcontents
 \eject
-\section{MAC OSX port}
-On the MAC OSX the signal [[SIGCLD]] has been renamed to [[SIGCHLD]].
-In order to handle this change we need to ensure that the platform
-variable is set properly and that the platform variable is changed
-everywhere.
-<<mac os signal rename>>=
-#if defined(MACOSXplatform)
-        bsdSignal(SIGCHLD, null_fnct,RestartSystemCalls);
-#else
-        bsdSignal(SIGCLD, null_fnct,RestartSystemCalls);
-#endif
-@
 \section{License}
 <<license>>=
 /*
@@ -364,7 +352,11 @@
                 close(fd);
             }
         }
-<<mac os signal rename>>
+#if defined(FREEBSDplatform) || defined(MACOSXplatform)
+        bsdSignal(SIGCHLD, null_fnct, RestartSystemCalls);
+#else
+        bsdSignal(SIGCLD, null_fnct, RestartSystemCalls);
+#endif
         switch (id = fork()) {
           case -1:
             perror("Special key");
Index: src/lib/openpty.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/openpty.c.pamphlet,v
retrieving revision 1.8
diff -u -d -r1.8 openpty.c.pamphlet
--- src/lib/openpty.c.pamphlet	27 Oct 2004 01:10:41 -0000	1.8
+++ src/lib/openpty.c.pamphlet	29 Oct 2004 13:52:29 -0000
@@ -9,16 +9,6 @@
 \eject
 \tableofcontents
 \eject
-\section{MAC OSX platform changes}
-Since we have no other information we are adding the [[MACOSXplatform]] variable
-to the list everywhere we find [[LINUXplatform]]. This may not be correct but
-we have no way to know yet.
-<<mac osx platform change 1>>=
-#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(MACOSXplatform)
-@
-<<mac osx platform change 2>>=
-#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform)
-@
 \section{License}
 <<license>>=
 /*
@@ -33,7 +23,7 @@
       notice, this list of conditions and the following disclaimer.
 
     - Redistributions in binary form must reproduce the above copyright
-     notice, this list of conditions and the following disclaimer in
+      notice, this list of conditions and the following disclaimer in
       the documentation and/or other materials provided with the
       distribution.
 
@@ -102,7 +92,7 @@
 #endif
 
 {
-#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) ||defined(AIX370platform) 
+#if defined(SUNplatform) || defined (HP9platform) || defined(RTplatform) || defined(AIX370platform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
   int looking = 1, i;
   int oflag = O_RDWR;                  /* flag for opening the pty */
   
@@ -145,7 +135,7 @@
   return(fdm);
 #endif
 
-<<mac osx platform change 1>>
+#if defined(SUN4OS5platform) || defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
 extern int grantpt(int);
 extern int unlockpt(int);
 extern char* ptsname(int);
@@ -214,7 +204,7 @@
 	sprintf(serv, "/dev/ttyp%02x", channelNo);
 	channelNo++;
 #endif
-<<mac osx platform change 2>>
+#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(FREEBSDplatform) || defined(MACOSXplatform)
 	static int channelNo = 0;
 	static char group[] = "pqrstuvwxyzPQRST";
 	static int groupNo = 0;
Index: src/lib/pixmap.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/pixmap.c.pamphlet,v
retrieving revision 1.5
diff -u -d -r1.5 pixmap.c.pamphlet
--- src/lib/pixmap.c.pamphlet	27 Oct 2004 01:10:41 -0000	1.5
+++ src/lib/pixmap.c.pamphlet	29 Oct 2004 13:52:31 -0000
@@ -369,8 +369,7 @@
 write_pixmap_file(Display *dsp, int scr, char  *fn, Window wid, int x, int y, int width,int height)
 #endif
 {
-  XpmAttributes attr;
-  XImage *xi,*xireturn;
+  XImage *xi;
   int status;
   
   /* reads image structure in ZPixmap format */
Index: src/lib/wct.c.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/lib/wct.c.pamphlet,v
retrieving revision 1.4
diff -u -d -r1.4 wct.c.pamphlet
--- src/lib/wct.c.pamphlet	27 Jun 2004 15:01:44 -0000	1.4
+++ src/lib/wct.c.pamphlet	29 Oct 2004 13:52:33 -0000
@@ -287,7 +287,7 @@
   printTime((long *)&(pwct->ftime));
   cc = skimString(pwct->fimage, pwct->fsize, NHEAD, NTAIL);
   printf("%s", "            " + (cc - (NHEAD + NTAIL)));
-  printf(" [%d w, %d c]", pwct->wordc, pwct->fsize);
+  printf(" [%d w, %ld c]", pwct->wordc, (long)pwct->fsize);
   printf("\n");
 
 #ifdef SHOW_WORDS
Index: src/scripts/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/scripts/Makefile.pamphlet,v
retrieving revision 1.2
diff -u -d -r1.2 Makefile.pamphlet
--- src/scripts/Makefile.pamphlet	27 Jun 2004 15:01:44 -0000	1.2
+++ src/scripts/Makefile.pamphlet	29 Oct 2004 13:52:33 -0000
@@ -19,6 +19,10 @@
 	@cp -pr * ${OUT}
 	@mkdir -p ${OUT}/tex
 	@rm -f ${OUT}/Makefile*
+
+clean:
+	@echo 2 cleaning ${SRC}/scripts
+	@rm -f Makefile Makefile.dvi
 @
 \eject
 \begin{thebibliography}{99}
Index: src/scripts/document
===================================================================
RCS file: /cvsroot/axiom/axiom/src/scripts/document,v
retrieving revision 1.3
diff -u -d -r1.3 document
--- src/scripts/document	12 Nov 2003 11:16:15 -0000	1.3
+++ src/scripts/document	29 Oct 2004 13:52:33 -0000
@@ -1,12 +1,14 @@
 #!/bin/sh
+
 latex=`which latex`
 if [ "$latex" = "" ] ; then
   echo document ERROR You must install latex first
   exit 0
 fi
 
-tangle=$AXIOM/bin/lib/notangle
-weave=$AXIOM/bin/lib/noweave
+tangle=notangle
+weave=noweave
+
 if [ "$#" = "3" ]; then
  REDIRECT=$2
  FILE=`basename $3 .pamphlet`
Index: src/share/Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/share/Makefile.pamphlet,v
retrieving revision 1.3
diff -u -d -r1.3 Makefile.pamphlet
--- src/share/Makefile.pamphlet	27 Jun 2004 15:01:46 -0000	1.3
+++ src/share/Makefile.pamphlet	29 Oct 2004 13:52:33 -0000
@@ -31,6 +31,9 @@
 	@ echo 2 finished ${IN}
 
 <<util.ht>>
+
+clean:
+
 @
 \eject
 \begin{thebibliography}{99}

--==_Exmh_-7609217490--

\start
Date: Tue, 2 Nov 2004 12:52:50 +0100 (CET)
From: Bertfried Fauser
To: list
Subject: Installing AXIOM on Mandrake

Hello,

=09I have installed AXIOM on a mandrake linux for my friend Rafal.
This was a challenge and he would not have succeded to do so.

Mandrake does not install by defult very much packages which are _needed_
to compile AXIOM, this starts with the gcc compiler(!), latex, X11
developer files, binutils, m4 preprocessor, etc.
=09It took quite a while for a non expert as I am to notice in which
package libbdf.a etc are located. Hence my question:
=09Would it be possible to put on the AXIOM homepage a list with
_all_ packages which are needed for compilation of AXIOM are listed.
(When AXIOM goes into an RPM (apt) archive this might be needed anyway)

=09Furthermore, since we tried to install from a Win machine (linux
box had no internet connection) it was quite hard to check out the files
from the cvs. (I did it using my linux book in Germany and ftp the file to
the Win box). Would it be difficult to produce daily an
AXIOM-...-version.tgz file in the download area of teh savannah server.
Perhaps on a weekly basis even a compiled binary file for a standard linux
box? This would help cvs dummies -as I am at least under Windows- to cope
with the download.

=09Sorry to report this, but my effort to advertise AXIOM was kicked
off by showing how difficult the installation was (for me, on a linux I
don=B4t know well). The current state is not an ivitation to AXIOM for user=
s
with few linux knowledge, and we would like to advertise AXIOM isnt it?

\start
Date: Tue, 2 Nov 2004 10:42:46 -0500 
From: Bill Page
To: Bertfried Fauser
Subject: RE: Installing AXIOM on Mandrake

Bertfried,

There is a CVS tarball that can be downloaded instead of
access via CVS. See

> Nightly CVS Tree Tarball
> This tarball is updated every night and contains a copy of
> your Source CVS tree.

This can be accessed by anyone without logging in.

http://savannah.nongnu.org/cvs-backup/axiom-sources.tar.gz

However I found this link on the following page project admin
page which (I think) is only accessible to registered project
admins:

http://savannah.nongnu.org/project/admin/?group=axiom

Anyway, I have also added this to

   http://page.axiom-developer.org/zope/mathaction/AxiomDownload

So you will be able to find it easily in the future.

I think a (fairly complete?) list of dependencies for debian is
given at

  http://packages.debian.org/testing/source/axiom

The debian build assumes that GCL in already installed, but
in the case of other linuxes, the Axiom build includes GCL.

Bertfried it would be very useful if you could confirm
this list of dependencies and add any that are missing, then
I will add this information to MathAction.

And of course for giving a quick demo of Axiom, you can
always use MathAction itself... :)

Cheers,
Bill Page.

> -----Original Message-----
> 	I have installed AXIOM on a mandrake linux for my friend Rafal.
> This was a challenge and he would not have succeded to do so.
> 
> Mandrake does not install by defult very much packages which 
> are _needed_ to compile AXIOM, this starts with the gcc compiler(!),
> latex, X11 developer files, binutils, m4 preprocessor, etc.
> 	It took quite a while for a non expert as I am to 
> notice in which package libbdf.a etc are located. Hence my question:
> 	Would it be possible to put on the AXIOM homepage a list with
> _all_ packages which are needed for compilation of AXIOM are listed.
> (When AXIOM goes into an RPM (apt) archive this might be 
> needed anyway)
> 
> 	Furthermore, since we tried to install from a Win machine
> (linux box had no internet connection) it was quite hard to check 
> out the files from the cvs. (I did it using my linux book in Germany
> and ftp the file to the Win box). Would it be difficult to produce
> daily an AXIOM-...-version.tgz file in the download area of the 
> savannah server. Perhaps on a weekly basis even a compiled binary
> file for a standard linux box? This would help cvs dummies - as I am
> at least under Windows- to cope with the download.
> 
> 	Sorry to report this, but my effort to advertise AXIOM 
> was kicked off by showing how difficult the installation was
> (for me, on a linux I don=B4t know well). The current state is not
> an ivitation to AXIOM for users with few linux knowledge, and we
> would like to advertise AXIOM isnt it?

\start
Date: 02 Nov 2004 12:17:14 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: new homepage / download section

Greetings!

Bill Page writes:

> About a month ago I (finally) managed to figure out how
> to put files in the savannah files section again - the
> procedure to do this changed last year after the hacker
> attack on savannah and the files that we preiously had there
> were removed by savannah. The method to upload files now
> involves signing them using gnupg - not so hard but not
> trivial. Anyway, we did not have any files there for a long
> time until just last month.
> 
> Whatever Tim Daly did in order to change the default home
> page has also apparently changed the savannah files link.
> Since I don't really understand how this home page re-direct
> thing works at savannah, I don't know how to correct this.
> 
> Tim, what do you think? Is there an easy way to fix this?
> If we store the files somewhere else and link directly to
> them via the download.html page, how can we transfer what
> we already have at savannah to the new location? Since
> the Axiom Portal software on page.axiom-developer.org has
> a simple file upload/download feature, maybe we should
> locate all such files there.
> 
>   http://page.axiom-developer.org/zope/Plone/download
> 

Personally, I'd prefer sticking with savannah due to the considerable
site infrastructure support that we simply won't have to do, including
nightly cvs snapshots, etc.

Just my $0.02.

Take care,

> Bill Page.
> 
> On Friday, October 29, 2004 10:08 AM Martin Rubey wrote:
> > 
> > Currently, 
> > 
> > http://savannah.nongnu.org/files/?group=axiom
> >
> >redirects to 
> >
> > http://axiom.axiom-developer.org/axiom-website/download.html
> > 
> > This is nonsense, because that way you never get to the
> > files :-(

\start
Date: 02 Nov 2004 12:14:47 -0500
From: Camm Maguire
To: Magnus Larsson
Subject: Re: Axiom cvs 2004-10-31 (gcl-2.6.5) gcc/binutils dependency?

Greetings!  Yes, another user has posted about the needed upgrade
here.

While bfd support has extended GCL's native code relocation ability to
arm, m68k, powerpc, s390, and amd64, fully justifying IMHO its use to
'offload' this functionality, its API is explicitly stated by its
developers to be subject to change like this without notice.  The
soname version of the library changes with each point release, making
the conventional means of tracking external backward-incompatible api
changes via shared library versioning extremely impracticable, as any
minor bfd shared lib change at all would force a gcl, maxima, acl2,
and axiom recompile.  Linking in libbfd.a statically extends the
binary life a bit, but can silently lead to problems, such as when
Debian's gcl was built against bfd 2.14, and then later used to build
axiom et.al. when bfd was upgraded to 2.15, leading to silent breakage
whenever intermediary build images are generated via
compiler::link/ld.

I'm coming to the reluctant conclusion that the best course for GCL is
to 1) effectively fork bfd and build from a local snapshot in the gcl
sources (--disable-statsysbfd --enable-locbfd to configure), or 2)
extend the older i386 and sparc only elf relocation code to the other
platforms.  2) means lots of work for sure, so 1) is best for now.

We can put in some configure magic to detect the external bfd version
and toggle the rawsize form accordingly, but this is too ad hoc for
words. :-)

Take care,

Magnus Larsson writes:

> Hello Axiom-developer,
> 
> FYI,
> 
> Building Axiom cvs 2004-10-31 using:
> 
> gcc-3.4.2 + binutils 2.15.92.0.2 (beta) or
> gcc-3.3.1 + binutils 2.15.92.0.2 (beta)
> =A0
> fails with a reference to "_raw_size" while making gcl-2.6.5:
> ...
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointe=
r =A0
> -I/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gc=
l-tk 
> init_pari.c
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointe=
r =A0
> -I/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gc=
l-tk 
> nsocket.c
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointe=
r =A0
> -I/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o -I../h -I../gc=
l-tk 
> sfasl.c
> In file included from sfasl.c:40:
> sfaslbfd.c: In function `fasload':
> sfaslbfd.c:266: error: structure has no member named `_raw_size'
> sfaslbfd.c:291: error: structure has no member named `_raw_size'
> sfaslbfd.c:356: error: structure has no member named `_raw_size'
> make[4]: *** [sfasl.o] Error 1
> make[4]: Leaving directory 
> `/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5/o'
> make[3]: *** [unixport/saved_pre_gcl] Error 2
> make[3]: Leaving directory 
> `/home/magnus/usr/source/axiom/axiom-test/lsp/gcl-2.6.5'
> /bin/sh: unixport/saved_gcl: No such file or directory
> make[2]: *** [gcldir] Error 127
> make[2]: Leaving directory `/home/magnus/usr/source/axiom/axiom-test/lsp'
> make[1]: *** [lspdir] Error 2
> make[1]: Leaving directory `/home/magnus/usr/source/axiom/axiom-test'
> make: *** [all] Error 2
> magnus@lfs:~/usr/source/axiom/axiom-test> =A0 =A0 =A0 =A0 =A0
> 
> I managed to build Axiom cvs 2004-10-31 using 
> gcc-3.3.1 and binutils 2.15.90.0.3 20040415.
> 
> Downgrading to binutils 2.15.90.0.3 20040415 allowed sfaslbfd.c to pick u=
p a 
> bfd.h with "_raw_size" defined. The more recent binutils 2.15.92.0.2 (bet=
a) 
> uses "rawsize" instead.
> 
> host system:
> Linux lfs 2.6.9 #2 Sun Oct 24 18:52:20 CEST 2004 i686 athlon i386 GNU/Lin=
ux

\start
Date: 02 Nov 2004 16:08:55 -0500
From: Camm Maguire
To: Bertfried Fauser
Subject: Re: Installing AXIOM on Mandrake

Greetings!

Bertfried Fauser writes:

> Hello,
> 
> 	I have installed AXIOM on a mandrake linux for my friend Rafal.
> This was a challenge and he would not have succeded to do so.
> 
> Mandrake does not install by defult very much packages which are _needed_
> to compile AXIOM, this starts with the gcc compiler(!), latex, X11
> developer files, binutils, m4 preprocessor, etc.
> 	It took quite a while for a non expert as I am to notice in which
> package libbdf.a etc are located. Hence my question:
> 	Would it be possible to put on the AXIOM homepage a list with
> _all_ packages which are needed for compilation of AXIOM are listed.
> (When AXIOM goes into an RPM (apt) archive this might be needed anyway)
> 

I think the union of:

http://packages.debian.org/unstable/source/gcl

and 

http://packages.debian.org/unstable/source/axiom

should do the trick.

Take care,


> 	Furthermore, since we tried to install from a Win machine (linux
> box had no internet connection) it was quite hard to check out the files
> from the cvs. (I did it using my linux book in Germany and ftp the file to
> the Win box). Would it be difficult to produce daily an
> AXIOM-...-version.tgz file in the download area of teh savannah server.
> Perhaps on a weekly basis even a compiled binary file for a standard linux
> box? This would help cvs dummies -as I am at least under Windows- to cope
> with the download.
> 
> 	Sorry to report this, but my effort to advertise AXIOM was kicked
> off by showing how difficult the installation was (for me, on a linux I
> don=B4t know well). The current state is not an ivitation to AXIOM for us=
ers
> with few linux knowledge, and we would like to advertise AXIOM isnt it?

\start
Date: Tue, 2 Nov 2004 22:05:22 +0100 (CET)
From: Bertfried Fauser
To: Bill Page
Subject: RE: Installing AXIOM on Mandrake

On Tue, 2 Nov 2004, Page, Bill wrote:

Hi Bill,

> http://savannah.nongnu.org/cvs-backup/axiom-sources.tar.gz
>
> However I found this link on the following page project admin
> page which (I think) is only accessible to registered project
> admins:
>
> http://savannah.nongnu.org/project/admin/?group=axiom
>
> Anyway, I have also added this to
>
>    http://page.axiom-developer.org/zope/mathaction/AxiomDownload

Thats good news, I will check it out.

> I think a (fairly complete?) list of dependencies for debian is
> given at
>
>   http://packages.debian.org/testing/source/axiom
>
> The debian build assumes that GCL in already installed, but
> in the case of other linuxes, the Axiom build includes GCL.

Most problems were due to the GCL build. When the GCL was working the
build went through with only one further problem if I remember right.


> Bertfried it would be very useful if you could confirm
> this list of dependencies and add any that are missing, then
> I will add this information to MathAction.

My problem was, that after a week with 4 talks in Cookeville I had only
teh last evening to see this linux box having mandrake running. So I was
also not acustomed to the package installing tools etc. I noticed only
eventually that nearly nothing was installed by the default(?) system. I
have no longer acces to this machine and can not come up with a list. If I
woul=F6d have known that the build would fail so often, I would have writte=
n
down what I had to postinstall.

> And of course for giving a quick demo of Axiom, you can
> always use MathAction itself... :)

I did it this way :-)) really a good alternative for a quit show.

\start
Date: Tue, 2 Nov 2004 21:03:38 -0500 
From: Bill Page
To: Alan G. Isaac
Subject: Axiom url shown under 'Symbolic Mathematics' is out of date

Dear Alan G. Isaac,

Thank you for your very useful web site listing many resources
of interest ot me.

I just wanted to  let you know that the link for Axiom at

 http://www.american.edu/academic.depts/cas/econ/soft.htm#SYMB

> # Axiom http://www.nag.com/symbolic_software_more.asp is now
> free and open source! "Axiom ... defines a strongly typed,
> mathematically correct type hierarchy. It has a programming
> language and a built-in compiler." 

is now quite out of date. Axiom is no longer available from
NAG however as you correctly state, it is open source and is
available for free download at

  http://axiom.axiom-developer.org

Axiom is also available online for free collaborative user
over the web at

  http://page.axiom-developer.org

\start
Date: Tue, 2 Nov 2004 21:06:13 -0500 
From: Bill Page
To: Martin Rubey
Subject: RE: Installing AXIOM on Mandrake

Martin,

I have just found out via the savannah admin interface below
that the Axiom download page is still accessible directly
via

  http://savannah.nongnu.org/download/axiom

I have corrected the page

  http://page.axiom-developer.org/zope/mathaction/AxiomDownload

on MathAction to use this new url.

Regards,
Bill Page.

> -----Original Message-----
> 
> Page, Bill writes:
>  > However I found this link on the following page project admin
>  > page which (I think) is only accessible to registered project
>  > admins:
>  > 
>  > http://savannah.nongnu.org/project/admin/?group=axiom
> 
> 
> Just to confirm: yes, only for admins...

\start
Date: Wed,  3 Nov 2004 09:12:06 +0000
From: Christopher Chamber
To: list
Subject: LaTeX output

I've installed a recent cvs axiom, and made some experiments with the
LaTeX generation stuff. I replaced some of very old plain TeX constructs
by their modern LaTeX forms, like

{x \over y} -> \frac{x}{y}
{x \sp y} -> {x}^{y}
{\root n \of x} -> \sqrt[n]{x}

Is there any reason to retain the old plain-TeX output? Does anybody
need it, or it can be replaced by the proper LaTeX output?

Use of $$...$$ in LaTeX is discouraged. I propose to replace it by
\[...\] . Comments?

The main reason I'm doing this is, of course, the TeXmacs interface. The
current setup, where axiom outputs old plain-TeX constructs, and tm_axiom
tries to parse it back (!!!) and replace by proper LaTeX constructs, is
unsatisfactory; it is much better to fix the problem, not to build
complicated workarounds. I see 2 possible ways to make this interface
better:

1. Either I duplicate the LaTeX generation code to TeXmacs generation
code, make adjustments, and introduce a new command
)set output texmacs on
(haven't looked at the code which processes system commands, but I'm sure
this must be not too difficult).

2. Or I make LaTeX generation parametrized. The number of required
differences is small: for TeXmacs, it is essential to generate \* for
multiplication, while for ordinary LaTeX, this should be either nothing
or, perhaps, \, ; TeXmacs stuff like \2latex: should be in the prelude and
the matching \5 at the end; maybe, a few other trivial points. I can
introduce a global variable latexMultiplicationString, for example, and
assign "\*" to it for TeXmacs and "\," (or "") for LaTeX. Or I can collect
all such hook strings into a Record, and have latexHooks and texmacsHooks
with all settings.

Which approach seems better to you?
-----------------------
Christopher Chamber
http://gem-hs.org/c.html

\start
Date: Wed, 3 Nov 2004 11:47:53 +0100
From: Martin Rubey
To: Christopher Chamber
Subject: Re: LaTeX output

In fact, I don't know about the current situation. However, if Axiom currently
produces plain TeX, why not leave it that way and add the capability of
producing LaTeX?

Martin

Christopher Chamber writes:
 > 
 > 
 > I've installed a recent cvs axiom, and made some experiments with the
 > LaTeX generation stuff. I replaced some of very old plain TeX constructs
 > by their modern LaTeX forms, like
 > 
 > {x \over y} -> \frac{x}{y}
 > {x \sp y} -> {x}^{y}
 > {\root n \of x} -> \sqrt[n]{x}
 > 
 > Is there any reason to retain the old plain-TeX output? Does anybody
 > need it, or it can be replaced by the proper LaTeX output?
 > 
 > Use of $$...$$ in LaTeX is discouraged. I propose to replace it by
 > \[...\] . Comments?
 > 
 > The main reason I'm doing this is, of course, the TeXmacs interface. The
 > current setup, where axiom outputs old plain-TeX constructs, and tm_axiom
 > tries to parse it back (!!!) and replace by proper LaTeX constructs, is
 > unsatisfactory; it is much better to fix the problem, not to build
 > complicated workarounds. I see 2 possible ways to make this interface
 > better:
 > 
 > 1. Either I duplicate the LaTeX generation code to TeXmacs generation
 > code, make adjustments, and introduce a new command
 > )set output texmacs on
 > (haven't looked at the code which processes system commands, but I'm sure
 > this must be not too difficult).
 > 
 > 2. Or I make LaTeX generation parametrized. The number of required
 > differences is small: for TeXmacs, it is essential to generate \* for
 > multiplication, while for ordinary LaTeX, this should be either nothing
 > or, perhaps, \, ; TeXmacs stuff like \2latex: should be in the prelude and
 > the matching \5 at the end; maybe, a few other trivial points. I can
 > introduce a global variable latexMultiplicationString, for example, and
 > assign "\*" to it for TeXmacs and "\," (or "") for LaTeX. Or I can collect
 > all such hook strings into a Record, and have latexHooks and texmacsHooks
 > with all settings.
 > 
 > Which approach seems better to you?

\start
Date: Wed, 3 Nov 2004 17:18:52 +0600 (NOVT)
From: Andrey G. Grozin
To: Christopher Chamber
Subject: Re: LaTeX output

On Wed, 3 Nov 2004, Christopher Chamber wrote:
> I've installed a recent cvs axiom, and made some experiments with the
> LaTeX generation stuff. I replaced some of very old plain TeX constructs
> by their modern LaTeX forms, like
> 
> {x \over y} -> \frac{x}{y}
> {x \sp y} -> {x}^{y}
> {\root n \of x} -> \sqrt[n]{x}
> 
> Is there any reason to retain the old plain-TeX output? Does anybody
> need it, or it can be replaced by the proper LaTeX output?
> 
> Use of $$...$$ in LaTeX is discouraged. I propose to replace it by
> \[...\] . Comments?
I did the same thing some time ago, and asked the list. I was told that 
there is a chance of re-introducing the Axiom interface to some 
closed-source Windows-only thing (don't remember its name), and because of 
this (remote) chance we cannot touch anything in Axiom's TeX generation.

> The main reason I'm doing this is, of course, the TeXmacs interface. The
> current setup, where axiom outputs old plain-TeX constructs, and tm_axiom
> tries to parse it back (!!!) and replace by proper LaTeX constructs, is
> unsatisfactory; it is much better to fix the problem, not to build
> complicated workarounds.
This is my motivation, too. The current situation is completely crazy. 
tm_axiom must die (though it was me who wrote it initially).

> I see 2 possible ways to make this interface
> better:
> 
> 1. Either I duplicate the LaTeX generation code to TeXmacs generation
> code, make adjustments, and introduce a new command
> )set output texmacs on
> (haven't looked at the code which processes system commands, but I'm sure
> this must be not too difficult).
This is exactly what I'm going to do when I'll have a little free time.
We need one more thing: parametrized prefixes and suffixes for all prompts 
Axiom can generate. I haven't studied the interpreter code in any detail, 
but I suppose this also should be not too difficult.

Maxima has recently done this. In the words of James Amundson, its leading 
developer, Maxima interfacing has moved from the stone age (parsing output 
to find prompts, brr... this was done by an ugly maxima_filter I wrote) to 
the bronze age (via parametrized prefixes/suffixes, maxima can now 
communicate with any front-end directly, including TeXmacs). James 
proposes to move directly to the Enlightment (corba).
Axiom interface is still firmly in the stone age. There were attempts to 
move it still deeper into paleolith by incorporating more 
parsing/rewriting into tm_axiom; they were, fortunately, not accepted by 
Joris van der Hoeven. Let's move to the bronze age, following the maxima's 
example.


> 2. Or I make LaTeX generation parametrized. The number of required
> differences is small: for TeXmacs, it is essential to generate \* for
> multiplication, while for ordinary LaTeX, this should be either nothing
> or, perhaps, \, ; TeXmacs stuff like \2latex: should be in the prelude and
> the matching \5 at the end; maybe, a few other trivial points. I can
> introduce a global variable latexMultiplicationString, for example, and
> assign "\*" to it for TeXmacs and "\," (or "") for LaTeX. Or I can collect
> all such hook strings into a Record, and have latexHooks and texmacsHooks
> with all settings.
Yes, I also thought about this approach. It has one clear advantage: 
whenever some bug is fixed in the TeX generation, this fix appears in the 
TeXmacs generation, too. If we fork the TeX generation code, we'll have to 
trace its changes by hand.

Andrey Grozin

\start
Date: Wed, 3 Nov 2004 05:11:30 -0800 (PST)
From: Cliff Yapp
To: Andrey G. Grozin, Christopher Chamber
Subject: Re: LaTeX output

--- Andrey G. Grozin wrote:

> I did the same thing some time ago, and asked the list. I was told
> that there is a chance of re-introducing the Axiom interface to some 
> closed-source Windows-only thing (don't remember its name), and
> because of this (remote) chance we cannot touch anything in Axiom's
> TeX generation.

Two questions, one comment.

Q1)  What is the current status of getting ahold of the Windows
interface (IIRC it was called TeXexplorer or somesuch?)

Q2)  If we can get ahold of it, would it be in source or binary form?

If it is in source form, surely it can be updated along with the TeX
generation itself to match up with modern standards.  Retaining old
style TeX is begging for trouble (or at least bug reports).  The only
reason to do it is if a) TeXexplorer becomes available and b) we have
no way to change it.  (IMHO if we can't update the interface there is
little point in it except as a temporary solution, but that's another
discussion.)

If all else fails, perhaps we can ask whoever has the rights to
TeXexplorer to alter it to call something like )set output explorer
instead of TeX.  Then we can put the old stuff there and update as we
like.

\start
Date: 03 Nov 2004 09:24:37 -0500
From: Camm Maguire
To: Tim Daly
Subject: Active arch braches listed somewhere?

Greetings!  Just wondering.

\start
Date: Wed, 3 Nov 2004 09:32:33 -0500
From: Tim Daly
To: Camm Maguire
Subject: Active arch branches listed somewhere?

Unfortunately no. I had arch running on tenkan but got kicked off 
because arch ate too much space. I bought a machine and the 
axiom-developer.org domain but I don't seem to be able to get arch
running there. It's been a source of frustration.

\start
Date: Wed, 3 Nov 2004 11:45:40 -0500 
From: Bill Page
To: Cliff Yapp
Subject: RE: LaTeX output

On Wednesday, November 03, 2004 8:12 AM Cliff Yapp wrote:

> --- Andrey G. Grozin wrote:
> 
> > I did the same thing some time ago, and asked the list.
> > I was told that there is a chance of re-introducing the Axiom 
> > interface to some closed-source Windows-only thing (don't
> > remember its name), and because of this (remote) chance we
> > cannot touch anything in Axiom's TeX generation.

This is not accurate. Axiom is open source and anyone can
touch whatever they like in the Axiom code. The issue is more:
What is the best thing to touch? We have discussed this is
great detail over the last two years. See:

  http://lists.gnu.org/archive/html/axiom-developer

and try a few good keyword searches such as:

  Search String: TechExplorer

and

  Search String: texmacs

> 
> Two questions, one comment.
> 
> Q1)  What is the current status of getting ahold of the
> Windows interface (IIRC it was called TeXexplorer or somesuch?)
> 
> Q2)  If we can get ahold of it, would it be in source or binary
> form?

Techexplorer is not open source:

  http://www.integretechpub.com/products/techexplorer/

> 
> If it is in source form, surely it can be updated along with
> the TeX generation itself to match up with modern standards.

I think that doing this (and much more!) is on the agenda
of the new Techexplorer developer Integre. *If* Techexplorer
is re-integrated with Axiom *then* it would very likely be
done by people at Integre.

> Retaining old style TeX is begging for trouble (or at least
> bug reports).  The only reason to do it is if a) TeXexplorer
> becomes available and b) we have no way to change it.  (IMHO
> if we can't update the interface there is little point in it
> except as a temporary solution, but that's another discussion.)
> 
> If all else fails, perhaps we can ask whoever has the rights
> to TeXexplorer to alter it to call something like )set output
> explorer instead of TeX.  Then we can put the old stuff there
> and update as we like.
> 

I think the only really interesting functionality that once
was a part of the NAG Techexplorer interface for Axiom
under windows is the hyperdoc navigation. But both Texmacs
and the MathAction-style web interface already have gone
at least part way to replacing thing functionality yet
again with something else.

\start
Date: Wed, 3 Nov 2004 12:26:06 -0500 
From: Bill Page
To: Tim Daly
Subject: RE: Active arch branches listed somewhere?

Tim,

On Wednesday, November 03, 2004 9:25 AM Camm Maguire
wrote:

> Subject: Active arch braches listed
>  somewhere?
> 
> 
> Greetings!  Just wondering.
> 

On Wednesday, November 03, 2004 9:33 AM Tim Daly wrote:

> 
> Unfortunately no. I had arch running on tenkan but got
> kicked off because arch ate too much space. I bought a
> machine and the axiom-developer.org domain but I don't
> seem to be able to get arch running there. It's been a
> source of frustration.
> 

But I just checked and it seems to me that arch is already
installed on axiom-developer.

[page@axiom-developer page]$ which 'tla'
/usr/local/bin/tla

[page@axiom-developer page]$ ls -l `which tla`
-rwxr-xr-x  1 root root 3824087 Apr  4  2004 /usr/local/bin/tla

[page@axiom-developer page]$ tla --version
tla lord@emf.net--2003b/dists--devo--1.0--patch-50(configs/emf.net/devo.scm)
 from regexps.com

---------

I don't recall if I was the one who originally installed it
or was it you? The executable file has the date Apr 4 2004.
This is an older version, the current one seems to be
tla-1.2.1 from August 2004.

When you say: "I don't seem to be able to get arch running
there" do you mean that it is not working properly? If you
want, I can install the newer version.

I also have darcs running on axiom-developer since it is
the source respository that is preferred by the ZWiki and
LatexWiki developers. I think it works well and is simpler
to use than CVS and tla but maybe it doesn't do everything
you need? (Not good enough for project branching?)

\start
Date: Wed, 3 Nov 2004 12:36:53 -0500 
From: Bill Page
To: Tim Daly
Subject: RE: Active arch branches listed somewhere?

Apropos ...

Here is a very good article about GNU arch that also
compares (and mentions several good things about) darcs
versus arch.

http://www.sourcefrog.net/weblog/software/vc/arch

" ...You can do this in Arch but it's more natural in Darcs. 

I think at the moment I would compare them like this:

Arch has a lot of structure and metadata to let you see
the history of every changeset and to organize large
trees. That might be good for very large projects. It's
good for small projects, though the sheer complexity can
be a disincentive.

Darcs is much simpler. I think you can show someone all
they need to know in ten minutes. It's naturally very
distributed. I rarely or never need to wait for network
traffic."

On Wednesday, November 03, 2004 12:26 PM I wrote:

> ...
> I also have darcs running on axiom-developer since it is
> the source respository that is preferred by the ZWiki and
> LatexWiki developers. I think it works well and is simpler
> to use than CVS and tla but maybe it doesn't do everything
> you need? (Not good enough for project branching?)

\start
Date: Wed, 3 Nov 2004 12:26:43 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Active arch branches listed somewhere?

if memory serves me the issue was getting it to work with the
webdav protocol on the apache server. i'll look at the article
you recommended as soon as i can.

\start
Date: Wed, 03 Nov 2004 19:35:25 +0100
From: David Mentre
To: Andrey G. Grozin
Subject: Re: LaTeX output
Cc: Christopher Chamber

Andrey G. Grozin writes:

>> 1. Either I duplicate the LaTeX generation code to TeXmacs generation
>> code, make adjustments, and introduce a new command
>> )set output texmacs on
>> (haven't looked at the code which processes system commands, but I'm sure
>> this must be not too difficult).
> This is exactly what I'm going to do when I'll have a little free time.
> We need one more thing: parametrized prefixes and suffixes for all prompts 
> Axiom can generate. I haven't studied the interpreter code in any detail, 
> but I suppose this also should be not too difficult.

It is certainly the path to follow. However I'm wondering if it is not
more efficient and future-proof (albeit probably more difficult) to
produce directly TeXmacs scheme?

\start
Date: Wed, 03 Nov 2004 19:42:42 +0100
From: David Mentre
To: Camm Maguire
Subject: Re: Active arch braches listed somewhere?

Hello Camm,

No, there is no central list.

Tim repository is lost due to disk constraints.

Mine (quite inactive for now) is at:

David Mentre--2004-code
   http://www.linux-france.org/~dmentre/arch-ive/


Regarding Tim former branches, an old post listed them:
http://lists.gnu.org/archive/html/axiom-developer/2004-03/msg00003.html

\start
Date: Thu, 4 Nov 2004 01:35:04 +0600 (NOVT)
From: Andrey G. Grozin
To: David Mentre
Subject: Re: LaTeX output
Cc: Christopher Chamber

On Wed, 3 Nov 2004, David MENTRE wrote:
> Andrey G. Grozin writes:
> >> 1. Either I duplicate the LaTeX generation code to TeXmacs generation
> >> code, make adjustments, and introduce a new command
> >> )set output texmacs on
> >> (haven't looked at the code which processes system commands, but I'm sure
> >> this must be not too difficult).
> > This is exactly what I'm going to do when I'll have a little free time.
> > We need one more thing: parametrized prefixes and suffixes for all prompts 
> > Axiom can generate. I haven't studied the interpreter code in any detail, 
> > but I suppose this also should be not too difficult.
> It is certainly the path to follow. However I'm wondering if it is not
> more efficient and future-proof (albeit probably more difficult) to
> produce directly TeXmacs scheme?
But I mean exactly this. If axiom will output some parametrized strings
* at its start
* before each prompt
* after each prompt (before user input)
* after user input (before any output)
* after its finish
then these strings can implement the TeXmacs protocol directly. No need to 
start tm_axiom (this monster can be killed). This has been successfully 
done in maxima-5.9.1, and now no maxima_filter is used - TeXmacs and 
maxima communicate directly.

\start
Date: Wed, 3 Nov 2004 14:39:52 -0500 
From: Bill Page
To: Andrey G. Grozin
Subject: RE: LaTeX output
Cc: Christopher Chamber, David Mentre

No, I think what David meant was using the native Texmacs
Scheme encoding of the mathematics *instead* of LaTeX. That
way one potentially has access to some Texmacs features that
do not translate well into LaTeX.

The communication protocol itself is (should be?) a somewhat
different subject at a different level.

Regards,
Bill Page.

David MENTRE wrote:
> > ... However I'm wondering if it is not more efficient and
> > future-proof (albeit probably more difficult) to produce
> > directly TeXmacs scheme?

Andrey G. Grozin wrote:
> But I mean exactly this. If axiom will output some 
> parametrized strings
> * at its start
> * before each prompt
> * after each prompt (before user input)
> * after user input (before any output)
> * after its finish
> then these strings can implement the TeXmacs protocol 
> directly. No need to start tm_axiom (this monster can be
> killed). This has been successfully done in maxima-5.9.1,
> and now no maxima_filter is used - TeXmacs and maxima
> communicate directly.

\start
Date: 04 Nov 2004 10:12:49 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Active arch branches listed somewhere?

Greetings!

Tim Daly writes:

> Unfortunately no. I had arch running on tenkan but got kicked off 
> because arch ate too much space. I bought a machine and the 
> axiom-developer.org domain but I don't seem to be able to get arch
> running there. It's been a source of frustration.
> 

My condolences for the frustration.  We seem to have a hard choice --
a revision control system with a lot of nice advanced features that is
not widely used and has no support on public servers like savannah, or
a more limited system (CVS) which has such public infrastructure
support but is more limited in its branching options.

Savannah has told me they plan to get subversion sometime, which might
be a good middle ground.  But can I suggest for the time being to
commit your arch branches into cvs as separate branches or 'modules'?
I think cvs import can separate the code in this manner.

Take care,

\start
Date: Thu, 4 Nov 2004 10:11:39 -0500
From: Tim Daly
To: Camm Maguire, Bill Page
Subject: CVS, Arch, Darcs

I'm looking to the CVS, Arch, Darcs issue at the moment.
I'll try to either recreate Arch or piggyback on Darcs.

I have about a dozen or so "subprojects" of axiom I'm working on
and they are all in one local pile. I'd like to put them up on a
public server with several goals
(a) other people can hack them. Axiom has several areas that 
    need work, like the Mac OSX/BSD port and I want to be able
    to branch the code to handle these experimental changes
    until they get back to the main branch.
(b) I can get them cleaned up and straight. Given the rapid 
    task-switching I do during the day I'm usually too busy 
    to keep things clean. 
(c) keep a couple sub-projects "semi-private". some of the
    branches have papers that I don't yet have permission to
    reproduce.
(d) keep multiple projects. For instance, I'm hacking a large
    C++ code pile that will eventually work with Axiom but is
    really a standalone project.
(e) "pull through" another server. I want Doyen to be a superset
    of Axiom and MathAction so I want to make these projects
    sub-projects of a larger effort
(f) "pull from" another server. Axiom currently extends and patches
    GCL. I'd like to pull a gcl tarball transparently when Axiom is
    fetched.

so I want something like:

Doyen Scientific Platform
  ^
  | 
  (merge) Doyen involves many subprojects of which Axiom is one.
  |
  + (patches) ---(checkout)------------> Doyen+patches
              <--(commit)--------------- Doyen+patches
^
|
(pull thru) Doyen uses Axiom and should include it automatically
|
Axiom (main)  -------(checkout)------------> Axiom
              <------(commit)---------------
  ^
  |
  (merge) There are about a dozen sub-efforts
  |
  + (graphics) ------(checkout)------------> Axiom+graphics
               <-----(commit)--------------- Axiom+graphics
  ^
  |
  (merge)
  |
  + (hyperdoc) ------(checkout)------------> Axiom+hyperdoc
               <-----(commit)--------------- Axiom+hyperdoc
  ^
  | 
  (merge)
  |
  + (crystal)  ------(checkout)------------> Axiom+crystal
               <-----(commit)--------------- Axiom+crystal
    crystal needs to be private because I don't yet have permission
    to publish the documents/code involved
^
|
(pull from) GCL is required and I want to automatically pull a
|           particular tarball from the GCL tree when Axiom is fetched.
|
GCL
  ^
  | 
  (merge)
  |
  + (patches) ---(checkout)------------> GCL+patches
              <--(commit)--------------- GCL+patches
^
|
(pull from) Mathaction has it's own maintain tree but I'd eventually
|          want to use it as a new Axiom and Magnus common front end.
|
MathAction
  ^
  | 
  (merge)
  |
  + (patches) ---(checkout)------------> MathAction+patches
              <--(commit)--------------- MathAction+patches
^
|
(separate) Eventually these two will merge algorithmically but not now
           so Magnus would be a separate subproject
|
Magnus
  ^
  | 
  (merge)
  |
  + (cluster) ---(checkout)------------> Magnus+cluster
              <--(commit)--------------- Magnus+cluster


I'm sure none of this is quite clear and seems overly complex.
However, I'm now the lead on 3 major projects and work "next to"
and eventually with other projects. I do all of the above things
by hand at the moment and it would be very nice to have support
software capable of handling the job(s). 

Some of this is covered well by all of the software. I switched
from CVS to Arch and was working with it reasonably well, although
I got the impression that I "didn't get it" and was using it wrong.
I eventually ran out of disk space on the machine that was hosting
Arch (where I was a guest) so I had to take it down. 

I currently fund a machine for axiom development (axiom-developer.org)
out of my own pocket so disk space costs are less of a problem. However
my effort to get Arch working failed and I gave up in frustration. For
the life of me I can't seem to figure out how to get the web server to
give me the files. I did it once and can't get it to work again.

One problem I see is that the standard expectation is that every
project is "standalone". The user is expected to fetch and build
not only the desired project but also several other projects it uses.

For instance, Axiom uses GCL but it uses a patched version. I'd like
to be able to fetch the raw version from the GCL site or the patched
version "pulled thru" the Axiom site. I have to be able to pull a
particular version or tarball because I test the main branch of Axiom
every time with every change of GCL before I publish Axiom. You
can expect that the version of GCL used by Axiom will work (and you
can't expect that a non-tested version will work).

I no longer view Axiom as a "standalone" project and, as the
complexity of the pile builds up (Doyen will use Axiom, Magnus, and
MathAction just to name 3 projects) there needs to be support for
a single checkout point of a multi-project pile. The single checkout
point needs to present a "view" that includes patches to the subprojects.
(Subprojects won't always accept patches upstream). GCL faces the same
issues with things like gmp, etc.

I suspect Arch could be hacked so that it would invoke programs to
pull in "virtual branches" (like GCL) but this adds to the complexity
of an already complex program.

Really what we seem to need is a "make" style program that sits behind
the "checkout" request. A checkout for "axiom" would run a bunch
of stanzas to fetch, patch, and forward the correct, collected source
tree. CVS and Arch don't seem to have this functionality and even if
they did it would end up buried in a 300-option command line.

Methinks the world needs a new kind of person, a "project librarian",
who has the job of building and maintaining meta-projects by contacting
and working with other librarians. The complexity of maintaining a
repository that holds dozens of cooperating projects makes my hair hurt.

Anyway, one mistake at a time... I'll try to recover the Arch tree.

\start
Date: Thu, 4 Nov 2004 08:32:01 -0800 (PST)
From: Cliff Yapp
To: Camm Maguire, Tim Daly
Subject: Re: Active arch branches listed somewhere?

--- Camm Maguire wrote:

> Greetings!
> 
> Tim Daly writes:
> 
> > Unfortunately no. I had arch running on tenkan but got kicked off 
> > because arch ate too much space. I bought a machine and the 
> > axiom-developer.org domain but I don't seem to be able to get arch
> > running there. It's been a source of frustration.
> 
> My condolences for the frustration.  We seem to have a hard choice -
> a revision control system with a lot of nice advanced features that
> is not widely used and has no support on public servers like 
> savannah, or a more limited system (CVS) which has such public 
> infrastructure support but is more limited in its branching options.

Given Axiom's trend for doing things the "right way" it would be
asthetically satisfying if that trend could be continued in the
development tools, although I grant you that's probably a rather silly
impulse ;-).  

Not that I have any experience with Arch, but what OS are you running
on axiom-developer.org?  I have successfully installed Arch on Debian
and Gentoo linux (courtesy of their package systems) but I've never
tried hooking it to the web.  Was the web based part the main problem?

> Savannah has told me they plan to get subversion sometime, which
> might be a good middle ground.  But can I suggest for the time 
> being to commit your arch branches into cvs as separate branches 
> or 'modules'? I think cvs import can separate the code in this 
> manner.

I always thought the model that made sense for the way Tim is working
is to have the "hard core" server with all the experimental code using
Arch.  This keeps the casual users from stumbling into it since they
have to jump the Arch hurdle, but allows the determined to check out
the lastest stuff.  Savannah seemes like the logical place for the main
releases, which will not need the complex versioning structure.  In the
case of Maxima people normally keep local trees for the major work and
then merge into the main one when things are shaping up.  In this case,
Tim would merge each tree into the main savannah cvs when it was ready,
and otherwise keep in in Arch land.  Was that what you were thinking
Tim?

\start
Date: Thu, 4 Nov 2004 17:42:40 +0100
From: Pierre Doucy
To: Camm Maguire
Subject: Re: Active arch branches listed somewhere?

Hi all,

just out of curiosity, I'd like to know what kind of problems you've
had trying to set up arch on your machine.
I'm using it quite a lot now, and everything seems rather simple.
I even used it on my sf.net sftp account without any problems.

Pierre


On 04 Nov 2004 10:12:49 -0500, Camm Maguire wrote:
> Greetings!
> 
> Tim Daly writes:
> 
> > Unfortunately no. I had arch running on tenkan but got kicked off
> > because arch ate too much space. I bought a machine and the
> > axiom-developer.org domain but I don't seem to be able to get arch
> > running there. It's been a source of frustration.
> >
> 
> My condolences for the frustration.  We seem to have a hard choice --
> a revision control system with a lot of nice advanced features that is
> not widely used and has no support on public servers like savannah, or
> a more limited system (CVS) which has such public infrastructure
> support but is more limited in its branching options.
> 
> Savannah has told me they plan to get subversion sometime, which might
> be a good middle ground.  But can I suggest for the time being to
> commit your arch branches into cvs as separate branches or 'modules'?
> I think cvs import can separate the code in this manner.

\start
Date: Thu, 4 Nov 2004 11:01:04 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Active arch branches listed somewhere?

>Given Axiom's trend for doing things the "right way" it would be
>asthetically satisfying if that trend could be continued in the
>development tools, although I grant you that's probably a rather silly
>impulse ;-).  

umm, presuming you think my way is the "right way", which not even *I*
tend to agree with some days :-)

but, yes, i'd like to see some global re-think of the idea of a 
code repository/configure/make. as my programming world gets ever
more complex i'm beginning to identify issues that needs clever
solutions. one issue that is beginning to surface is related to 
Doyen, which is intended to be a scientific platform built on the
LiveCD/Quantian idea. It needs to be able to pull/patch multiple
projects that it does not host. These issues are also there in
Axiom but were never as clear.

In fact, if we take the "30 year horizon" view it is clear that we
need to think about very complex applications that transparently
include customized sub-projects. in the current instance we have
the notion of an "office suite" (openoffice) which really is just
a large number of cooperating applications. a project that includes
many other projects (as Doyen intends) will need more than a code
repository. it will need a "library" system that can pull/patch
whole cross-sections of code.

>Not that I have any experience with Arch, but what OS are you running
>on axiom-developer.org?  I have successfully installed Arch on Debian
>and Gentoo linux (courtesy of their package systems) but I've never
>tried hooking it to the web.  Was the web based part the main problem?

I believe it is a redhat 9 system. The hosting company set it up.
I just buy the service.

I have a new open source lab with two dozen machines I'm configuring.
I'm setting up a web server on one now to try to debug this problem
(which is clearly just a lack of understanding on my part). Once I
get it working locally I'll turn my attention back to axiom-developer.org
and get it working there. Perhaps I can convince a student to undertake
the "library" program problem (but I doubt it; 'tisn't sexy, yaknow?)

>I always thought the model that made sense for the way Tim is working
>is to have the "hard core" server with all the experimental code using
>Arch.  This keeps the casual users from stumbling into it since they
>have to jump the Arch hurdle, but allows the determined to check out
>the lastest stuff.  Savannah seemes like the logical place for the main
>releases, which will not need the complex versioning structure.  In the
>case of Maxima people normally keep local trees for the major work and
>then merge into the main one when things are shaping up.  In this case,
>Tim would merge each tree into the main savannah cvs when it was ready,
>and otherwise keep in in Arch land.  Was that what you were thinking
>Tim?

yes, that's exactly it. i have no plans to change the savannah CVS
site as it is globally known and easy to find. However I'd like to 
encourage more participation (having already given out pieces of code like
hyperdoc to various people) that didn't require me to be the bottleneck.
so a while ago I started unwinding the current code pile I maintain
locally to split out the various interesting pieces into branches.
that way people could hack particular branches independently. the
arch server i set up identified about a dozen separate projects.

\start
Date: Thu, 04 Nov 2004 17:37:09 +0000
From: Nic Doye
To: Cliff Yapp
Subject: Re: Active arch branches listed somewhere?
Cc: Camm Maguire

On an arch-related viewpoint. canonical are trying to recreate arch in a
more friendly manner called bazaar.

http://www.canonical.com/projects/bazaar/

\start
Date: Thu, 4 Nov 2004 11:31:37 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Active arch branches listed somewhere?
Cc: Camm Maguire

--- Tim Daly wrote:

> >Given Axiom's trend for doing things the "right way" it would be
> >asthetically satisfying if that trend could be continued in the
> >development tools, although I grant you that's probably a rather
> >silly impulse ;-).  
> 
> umm, presuming you think my way is the "right way", which not even
> *I* tend to agree with some days :-)

Well, from what I've seen you're doing very impressive work.  Your
documentation system is very much the "right way" - adding the research
and the code together with literate programming is probably something
Knuth would dream of seeing achieve fruition.  I was also thinking of
Axiom itself though - it seems to go to great lengths to do the
mathematics the "right way" rather than just a "get an answer" way. 
This isn't always the "best" way for things like practical
get-the-job-done applied math, but for mathematical research it seems
to make Axiom unique.

> but, yes, i'd like to see some global re-think of the idea of a 
> code repository/configure/make. as my programming world gets ever
> more complex i'm beginning to identify issues that needs clever
> solutions. one issue that is beginning to surface is related to 
> Doyen, which is intended to be a scientific platform built on the
> LiveCD/Quantian idea. It needs to be able to pull/patch multiple
> projects that it does not host. These issues are also there in
> Axiom but were never as clear.

Hmm.  Don't know anything clever there.  Usually people try to work
with the 3rd party programs to incorporate the patches, but I guess for
something like Axiom that may not be possible.

> In fact, if we take the "30 year horizon" view it is clear that we
> need to think about very complex applications that transparently
> include customized sub-projects. 

Sounds like CORBA :-).

> in the current instance we have the notion of an "office suite"
> (openoffice) which really is just a large number of cooperating 
> applications. a project that includes many other projects (as Doyen 
> intends) will need more than a code repository. it will need 
> a "library" system that can pull/patch whole cross-sections of code.

But Doxyen isn't a single integrated environment, correct?  I don't see
how that is possible - Axiom might reach the point where all of its
underlying assumptions are well described at all levels of the system
(the "right way" ;-) but I don't think there is any other system I am
aware of that is even close to that level of sophistication.  If there
is a more specialized program (like Macaulay2, Singular, GAP) trying to
function as a subsystem of a broader program, the broader program might
not have even defined all the parameters the specialized program would
need, except as implicit assumptions.  And then if the subprogram does
return a result, there may be parameters used in the subsystem which
SHOULD impact how subsequent calculations should be done in the calling
program, but the parent program might not even be programmed to handle.
 I can certainly understand the desire to incorporate the excellent
work done in these programs, but I'm not quite sure how you could
ensure that the mathematical "environment" in which the calculation
takes place is sufficiently uniform to be correct.  If somebody knows a
way to do this short of rewriting the programs as parts of Axiom (which
I suppose is not out of the question, except that version of Axiom
would be GPL) please please pretty please tell me I'm wrong and it is
possible.

If you don't integrate systems like this, it seems like normal
Debian/Gentoo/BSD style package management should handle obtaining the
various needed sources and patching them.  I have seen gentoo do this
in the past - in fact I think the Macaulay2 ebuild does just that.

> I have a new open source lab with two dozen machines I'm configuring.

Must... control... geek... envy...

> I'm setting up a web server on one now to try to debug this problem
> (which is clearly just a lack of understanding on my part). Once I
> get it working locally I'll turn my attention back to
> axiom-developer.org and get it working there. Perhaps I can convince 
> a student to undertake the "library" program problem (but I doubt 
> it; 'tisn't sexy, yaknow?)

[snip]

> yes, that's exactly it. i have no plans to change the savannah CVS
> site as it is globally known and easy to find. However I'd like to 
> encourage more participation (having already given out pieces of code
> like hyperdoc to various people) that didn't require me to be the
> bottleneck.

Makes sense :-).

> so a while ago I started unwinding the current code pile I maintain
> locally to split out the various interesting pieces into branches.
> that way people could hack particular branches independently. the
> arch server i set up identified about a dozen separate projects.

That reminds me - what's the status of the Axiom book?  Is it up
somewhere as a PDF?  Is anybody planning to get a new edition published
somewhere when Axiom 1.0 (or whatever the version is) is released?

CY

P.S. - Has anybody read a copy of Michael J. Wester's Computer Algebra
Systems : A Practical Guide?  It seems like it might be a good place to
look for ways to make Axiom (or any free CAS for that matter) better.
http://www.amazon.com/exec/obidos/tg/detail/-/0471983535/qid=1099596462/sr=1-1/ref=sr_1_1/104-8290387-0282321?v=glance&s=books

\start
Date: Thu, 4 Nov 2004 13:58:55 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Active arch branches listed somewhere?
Cc: Camm Maguire

the axiom book is in the CVS.
get the current CVS
cd axiom
export AXIOM=`pwd`/mnt/linux
make book
xdvi `pwd`/mnt/linux/doc/book.dvi

\start
Date: Fri, 5 Nov 2004 11:06:11 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Active arch branches listed somewhere?

> 
> That reminds me - what's the status of the Axiom book?  Is it up
> somewhere as a PDF?  Is anybody planning to get a new edition 
> published somewhere when Axiom 1.0 (or whatever the version is)
> is released?
> 
> CY
> 

http://page.axiom-developer.org/zope/mathaction/AxiomDocumentationAndComm=
uni
ty

Tutorials

There is a good introduction to Axiom by Martin N. Dunstan (in English) =
at
http://www.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial. An even =
more
complete introduction by Daniel Augot (in French) is available at
http://www-rocq.inria.fr/codes/Daniel.Augot/axiom_intro.pdf.

The Axiom Book

An electronic version of the wonderful Axiom book by Richard D. Jenks
and Robert S. Sutor is available online as a large pdf
http://page.axiom-developer.org/zope/Plone/refs/books/axiom-book2.pdf,
but it is of course also included in the distribution
http://page.axiom-developer.org/zope/mathaction/AxiomDownload.


\start
Date: Fri, 5 Nov 2004 11:40:38 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Active arch branches listed somewhere?

Tim,

There seems to be a common misconception about how GNU arch
"installs" on a server. In fact from the docs that I found
one does not need to install the tla program on the server
at all. Instead all that is needed is a way for the tla that
is installed on your workstation to talk to the server via
webdav or sftp etc.

Accessing a directory on a server running under Apache
requires that Apache be appropriately configured. Apache on
axiom-developer.org has all of the preliminary stuff done
such as enabling mod_dav etc. but for each directory on which
one wants webdav access it is necessary to configure the
appropriate aliases and specify the option DAV On. I have
done this as a test example at

  http://page.axiom-developer.org/webdav

You should be able to access the directory via webdav. If
the arch repositories where located there, then you should
have no problem accessing them in the ususal way. If you
manage to test this and it works, I can help you set up
a more reasonably named place on axiom-developer for your
project archives.

Regards,
Bill Page.

> -----Original Message-----

> Hi all,
> 
> just out of curiosity, I'd like to know what kind of problems
> you've had trying to set up arch on your machine. I'm using it
> quite a lot now, and everything seems rather simple.
> I even used it on my sf.net sftp account without any problems.
> 
> Pierre
> 
> 
> On 04 Nov 2004 10:12:49 -0500, Camm Maguire wrote:
> > Greetings!
> > 
> > Tim Daly writes:
> > 
> > > Unfortunately no. I had arch running on tenkan but got kicked
> > > off because arch ate too much space. I bought a machine and the
> > > axiom-developer.org domain but I don't seem to be able to get arch
> > > running there. It's been a source of frustration.
> > >
> > 

> -----Original Message-----
> 
> if memory serves me the issue was getting it to work with the
> webdav protocol on the apache server. i'll look at the article
> you recommended as soon as i can.
> 

> -----Original Message-----

>Not that I have any experience with Arch, but what OS are you running
>on axiom-developer.org?  I have successfully installed Arch on Debian
>and Gentoo linux (courtesy of their package systems) but I've never
>tried hooking it to the web.  Was the web based part the main problem?

I believe it is a redhat 9 system. The hosting company set it up.
I just buy the service.

I have a new open source lab with two dozen machines I'm configuring.
I'm setting up a web server on one now to try to debug this problem
(which is clearly just a lack of understanding on my part). Once I
get it working locally I'll turn my attention back to axiom-developer.org
and get it working there. Perhaps I can convince a student to undertake
the "library" program problem (but I doubt it; 'tisn't sexy, yaknow?)

\start
Date: Sun, 07 Nov 2004 15:04:12 +0100
From: David Mentre
To: Bill Page
Subject: Re: Active arch branches listed somewhere?

Hello,

Bill Page writes:

> There seems to be a common misconception about how GNU arch
> "installs" on a server. In fact from the docs that I found
> one does not need to install the tla program on the server
> at all. Instead all that is needed is a way for the tla that
> is installed on your workstation to talk to the server via
> webdav or sftp etc.

Exactly. You do not need to install arch on server. You just need an
access to the public repository.

The turorial explains this quite well:
http://www.gnu.org/software/gnu-arch/tutorial/shared-and-public-archives.html#Shared_and_Public_Archives
See "Mirroring a Local Archive Remotely".

And it is overly simple with an ssh account, just use sftp URL.

For example, I have:

# My arch repository on my local disk:
David Mentre--2004-code
    /home/david/{archives}/2004-code

# the copy of this repository on linux-france.org:
David Mentre--2004-code-MIRROR
    sftp://linux-france.org/home/lf/dmentre/html/arch-ive

Each time you do a local commit, update your public mirror with "tla
archive-mirror".

I do this automatically, as well as sending an email on a list and
making available a tarball of the sources, for my own project with
following "~/.arch-params/hook" file:


--=-=-=

#!/bin/sh

# Original script from: Sascha Silbe <sascha-ml-gnu-arch-users@silbe.org>

# ARCH_ARCHIVE: always
#   represents the archive on which the action is being performed
# 
# ARCH_LOCATION: make-archive
#   gives the location of the archive being prepared by tla
# 
# ARCH_REVISION: import, tag, commit
#   gives the exact revision being (import|tagg|commit)ed
# 
# ARCH_CATEGORY: make-category
#   gives the category being prepared (format: category)
# 
# ARCH_BRANCH: make-branch
#   gives the branch being prepared (format: category--branch)
# 
# ARCH_VERSION: make-version
#   gives the version being prepared (format: category--branch--version)
# 
# ARCH_TREE_ROOT: commit, import
#   gives the location of the working tree from which tla is performing
#   the action
# 
# ARCH_TAGGED_ARCHIVE: tag
#   gives the archive of the revision from which tla will create the tag
# 
# ARCH_TAGGED_REVISION
#   gives the revision from which tla will create the tagged version

ARCH_ACTION="$1"

doPrepLog() {
    tla cat-archive-log "${ARCH_ARCHIVE}/${ARCH_REVISION}"
}

doMirror() {
    echo "* update mirror"
    tla push-mirror "${ARCH_ARCHIVE}" "`tla parse-package-name --package-version $ARCH_REVISION`"
}

doSendMail() {
    local recipients="${1}"

    echo "* send email to ${recipients}"
    cat "${logfile}" | mailx -s "arch ${ARCH_ACTION}: ${ARCH_REVISION}" ${recipients}
#  mutt -s "arch ${ARCH_ACTION}: ${ARCH_REVISION}" -i "${logfile}" -e 'unset signature' ${recipients}
}

doTagTarball() {
# works without being in the source tree
    local current_dir=`pwd`
    local targetdir="${1}"
    local tarball_name="`tla parse-package-name --package-version $ARCH_REVISION`"
    local temp_dir="`mktemp -d`"
    local tarball_dir=${temp_dir}/${tarball_name}

    echo "* updating tarball on ${targetdir}"
    echo "** making archive tree"
    cd ${temp_dir}
    tla get $ARCH_REVISION $tarball_name

    echo "** making ${tarball_name} tarball"
    cd ${temp_dir}
    tar --exclude '*{arch}*' --exclude '*.arch-ids*' -zcf ${tarball_name}.tar.gz ${tarball_name}
    echo "** copying ${tarball_name} to ${targetdir}"
    scp ${temp_dir}/${tarball_name}.tar.gz ${targetdir}

    cd $current_dir
    rm -rf ${temp_dir}/
}

doUpdateTarball() {
# we need to be in the source tree for this function to work
    local current_dir=`pwd`
    local targetdir="${1}"
    local tarball_name="`tla parse-package-name --package-version $ARCH_REVISION`"
    local temp_dir="`mktemp -d`"
    local tarball_dir=${temp_dir}/${tarball_name}
    local files="`tla inventory -s`"

    echo "* updating tarball on ${targetdir}"
    echo "** making archive tree"
    mkdir ${tarball_dir}
    tar c ${files} | (cd ${tarball_dir}; tar xf -)
     
    echo "** making ${tarball_name} tarball"
    cd ${temp_dir}
    tar -zcf ${tarball_name}.tar.gz ${tarball_name}
    echo "** copying ${tarball_name} to ${targetdir}"
    scp ${temp_dir}/${tarball_name}.tar.gz ${targetdir}

    cd $current_dir
    rm -rf ${temp_dir}/
}

echo "* hook called for: ${ARCH_ACTION}"
# echo "ARCH_REVISION: ${ARCH_REVISION}"
# echo
# echo " pwd: `pwd`"

case "${ARCH_ACTION}" in
    tag)
        ARCH_CATEGORY="`tla parse-package-name --category $ARCH_REVISION`"
        ARCH_BRANCH="`tla parse-package-name --branch $ARCH_REVISION`"
        logfile="`tempfile`"
        doPrepLog > "${logfile}"
        case "${ARCH_REVISION}" in
            test--*)
                doSendMail david
                doTagTarball lfo:html/tmp/
                ;;
            demexp--*)
                doMirror
                doTagTarball lfo:html/demexp/latest-src/
                doSendMail demexp-cvs@nongnu.org
                ;;                
        esac
        rm "${logfile}"
        ;;
    commit | import)
        ARCH_CATEGORY="`tla parse-package-name --category $ARCH_REVISION`"
        ARCH_BRANCH="`tla parse-package-name --branch $ARCH_REVISION`"
        logfile="`tempfile`"
        doPrepLog > "${logfile}"
        case "${ARCH_REVISION}" in
            test--*)
                doSendMail david
                doUpdateTarball lfo:html/tmp/
                ;;
            demexp--*)
                doMirror
                doUpdateTarball lfo:html/demexp/latest-src/
                doSendMail demexp-cvs@nongnu.org
                ;;                
        esac
        rm "${logfile}"
        ;;
    *)
        ;;
esac

\start
Date: Sun, 07 Nov 2004 15:22:27 +0100
From: David Mentre
To: Tim Daly
Subject: Re: CVS, Arch, Darcs
Cc: Camm Maguire, Bill Page

Hello Tim,

Tim Daly writes:

> Some of this is covered well by all of the software. I switched
> from CVS to Arch and was working with it reasonably well, although
> I got the impression that I "didn't get it" and was using it wrong.
> I eventually ran out of disk space on the machine that was hosting
> Arch (where I was a guest) so I had to take it down. 

Once again:

 - use Arch on your local machine, with a lot of free disk space;

 - make a mirror of your local Arch archive to the axiom-developer.org
   server.


To give figures, for about 100Ko of compressed sources (per release):

 - my local arch tree where I work takes 20 MBytes;

 - the local Arch repository is about 4 MBytes (for about 200 releases);

 - the remote Arch repository is also of about 4 MBytes.
 

[...]
> Methinks the world needs a new kind of person, a "project librarian",
> who has the job of building and maintaining meta-projects by contacting
> and working with other librarians. The complexity of maintaining a
> repository that holds dozens of cooperating projects makes my hair hurt.

In some sense, the people making packages in Linux distributions (like
Camm as a Debian developer) are doing exactly this: make a coherent set
from a set of sources on the Net. To attack this complexity, they are
defining policy and rules like in the Debian Policy Manual
(http://www.debian.org/doc/debian-policy/).

Other people are doing similar things in an OS agnostic but language
specific way with GODI packaging system for OCaml software
(http://godi.ocaml-programming.de/). Once again, real people are behind
software packaging.

I cannot comment further on your proposal and certainly won't volunteer
for the job, but your long term vision is probably right. However, we
are probably a too small comunity to be able to do this right now.

\start
Date: Fri, 12 Nov 2004 11:17:30 +0200
From: Constantine Frangos
To: list
Subject: (no subject)

Hi there,

I recently downloaded the Axiom tutorial and am very interested in
trying out this program on my linux system. I have been using the
Matlab extended symbolic toolbox for the last five years in the
modelling and control of mechanical systems, and would like to compare
with Axiom.

I have a suse linux 7.2 installation with gcc version 2.95.3. Will the
source code compile under this version of gcc ?? Alternatively, is it
possible for somebody to do a static compilation of the source code and
place these binaries on your website ??

\start
Date: Fri, 12 Nov 2004 10:16:20 -0500
From: Tim Daly
To: Constantine Frangos
Subject: Re: [Axiom-mail] (no subject)

I'm unaware of any issues related to GCC 2.95.3
Axiom is mostly written in Common Lisp so if you get GCL to
compile (the first steps of the Axiom build) it is likely that
the complete system will build.

I don't have SUSE running anywhere but I believe I could build
a 2.95.3 copy of GCC.

Since you have it already set up just try to build Axiom:

cd /tmp
cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/axiom co axiom
cd axiom
export AXIOM=/tmp/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
make

when this build completes you should be able to type

axiom

and have a running system. If you do the build in an emacs shell buffer
you can email the failure to "Tim Daly" and I can try to figure out
what failed.

\start
Date: Sun, 14 Nov 2004 17:38:54 +1100
From: Jason White
To: list
Subject: Scientific Computing with Free software on GNU/Linux HOWTO

I noticed that Axiom wasn't mentioned in the Scientific Computing with
Free software on GNU/Linux HOWTO:
http://www.tldp.org/HOWTO/Scientific-Computing-with-GNU-Linux/

Is this deliberate in as much as Axiom hasn't been officially
released? If not, then perhaps the maintainer of the HOWTO could be
encouraged to include it in the next revision.

It isn't clear exactly which Web pages to cite: the project page at
http://nongnu.org/axiom/ is somewhat out of date (the Axiom book is
still noted as forthcoming, for example).
http://page.axiom-developer.org/ might be a better reference. Either
way, whenever Axiom is ready for publicity we could request that it be
added.

\start
Date: Sun, 14 Nov 2004 21:20:47 -0500
From: Bill Page
To: Jason White
Subject: RE: Scientific Computing with Free software on GNU/Linux HOWTO

On Sunday, November 14, 2004 1:39 AM Jason White wrote:

> 
> I noticed that Axiom wasn't mentioned in the Scientific Computing
> with Free software on GNU/Linux HOWTO:
> http://www.tldp.org/HOWTO/Scientific-Computing-with-GNU-Linux/
> 
> Is this deliberate in as much as Axiom hasn't been officially
> released? If not, then perhaps the maintainer of the HOWTO could
> be encouraged to include it in the next revision.

I think Axiom should be listed at the above site. I see not
reason to wait until there is an "official" release since this
could end up being a long time. In the mean time I think that
the Axiom project could use as many new users as possible.
Some of these might well be sufficiently motivated to help
bring Axiom to it's first official release state.

Unless somebody else here says "no" with good reasons, I think
you should go ahead and inform the maintainer of www.tldp.org
about Axiom and recommend that it be added.

> 
> It isn't clear exactly which Web pages to cite: the project
> page at http://nongnu.org/axiom/ is somewhat out of date
> (the Axiom book is still noted as forthcoming, for example).

I have to admit that that currently is a bit of a problem!

The site you mention above has been replaced by Tim Daly with
the following web site:

  http://axiom.axiom-developer.org

as the default home page for the developer site:

  http://savannah.nongnu.org/projects/axiom

I am not exactly sure why he did this. ??

I think the contents of Tim's pages are more up to date but
apparently Tim has not yet had enough time to complete the
transition since there are still a few rough edges. Unfortunately
the web pages at http://axiom-axiom-developer.org can only be
updated by Tim Daly.

Both http://axiom-developer.org and
     http://www.axiom-developer.org
currently are redirected to the above page.

The pages at http://nongnu.org/axiom however can still be
updated by any of the developers with CVS access at Savannah.
In fact I did update it in September to point to the page you
mention below, but as far as I know, no other changes have
been made since they were first designed by David Mentre.

> http://page.axiom-developer.org/ might be a better reference.

There is also a link to this page at axiom.axiom-developer.org
where it is called 'wiki'. But this page is really just a
"place holder" page that currently I can update. It contains
links to the Axiom Portal

  http://page.axiom-developer.org/zope/Plone

and the MathAction wiki

  http://page.axiom-developer.org/zope/mathaction

There is also a link to the test environment for further
development of Axiom Portal and MathAction itself and few
selected other relevant links.

Recently Martin Rubey has done an excellent job of cleaning
up the MathAction wiki so that it also now serves as a good
starting point for new Axiom users. Both MathAction and the
Axiom Portal have the advantage that they can be updated by
anyone, directly over the web.

I think perhaps the best web reference for now might be

  http://www.axiom-developer.org

In the future once we straighten all this out, either that
can become the "official" home page for Axiom users or else
it can be redirected to the right place. Anyone else have
a better suggestion?

Note however that the computer where axiom-developer.org
resides is currently paid for privately by Tim Daly. I have
suggested previously that if we (collectively) see an advantage
to having parts of the Axiom support web pages (such as Axiom
Portal or MathAction) hosted on a "paid for" site such as
axiom-developer.org which has more flexibility than Savannah
or some other free open source development site, then I think
that it would be appropriate to call for donations to help
with funding this site. I think the costs right now are on
the order of $60 per month.

> Either way, whenever Axiom is ready for publicity we could
> request that it be added.
> 

I say do it now!

\start
Date: Mon, 15 Nov 2004 13:49:12 +1100
From: Jason White
To: Bill Page
Subject: RE: Scientific Computing with Free software on GNU/Linux HOWTO

Bill Page writes:
 > 
 > I think Axiom should be listed at the above site.

\start
Date: Mon, 15 Nov 2004 08:46:48 -0500
From: Tim Daly
To: Constantine Frangos
Subject: Re: [Axiom-math] (no subject)

Constantine,

I tried to reply to your previous message but it bounced.
You sent it from some random numeric username it seems.
Anyway, I retried the instructions I sent you and they work here.

In any case, I've put a recent tarball of Axiom at:
http://axiom.axiom-developer.org/axiom-website/download.html

Click on the link that reads:
  "The source code tarball from November 15, 2004 is here"
and store it somewhere (I'm assuming /tmp but you can put it anywhere
if you replace the /tmp)

Once you get it type:
tar -zxf axiom.20041115.tgz
cd axiom
export AXIOM=/tmp/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
make
(wait until the build completes)
axiom

\start
Date: Tue, 16 Nov 2004 08:06:43 -0500
From: Tim Daly
To: Constantine Frangos
Subject: Re: [Axiom-math] (no subject)

Constantine,

First, my apologies. There was a file missing from the tarball.
I've uploaded a new version. But that isn't the problem you're
having it seems.

In slightly more detail the directions are:

This is not a binary distribution since I don't have access to 
a SUSE 7.2 box. This is a source distribution. You have to build
it before you install it in /usr/local. The steps to build it are:

 a) decide on a place to build axiom. lets assume you choose /tmp
    If you decide to build it somewhere else change "/tmp" to that place.

cd /tmp

 b) get a the newly clean download of the tarball. it is at:

http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom.20041115.tgz

 c) save the tarball to /tmp

 d) unpack the tarball:

tar -zxf axiom.20041115.tgz

 e) this will create a new directory in /tmp called "axiom". go there:

cd /tmp/axiom

 f) the build needs a shell variable called "AXIOM" set to the location
    of the build and the type of the machine. Since I have never built
    a SUSE box we can only assume it is a "standard linux", thus do:

export AXIOM=/tmp/axiom/mnt/linux

 g) just for convenience you can also set the PATH variable:

export PATH=$AXIOM/bin:$PATH

 h) now you are ready to start the build. The build goes thru many
    different phases and, as long as it doesn't stop it will build
    a working axiom. If you work in an emacs shell buffer you can
    capture all of the output. In any case, if there is a failure
    please mail the output to "Tim Daly" and copy the list
    "list":

make

 i) the make will take something proportional to 3 hours on a 2Ghz box.

 j) when the make finishes you should have a running axiom. To test it
    you can just start axiom, type '1+1' and then type ')quit' to exit:


axiom
1+1
)quit

 k) if step j worked you can, but are not required to, install axiom 
    into any location you want. By default it will install into
    "/usr/local/axiom". You need to be root to install it in the system
    tree but you could install it anywhere. In fact, all you need to
    keep is the /tmp/axiom/mnt subdirectory. The rest is just overhead
    at this point. 

su - root
make install
exit

 l) the actual axiom command requires that the 'AXIOM' shell variable
    tell axiom where it lives. So you will need to set this variable.
    Also, the 'axiom' command needs to be added to your path. 

export AXIOM=/usr/local/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
axiom

 m) in order to simplify life you could make an axiom command in your
    default path. So, for example, if your PATH includes /usr/local/bin
    you can type: (be sure to use single quotes, not double quotes)

su - root
echo 'export AXIOM=/usr/local/axiom/mnt/linux' >/usr/local/bin/axiom
echo 'export PATH=$AXIOM/bin:$PATH' >/usr/local/bin/axiom
echo 'AXIOMsys' >/usr/local/bin/axiom
chmod a+x /usr/local/bin/axiom
exit

 n) if you do step 'm' above any user can run axiom by just typing:

axiom

Let me know if this works or fails.

\start
Date: Wed, 17 Nov 2004 09:30:51 -0500
From: Tim Daly
To: list
Subject: superman
Cc: Gilbert Baumslag

*,

I've mostly finished another piece of the puzzle.
It is now possible to run graphics from within axiom.
To test this you need to build the latest version and then type:

sman            <--- this will start the superman process, which starts axiom
                     there will be a lot of complaints. ignore them.
                     you could type 'sman 2>/dev/null' to start quietly.

(axiom should start)

draw(sin(x),x=-10..10)                <--- 2d graphics example
draw(sin(x,y),x=-10..10,y=-10..10)    <--- 3d graphics example



There is, of course, more to do so I haven't made this the default way
to start axiom but that too is coming. I've been running tests against
the CRC handbook of curves and surfaces and it looks pretty good although
I still have one bug to track down. I also have to integrate the test
cases, reimplement the axiom shell script, document the pile better, etc.

As usual, send complaints to 'Tim Daly' and I'll do my best to help.

The next major piece of work is to rebuild the hypertex browser.

\start
Date: Wed, 17 Nov 2004 09:29:48 -0500
From: Bill Page
To: Tim Daly
Subject: RE: superman
Cc: Gilbert Baumslag

Tim,

That's fantastic! We could definitely use a lot more
"supermen" (more generically - "super-people") like
you... :) This is a giant leap forward.

Cheers!

Bill Page.

> -----Original Message-----
> From: root [mailto:Tim Daly]
> Sent: Wednesday, November 17, 2004 9:31 AM
> To: list
> Cc: Gilbert Baumslag; Tim Daly
> Subject: superman
> 
> 
> *,
> 
> I've mostly finished another piece of the puzzle. It
> is now possible to run graphics from within axiom.
> To test this you need to build the latest version and
> then type:
> 
> sman            <--- this will start the superman process, 
> which starts axiom
>                      there will be a lot of complaints.
>                      ignore them. you could type
>                      'sman 2>/dev/null' to start quietly.
> 
> (axiom should start)
> 
> draw(sin(x),x=-10..10)                <--- 2d graphics example
> draw(sin(x,y),x=-10..10,y=-10..10)    <--- 3d graphics example
>
> ...

\start
Date: 17 Nov 2004 10:02:40 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: superman
Cc: Gilbert Baumslag

Greetings!

You da superman, Tim!  Am checking this out now.  Perhaps it might
warrant another Debian package snapshot.

So all development is via savannah for the forseable future, right?

Take care,

Tim Daly writes:

> *,
> 
> I've mostly finished another piece of the puzzle.
> It is now possible to run graphics from within axiom.
> To test this you need to build the latest version and then type:
> 
> sman            <--- this will start the superman process, which starts axiom
>                      there will be a lot of complaints. ignore them.
>                      you could type 'sman 2>/dev/null' to start quietly.
> 
> (axiom should start)
> 
> draw(sin(x),x=-10..10)                <--- 2d graphics example
> draw(sin(x,y),x=-10..10,y=-10..10)    <--- 3d graphics example
> 
> 
> 
> There is, of course, more to do so I haven't made this the default way
> to start axiom but that too is coming. I've been running tests against
> the CRC handbook of curves and surfaces and it looks pretty good although
> I still have one bug to track down. I also have to integrate the test
> cases, reimplement the axiom shell script, document the pile better, etc.
> 
> As usual, send complaints to 'Tim Daly' and I'll do my best to help.
> 
> The next major piece of work is to rebuild the hypertex browser.

\start
Date: Wed, 17 Nov 2004 10:01:29 -0500
From: Bill Page
To: Tim Daly
Subject: Urban Legends (was: superman)

Tim,

This one is for you:

Photo showing Tim Daly in his basement "home computer lab"

http://www.snopes.com/inboxer/images/rand.jpg

(From: Urban Legends Reference Pages :)

Cheers,
Bill Page.

> -----Original Message-----
> 
> Tim,
> 
> That's fantastic! We could definitely use a lot more
> "supermen" (more generically - "super-people") like
> you... :) This is a giant leap forward.
> 
> Cheers!
> 
> Bill Page.
> 
> > -----Original Message-----
> > From: root [mailto:Tim Daly]
> > Sent: Wednesday, November 17, 2004 9:31 AM
> > To: list
> > Cc: Gilbert Baumslag; Tim Daly
> > Subject: superman
> > 
> > *,
> > 
> > I've mostly finished another piece of the puzzle. It
> > is now possible to run graphics from within axiom.
> ...

\start
Date: 17 Nov 2004 10:20:00 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: CVS, Arch, Darcs
Cc: Bill Page

Greetings!  Just thought I'd add my feeble $.02 to Tim's breathtaking
vision. 

The goals are obviously quite impressive. In my work with GCL
supporting maxima, acl2, and axiom for Debian, though, I've already
run into obstacles associated with Lisp's extreme level of
integration.  A similar philosophy has killed Windows in comparison to
'keep-it-simple' modular Linux/unix design, IMHO.  For example, at
present, without some as-yet-to-be-implemented distributed patching
mechanism, a bug fix in GCL requires a rebuild of GCL + all three
programs on 12 architectures.  It appears that there is a definite
tradeoff between the advantages of integration to developers/users,
and a modular independent black box leggo-like construction for ease
of maintenance and bug fixing.  I still have more experience in C than
lisp, and would be pulling out all my hair even thinking about
implementing some of the spaghetti I've seen from scratch, at least in
C.  Simplicity and modularity let me leverage my feeble time resources
much better, in my experience.

Just a thought.

\start
Date: Wed, 17 Nov 2004 09:17:23 -0500
From: Tim Daly
To: list, Gilbert Baumslag
Subject: call for papers

fyi

There is a call for papers on Calculemus 2005, the 12th Symposium on
the Integration of Symbolic Computation and Mechanical Reasoning
http://imps.mcmaster.ca/calculemus-2005/call-for-papers.html

Perhaps it's time to install ACL2 under Axiom.

\start
Date: Wed, 17 Nov 2004 09:32:59 -0500
From: Tim Daly
To: Camm Maguire
Subject: call for papers
Cc: Gilbert Baumslag

Camm,

> so all development is via savannah for the forseable future, right?

I'm still using savannah for most things like CVS but I shifted the
web pages to axiom-developer.org (a data-center hosted box I pay for)
because I couldn't seem to update the web pages nor the download site
on savannah. These two pages are actually offsite links to my box.

In the longer term I'd like to recover Arch, which I had running 
previously. I blew out my guest disk space quota and got kicked off the
box. When I went to my own box I couldn't get Arch working again.
There is no such thing as a simple job.

I believe I've gotten Arch running locally (still one more thing to
check). Arch gives me better control over branching and has changesets
so I'm inclined to favor it. There are at least a dozen branches of
work on Axiom that I maintain locally, mostly in one big swamp. I
started breaking them out into separate arch branches so other people
could work on them. So one long term (next year or so) direction is to
use arch for development and CVS for working, released snapshots on
savannah.

Also, the test cases, like the graphics test cases I'm working on now,
are supposed to be combed out into the CATS (Computer Algebra Test Suite)
project. The plan is to take the CRC handbook of curves and surfaces and
encode it so that it can be used to test the graphics on several CA systems
rather than just Axiom. So CATS is technically a separate project and 
arch will support that better than CVS. At the moment CATS is just a
massive directory on my localhost.

\start
Date: Wed, 17 Nov 2004 10:56:59 -0500
From: Bill Page
To: Tim Daly
Subject: development on Savannah
Cc: Camm Maguire

Tim,

There is a very useful tutorial on arch in this month's
Linux Journal (November 2004) - highly recommended. For
background references see:

  http://www.linuxjournal.com/article/7752

tla certainly *is* complicated compared to things like darcs,
but then "no pain, no gain" I suppose...

I think re-establishing the arch repository for Axiom would
be a good idea. Please let me know if there is something that
I can do to help.

Regards,
Bill Page.

> -----Original Message-----

> Camm,
> 
> > so all development is via savannah for the forseable future,
> > right?
> 
> I'm still using savannah for most things like CVS but I shifted
> the web pages to axiom-developer.org (a data-center hosted box
> I pay for) because I couldn't seem to update the web pages nor
> the download site on savannah. These two pages are actually
> offsite links to my box.

Tim, did you have trouble updating the Savannah webcvs? It works
just the same way as the source cvs. All you need to do is
update the webcvs the way you do with the source and the content
"just magically" shows up at http://nongnu.org/axiom This was
working the last time I tried.

> 
> In the longer term I'd like to recover Arch, which I had
> running previously. I blew out my guest disk space quota and
> got kicked off the box. When I went to my own box I couldn't
> get Arch working again. There is no such thing as a simple job.
> ...

\start
Date: Wed, 17 Nov 2004 10:06:51 -0500
From: Tim Daly
To: Camm Maguire
Subject: breathtaking vision
Cc: Gilbert Baumslag

Camm,

We're running into the limits of the lego model, I believe.
It wouldn't be reasonable to expect a user to collect the various
parts required to build Axiom although a subset of us consider it
the best path.

Consider larger "breathtaking", 30 year horizon projects like
the Crystal effort which collects and integrates dozens of tools. My
gut feeling is that the lego model collapses. We still need modularity
but we need it at a much bigger level. Sort of the prefab-house level
where somebody already integrated the kitchen and living room.

This is beginning to be clear with various projects. There is one
recently announced (Wired) that is a music studio similar to CakeWalk
or ProTools. For such a project you need sound generators, score
construction, codecs, CD rip/burn tools, A-D/D-A I/O board
controllers, midi tools, etc.  I have most of these around but the
Wired project is an integration problem. If I download these and
install them from rpms I end up doing a Wired rebuild every time
Lilypond (a scoring program) changes. Worse yet, that thrusts the
debugging problem onto me. In the case of Wired I just want a tool
that is comprehensive and "just works" so I'd rather they did the
integration with Lilypond and handled new versions.

The GCL case conflates two activities. The first is maintaining
GCL and the second is packaging axiom/maxima/acl2. From a GCL point of
view the axiom program is a big test suite. From the axiom point of view
GCL is flooring and wallboard. The fact that you do both activities makes
it feel like they're connected but it is entirely possible to keep them
at different levels.

Axiom is carefully tested each release with a particular snapshot of GCL
which is packaged with the system. There has been some flak for this
but we don't want users trying to debug failures due to GCL
changes.  So axiom is a stable release or so behind the GCL leading
edge but the users don't need to know that. And axiom developers are
the right people to either feed patches back to GCL or hot patch the
system for changes GCL doesn't want or need. If users try to assemble a
large, integrated system from parts they have to have these skills
which is unlikely in the larger world.

\start
Date: Wed, 17 Nov 2004 10:15:41 -0500
From: Tim Daly
To: Bill Page
Subject: savannah webcvs
Cc: Gilbert Baumslag

Bill

Somehow my ability to update certain pieces of savannah got smashed
during the january outage. I suspect my host key is out of sync with
the local key. I tried to upload web pages and files for the download
area without success. I had a pending help request from a while ago
that never got answered. So, being in problem solving mode and under
a deadline to update the pages I routed around the blockage. There
is no reason why they can't move back but I still have a pile of work
to bring them up to date so it won't happen real soon. They are on
axiom-developer.org so you, at least, have the ability to mod them
at will.

They really should reside on a wiki if we could only find one. :-)

\start
Date: Wed, 17 Nov 2004 11:43:12 -0500
From: Bill Page
To: Tim Daly
Subject: RE: savannah webcvs
Cc: Bill Page

Tim,

About wikis.

Actually I was looking at Moinmoin the other day

  http://moinmoin.wikiwikiweb.de

Moinmoin is a wiki written in Python (like ZWiki but without
the ZOPE web development environment). It also has some
capabilities to handle LaTeX and could probably be quite
easily extended (for someone already familiar with programming
for Moinmoin) to interface with Axiom the way we do now with
LatexWiki.

http://sourceforge.net/mailarchive/forum.php?forum_id=624&max_rows=25&style=
flat&viewmonth 0208

Moinmoin seems quite fast and "tidy" but I am not sure if it
really provides much advantage over what we are doing already.

  http://moinmoin.wikiwikiweb.de/ZWiki?highlight=%28zwiki%29

Anyone have any comments?

Cheers,
Bill Page.

On Wednesday, November 17, 2004 10:16 AM Tim Daly wrote: 
> ...
> They really should reside on a wiki if we could only find one. :-)

\start
Date: 17 Nov 2004 11:52:22 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: superman
Cc: Gilbert Baumslag

Greetings!  OK, from a freash cvs checkout and build:

$sman

sman:main entered
sman:process_options entered
sman:set_up_defaults entered
sman:set_up_defaults exit
sman:process_arguments entered
  sman -clef -gr -nag -ht -noiw -ihere -ihere -ws '$AXIOM/bin/AXIOMsys' -grprog '$AXIOM/lib/viewman' -nagprog '$AXIOM/lib/nagman' -htprog '$AXIOM/bin/hypertex -s' -clefprog '' -sessionprog '$AXIOM/lib/session' -clientprog '$AXIOM/lib/spadclient' -rm '(null)' -rv '(null)' -paste '(null)' 
sman:process_arguments exit
sman:process_options exit
ptyopen: Failed to grant access to slave device: No such file or directory
ptyopen: Failed to get name of slave device: No such file or directory
ptyopen: Failed to open slave: Bad address
fork_Axiom: Failed to reopen server: No such file or directory
sman:start_the_local_spadclient: $AXIOM/bin/clef -f $AXIOM/lib/command.list -e   $AXIOM/lib/spadclient
/bin/sh: /fix/g/camm/axiom/cvs/mnt/linux/lib/nagman: No such file or directory
/bin/sh: line 0: exec: /fix/g/camm/axiom/cvs/mnt/linux/lib/nagman: cannot execute: No such file or directory
ptyopen: Failed to grant access to slave device: No such file or directory
ptyopen: Failed to get name of slave device: No such file or directory
ptyopen: Failed to open slave: Bad address
/bin/sh: /fix/g/camm/axiom/cvs/mnt/linux/bin/hypertex: No such file or directory
/bin/sh: line 0: exec: /fix/g/camm/axiom/cvs/mnt/linux/bin/hypertex: cannot execute: No such file or directory
clef trying to get the initial terminal settings: Invalid argument


Do I need nagman?

Take care,

Tim Daly writes:

> *,
> 
> I've mostly finished another piece of the puzzle.
> It is now possible to run graphics from within axiom.
> To test this you need to build the latest version and then type:
> 
> sman            <--- this will start the superman process, which starts axiom
>                      there will be a lot of complaints. ignore them.
>                      you could type 'sman 2>/dev/null' to start quietly.
> 
> (axiom should start)
> 
> draw(sin(x),x=-10..10)                <--- 2d graphics example
> draw(sin(x,y),x=-10..10,y=-10..10)    <--- 3d graphics example
> 
> 
> 
> There is, of course, more to do so I haven't made this the default way
> to start axiom but that too is coming. I've been running tests against
> the CRC handbook of curves and surfaces and it looks pretty good although
> I still have one bug to track down. I also have to integrate the test
> cases, reimplement the axiom shell script, document the pile better, etc.
> 
> As usual, send complaints to 'Tim Daly' and I'll do my best to help.
> 
> The next major piece of work is to rebuild the hypertex browser.

\start
Date: Wed, 17 Nov 2004 18:00:37 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: Wikis
Cc: Bill Page

What's wrong with the Wiki we have?

\start
Date: Wed, 17 Nov 2004 12:06:16 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: Wikis

Martin,

I think Tim Daly's comment:

On Wednesday, November 17, 2004 10:16 AM Tim Daly wrote: 
> ...
> They really should reside on a wiki if we could only find one. :-)
> 

should be interpreted as "tounge-in-cheek" humor. Perhaps
what he is saying is a rebuke to himself for not having
enough time to "get around" to actually seriously using the
one we have... Finding enough time seems to be a problem
in almost everything I do these days ... <sigh>

Anyway, my interest in Moinmoin is mainly from the point
of view of how fast it seems compared to ZWiki. Of course
this could be more a matter of hardware and networks than
actual software. There are a lot of developer advantages to
working inside of the ZOPE application development environment
(once you get used to the dynamic object-orientation, etc.
blah, blah).

Then again, diversity is one of the hallmarks of the open
source development environment, so if *someone* did implement
another Axiom-aware wiki environment, then I would be one
of the first to step up and try to help.

Cheers,
Bill Page.

> -----Original Message-----
> 
> What's wrong with the Wiki we have?

\start
Date: Wed, 17 Nov 2004 12:18:26 -0500
From: Tim Daly
To: Camm Maguire
Subject: sman

Camm,

It appears that you can't open a socket to the terminal.
There are three things that might be a problem.

1) did you try to run this in a terminal that can't open sockets
   (whatever that means). i've run into this message when i tried
   to run axiom remotely and the socket wouldn't open. are you
   running it on a local box?

2) this is a clef (command line editor function) problem, not an
   sman problem. so try:

sman -noclef

   and see if that cures it.

3) try running it as root. perhaps you don't have socket permissions.
  
let me know if any of these three cure the problem.

\start
Date: Wed, 17 Nov 2004 11:36:43 -0800
From: Bob McElrath
To: Bill Page
Subject: Re: Wikis

Page, Bill [Bill Page] wrote:
> Tim,
> 
> About wikis.
> 
> Actually I was looking at Moinmoin the other day
> 
>   http://moinmoin.wikiwikiweb.de
>  
> Moinmoin is a wiki written in Python (like ZWiki but without
> the ZOPE web development environment). It also has some
> capabilities to handle LaTeX and could probably be quite
> easily extended (for someone already familiar with programming
> for Moinmoin) to interface with Axiom the way we do now with
> LatexWiki.
>
> 
> http://sourceforge.net/mailarchive/forum.php?forum_id=624&max_rows=25&style=
> flat&viewmonth 0208

It appears they did not steal my image alignment or mathml code.  :(
Also their block equation mode is obtuse and un-latex-like::

     [[[latex (multiple lines)
     stuff
     $$ \alpha \beta \gamma $$
     ]]]

> Moinmoin seems quite fast and "tidy" but I am not sure if it
> really provides much advantage over what we are doing already.
> 
> http://moinmoin.wikiwikiweb.de/ZWiki?highlight=%28zwiki%29

I have updated this page with more accurate information.  For instance,
zwiki now has a preview button, and actually supports the MoinMoin
input syntax, if you prefer that.

> Anyone have any comments?

My general dissatisfaction with zwiki has led me to look into other
wiki's (and porting my code), including moinmoin.  Basically, my latex
code is a lot better than others out there (nobody else gets images
aligned as well, nobody else does mathml...).

Anyway, after much deliberation, I decided to stick with zwiki.  It is
just more powerful and more flexible.  I figured out how to fix the
problems, and have been working on that.  My recent work has been on
removing rendering errors and improving speed, and you can find it here,
http://mcelrath.org:9675/newstx/FrontPage For large pages, rendering
speed can be improved by a factor of 20.  I have further
speed-improvement tricks up my sleeve, but am waiting to get my existing
code merged to zwiki before making more extensive changes to their
codebase.

As these changes are extensive, I have received some resistance to
incorporating them.  I am confident we can get these resolved, but in
the meantime you can see my page above and try it yourself.  Note these
changes have not been merged with latexwiki yet.

I think for a project as extensive as axiom, zope/zwiki will serve you
better than a simpler wiki like moin.  Access control, putting up
non-wiki content, Plone integration...will serve you well.

\start
Date: Wed, 17 Nov 2004 15:23:11 -0500
From: Bill Page
To: Bob McElrath
Subject: RE: Wikis

On Wednesday, November 17, 2004 2:37 PM Bob McElrath wrote: 
>
> ...
>> http://moinmoin.wikiwikiweb.de/ZWiki?highlight=%28zwiki%29
>
> I have updated this page with more accurate information.
> For instance, zwiki now has a preview button, and actually
> supports the MoinMoin input syntax, if you prefer that.

Yes, I want that preview button NOW on MathAction! Some
way to test and see what you modifications look like before
committing them to the Wiki and emailing them to all
subscribers would be a great improvement. How disruptive
will it be, do you think, to upgrade ZWiki for this
enhancement?

>...
> Anyway, after much deliberation, I decided to stick
> with zwiki.  It is just more powerful and more flexible.
> I figured out how to fix the problems, and have been
> working on that.  My recent work has been on removing
> rendering errors and improving speed, and you can find
> it here, http://mcelrath.org:9675/newstx/FrontPage For
> large pages, rendering speed can be improved by a factor
> of 20.  I have further speed-improvement tricks up my
> sleeve, but am waiting to get my existing code merged
> to zwiki before making more extensive changes to their
> codebase.

Excellent. Great work.

> As these changes are extensive, I have received some
> resistance to incorporating them.  I am confident we
> can get these resolved, but in the meantime you can
> see my page above and try it yourself.  Note these
> changes have not been merged with latexwiki yet.
>
> I think for a project as extensive as axiom, zope/zwiki
> will serve you better than a simpler wiki like moin.
> Access control, putting up non-wiki content, Plone
> integration...will serve you well.

Yes, I agree completely that that is the best way to go.

\start
Date: Wed, 17 Nov 2004 12:32:43 -0800
From: Bob McElrath
To: Bill Page
Subject: Re: Wikis

Page, Bill [Bill Page] wrote:
> On Wednesday, November 17, 2004 2:37 PM Bob McElrath wrote: 
> >
> > ...
> >> http://moinmoin.wikiwikiweb.de/ZWiki?highlight=%28zwiki%29
> >
> > I have updated this page with more accurate information.
> > For instance, zwiki now has a preview button, and actually
> > supports the MoinMoin input syntax, if you prefer that.
> 
> Yes, I want that preview button NOW on MathAction! Some
> way to test and see what you modifications look like before
> committing them to the Wiki and emailing them to all
> subscribers would be a great improvement. How disruptive
> will it be, do you think, to upgrade ZWiki for this
> enhancement?

I don't think it will be very disruptive at all.

Most of the recent zwiki work has been in internationalization issues.

But, I've not tried the latest latexwiki with the latest zwiki.  I'm a
version behind.  I've been working on the zwiki modifications...

So the next latexwiki release will extend my zwiki work, and be a total
rewrite of the page-rendering part.  (Believe it or not this is quite
easy...but I haven't done it yet)

\start
Date: Wed, 17 Nov 2004 15:43:38 -0500
From: Bill Page
To: Bob McElrath
Subject: bounties

I really love this "bounty" idea that seems to have been started
by Canonical

  http://www.ubuntulinux.org/community/bounties

in relation to the Ubuntu linux project, but it seems to be
rapidly spreading to other areas.

The idea is apparently to use donated (as well as some
corporate sponsor) funds to pay relatively small incentives
(but which carrying a *big* emotional multiplier of recognition
for people who have been doing voluntary open-source programming,
some extraordinary work that has remained quite unrecognized
of several years).

So the preview extension for ZWiki was paid such a bounty

  http://zwiki.org/933BountyForEditPreviewMode

That's great!

I would really like to see this idea extended to our little
realm of computer algebra systems.

Regards,
Bill Page.

-----Original Message-----

Page, Bill [Bill Page] wrote:
> On Wednesday, November 17, 2004 2:37 PM Bob McElrath wrote: 
> >
> > ...
> >> http://moinmoin.wikiwikiweb.de/ZWiki?highlight=%28zwiki%29
> >
> > I have updated this page with more accurate information.
> > For instance, zwiki now has a preview button, and actually
> > supports the MoinMoin input syntax, if you prefer that.
> 
> Yes, I want that preview button NOW on MathAction! Some
> way to test and see what you modifications look like before
> committing them to the Wiki and emailing them to all
> subscribers would be a great improvement. How disruptive
> will it be, do you think, to upgrade ZWiki for this
> enhancement?

I don't think it will be very disruptive at all.

Most of the recent zwiki work has been in internationalization
issues.

But, I've not tried the latest latexwiki with the latest
zwiki.  I'm a version behind.  I've been working on the zwiki
modifications...

So the next latexwiki release will extend my zwiki work, and
be a total rewrite of the page-rendering part.  (Believe it
or not this is quite easy...but I haven't done it yet)

\start
Date: 17 Nov 2004 16:04:29 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: sman

Greetings!  Thanks for the tip -- I did not have /dev/pts mounted in
my unstable dchroot.

This looks great!

1) Docs for the GUI?

2) Advice on to when this might be stable enough to warrant another
   Debian snapshot package?  

3) Can sman and/or graphics be invoked from within AXIOMsys, of must
   sman be the master process?  How does this interface with other
   frontends, eg. texmacs?

Take care, and thanks!

Tim Daly writes:

> Camm,
> 
> It appears that you can't open a socket to the terminal.
> There are three things that might be a problem.
> 
> 1) did you try to run this in a terminal that can't open sockets
>    (whatever that means). i've run into this message when i tried
>    to run axiom remotely and the socket wouldn't open. are you
>    running it on a local box?
> 
> 2) this is a clef (command line editor function) problem, not an
>    sman problem. so try:
> 
> sman -noclef
> 
>    and see if that cures it.
> 
> 3) try running it as root. perhaps you don't have socket permissions.
>   
> let me know if any of these three cure the problem.

\start
Date: Wed, 17 Nov 2004 16:14:26 -0500
From: Bill Page
To: 'Camm Maguire' <Camm Maguire>
Subject: re: sman

On Wednesday, November 17, 2004 4:04 PM Camm Maguire wrote:

>...
> 3) Can sman and/or graphics be invoked from within AXIOMsys,
> of must sman be the master process?  How does this interface
> with other frontends, eg. texmacs?

Apparently the Axiom graphics package can create postscript
output (although I have yet to find out how to access all
the controls without interfacing via the gui). There is a
stand alone viewer, but one has to first (usually interactively?)
create an external file using the gui controls.

Anyway, once you have a postscript file, both TeXmacs and
LatexWiki (MathAction) can present them to the user. This
is already done for gnuplot output under Reduce on MathAction
and in TeXmacs for gnuplot sessions. The interface to Axiom
will have to be extended for both systems to automatically
handle the internal file manipulation and process handling.

\start
Date: Wed, 17 Nov 2004 13:36:24 -0800
From: Bob McElrath
To: Bill Page
Subject: Re: bounties
Cc: Steve Hess, Bill Page

Page, Bill [Bill Page] wrote:
> The idea is apparently to use donated (as well as some
> corporate sponsor) funds to pay relatively small incentives
> (but which carrying a *big* emotional multiplier of recognition
> for people who have been doing voluntary open-source programming,
> some extraordinary work that has remained quite unrecognized
> of several years).

I have even put forward some of my money for bounties.  (Unrelated to
this topic)  I don't know how many other people are putting forward
money for things they want.

> I would really like to see this idea extended to our little
> realm of computer algebra systems.

Do you think one could put forward a bounty for, say, an algebraic
extension?  In academia we generally have a very different
motivation/reward system involving journal publications.

However, Axiom does, and will continue to need pieces implemented which
are mundane, from an academic perspective.  (e.g. nobody could/would
write an academic paper about it)  Axoim is playing catch-up with Maple
and Mathematica.  Do you think bounties could work for this?  I can
imagine poor graduate students implementing some of this, and being
highly motivated by the bounty.  In my own little world, I would like
the equivalent of FeynCalc (and general Quantum Field Theory tools) for
Axiom, but I can't justify dumping a lot of time into that, because a
publication on it is unwise, and would not be respected (as physics) by
my field.  (e.g. it's not physics, but it's very important)

The other obvious way to get "mundane" things implemented is for people
in academia to put their students on it.  But, this is not necessarily
good for their students.  We would rather have our graduate students get
publications...  Students younger than Ph.D. candidates would be
excellent for implementing some of this, as they can do it in the course
of working a problem set (which is "mundane" in an academic-publication
sense) and may not conflict with the goals of their advisor.
I suppose we won't know if this will work until it's tried.  But I see a
lot of potential.

Hey...I have an idea, let's try.  Does Axiom have any existing funding
sources?  Could one write an academic grant for this, and establish a
pot for paying bounties?  The advantage of bounties is that they're
cheap, compared to hiring a developer.

Right now I volunteer $100 of my personal funds for Axiom work.
(because I'm a single post-doc and don't have a lot of expenses ;)  What
do people consider to be an important goal that is not already being
worked on, that we could reasonably expect someone to pick up?  This
kind of thing needs a rigorous definition for completion of the bounty,
and test-cases accompanying it to ensure correctness.

I'm going to put a lot of thought into applying for a small grant... I
mean, the arxiv got a grant, and is a critical tool.  This seems just as
worthy.

\start
Date: Wed, 17 Nov 2004 19:06:05 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: sman

Camm,

>> 1) Docs for the GUI?

see the book. xdvi (path)/axiom/mnt/linux/doc/book.dvi

>>2) Advice on to when this might be stable enough to warrant another
>>   Debian snapshot package?  

i still have to clean up the sman setup, etc, so there are going to
be some changes for a little while. i'm also working on a MAC and BSD
port in the near term so they are probably of interest also. and i have
to bring the testcases back to life.

the standard axiom command does not yet use sman. i put it out for
testing purpose and to make sure i didn't break anything fundamental.
processwise it's a fundamental change. eventually the axiom shell
script will invoke sman rather than AXIOMsys.

i'll let you know when these tasks are reasonably complete.
without them i think it's not worth the effort to snapshot yet.

3) Can sman and/or graphics be invoked from within AXIOMsys, of must
   sman be the master process?  How does this interface with other
   frontends, eg. texmacs?

nope. sman sets up a set of sockets and manages communication between
subprocesses. AXIOMsys, graphics, hyperdoc, nagman, etc. The AXIOMsys
can either be run locally (-ihere) or in a separate window (-iw (?))
which can be controlled when sman is invoked. i'm working thru the
internals of sman to document it and, in fact, this will probably
be the first of the "internals.booklet" sections.

\start
Date: Wed, 17 Nov 2004 22:08:56 -0500
From: Dylan Thurston
To: list
Subject: Calculemus

Has anyone here heard of the Calculemus project at
http://www.calculemus.net ?  It looks possibly relevant.

\start
Date: Thu, 18 Nov 2004 00:56:26 -0500
From: Tim Daly
To: Dylan Thurston
Subject: Re: Calculemus

Dylan,

Yes, I did see that actually.

One of the proposed pieces of work with Axiom is to join it with
ACL2. There have been email discussions with that group (Kaufmann,
Boyer, and Moore) about it in the past.

ACL2 and Axiom are both written in common lisp and both run on GCL
so it would be straightforward to load them into the same image.
Cover functions could be created in axiom (since axiom code can
directly call lisp code).

One research issue would be to take the merger as an assumption
and see how axiom's categorical view supports or conflicts with
ACL2's world view.

Another research issue would be to look at self-application of
ACL2 to Axiom by focusing on something like Axiom's list or
sorting implementations, showing proofs of code. Could proven
axiom functions be used in further ACL2 proofs?

A third idea is to look at decorating the categories and domains
with theorems (e.g. the ring properties and related theorems) and
then propagating this information onto the domain functions and
their arguments. Can we propagate properties to reach "logical
conclusions" without actually computing a result?

A fourth idea is to apply ACL2 to computing "proviso" information
(e.g. 1/x provided x!=0) where the provisos are carried at each
step of a computation.

In general, I think that the merging of an algebra system, especially
one based around theory as Axiom is, and a logic system will be a
fruitful area of research work.

\start
Date: Thu, 18 Nov 2004 11:25:06 +0100
From: Juergen Weiss
To: Camm Maguire
Subject: RE: CVS, Arch, Darcs
Cc: Bill Page

Hello,

I would strongly support Camm's views on a more modular
approach. With extremely limited development resources,
if it takes month to port a little C application (sman)
to Linux (which should require maybe two days of work),
we should clearly focus on making things simple. This 
is not to criticize Tim for not being able to spend more
time on this -- I myself have not found almost any time for
Axiom during the last months.

I would argue in favor of using out of the box tools (gcl,
notangle etc.). Development on one Linux platform only 
-- others can send patches for other Linux platforms and
other operating systems (BSD, OS X, Windows) and test
these. 

I'm not an expert on CVS, Arch, Darcs. But my impression
is, that we spent more time on changing the systems used
than on using CVS on nongnu.org in an efficient way.

With best regards

Juergen Weiss

> -----Original Message-----
> 
> Greetings!  Just thought I'd add my feeble $.02 to Tim's breathtaking
> vision. 
> 
> The goals are obviously quite impressive. In my work with GCL
> supporting maxima, acl2, and axiom for Debian, though, I've already
> run into obstacles associated with Lisp's extreme level of
> integration.  A similar philosophy has killed Windows in comparison to
> 'keep-it-simple' modular Linux/unix design, IMHO.  For example, at
> present, without some as-yet-to-be-implemented distributed patching
> mechanism, a bug fix in GCL requires a rebuild of GCL + all three
> programs on 12 architectures.  It appears that there is a definite
> tradeoff between the advantages of integration to developers/users,
> and a modular independent black box leggo-like construction for ease
> of maintenance and bug fixing.  I still have more experience in C than
> lisp, and would be pulling out all my hair even thinking about
> implementing some of the spaghetti I've seen from scratch, at least in
> C.  Simplicity and modularity let me leverage my feeble time resources
> much better, in my experience.
> 
> Just a thought.

\start
Date: Thu, 18 Nov 2004 13:36:21 +0100
From: Martin Rubey
To: list
Subject: RE: CVS, Arch, Darcs / bounties

1.

Weiss, Juergen writes:
 > Hello,
 > 
 > I would strongly support Camm's views on a more modular approach. With
 > extremely limited development resources, if it takes month to port a little
 > C application (sman) to Linux (which should require maybe two days of work),
 > we should clearly focus on making things simple. This is not to criticize
 > Tim for not being able to spend more time on this -- I myself have not found
 > almost any time for Axiom during the last months.
 > 
 > I would argue in favor of using out of the box tools (gcl, notangle
 > etc.). Development on one Linux platform only -- others can send patches for
 > other Linux platforms and other operating systems (BSD, OS X, Windows) and
 > test these.
 > 
 > I'm not an expert on CVS, Arch, Darcs. But my impression is, that we spent
 > more time on changing the systems used than on using CVS on nongnu.org in an
 > efficient way.

I agree wholeheartedly. 

2. regarding bounties: Maybe we could simply put rewards on the items of the
   WishList/TodoList. (0$ being a possible reward...)

   In order to do so, we would have to agree upon the importance/benefit of the
   various issues.

   I think possible candidates could include

   * pamphlet support on MathAction
   * a Windows port
   * Aldor integration
   * numerical integration.

   I think it would be great to get some students to work on the mathematical
   side -- I know that some universities have courses where the students are to
   implement the algorithms from the book A=B -- in Maple :-(. However, I'd
   advise anybody who wants to implement these things to get into contact with
   RISC. 

   Unfortunately, in my departement Axiom is of little use, R is very good at
   statistics.

Martin

PS: and yes, I did not have much time for Axiom either in the past two
months. Sorry.

\start
Date: Fri, 19 Nov 2004 10:04:59 +1100
From: Jason White
To: list
Subject: RE: CVS, Arch, Darcs

Weiss, Juergen writes:
 > 
 > I would argue in favor of using out of the box tools (gcl,
 > notangle etc.). Development on one Linux platform only 
 > -- others can send patches for other Linux platforms and
 > other operating systems (BSD, OS X, Windows) and test
 > these. 

As one who has been following the list rather than participating, this
seems reasonable enough. Another approach would be to adopt
portability guidelines, I suppose, as some projects do. However, I
expect this would mostly (entirely?) apply to the C code rather than
to the Lisp or Axiom code, and to the build procedure.

 > 
 > I'm not an expert on CVS, Arch, Darcs. But my impression
 > is, that we spent more time on changing the systems used
 > than on using CVS on nongnu.org in an efficient way.
 > 
>From reading the list, I agree with that impression but it is also
quite clear that Tim has been trying to maintain multiple branches of
development efficiently, that CVS has significant limitations and that
it is worth investing time in an alternative, namely Arch. It is to be
hoped this will settle down fairly quickly. Even the CVS developers
agree that CVS has reached the end of the line, which is why they
wrote Subversion.

\start
Date: Thu, 18 Nov 2004 21:16:02 -0500
From: Tim Daly
To: Juergen Weiss
Subject: Re: CVS, Arch, Darcs
Cc: Camm Maguire, Bill Page

Juergen,

>I would strongly support Camm's views on a more modular
>approach. With extremely limited development resources,
>if it takes month to port a little C application (sman)
>to Linux (which should require maybe two days of work),
>we should clearly focus on making things simple. This 
>is not to criticize Tim for not being able to spend more
>time on this -- I myself have not found almost any time for
>Axiom during the last months.

modular and integrated are orthogonal issues. GCL includes many
other projects like the TK toolkit, gmp, etc. From axiom's view
GCL is a modular piece but it needs integration work to build 
smoothly and end users shouldn't do that.

as to the apparent time factor...
unfortunately in the current development method, namely locally on my
machine, all anyone ever gets to see is the endpoints. that gives the
impression that nothing is happening which is anything but true. sman
took so long because i've been working on a MAC port (which I'm
working with a fellow in australia), a BSD port (a fellow in the UK)
and a Windows port (me, myself, and i in the US).

sman has existed for a while but i had to rip it out of the local
code, make sure it is clean enough, test it and publish it.  

These things take time because i have to learn how to use a MAC (which
i find completely unintuitive, frankly) and Windows (which is a steep
learning curve). i'm quite far along on the hyperdoc process (it's
compiling as i write) but you can't see that anything is moving. arch
will at least solve the visibility issue.

>I'm not an expert on CVS, Arch, Darcs. But my impression
>is, that we spent more time on changing the systems used
>than on using CVS on nongnu.org in an efficient way.

there are a couple reasons to move to arch from the project point of view.

first, it enables me to "comb" out the pieces of the system into
separate branches. since arch handles branches much easier than CVS i
prefer it. this will allow myself and others to publish a dozen or
more branches of the development, any one of which is badly broken but
doesn't affect the main build (or the savannah CVS).

second, there is no reason why someone couldn't create a new branch to
investigate some interesting development (say, a logic-algebra
branch). while it is technically possible to do this in CVS the arch
system seems to have a stronger ability to handle branching and
joining.

third, arch supports changesets. if you look at the last 2 dozen items
in the CHANGELOG it isn't clear to anyone except myself which of those
changes are related to sman and which are not. i suppose if i had more
time and were better organized i could simulate changesets in CVS but why?
the kernel people have found changesets so compelling they switched to
using bitkeeper.

the downside is that arch has a fairly painful learning curve.  it is
supposed to be "self documenting" but i've found it to be a painful
startup experience. ah, well, i had the same complaint about SCCS,
RCS, mget, SourceSafe, CVS, and bitkeeper.

>I would argue in favor of using out of the box tools (gcl,
>notangle etc.). Development on one Linux platform only 
>-- others can send patches for other Linux platforms and
>other operating systems (BSD, OS X, Windows) and test
>these. 
>

well, i do the development on my main box which is Linux Redhat 9.  
i have a local "compile farm" in my basement that supports a few other
linux distros and i try to test axiom changes on them before i inflict
them on the rest of the world.  clearly others could "send patches"
but my experience has been that i become involved in the other
platforms anyway. Camm, Mark, Chuck, Bill, and several others have
been very helpful, especially in giving me advice and access to 
equipment i don't have available locally.

\start
Date: Thu, 18 Nov 2004 21:35:22 -0500
From: Tim Daly
To: Martin Rubey
Subject: Re: CVS, Arch, Darcs / bounties

Martin,

re: bounties. i have no objection to someone setting up a bounty or
paypal system on the savannah site. however, i'm unlikely to have
anything to do with it except maybe to contribute some cash. money
has a way of making the rational into the emotional and experience
tells me to avoid it. so my response to the whole bounty issue is
"anyone but me".

i did discuss support of axiom with the NSF thru grants and the 
response is "if there is a commercial product in the area then there
won't be any grant money". so as long as maple and mathematica exist
the NSF won't give grants for axiom research and development.

i spoke to NIST about doing the CATS (Computer Algebra Test Suite)
but got a lukewarm reception. i ought to construct a grant proposal
for the work i've done and plan to do but haven't taken the time yet.

i wrote up a request to the Sloan Foundation for support this summer
but never got a reply. i'm not even sure they got the request.

the only source of funding i'm aware of is that there is a "Jenks Award"
of about $1000/year that is given out every year at ISSAC. Dick Jenks
(the father of Axiom) left it as part of his will. i don't know what
project won the award this year as i wasn't at ISSAC. I nominated Camm
for his contributions to axiom, maxima, and ACL2.

i'm supported by CAISS at City College of New York since, although they
do not make any claims on Axiom, Gilbert Baumslag, my boss encourages
me to work on it. We have a new open source lab that has just opened
this semester and next semester we're likely to get students, some of
whom i'm hoping to lead into development of axiom.

re: the current state and list of proposed work see:
http://axiom.axiom-developer.org/axiom-website/currentstate.html
which is reasonably up to date. 

\start
Date: Thu, 18 Nov 2004 21:18:24 -0500
From: Bill Page
To: Tim Daly
Subject: RE: CVS, Arch, Darcs
Cc: Camm Maguire

On Thursday, November 18, 2004 9:16 PM Tim Daly wrote:

>...
> From axiom's view GCL is a modular piece but it needs
> integration work to build smoothly and end users shouldn't
> do that.
> 

>From the point of view of *end users*, I think it should not
be more complicated than

  $ apt-get install axiom

(or the equivalent)

Forget about end-users building anything. All they want to
do (and all they should expect to have to do) is to learn
to use Axiom and get on with their main work. If we are lucky
perhaps some end-users will be willing and interested in
making they Axiom application work accessible to others.

For everyone else, there are so many levels and combinations
of experience, skill and patience that I can't imagine how it
would ever be possible to satisfy everyone. I would like more
people to become more actively involved with Axiom development
but for reasons that have little to do with the tools we are
using, it seems unlikely to me that this will change even if the
Axiom development process somehow manages to be more accessible.
Basically, most people just do not have enough time to devote
to this. So from my point of view, what is happening right now
is (more or less) optimal.

About the only improvement I can think of right now is to make
easily available a larger and well documented library of up to
date and tested pre-compiled binaries for as many platforms
and linux variants as possible. It would be great if some people
besides Tim and Cam could contribute to such a library. I would
be very pleased to set up an area on MathAction and the Axiom
Portal where such contributed binary versions can be uploaded.

\start
Date: Thu, 18 Nov 2004 18:23:32 -0800
From: Bob McElrath
To: Tim Daly
Subject: Re: CVS, Arch, Darcs / bounties

root [Tim Daly] wrote:
> i did discuss support of axiom with the NSF thru grants and the 
> response is "if there is a commercial product in the area then there
> won't be any grant money". so as long as maple and mathematica exist
> the NSF won't give grants for axiom research and development.

That is very unfortunate.  Very shortsighted.  The whole point of open
source in this regard is future-proofing, for the case when the
commercial entities collapse, or make decisions that are not in our
favor.  e.g. how long can both Maple and Mathematica both be
financially viable?  Sooner or later, *every* company falls on hard
times.  It's already happened to Axiom and Maxima, which will be next?

Money could come for specific purposes in other fields (e.g. QFT, CFD,
-- not specifically "computer algebra").  One would have to make a
strong case that the open source solution is better.  Problem is, one
can make a pretty strong argument that existing source release by
research groups is "working" and/or "good enough".

Small grants from universities may be easier, since they can directly
involve students at that university.  But there you run into the "why
not just give someone an RA/TA" argument.

> re: the current state and list of proposed work see:
> http://axiom.axiom-developer.org/axiom-website/currentstate.html
> which is reasonably up to date. 

You are doing so much work...I wish it were more transparent.  Arch will
help.

\start
Date: Thu, 18 Nov 2004 21:48:07 -0500
From: Bill Page
To: Tim Daly
Subject: proposal to create the Axiom Foundation (was: bounties etc.)
Cc: Camm Maguire, Bob McElrath

On Thursday, November 18, 2004 9:35 PM Tim Daly wrote:

> 
> re: bounties. i have no objection to someone setting up
> a bounty or paypal system on the savannah site. however,
> i'm unlikely to have anything to do with it except maybe
> to contribute some cash. money has a way of making the
> rational into the emotional and experience tells me to
> avoid it. so my response to the whole bounty issue is
> "anyone but me".
> 

Ok. Personally, I don't have a problem with being emotional
about money, so that's all the encouragement I need... :)

I volunteer to setup such a fund. But here more precisely is
what I propose (and I am open to any alternate suggestions on
all points):

1. We call in the "Axiom Foundation". I am not worried at all
   right now about it's legal status or anything. Just a name
   will do on which to hang the idea.

2. Decisions on behalf of the Axiom Foundation will be made by a
   small sub-group. Maybe 3 people? I would like to think that
   with a small group it will be possible to make all important
   decisions by consensus (everyone must agree). I'll be asking
   for volunteers at the end of this note. If more that 3 people
   step up for the job then maybe we can take a vote or something.

3. The main task of the Axiom Foundation will be to serve as the
   "official" channel through which to promote the development
   and maintenance of the open source version of Axiom through the
   dispersement of donations and sponsorship money to Axiom-related
   activities.

4. Right now I can think of at least two potentially fundable
   activites:

   4a. The axiom-developer.org host system

   4b. Bounties (relatively small promotional awards) to be paid
       for programming work done enhance Axiom

   Perhaps we will be able to identify others, but I think that
   the list should remain short.

5. I am willing to take initial responsibility for setting up and
   administering a paypal account (and/or any other acceptible
   financial means) on behalf of the Axiom Foundation and I agree
   to act on the funds collected according to the instructions of
   the Axiom Foundation.

6. Finally, the people I would personally like to see volunteer
   as initial members of the Axiom Fundation are:

   Martin Rubey
   Bob McElrath
   Camm Macquire

   The only reason I left Tim's name of the list is that he
   already seems especially shy about the idea. :)

\start
Date: Thu, 18 Nov 2004 22:06:00 -0500
From: Bill Page
To: Tim Daly
Subject: current state and CCL

Tim,

In your

> http://axiom.axiom-developer.org/axiom-website/currentstate.html

I noticed the entry:

>  CCL BUILD
>  Motivation: run on a popular common lisp
>  -  Get final CCL sources from Arthur
>  -  Build image in /spad/lsp/ccl
>  -  Build Axiom on image

Does the - signs here mean that you have already managed to build
open source Axiom under CCL? If the answer is yes, then I am very
interested because I think that might be a fast way to get an
operational version of Axiom under Windows.

\start
Date: Thu, 18 Nov 2004 23:21:18 -0500
From: Tim Daly
To: Bill Page
Subject: Re: current state and CCL

Bill,

I did manage to build a running CCL many moons ago but never
managed to get it to run axiom. the build steps were never 
clear to me and after 2 months i gave up and switched to gcl.

CCL is still in the queue of things to do and is likely to be
the third lisp port. somebody on this list managed to get 
axiom running on CMUCL, i believe, and i need to integrate
that piece of work. CLISP is likely to be the fourth lisp
porting effort.

axiom used to run on several lisps including vmlisp, maclisp,
franz lisp, symbolics common lisp, golden common lisp, lucid
common lisp, spice lisp (aka cmucl) and akcl (aka gcl) 
and i even had a scheme cover version for a brief
moment in time but that was entirely interpreted. the big issue
is the ability to save an image with compiled code inside. the
other issue is that most of the axiom build-time steps have
system-dependent commands (e.g. GCL's save-system command).
a great deal of effort went into optimizing axiom to run on 
AKCL (aka GCL) and SPICE (aka CMUCL). in particular, CMUCL has
a really sweet disassemble output which really helps to optimize
lisp code and GCL has a profiler. axiom also has a trace profiler
(src/interp/monitor.lisp.pamphlet) which can handle the algebra.

unfortunately the various special purpose branches of this code
never made it off my desk at ibm. they were not part of the NAG
original distribution as they were very "experimental", meaning
they only ran on my local group of machines. some of the code is
still there as you can see if you grep for the "#+" and "#-" sexprs.

we could easily start a CCL arch branch and restart that effort.
(assuming i get my ass in gear and restart arch).

\start
Date: Fri, 19 Nov 2004 00:13:20 -0800
From: Bob McElrath
To: Bill Page
Subject: Re: proposal to create the Axiom Foundation (was: bounties etc.)
Cc: Camm Maguire

Bill Page wrote:
> Ok. Personally, I don't have a problem with being emotional
> about money, so that's all the encouragement I need... :)

Sounds great!

> 1. We call in the "Axiom Foundation". I am not worried at all
>    right now about it's legal status or anything. Just a name
>    will do on which to hang the idea.

It is easier to get donations if, eventually, the foundation can be
legally established as a 503(c) non-profit or something.

> 4. Right now I can think of at least two potentially fundable
>    activites:
> 
>    4a. The axiom-developer.org host system

How is this currently hosted/funded?  Is CUNY hosting?

I also have a co-located server sitting far below it's bandwidth
allotment, and a 99% idle CPU.  I'd be willing to host some resources,
if that would be helpful.  It's also an alpha/linux, if people want to
compile/test Axiom on that arch.

I'm not sure I want to allocate university resources (e.g. my office
computer) because I am still a post-doc, I will likely leave Davis in 2
years.  Also this would have to move from a spare-time activity to a
work activity.  In my mind I would need to justify that it is related to
my research.  We'll see...

> 6. Finally, the people I would personally like to see volunteer
>    as initial members of the Axiom Fundation are:

I'm flattered to be nominated, but I doubt I'm really qualified.  My
understanding of Axiom is less than poor.  I hope I will be able to
improve that in time, but right now I could not identify what is useful
for Axiom.  Nor have I even decided if my future efforts will be based
on Axiom or Maxima.  My monetary offer really needs someone else to
suggest a project.  My QFT ideas are underdeveloped at this point.  On
the other hand, the person(s) putting up money should of course have a
say in what it goes for.

My spare-time allotment will be fixing zwiki, fixing latexwiki,
integrating axiom/reduce/wiki, *then* doing some real work with Axiom.
Unfortunately I don't have any physics projects on the horizon which
would let me dump time into it.  So, I'll be useless to Axiom for a
while.

\start
Date: 19 Nov 2004 09:22:52 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: proposal to create the Axiom Foundation (was: bounties etc.)
Cc: Bob McElrath

Greetings!  Thanks, Bill, as always for your amazing initiative!

If the group determines it is useful to have such a foundation, and
you would like me to assist in making decisions regarding the
foundation, I'd be glad to help.  Personally, I would not feel
comfortable about accepting funds for axiom work.  Its existence is
its own payment, far exceeding in value IMHO any 'bounty' we'd set.
The other difficulty of course is in judging when a task has been
adequately completed to warrant disbursement of the bounty.  Still
another is to ensure that the author (ideally) remains committed to
fixing/maintaining his/her code.  Introducing this dynamic might tend
to interfere with the spirit and collegiality of most open source
projects I've worked with.  This said, if axiom is in need of funds
for some good reason, I might be able to help provide some.

I've been a bit too reticent about my plans re: axiom I think.  I've
been planning on implementing Zeliberger for axiom and working through
the issues in some of the symbolic summation bugs.  I'm about halfway
through the book, and have just discovered Caruso's paper on his
implementation for maxima.  This is my intention.  I hesitate to speak
about it prematurely, as I want to ensure that I can find the time to
bring it to successful completion.  If there is anything more
pressing, or if anyone else is already doing this, please let me know.

If my experience with GCL is any guide, improvements of this sort have
a high activation energy of thoroughly mastering the internals of the
system.  Once this is done, many such projects can be completed
relatively quickly.  Alas, I still have to fully digest the axiom
docs, and especially Tim's earlier posts on axiom debugging/tracing
facilities. 

I like maxima, and all, but in truth I think axiom should be more
popular.  With user-base/mindshare comes a lot of synergy, IMHO.
Right now, I think axiom is effectively targeted at too small a class
of people -- researchers in mathematical computing.  We need to expand
this to the general technical user, and then things will take off.

Not that it is very representative, but I check these out every so
often:

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=axiom&show_installed=on&show_vote=on&show_old=on&show_recent=on&show_nofiles=on&want_percent=on&beenhere=1

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=maxima&show_installed=on&show_vote=on&show_old=on&show_recent=on&show_nofiles=on&want_percent=on&beenhere=1

Take care,

Bill Page writes:

> On Thursday, November 18, 2004 9:35 PM Tim Daly wrote:
> 
> > 
> > re: bounties. i have no objection to someone setting up
> > a bounty or paypal system on the savannah site. however,
> > i'm unlikely to have anything to do with it except maybe
> > to contribute some cash. money has a way of making the
> > rational into the emotional and experience tells me to
> > avoid it. so my response to the whole bounty issue is
> > "anyone but me".
> > 
> 
> Ok. Personally, I don't have a problem with being emotional
> about money, so that's all the encouragement I need... :)
> 
> I volunteer to setup such a fund. But here more precisely is
> what I propose (and I am open to any alternate suggestions on
> all points):
> 
> 1. We call in the "Axiom Foundation". I am not worried at all
>    right now about it's legal status or anything. Just a name
>    will do on which to hang the idea.
> 
> 2. Decisions on behalf of the Axiom Foundation will be made by a
>    small sub-group. Maybe 3 people? I would like to think that
>    with a small group it will be possible to make all important
>    decisions by consensus (everyone must agree). I'll be asking
>    for volunteers at the end of this note. If more that 3 people
>    step up for the job then maybe we can take a vote or something.
> 
> 3. The main task of the Axiom Foundation will be to serve as the
>    "official" channel through which to promote the development
>    and maintenance of the open source version of Axiom through the
>    dispersement of donations and sponsorship money to Axiom-related
>    activities.
> 
> 4. Right now I can think of at least two potentially fundable
>    activites:
> 
>    4a. The axiom-developer.org host system
> 
>    4b. Bounties (relatively small promotional awards) to be paid
>        for programming work done enhance Axiom
> 
>    Perhaps we will be able to identify others, but I think that
>    the list should remain short.
> 
> 5. I am willing to take initial responsibility for setting up and
>    administering a paypal account (and/or any other acceptible
>    financial means) on behalf of the Axiom Foundation and I agree
>    to act on the funds collected according to the instructions of
>    the Axiom Foundation.
> 
> 6. Finally, the people I would personally like to see volunteer
>    as initial members of the Axiom Fundation are:
> 
>    Martin Rubey
>    Bob McElrath
>    Camm Macquire
> 
>    The only reason I left Tim's name of the list is that he
>    already seems especially shy about the idea. :)

\start
Date: Fri, 19 Nov 2004 15:55:34 +0100
From: Martin Rubey
To: Camm Maguire
Subject: Re: proposal to create the Axiom Foundation (was: bounties etc.)
Cc: Bob McElrath, Bill Page

Dear Bill, Bob, Camm, *,

I don't have the time right now to say anything useful - only: I'm thinking
about it and I will reply next week Thursday. (In principle I think the idea is
great, however, I do very well understand Camm's reservations)

Camm: If you digest the Wilf-Zeilberger-Petkovsek stuff: Great! If you run in
(mathematical) difficulties somewhere, I might be able to help, or at least
point out somebody who could help.

\start
Date: Sun, 21 Nov 2004 15:39:51 -0500
From: Tim Daly
To: Constantine Frangos
Subject: Re: [Axiom-math] (no subject)

> I obtained the assistance of some Linux experts and we managed to
> compile the axiom source code on a suse linux 9.1 machine in
> about 2 hours, after a small modification to the makefile.

Please do the following:

  copy the original Makefile as Makefile.org
  copy the new Makefile as Makefile.new
  diff -Naur Makefile.org Makefile.new >Makefile.patch

and send me the patch file.


> We then compiled the source code on my older suse linux 7.2
> computer (with gcc version 2.95.3), and this took more than 5 hours (left
> to run overnight). Strangely, the above-mentioned  change to the
> makefile did not work, and we had to revert to the original makefile.

curious.

> I havent quite completed the install steps, etc, and am currently
> running axiom from my user directory using an alias to the axiom file:
> /usr/local/src/axiom/mnt/linux/bin/axiom

Generally what I do is the following (as root):

cd /usr/local/bin
echo 'export AXIOM=/usr/local/axiom/mnt/linux' >axiom
echo 'export PATH=$AXIOM/bin:$PATH' >>axiom
echo '/usr/local/axiom/mnt/linux/bin/axiom' >>axiom
chmod a+x axiom

That sets up an axiom command and also presets the AXIOM and PATH 
shell variables. Be sure to use single quotes with the above otherwise
the $PATH variable will be prematurely expanded.


> Thanks again for putting the source code on the website and for the
> detailed instructions in your email - much appreciated.

no prob.

> I have printed parts of the 1000 page manual and tried out various
> commands from the command line. I want to translate some of my
> programs written in Matlab (extended symbolic toolbox) to axiom and
> test the performance, etc. I have the following question:
> 
> (1) I usually run a Matlab program, eg. test.m, in the backround with the
>     command:
> 
>     time nohup matlab < test.m > test.dat &
> 
>     The output to the screen is saved in test.dat. The file test.m usually
>     contains a function called test, and having no input or output
> parameters. 
> 
>     Typically, test.m calls various other functions, which in turn
>     call other functions, and so on, while also reading and saving
>     data in Matlab data files, eg. test1a.mat, as needed. Such a program
>     can run for several hours, days or even weeks, depending on the
>     computation. 
>   
>     What are the equivalent commands for doing this in axiom, and the
>     extensions for axiom program file names and data file names ?? Maybe
>     a small example would help.

> C. Frangos.

The 'axiom' command in the mnt/linux/bin directory is actually a shell
script. It ends up executing 'AXIOMsys' which is the binary. If you 
just want to run commands the AXIOMsys command can be piped:


Try the following:

cd /tmp
echo "1+1" >in
AXIOMsys <in >out
cat out

alternatively you can execute things from ".input" files. Create a file
called foo.input that contains a series of commands. Suppose foo.input
contains:

2+2
3+3

you can execute this input file with

echo ")read foo.input" | AXIOMsys

\start
Date: Sun, 21 Nov 2004 14:41:38 -0500
From: Tim Daly
To: Camm Maguire
Subject: [Gerard Milmeister: Axiom on FC3]
Cc: Gerard Milmeister

Camm,

Have you tried FC3 builds yet? I know GCL runs on FC1 and FC2 but
I don't yet have a machine running FC3.


There are at most 2 versions of GCL, but intentionally one 1.
Part of the stable transition is to build and test with the 
new GCL release but keep the old one available until I'm sure
that the new one builds everywhere. 

------- Start of forwarded message -------

Hi Tim,

I have successively made an Axiom rpm for Fedora Core 2 (Axiom cvs
20041106), but failed in building on Fedora Core 3.
First, gcl doesn't compile. Apparently the bfd interface has changed.
in file sfaslbfd.c, I changed the references of _raw_size to rawsize.
Sees seemed to fix it, but while compiling axiom there is the following
error:
make[3]: Entering directory `/tmp/axiom/src/boot'
44 invoking make in /tmp/axiom/src/boot with parms:
SYS= linux
LSP= /tmp/axiom/lsp
PART= cprogs
SPAD= /tmp/axiom/mnt/linux
SRC= /tmp/axiom/src
INT= /tmp/axiom/int
OBJ= /tmp/axiom/obj
MNT= /tmp/axiom/mnt
make[3]: *** [/tmp/axiom/obj/linux/bin/bootsys] Error 255

BTW, why are there multiple gcl packages included?

\start
Date: Sun, 21 Nov 2004 18:13:28 -0500
From: Tim Daly
To: list
Subject: Re: order of arguments of (choose k n) in books/arithmetic/binomial.lisp

Josh

> The 'choose' function in binomial.lisp is declared as:
> 	(defun choose (k n) ...)
> But in the binomial coefficient notation, n appears above k.  Also, it
> is normally said aloud as "n choose k" and written as nCk.
> 
> The function would be easier to use if it took its parameters in the
> standard order (n k).
> 
> -- 
> Josh Purinton

This seems reasonable. I need to do checking to find out if and where
it is used. If it isn't used I will reverse them.

\start
Date: 22 Nov 2004 10:46:57 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gerard Milmeister: Axiom on FC3]
Cc: Gerard Milmeister

Greetings!

Tim Daly writes:

> Camm,
> 
> Have you tried FC3 builds yet? I know GCL runs on FC1 and FC2 but
> I don't yet have a machine running FC3.
> 

My suggestion is to configure with --disable-statsysbfd
--enable-locbfd for now, and see if this fixes things.  If so, we can
chase down any potentially new bfd problems thereafter. 

Take care,

> G=E9rard,
> 
> There are at most 2 versions of GCL, but intentionally one 1.
> Part of the stable transition is to build and test with the 
> new GCL release but keep the old one available until I'm sure
> that the new one builds everywhere. 
> 
> Tim
> 
> From: Gerard Milmeister <Gerard Milmeister>

> Hi Tim,
> 
> I have successively made an Axiom rpm for Fedora Core 2 (Axiom cvs
> 20041106), but failed in building on Fedora Core 3.
> First, gcl doesn't compile. Apparently the bfd interface has changed.
> in file sfaslbfd.c, I changed the references of _raw_size to rawsize.
> Sees seemed to fix it, but while compiling axiom there is the following
> error:
> make[3]: Entering directory `/tmp/axiom/src/boot'
> 44 invoking make in /tmp/axiom/src/boot with parms:
> SYS= linux
> LSP= /tmp/axiom/lsp
> PART= cprogs
> SPAD= /tmp/axiom/mnt/linux
> SRC= /tmp/axiom/src
> INT= /tmp/axiom/int
> OBJ= /tmp/axiom/obj
> MNT= /tmp/axiom/mnt
> make[3]: *** [/tmp/axiom/obj/linux/bin/bootsys] Error 255
> 
> BTW, why are there multiple gcl packages included?

\start
Date: 22 Nov 2004 12:06:05 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: CVS, Arch, Darcs

Greetings!

Bill Page writes:

> On Thursday, November 18, 2004 9:16 PM Tim Daly wrote:
> 
> >...
> > From axiom's view GCL is a modular piece but it needs
> > integration work to build smoothly and end users shouldn't
> > do that.
> > 
> 
> >From the point of view of *end users*, I think it should not
> be more complicated than
> 
>   $ apt-get install axiom
> 
> (or the equivalent)
> 
> Forget about end-users building anything. All they want to

I think this point is very important.

Just a suggestion -- We need three tiers in the axiom community:

Developers (us) -- work on axiom bugs/features, ideally on only one
                   reference system

Porters/distros -- Build binaries for their favorite machine, and
                   perhaps pass patches back, which we should
                   incorporate in such a way as to not interfere with
                   the reference build and require no direct testing
                   on our part.

                   Support all 'it doesn't build for me' types of
                   reports from users who should (ideally) be using a
                   binary.


Users           -- Use the binaries, supply feedback, bug reports,
                   etc. 


Again, this is just a suggestion.  I think things are great just the
way they are too -- thanks to everyone's heroic efforts!


> do (and all they should expect to have to do) is to learn
> to use Axiom and get on with their main work. If we are lucky
> perhaps some end-users will be willing and interested in
> making they Axiom application work accessible to others.
> 
> For everyone else, there are so many levels and combinations
> of experience, skill and patience that I can't imagine how it
> would ever be possible to satisfy everyone. I would like more
> people to become more actively involved with Axiom development
> but for reasons that have little to do with the tools we are
> using, it seems unlikely to me that this will change even if the
> Axiom development process somehow manages to be more accessible.
> Basically, most people just do not have enough time to devote
> to this. So from my point of view, what is happening right now
> is (more or less) optimal.
> 
> About the only improvement I can think of right now is to make
> easily available a larger and well documented library of up to
> date and tested pre-compiled binaries for as many platforms
> and linux variants as possible. It would be great if some people
> besides Tim and Cam could contribute to such a library. I would
> be very pleased to set up an area on MathAction and the Axiom
> Portal where such contributed binary versions can be uploaded.

\start
Date: 22 Nov 2004 12:13:01 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Calculemus

Greetings!

Tim Daly writes:

> Dylan,
> 
> Yes, I did see that actually.
> 
> One of the proposed pieces of work with Axiom is to join it with
> ACL2. There have been email discussions with that group (Kaufmann,
> Boyer, and Moore) about it in the past.
> 
> ACL2 and Axiom are both written in common lisp and both run on GCL
> so it would be straightforward to load them into the same image.
> Cover functions could be created in axiom (since axiom code can
> directly call lisp code).
> 

This could be very interesting.  As you've said, luckily, the
technical aspects of the combination should be trivial, as both
projects have a thorough workout atop the same GCL image, at least in
the Debian autobuilding infrastructure.  The key of course lies in the
actual logic of the connections themselves.  I have a reasonably good
relationship with the ACL2 authors if/when we would like to solicit
their help/advice.

Take care,

> One research issue would be to take the merger as an assumption
> and see how axiom's categorical view supports or conflicts with
> ACL2's world view.
> 
> Another research issue would be to look at self-application of
> ACL2 to Axiom by focusing on something like Axiom's list or
> sorting implementations, showing proofs of code. Could proven
> axiom functions be used in further ACL2 proofs?
> 
> A third idea is to look at decorating the categories and domains
> with theorems (e.g. the ring properties and related theorems) and
> then propagating this information onto the domain functions and
> their arguments. Can we propagate properties to reach "logical
> conclusions" without actually computing a result?
> 
> A fourth idea is to apply ACL2 to computing "proviso" information
> (e.g. 1/x provided x!=0) where the provisos are carried at each
> step of a computation.
> 
> In general, I think that the merging of an algebra system, especially
> one based around theory as Axiom is, and a logic system will be a
> fruitful area of research work.

\start
Date: Tue, 23 Nov 2004 09:48:23 -0500
From: Tim Daly
To: list
Subject: who we are

Mr Chai,

Axiom is a computer algebra system that has been around for about 30 years.

see http://axiom@axiom-developer.org
see http://savannah.nongnu.org/projects/axiom

axiom-legal is one of our mailing lists dealing with the issue of
licensing.

\start
Date: Tue, 23 Nov 2004 11:03:42 -0500
From: Tim Daly
To: Eugene Chai
Subject: who we are

Mr Chai,

Axiom is a computer algebra system that has been around for about 30 years.

see http://axiom@axiom-developer.org
see http://savannah.nongnu.org/projects/axiom

axiom-legal is one of our mailing lists dealing with the issue of
licensing.

\start
Date: 24 Nov 2004 11:10:49 -0500
From: Camm Maguire
To: Matthew Kenendy
Subject: Re: [Gcl-devel] changes in binutils break gcl

Greetings!  Here is the fix you need.  Works with old and new
binutils.  Posted to the errata page on the website.  Tim, this should
address your earlier reports too.

==========================
==========================
==========================
==
Index: o/sfaslbfd.c
==========================
==========================
=================
RCS file: /cvsroot/gcl/gcl/o/sfaslbfd.c,v
retrieving revision 1.18
diff -u -r1.18 sfaslbfd.c
--- o/sfaslbfd.c	23 Aug 2004 23:09:23 -0000	1.18
+++ o/sfaslbfd.c	24 Nov 2004 16:00:09 -0000
@@ -256,7 +256,7 @@
 
     current=round_up(current,1<<s->alignment_power);
 
-    current+=s->_raw_size;
+    current+=bfd_section_size(b,s);
 
   }
   curr_size=(unsigned long)current;
@@ -281,7 +281,7 @@
 
     m=round_up(m,1<<s->alignment_power);
     s->output_section->vma=(unsigned long)m;
-    m+=s->_raw_size;
+    m+=bfd_section_size(b,s);
 =09     
   }
 
@@ -346,7 +346,7 @@
 					     v,0,q)) 
        FEerror("Cannot get relocated section contents\n",0);
 
-     memcpy((void *)(unsigned long)s->output_section->vma,v,s->_raw_size);
+     memcpy((void *)(unsigned long)s->output_section->vma,v,bfd_section_si=
ze(b,s));
      
    }
  }
==========================
==========================
==========================
==

Take care,

Matthew Kenendy writes:

> Hi Camm,
> 
> Camm Maguire writes:
> 
> [...]
> 
> > Actually, dont we want this:
> >
> > #define bfd_get_section_size_before_reloc(section) \
> >      ((section)->_raw_size)
> 
> I don't really know, however bfd.h from this binutils version has the
> following which is similar:
> 
> #define bfd_get_section_limit(bfd, sec) \
>   (((sec)->rawsize ? (sec)->rawsize : (sec)->size) \
>    / bfd_octets_per_byte (bfd))
> 
> > Also, have you been able to test your build against the new binutils?
> > Last I heard there were other problems.  Feedback most helpful,
> > esp. as this binutils is not in Debian yet.
> 
> There are no other build problems, but loading compiled files at
> runtime does fail.  Attached is a backtrace for gcl-2.6.5 built with
> --enable-dynsysbfd --disable-statsysfd.
> 
> Are there any other details I can provide for you?
> 
> mkennedy@camus:/mnt/space/tmp/gcl-2.6.5$ gdb
> GNU gdb 6.2.1
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you =
are
> welcome to change it and/or distribute copies of it under certain conditi=
ons.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for detail=
s.
> This GDB was configured as "i686-pc-linux-gnu".
> (gdb) file unixport/saved_gcl
> Reading symbols from /mnt/space/tmp/gcl-2.6.5/unixport/saved_gcl...done.
> Using host libthread_db library "/lib/libthread_db.so.1".
> (gdb) r
> Starting program: /mnt/space/tmp/gcl-2.6.5/unixport/saved_gcl 
> GCL (GNU Common Lisp)  2.6.5 CLtL1    Nov 23 2004 09:36:22
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> 
> >(load (compile-file "foo.lisp"))
> 
> Compiling foo.lisp.
> End of Pass 1.  
> End of Pass 2.  
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=
=3
> Finished compiling foo.lisp.
> Loading foo.o
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7ef1a86 in bfd_elf32_slurp_symbol_table () from /usr/lib/libbfd-2.15.9=
2.0.2.so
> 
> (gdb) bt full
> #0  0xb7ef1a86 in bfd_elf32_slurp_symbol_table () from /usr/lib/libbfd-2.=
15.92.0.2.so
> No symbol table info available.
> #1  0xb7ef1d51 in bfd_elf32_slurp_reloc_table () from /usr/lib/libbfd-2.1=
5.92.0.2.so
> No symbol table info available.
> #2  0xb7efea57 in _bfd_elf_canonicalize_reloc () from /usr/lib/libbfd-2.1=
5.92.0.2.so
> No symbol table info available.
> #3  0xb7ecf1cc in bfd_canonicalize_reloc () from /usr/lib/libbfd-2.15.92.=
0.2.so
> No symbol table info available.
> #4  0xb7ed8e5f in bfd_generic_get_relocated_section_contents ()
>    from /usr/lib/libbfd-2.15.92.0.2.so
> No symbol table info available.
> #5  0xb7ecfac3 in bfd_get_relocated_section_contents ()
>    from /usr/lib/libbfd-2.15.92.0.2.so
> No symbol table info available.
> #6  0x0806ec48 in fasload (faslfile=0x8577438) at sfaslbfd.c:352
> 	v = (void *) 0xbfffddb0
> 	data = 0x805eb25
> 	filename = "foo.o", '\0' <repeats 19 times>, "\017\000\000\000\017\000=
\000\000\224=F6=FF=BF =F6=FF=BFx=DF=FF=BF\0223\f\b\n\000\000\000\000\006=E2=
=B7\000\000\000\000\000\000\000\000\f\000\000\000\224=F6=FF=BF=B8=DF=FF=BF=
=EE|\n\b\n\000\000\000\000\006=E2=B7\000\000\000\000=B8=DF=FF=BF\016\000\00=
0\000=C0=DC6\b\203=E4=DA=B7=F4=FF=E1=B7=FF=FF=D4=B7\001\000\000\000=C0=DC6\=
b\016\000\000\000\000\006=E2=B7\200=FB=E1=B7=DC=DF=FF=BF=BB=EA=D4=B7\000\00=
6=E2=B7=C0=DC6\b\016\000\000\000=F7\r\a\b=F4=FF=E1=B7\000\006=E2=B7\000\000=
\000\000\000=E0=FF=BFB=F7=D4=B7\000\006=E2=B7=C0=DC6\b\016\000\000\000x=EF7=
\b=F4=FF=E1=B7\000\006=E2=B7\200=FB=E1=B7\030"...
> 	init_address = 0
> 	memory = 0x8384b2c
> 	max_align = 4
> 	current = (void *) 0x0
> 	curr_size = 0
> 	old_vs_base = (object *) 0x81e297c
> 	old_vs_top = (object *) 0x81e29bc
> 	nbfd = 1
> 	b = (bfd *) 0x83aefb0
> 	myerr = bfd_error_wrong_format
> 	u = 28
> 	v = 28
> 	q = (asymbol **) 0xbfffddc0
> 	s = (asection *) 0x83b3bb4
> 	the_start = (void *) 0x83af1a0
> 	start_address = (void *) 0x83af1a0
> 	m = (void *) 0x83af1a0
> 	dum = {FIX = {t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = =
0 '\0', 
>     FIXVAL = 0}, big = {t = 16 '\020', flag = 0 '\0', s = 0 '\0=
', m = 0 '\0', 
>     big_mpz_t = {_mp_alloc = 0, _mp_size = 137901976, _mp_d = 0x0=
}}, rat = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', rat_den=
 = 0x0, 
>     rat_num = 0x8383798}, SF = {t = 16 '\020', flag = 0 '\0', s =
= 0 '\0', m = 0 '\0', 
>     SFVAL = 0}, LF = {t = 16 '\020', flag = 0 '\0', s = 0 '\0',=
 m = 0 '\0', 
>     LFVAL = 4.5840268370521081e-269}, cmp = {t = 16 '\020', flag =
= 0 '\0', s = 0 '\0', 
>     m = 0 '\0', cmp_real = 0x0, cmp_imag = 0x8383798}, ch = {t =
= 16 '\020', 
>     flag = 0 '\0', s = 0 '\0', m = 0 '\0', ch_code = 0, ch_font =
= 0 '\0', 
>     ch_bits = 0 '\0'}, s = {t = 16 '\020', flag = 0 '\0', s = 0=
 '\0', m = 0 '\0', 
>     s_dbind = 0x0, s_sfdef = 0x8383798 <imag_two+27096>, st_self = =
0x0, st_fillp = 0, 
>     s_gfdef = 0x0, s_plist = 0x0, s_hpack = 0x0, s_stype = 0, s_m=
flag = 0}, p = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', p_name =
= 0x0, 
>     p_nicknames = 0x8383798, p_shadowings = 0x0, p_uselist = 0x0, p=
_usedbylist = 0x0, 
>     p_internal = 0x0, p_external = 0x0, p_internal_size = 0, p_exte=
rnal_size = 0, 
>     p_internal_fp = 0, p_external_fp = 0, p_link = 0x0}, c = {t =
= 16 '\020', 
>     flag = 0 '\0', s = 0 '\0', m = 0 '\0', c_cdr = 0x0, c_car ==
 0x8383798}, ht = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', ht_self=
 = 0x0, 
>     ht_rhsize = 0x8383798, ht_rhthresh = 0x0, ht_nent = 0, ht_size =
= 0, ht_test = 0}, 
>   a = {t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', a_=
displaced = 0x0, 
>     a_rank = 14232, a_elttype = 2104, a_self = 0x0, a_adjustable =
= 0, a_offset = 0, 
>     a_dim = 0, a_dims = 0x0}, v = {t = 16 '\020', flag = 0 '\0'=
, s = 0 '\0', 
>     m = 0 '\0', v_displaced = 0x0, v_hasfillp = 14232, v_elttype =
= 2104, v_self = 0x0, 
>     v_fillp = 0, v_dim = 0, v_adjustable = 0, v_offset = 0}, st =
= {t = 16 '\020', 
>     flag = 0 '\0', s = 0 '\0', m = 0 '\0', st_displaced = 0x0, st=
_hasfillp = 14232, 
>     st_adjustable = 2104, st_self = 0x0, st_fillp = 0, st_dim = 0=
}, ust = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', ust_dis=
placed = 0x0, 
>     ust_hasfillp = 14232, ust_adjustable = 2104, ust_self = 0x0, us=
t_fillp = 0, 
>     ust_dim = 0}, bv = {t = 16 '\020', flag = 0 '\0', s = 0 '\0=
', m = 0 '\0', 
>     bv_displaced = 0x0, bv_hasfillp = 14232, bv_elttype = 2104, bv_=
self = 0x0, 
>     bv_fillp = 0, bv_dim = 0, bv_adjustable = 0, bv_offset = 0}, =
str = {t = 16 '\020', 
>     flag = 0 '\0', s = 0 '\0', m = 0 '\0', str_def = 0x0, str_sel=
f = 0x8383798}, sm = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', sm_fp =
= 0x0, 
>     sm_object0 = 0x8383798, sm_object1 = 0x0, sm_int0 = 0, sm_int1 =
= 0, 
>     sm_buffer = 0x0, sm_mode = 0 '\0', sm_flags = 0 '\0', sm_fd ==
 0}, rnd = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', rnd_val=
ue = 0}, rt = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', rt_self=
 = 0x0}, pn = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', pn_host=
 = 0x0, 
>     pn_device = 0x8383798, pn_directory = 0x0, pn_name = 0x0, pn_ty=
pe = 0x0, 
>     pn_version = 0x0}, cf = {t = 16 '\020', flag = 0 '\0', s = =
0 '\0', m = 0 '\0', 
>     cf_name = 0x0, cf_self = 0x8383798 <imag_two+27096>, cf_data = =
0x0}, cc = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', cc_name=
 = 0x0, 
>     cc_self = 0x8383798 <imag_two+27096>, cc_env = 0x0, cc_data = 0=
x0, cc_envdim = 0, 
>     cc_turbo = 0x0}, cl = {t = 16 '\020', flag = 0 '\0', s = 0 =
'\0', m = 0 '\0', 
>     cl_name = 0x0, cl_self = 0x8383798 <imag_two+27096>, cl_data = =
0x0, cl_argd = 0, 
>     cl_envdim = 0, cl_env = 0x0}, sfn = {t = 16 '\020', flag = =
0 '\0', s = 0 '\0', 
>     m = 0 '\0', sfn_name = 0x0, sfn_self = 0x8383798 <imag_two+2709=
6>, sfn_data = 0x0, 
>     sfn_argd = 0}, vfn = {t = 16 '\020', flag = 0 '\0', s = 0 '=
\0', m = 0 '\0', 
>     vfn_name = 0x0, vfn_self = 0x8383798 <imag_two+27096>, vfn_data =
= 0x0, 
>     vfn_minargs = 0, vfn_maxargs = 0}, cfd = {t = 16 '\020', flag=
 = 0 '\0', s = 0 '\0', 
>     m = 0 '\0', cfd_start = 0x0, cfd_size = 137901976, cfd_fillp =
= 0, cfd_self = 0x0}, 
>   spc = {t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', =
spc_dummy = 0}, d = {
>     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0'}, fixa =
= {t = 16 '\020', 
>     flag = 0 '\0', s = 0 '\0', m = 0 '\0', fixa_displaced = 0x0, =
fixa_rank = 14232, 
>     fixa_elttype = 2104, fixa_self = 0x0, fixa_adjustable = 0, fixa=
_offset = 0, 
>     fixa_dim = 0, fixa_dims = 0x0}, sfa = {t = 16 '\020', flag =
= 0 '\0', s = 0 '\0', 
>     m = 0 '\0', sfa_displaced = 0x0, sfa_rank = 14232, sfa_elttype =
= 2104, 
>     sfa_self = 0x0, sfa_adjustable = 0, sfa_offset = 0, sfa_dim ==
 0, sfa_dims = 0x0}, 
>   lfa = {t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', =
lfa_displaced = 0x0, 
>     lfa_rank = 14232, lfa_elttype = 2104, lfa_self = 0x0, lfa_adjus=
table = 0, 
>     lfa_offset = 0, lfa_dim = 0, lfa_dims = 0x0}}
> 	link_callbacks = {add_archive_element = 0x806e3d8 <madd_archive_elem=
ent>, 
>   multiple_definition = 0x806e3e2 <mmultiple_definition>, 
>   multiple_common = 0x806e3ec <mmultiple_common>, add_to_set = 0x806e=
3f6 <madd_to_set>, 
>   constructor = 0x806e400 <mconstructor>, warning = 0x806e40a <mwarni=
ng>, 
>   undefined_symbol = 0x806e414 <mundefined_symbol>, 
>   reloc_overflow = 0x806e434 <mreloc_overflow>, 
>   reloc_dangerous = 0x806e454 <mreloc_dangerous>, 
>   unattached_reloc = 0x806e474 <munattached_reloc>, notice = 0x806e47=
e <mnotice>}
> 	link_order = {next = 0x0, type = bfd_indirect_link_order, offset =
= 0, size = 0, 
>   u = {indirect = {section = 0x83b3bb4}, data = {size = 1380996=
36, contents = 0x0}, 
>     reloc = {p = 0x83b3bb4}}}
> 	entry_name = "\000init_"
> 	entry_name_ptr = 0xbfffdee1 "init_"
> #7  0x080aa002 in Lload () at file.d:1842
> 	old_bds_top = 0x8283dc8
> 	i = 136194436
> 	strm1 = 0x81e2980
> 	narg = 1
> 	DPPbase = (object *) 0x81e297c
> #8  0x080a0d5e in eval (form=0x8369aa0) at eval.c:1090
> 	temporary = 0x8369aa0
> 	fun = 0x8387e34
> 	x = 0x838a550
> 	top = (object *) 0x81e2980
> 	base = (object *) 0x81e297c
> #9  0x080a1258 in fLeval (x0=0x8531c30) at eval.c:1178
> 	lex = (object *) 0x81e2920
> #10 0x080b32a1 in c_apply_n (fn=0x80a11fc <fLeval>, n=1, x=0x81e296=
8) at funlink.c:271
> 	res = 0x8369aa0
> #11 0x080504db in IapplyVector (fun=0x8384e24, nargs=1, base=0x81e2=
968)
>     at nfunlink.c:229
> 	res = 0xb7e1fff4
> 	abase = (object *) 0x81e2968
> 	i = 1
> 	oldtop = (object *) 0x81e2968
> 	atypes = 0
> #12 0x0809ef38 in funcall (fun=0x8384e24) at eval.c:190
> 	res = 0xbfffef38
> 	b = (object *) 0x81e2964
> 	n = 1
> 	temporary = 0x4
> 	x = 0x81e2964
> 	top = (object * volatile) 0x8
> 	lex = (object *) 0xbfffef38
> 	old_bds_top = 0x837ef48
> 	b = 137919404
> 	c = 134636159
> #13 0x0809fea1 in symlispcall (sym=0x83831f8, base=0x81e2964, narg==
1) at eval.c:507
> 	fun = 0x8384e24
> #14 0x0815a9e7 in LI1 () at gcl_top.c:140
> 	V6 = 0x8289240
> 	base = (object * volatile) 0x81e293c
> 	V4 = 0x8380f70
> 	V2 = 0x8049b5c
> 	V1 = 0x8369aa0
> 	sup = (object * volatile) 0x81e2974
> #15 0x0809e282 in quick_call_sfun (fun=0x84ddfa0) at eval.c:117
> 	i = 0
> 	n = 0
> 	restype = f_object
> 	x = (object *) 0x81e293c
> 	res = 0xb7ffd508
> 	base = (object *) 0x81e293c
> 	temp_ar = (object *) 0xbfffefe0
> #16 0x0809eeb2 in funcall (fun=0x84ddfa0) at eval.c:178
> 	temporary = 0xb7ffa58a
> 	x = 0xbffff0a0
> 	top = (object * volatile) 0xb8000fd4
> 	lex = (object *) 0x1000
> 	old_bds_top = 0x837eed0
> 	b = 137903596
> 	c = 134951618
> #17 0x08050604 in IapplyVector (fun=0x84ddfa0, nargs=0, base=0x81e2=
93c)
>     at nfunlink.c:239
> 	res = 0x0
> 	abase = (object *) 0x0
> 	i = -1073746032
> 	oldtop = (object *) 0x81e293c
> 	atypes = 0
> #18 0x080a0fd6 in fLfuncall (fun=0x84ddfa0) at eval.c:1140
> 	Xxvl = {0xea343, 0xbffff694, 0xbffff620, 0xbffff198, 0xbfffef70, 0x80b=
26cf, 
>   0x0, 0xb7fe95a2, 0xb7fe91ec, 0xb7fe9000, 0xbffff190, 0xbffff190, 0xb800=
11c0, 0x2, 
>   0xb8000fd4, 0xffffffe8, 0x4, 0x0, 0xb7ced240, 0xb80014e0, 0x7, 0xb8000f=
f0, 
>   0xb7fe940c, 0xb7fe95a2, 0xb7fe91ec, 0xb7fe9000, 0x8049f2c, 0x0, 0xb8001=
1c0, 0x2, 
>   0xb80011c0, 0x0, 0xbffff180, 0x837eed0, 0xbffff2b8, 0x8050877, 0x808eb2=
b, 0x2, 
>   0xbffff1a0, 0xbffff190, 0x1, 0x0, 0x0, 0xbffff1a8, 0x837eed0, 0x81e293c=
, 0xbffff2a8, 
>   0x80b32c2, 0x8387bac, 0x853bb10, 0x8, 0x81e2900, 0xbffff694, 0xbffff620=
, 0xbffff2e8, 
>   0xb7ff6c13, 0x8049877, 0xb7fb3a0c, 0xb8000fd4, 0xb7fb3e30, 0x0, 0xbffff=
228, 
>   0xb7ff1c31, 0xb7cfeb14, 0x8049ca7}
> 	ap = 0xbffff218 "h\233\004\b=D4\017"
> 	new = (object *) 0xbffff0e0
> 	n = 1
> #19 0x080b32a1 in c_apply_n (fn=0x80a0f44 <fLfuncall>, n=1, x=0x81e=
2938)
>     at funlink.c:271
> 	res = 0x8369aa0
> #20 0x080504db in IapplyVector (fun=0x8384e4c, nargs=1, base=0x81e2=
938)
>     at nfunlink.c:229
> 	res = 0x1
> 	abase = (object *) 0x81e2938
> 	i = -1073744984
> 	oldtop = (object *) 0x81e2938
> 	atypes = 0
> #21 0x0809ef38 in funcall (fun=0x8384e4c) at eval.c:190
> 	res = 0x81e2958
> 	b = (object *) 0x81e2934
> 	n = 1
> 	temporary = 0x81e2900
> 	x = 0x2
> 	top = (object * volatile) 0x805440f
> 	lex = (object *) 0xbffff3d8
> 	old_bds_top = 0x81e2900
> 	b = 137891696
> 	c = 0
> #22 0x0809f844 in funcall_no_event (fun=0x8384e4c) at eval.c:381
> No locals.
> #23 0x080a0d6b in eval (form=0x8369aa0) at eval.c:1092
> 	temporary = 0x81e2900
> 	fun = 0x8383240
> 	x = 0x8384e4c
> 	top = (object *) 0x81e2938
> 	base = (object *) 0x81e2934
> #24 0x0809f5b6 in funcall (fun=0x852efe0) at eval.c:327
> 	not_pushed = 1
> 	temporary = 0x85e0f30
> 	x = 0x84f2de0
> 	top = (object * volatile) 0x81e2930
> 	lex = (object *) 0x81e290c
> 	old_bds_top = 0x8283d78
> 	b = 1
> 	c = 0
> #25 0x0809f844 in funcall_no_event (fun=0x85e0d14) at eval.c:381
> No locals.
> #26 0x080a0d6b in eval (form=0x8369aa0) at eval.c:1092
> 	temporary = 0xb80014e0
> 	fun = 0x84ea9b4
> 	x = 0x85e0d14
> 	top = (object *) 0x81e2920
> 	base = (object *) 0x81e2920
> #27 0x0809f5b6 in funcall (fun=0x852eff0) at eval.c:327
> 	not_pushed = 0
> 	temporary = 0x85e0f84
> 	x = 0x84f2d14
> 	top = (object * volatile) 0x81e291c
> 	lex = (object *) 0x81e2900
> 	old_bds_top = 0x8283d78
> 	b = 1
> 	c = 0
> #28 0x080a058a in super_funcall (fun=0x85e0ff0) at eval.c:743
> No locals.
> #29 0x0804b6c8 in main (argc=1, argv=0xbffff694, envp=0xbffff69c) a=
t main.c:369
> 	rl = {rlim_cur = 4294967295, rlim_max = 4294967295}
> (gdb) quit

\start
Date: Wed, 24 Nov 2004 13:51:10 -0500
From: Tim Daly
To: list
Subject: arch server support
Cc: Gilbert Baumslag

*,

With the essential help of Bill Page and Mark Murray we've configured
an arch server for Axiom development.

Most of you don't care. Savannah is still the authoritative source
for a working axiom system.

For those who want to get the lastest set of mistakes you can visit
http://axiom.axiom-developer.org and look at the [ Developers ] link.

This will take you to a page that describes how to get the latest
version of the code.

Note that I change code on an almost-daily basis, at least in some
branch and that the code is almost certainly broken and may not even
compile.

The point of this archive is to open up the development of axiom, to
make it possible for others to collaborate effectively and make the
development transparent. Since only the fully tested endpoints ever
get put on savannah it appears that nothing is changing between
observed endpoints. While I realize that the universe works this way
at a fundamental level and such changes are not observable this is
not the case with Axiom.

If you're willing to jointly work on developing some new feature we
can create a branch where we can work together. Once it works
we can merge the changes back to the main line and eventually back
to savannah.

\start
Date: 24 Nov 2004 13:46:21 -0500
From: Camm Maguire
To: Matthew Kenendy
Subject: re: [Gcl-devel] changes in binutils break gcl

Greetings!  Minor update to the afore posted patch to work with the
local bfd source.  This is the version now on the website errata page:

==========================
==========================
==========================
==
Index: o/sfaslbfd.c
==========================
==========================
=================
RCS file: /cvsroot/gcl/gcl/o/sfaslbfd.c,v
retrieving revision 1.18
diff -u -r1.18 sfaslbfd.c
--- o/sfaslbfd.c	23 Aug 2004 23:09:23 -0000	1.18
+++ o/sfaslbfd.c	24 Nov 2004 16:00:09 -0000
@@ -256,7 +256,7 @@
 
     current=round_up(current,1<<s->alignment_power);
 
-    current+=s->_raw_size;
+    current+=bfd_section_size(b,s);
 
   }
   curr_size=(unsigned long)current;
@@ -281,7 +281,7 @@
 
     m=round_up(m,1<<s->alignment_power);
     s->output_section->vma=(unsigned long)m;
-    m+=s->_raw_size;
+    m+=bfd_section_size(b,s);
 =09     
   }
 
@@ -346,7 +346,7 @@
 					     v,0,q)) 
        FEerror("Cannot get relocated section contents\n",0);
 
-     memcpy((void *)(unsigned long)s->output_section->vma,v,s->_raw_size);
+     memcpy((void *)(unsigned long)s->output_section->vma,v,bfd_section_si=
ze(b,s));
      
    }
  }
Index: binutils/bfd/bfd-in.h
==========================
==========================
=================
RCS file: /cvsroot/gcl/gcl/binutils/bfd/bfd-in.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 bfd-in.h
--- binutils/bfd/bfd-in.h	9 Aug 2002 05:34:46 -0000	1.1.1.1
+++ binutils/bfd/bfd-in.h	24 Nov 2004 18:45:08 -0000
@@ -337,7 +337,8 @@
 #define bfd_get_section_lma(bfd, ptr) ((ptr)->lma + 0)
 #define bfd_get_section_alignment(bfd, ptr) ((ptr)->alignment_power + 0)
 #define bfd_section_name(bfd, ptr) ((ptr)->name)
-#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))
+#define bfd_section_size(bfd, ptr) ((ptr)->_raw_size)
+/* #define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(p=
tr)) */
 #define bfd_section_vma(bfd, ptr) ((ptr)->vma)
 #define bfd_section_lma(bfd, ptr) ((ptr)->lma)
 #define bfd_section_alignment(bfd, ptr) ((ptr)->alignment_power)
Index: binutils/bfd/bfd-in2.h
==========================
==========================
=================
RCS file: /cvsroot/gcl/gcl/binutils/bfd/bfd-in2.h,v
retrieving revision 1.3
diff -u -r1.3 bfd-in2.h
--- binutils/bfd/bfd-in2.h	22 Feb 2004 11:05:18 -0000	1.3
+++ binutils/bfd/bfd-in2.h	24 Nov 2004 18:45:08 -0000
@@ -342,7 +342,8 @@
 #define bfd_get_section_lma(bfd, ptr) ((ptr)->lma + 0)
 #define bfd_get_section_alignment(bfd, ptr) ((ptr)->alignment_power + 0)
 #define bfd_section_name(bfd, ptr) ((ptr)->name)
-#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))
+#define bfd_section_size(bfd, ptr) ((ptr)->_raw_size)
+/*#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(pt=
r))*/
 #define bfd_section_vma(bfd, ptr) ((ptr)->vma)
 #define bfd_section_lma(bfd, ptr) ((ptr)->lma)
 #define bfd_section_alignment(bfd, ptr) ((ptr)->alignment_power)
==========================
==========================
==========================
==

Take care,

Camm Maguire writes:

> Greetings!  Here is the fix you need.  Works with old and new
> binutils.  Posted to the errata page on the website.  Tim, this should
> address your earlier reports too.
> 
> =========================
==========================
==========================
===
> Index: o/sfaslbfd.c
> =========================
==========================
==================
> RCS file: /cvsroot/gcl/gcl/o/sfaslbfd.c,v
> retrieving revision 1.18
> diff -u -r1.18 sfaslbfd.c
> --- o/sfaslbfd.c	23 Aug 2004 23:09:23 -0000	1.18
> +++ o/sfaslbfd.c	24 Nov 2004 16:00:09 -0000
> @@ -256,7 +256,7 @@
>  
>      current=round_up(current,1<<s->alignment_power);
>  
> -    current+=s->_raw_size;
> +    current+=bfd_section_size(b,s);
>  
>    }
>    curr_size=(unsigned long)current;
> @@ -281,7 +281,7 @@
>  
>      m=round_up(m,1<<s->alignment_power);
>      s->output_section->vma=(unsigned long)m;
> -    m+=s->_raw_size;
> +    m+=bfd_section_size(b,s);
>  =09     
>    }
>  
> @@ -346,7 +346,7 @@
>  					     v,0,q)) 
>         FEerror("Cannot get relocated section contents\n",0);
>  
> -     memcpy((void *)(unsigned long)s->output_section->vma,v,s->_raw_size=
);
> +     memcpy((void *)(unsigned long)s->output_section->vma,v,bfd_section_=
size(b,s));
>       
>     }
>   }
> =========================
==========================
==========================
===
> 
> Take care,
> 
> Matthew Kenendy writes:
> 
> > Hi Camm,
> > 
> > Camm Maguire writes:
> > 
> > [...]
> > 
> > > Actually, dont we want this:
> > >
> > > #define bfd_get_section_size_before_reloc(section) \
> > >      ((section)->_raw_size)
> > 
> > I don't really know, however bfd.h from this binutils version has the
> > following which is similar:
> > 
> > #define bfd_get_section_limit(bfd, sec) \
> >   (((sec)->rawsize ? (sec)->rawsize : (sec)->size) \
> >    / bfd_octets_per_byte (bfd))
> > 
> > > Also, have you been able to test your build against the new binutils?
> > > Last I heard there were other problems.  Feedback most helpful,
> > > esp. as this binutils is not in Debian yet.
> > 
> > There are no other build problems, but loading compiled files at
> > runtime does fail.  Attached is a backtrace for gcl-2.6.5 built with
> > --enable-dynsysbfd --disable-statsysfd.
> > 
> > Are there any other details I can provide for you?
> > 
> > mkennedy@camus:/mnt/space/tmp/gcl-2.6.5$ gdb
> > GNU gdb 6.2.1
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and yo=
u are
> > welcome to change it and/or distribute copies of it under certain condi=
tions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for deta=
ils.
> > This GDB was configured as "i686-pc-linux-gnu".
> > (gdb) file unixport/saved_gcl
> > Reading symbols from /mnt/space/tmp/gcl-2.6.5/unixport/saved_gcl...done.
> > Using host libthread_db library "/lib/libthread_db.so.1".
> > (gdb) r
> > Starting program: /mnt/space/tmp/gcl-2.6.5/unixport/saved_gcl 
> > GCL (GNU Common Lisp)  2.6.5 CLtL1    Nov 23 2004 09:36:22
> > Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> > Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> > Modifications of this banner must retain notice of a compatible license
> > Dedicated to the memory of W. Schelter
> > 
> > Use (help) to get some basic information on how to use GCL.
> > 
> > >(load (compile-file "foo.lisp"))
> > 
> > Compiling foo.lisp.
> > End of Pass 1.  
> > End of Pass 2.  
> > OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Spe=
ed=3
> > Finished compiling foo.lisp.
> > Loading foo.o
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xb7ef1a86 in bfd_elf32_slurp_symbol_table () from /usr/lib/libbfd-2.15=
.92.0.2.so
> > 
> > (gdb) bt full
> > #0  0xb7ef1a86 in bfd_elf32_slurp_symbol_table () from /usr/lib/libbfd-=
2.15.92.0.2.so
> > No symbol table info available.
> > #1  0xb7ef1d51 in bfd_elf32_slurp_reloc_table () from /usr/lib/libbfd-2=
.15.92.0.2.so
> > No symbol table info available.
> > #2  0xb7efea57 in _bfd_elf_canonicalize_reloc () from /usr/lib/libbfd-2=
.15.92.0.2.so
> > No symbol table info available.
> > #3  0xb7ecf1cc in bfd_canonicalize_reloc () from /usr/lib/libbfd-2.15.9=
2.0.2.so
> > No symbol table info available.
> > #4  0xb7ed8e5f in bfd_generic_get_relocated_section_contents ()
> >    from /usr/lib/libbfd-2.15.92.0.2.so
> > No symbol table info available.
> > #5  0xb7ecfac3 in bfd_get_relocated_section_contents ()
> >    from /usr/lib/libbfd-2.15.92.0.2.so
> > No symbol table info available.
> > #6  0x0806ec48 in fasload (faslfile=0x8577438) at sfaslbfd.c:352
> > 	v = (void *) 0xbfffddb0
> > 	data = 0x805eb25
> > 	filename = "foo.o", '\0' <repeats 19 times>, "\017\000\000\000\017\0=
00\000\000\224=F6=FF=BF =F6=FF=BFx=DF=FF=BF\0223\f\b\n\000\000\000\000\006=
=E2=B7\000\000\000\000\000\000\000\000\f\000\000\000\224=F6=FF=BF=B8=DF=FF=
=BF=EE|\n\b\n\000\000\000\000\006=E2=B7\000\000\000\000=B8=DF=FF=BF\016\000=
\000\000=C0=DC6\b\203=E4=DA=B7=F4=FF=E1=B7=FF=FF=D4=B7\001\000\000\000=C0=
=DC6\b\016\000\000\000\000\006=E2=B7\200=FB=E1=B7=DC=DF=FF=BF=BB=EA=D4=B7\0=
00\006=E2=B7=C0=DC6\b\016\000\000\000=F7\r\a\b=F4=FF=E1=B7\000\006=E2=B7\00=
0\000\000\000\000=E0=FF=BFB=F7=D4=B7\000\006=E2=B7=C0=DC6\b\016\000\000\000=
x=EF7\b=F4=FF=E1=B7\000\006=E2=B7\200=FB=E1=B7\030"...
> > 	init_address = 0
> > 	memory = 0x8384b2c
> > 	max_align = 4
> > 	current = (void *) 0x0
> > 	curr_size = 0
> > 	old_vs_base = (object *) 0x81e297c
> > 	old_vs_top = (object *) 0x81e29bc
> > 	nbfd = 1
> > 	b = (bfd *) 0x83aefb0
> > 	myerr = bfd_error_wrong_format
> > 	u = 28
> > 	v = 28
> > 	q = (asymbol **) 0xbfffddc0
> > 	s = (asection *) 0x83b3bb4
> > 	the_start = (void *) 0x83af1a0
> > 	start_address = (void *) 0x83af1a0
> > 	m = (void *) 0x83af1a0
> > 	dum = {FIX = {t = 16 '\020', flag = 0 '\0', s = 0 '\0', m =
= 0 '\0', 
> >     FIXVAL = 0}, big = {t = 16 '\020', flag = 0 '\0', s = 0 '=
\0', m = 0 '\0', 
> >     big_mpz_t = {_mp_alloc = 0, _mp_size = 137901976, _mp_d = 0=
x0}}, rat = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', rat_d=
en = 0x0, 
> >     rat_num = 0x8383798}, SF = {t = 16 '\020', flag = 0 '\0', s=
 = 0 '\0', m = 0 '\0', 
> >     SFVAL = 0}, LF = {t = 16 '\020', flag = 0 '\0', s = 0 '\0=
', m = 0 '\0', 
> >     LFVAL = 4.5840268370521081e-269}, cmp = {t = 16 '\020', flag =
= 0 '\0', s = 0 '\0', 
> >     m = 0 '\0', cmp_real = 0x0, cmp_imag = 0x8383798}, ch = {t =
= 16 '\020', 
> >     flag = 0 '\0', s = 0 '\0', m = 0 '\0', ch_code = 0, ch_font=
 = 0 '\0', 
> >     ch_bits = 0 '\0'}, s = {t = 16 '\020', flag = 0 '\0', s ==
 0 '\0', m = 0 '\0', 
> >     s_dbind = 0x0, s_sfdef = 0x8383798 <imag_two+27096>, st_self =
= 0x0, st_fillp = 0, 
> >     s_gfdef = 0x0, s_plist = 0x0, s_hpack = 0x0, s_stype = 0, s=
_mflag = 0}, p = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', p_nam=
e = 0x0, 
> >     p_nicknames = 0x8383798, p_shadowings = 0x0, p_uselist = 0x0,=
 p_usedbylist = 0x0, 
> >     p_internal = 0x0, p_external = 0x0, p_internal_size = 0, p_ex=
ternal_size = 0, 
> >     p_internal_fp = 0, p_external_fp = 0, p_link = 0x0}, c = {t=
 = 16 '\020', 
> >     flag = 0 '\0', s = 0 '\0', m = 0 '\0', c_cdr = 0x0, c_car =
= 0x8383798}, ht = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', ht_se=
lf = 0x0, 
> >     ht_rhsize = 0x8383798, ht_rhthresh = 0x0, ht_nent = 0, ht_siz=
e = 0, ht_test = 0}, 
> >   a = {t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', =
a_displaced = 0x0, 
> >     a_rank = 14232, a_elttype = 2104, a_self = 0x0, a_adjustable =
= 0, a_offset = 0, 
> >     a_dim = 0, a_dims = 0x0}, v = {t = 16 '\020', flag = 0 '\=
0', s = 0 '\0', 
> >     m = 0 '\0', v_displaced = 0x0, v_hasfillp = 14232, v_elttype =
= 2104, v_self = 0x0, 
> >     v_fillp = 0, v_dim = 0, v_adjustable = 0, v_offset = 0}, st=
 = {t = 16 '\020', 
> >     flag = 0 '\0', s = 0 '\0', m = 0 '\0', st_displaced = 0x0, =
st_hasfillp = 14232, 
> >     st_adjustable = 2104, st_self = 0x0, st_fillp = 0, st_dim ==
 0}, ust = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', ust_d=
isplaced = 0x0, 
> >     ust_hasfillp = 14232, ust_adjustable = 2104, ust_self = 0x0, =
ust_fillp = 0, 
> >     ust_dim = 0}, bv = {t = 16 '\020', flag = 0 '\0', s = 0 '=
\0', m = 0 '\0', 
> >     bv_displaced = 0x0, bv_hasfillp = 14232, bv_elttype = 2104, b=
v_self = 0x0, 
> >     bv_fillp = 0, bv_dim = 0, bv_adjustable = 0, bv_offset = 0}=
, str = {t = 16 '\020', 
> >     flag = 0 '\0', s = 0 '\0', m = 0 '\0', str_def = 0x0, str_s=
elf = 0x8383798}, sm = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', sm_fp=
 = 0x0, 
> >     sm_object0 = 0x8383798, sm_object1 = 0x0, sm_int0 = 0, sm_int=
1 = 0, 
> >     sm_buffer = 0x0, sm_mode = 0 '\0', sm_flags = 0 '\0', sm_fd =
= 0}, rnd = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', rnd_v=
alue = 0}, rt = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', rt_se=
lf = 0x0}, pn = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', pn_ho=
st = 0x0, 
> >     pn_device = 0x8383798, pn_directory = 0x0, pn_name = 0x0, pn_=
type = 0x0, 
> >     pn_version = 0x0}, cf = {t = 16 '\020', flag = 0 '\0', s =
= 0 '\0', m = 0 '\0', 
> >     cf_name = 0x0, cf_self = 0x8383798 <imag_two+27096>, cf_data =
= 0x0}, cc = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', cc_na=
me = 0x0, 
> >     cc_self = 0x8383798 <imag_two+27096>, cc_env = 0x0, cc_data ==
 0x0, cc_envdim = 0, 
> >     cc_turbo = 0x0}, cl = {t = 16 '\020', flag = 0 '\0', s = =
0 '\0', m = 0 '\0', 
> >     cl_name = 0x0, cl_self = 0x8383798 <imag_two+27096>, cl_data =
= 0x0, cl_argd = 0, 
> >     cl_envdim = 0, cl_env = 0x0}, sfn = {t = 16 '\020', flag =
= 0 '\0', s = 0 '\0', 
> >     m = 0 '\0', sfn_name = 0x0, sfn_self = 0x8383798 <imag_two+27=
096>, sfn_data = 0x0, 
> >     sfn_argd = 0}, vfn = {t = 16 '\020', flag = 0 '\0', s = 0=
 '\0', m = 0 '\0', 
> >     vfn_name = 0x0, vfn_self = 0x8383798 <imag_two+27096>, vfn_data=
 = 0x0, 
> >     vfn_minargs = 0, vfn_maxargs = 0}, cfd = {t = 16 '\020', fl=
ag = 0 '\0', s = 0 '\0', 
> >     m = 0 '\0', cfd_start = 0x0, cfd_size = 137901976, cfd_fillp =
= 0, cfd_self = 0x0}, 
> >   spc = {t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0'=
, spc_dummy = 0}, d = {
> >     t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0'}, fixa=
 = {t = 16 '\020', 
> >     flag = 0 '\0', s = 0 '\0', m = 0 '\0', fixa_displaced = 0x0=
, fixa_rank = 14232, 
> >     fixa_elttype = 2104, fixa_self = 0x0, fixa_adjustable = 0, fi=
xa_offset = 0, 
> >     fixa_dim = 0, fixa_dims = 0x0}, sfa = {t = 16 '\020', flag =
= 0 '\0', s = 0 '\0', 
> >     m = 0 '\0', sfa_displaced = 0x0, sfa_rank = 14232, sfa_elttyp=
e = 2104, 
> >     sfa_self = 0x0, sfa_adjustable = 0, sfa_offset = 0, sfa_dim =
= 0, sfa_dims = 0x0}, 
> >   lfa = {t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0'=
, lfa_displaced = 0x0, 
> >     lfa_rank = 14232, lfa_elttype = 2104, lfa_self = 0x0, lfa_adj=
ustable = 0, 
> >     lfa_offset = 0, lfa_dim = 0, lfa_dims = 0x0}}
> > 	link_callbacks = {add_archive_element = 0x806e3d8 <madd_archive_el=
ement>, 
> >   multiple_definition = 0x806e3e2 <mmultiple_definition>, 
> >   multiple_common = 0x806e3ec <mmultiple_common>, add_to_set = 0x80=
6e3f6 <madd_to_set>, 
> >   constructor = 0x806e400 <mconstructor>, warning = 0x806e40a <mwar=
ning>, 
> >   undefined_symbol = 0x806e414 <mundefined_symbol>, 
> >   reloc_overflow = 0x806e434 <mreloc_overflow>, 
> >   reloc_dangerous = 0x806e454 <mreloc_dangerous>, 
> >   unattached_reloc = 0x806e474 <munattached_reloc>, notice = 0x806e=
47e <mnotice>}
> > 	link_order = {next = 0x0, type = bfd_indirect_link_order, offset=
 = 0, size = 0, 
> >   u = {indirect = {section = 0x83b3bb4}, data = {size = 13809=
9636, contents = 0x0}, 
> >     reloc = {p = 0x83b3bb4}}}
> > 	entry_name = "\000init_"
> > 	entry_name_ptr = 0xbfffdee1 "init_"
> > #7  0x080aa002 in Lload () at file.d:1842
> > 	old_bds_top = 0x8283dc8
> > 	i = 136194436
> > 	strm1 = 0x81e2980
> > 	narg = 1
> > 	DPPbase = (object *) 0x81e297c
> > #8  0x080a0d5e in eval (form=0x8369aa0) at eval.c:1090
> > 	temporary = 0x8369aa0
> > 	fun = 0x8387e34
> > 	x = 0x838a550
> > 	top = (object *) 0x81e2980
> > 	base = (object *) 0x81e297c
> > #9  0x080a1258 in fLeval (x0=0x8531c30) at eval.c:1178
> > 	lex = (object *) 0x81e2920
> > #10 0x080b32a1 in c_apply_n (fn=0x80a11fc <fLeval>, n=1, x=0x81e2=
968) at funlink.c:271
> > 	res = 0x8369aa0
> > #11 0x080504db in IapplyVector (fun=0x8384e24, nargs=1, base=0x81=
e2968)
> >     at nfunlink.c:229
> > 	res = 0xb7e1fff4
> > 	abase = (object *) 0x81e2968
> > 	i = 1
> > 	oldtop = (object *) 0x81e2968
> > 	atypes = 0
> > #12 0x0809ef38 in funcall (fun=0x8384e24) at eval.c:190
> > 	res = 0xbfffef38
> > 	b = (object *) 0x81e2964
> > 	n = 1
> > 	temporary = 0x4
> > 	x = 0x81e2964
> > 	top = (object * volatile) 0x8
> > 	lex = (object *) 0xbfffef38
> > 	old_bds_top = 0x837ef48
> > 	b = 137919404
> > 	c = 134636159
> > #13 0x0809fea1 in symlispcall (sym=0x83831f8, base=0x81e2964, narg=
=1) at eval.c:507
> > 	fun = 0x8384e24
> > #14 0x0815a9e7 in LI1 () at gcl_top.c:140
> > 	V6 = 0x8289240
> > 	base = (object * volatile) 0x81e293c
> > 	V4 = 0x8380f70
> > 	V2 = 0x8049b5c
> > 	V1 = 0x8369aa0
> > 	sup = (object * volatile) 0x81e2974
> > #15 0x0809e282 in quick_call_sfun (fun=0x84ddfa0) at eval.c:117
> > 	i = 0
> > 	n = 0
> > 	restype = f_object
> > 	x = (object *) 0x81e293c
> > 	res = 0xb7ffd508
> > 	base = (object *) 0x81e293c
> > 	temp_ar = (object *) 0xbfffefe0
> > #16 0x0809eeb2 in funcall (fun=0x84ddfa0) at eval.c:178
> > 	temporary = 0xb7ffa58a
> > 	x = 0xbffff0a0
> > 	top = (object * volatile) 0xb8000fd4
> > 	lex = (object *) 0x1000
> > 	old_bds_top = 0x837eed0
> > 	b = 137903596
> > 	c = 134951618
> > #17 0x08050604 in IapplyVector (fun=0x84ddfa0, nargs=0, base=0x81=
e293c)
> >     at nfunlink.c:239
> > 	res = 0x0
> > 	abase = (object *) 0x0
> > 	i = -1073746032
> > 	oldtop = (object *) 0x81e293c
> > 	atypes = 0
> > #18 0x080a0fd6 in fLfuncall (fun=0x84ddfa0) at eval.c:1140
> > 	Xxvl = {0xea343, 0xbffff694, 0xbffff620, 0xbffff198, 0xbfffef70, 0x8=
0b26cf, 
> >   0x0, 0xb7fe95a2, 0xb7fe91ec, 0xb7fe9000, 0xbffff190, 0xbffff190, 0xb8=
0011c0, 0x2, 
> >   0xb8000fd4, 0xffffffe8, 0x4, 0x0, 0xb7ced240, 0xb80014e0, 0x7, 0xb800=
0ff0, 
> >   0xb7fe940c, 0xb7fe95a2, 0xb7fe91ec, 0xb7fe9000, 0x8049f2c, 0x0, 0xb80=
011c0, 0x2, 
> >   0xb80011c0, 0x0, 0xbffff180, 0x837eed0, 0xbffff2b8, 0x8050877, 0x808e=
b2b, 0x2, 
> >   0xbffff1a0, 0xbffff190, 0x1, 0x0, 0x0, 0xbffff1a8, 0x837eed0, 0x81e29=
3c, 0xbffff2a8, 
> >   0x80b32c2, 0x8387bac, 0x853bb10, 0x8, 0x81e2900, 0xbffff694, 0xbffff6=
20, 0xbffff2e8, 
> >   0xb7ff6c13, 0x8049877, 0xb7fb3a0c, 0xb8000fd4, 0xb7fb3e30, 0x0, 0xbff=
ff228, 
> >   0xb7ff1c31, 0xb7cfeb14, 0x8049ca7}
> > 	ap = 0xbffff218 "h\233\004\b=D4\017"
> > 	new = (object *) 0xbffff0e0
> > 	n = 1
> > #19 0x080b32a1 in c_apply_n (fn=0x80a0f44 <fLfuncall>, n=1, x=0x8=
1e2938)
> >     at funlink.c:271
> > 	res = 0x8369aa0
> > #20 0x080504db in IapplyVector (fun=0x8384e4c, nargs=1, base=0x81=
e2938)
> >     at nfunlink.c:229
> > 	res = 0x1
> > 	abase = (object *) 0x81e2938
> > 	i = -1073744984
> > 	oldtop = (object *) 0x81e2938
> > 	atypes = 0
> > #21 0x0809ef38 in funcall (fun=0x8384e4c) at eval.c:190
> > 	res = 0x81e2958
> > 	b = (object *) 0x81e2934
> > 	n = 1
> > 	temporary = 0x81e2900
> > 	x = 0x2
> > 	top = (object * volatile) 0x805440f
> > 	lex = (object *) 0xbffff3d8
> > 	old_bds_top = 0x81e2900
> > 	b = 137891696
> > 	c = 0
> > #22 0x0809f844 in funcall_no_event (fun=0x8384e4c) at eval.c:381
> > No locals.
> > #23 0x080a0d6b in eval (form=0x8369aa0) at eval.c:1092
> > 	temporary = 0x81e2900
> > 	fun = 0x8383240
> > 	x = 0x8384e4c
> > 	top = (object *) 0x81e2938
> > 	base = (object *) 0x81e2934
> > #24 0x0809f5b6 in funcall (fun=0x852efe0) at eval.c:327
> > 	not_pushed = 1
> > 	temporary = 0x85e0f30
> > 	x = 0x84f2de0
> > 	top = (object * volatile) 0x81e2930
> > 	lex = (object *) 0x81e290c
> > 	old_bds_top = 0x8283d78
> > 	b = 1
> > 	c = 0
> > #25 0x0809f844 in funcall_no_event (fun=0x85e0d14) at eval.c:381
> > No locals.
> > #26 0x080a0d6b in eval (form=0x8369aa0) at eval.c:1092
> > 	temporary = 0xb80014e0
> > 	fun = 0x84ea9b4
> > 	x = 0x85e0d14
> > 	top = (object *) 0x81e2920
> > 	base = (object *) 0x81e2920
> > #27 0x0809f5b6 in funcall (fun=0x852eff0) at eval.c:327
> > 	not_pushed = 0
> > 	temporary = 0x85e0f84
> > 	x = 0x84f2d14
> > 	top = (object * volatile) 0x81e291c
> > 	lex = (object *) 0x81e2900
> > 	old_bds_top = 0x8283d78
> > 	b = 1
> > 	c = 0
> > #28 0x080a058a in super_funcall (fun=0x85e0ff0) at eval.c:743
> > No locals.
> > #29 0x0804b6c8 in main (argc=1, argv=0xbffff694, envp=0xbffff69c)=
 at main.c:369
> > 	rl = {rlim_cur = 4294967295, rlim_max = 4294967295}
> > (gdb) quit

\start
Date: Wed, 24 Nov 2004 14:22:25 -0500
From: Bill Page
To: Tim Daly
Subject: RE: [Axiom-mail] arch server support
Cc: Gilbert Baumslag

Tim,

This looks great! I hope it will result in making a lot more
Axiom development and testing help available.

> ...
> For those who want to get the lastest set of mistakes you
> can visit http://axiom.axiom-developer.org and look at the
> [ Developers ] link.
> ...

One thing I noticed however is that near the end of this web
page you wrote:
  "More information on arch is available _here_"
where the url is http://rubick.com:8002/openacs/arch

Unfortunately this url uses a non-standard port 8002 which
is not likely to be available to most people working behind
a firewall. Of course there is a lot of useful stuff available
about arch just by doing a goggle search for "gnu-arch", but
I would suggest that you include at least the following
"official" url on your developer page:

  http://www.gnu.org/software/gnu-arch

which includes some useful links.

\start
Date: Wed, 24 Nov 2004 15:18:47 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel] changes in binutils break gcl
Cc: Matthew Kenendy

Camm,

As far as I can see they are the same patch.
What has changed?

Note that I applied the patch and now the saved image will not execute:


make[3]: *** [/tmp/axiom/obj/linux/bin/bootsys] Error 134
make[3]: Leaving directory `/tmp/axiom/src/boot'
make[2]: *** [bootdir] Error 2
make[2]: Leaving directory `/tmp/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/tmp/axiom'
make: *** [all] Error 2

\start
Date: Wed, 24 Nov 2004 14:33:45 -0500
From: Bill Page
To: Tim Daly
Subject: axiom--hyperdoc--1 branch and Axiom graphics

Tim,

Can you give me a quick (one line) status of the hyperdoc branch?
Does it build? Is there any specific (small?) issue that might
benefit from the attention of someone else (such as me)?

BTW, so far I have successfully built the axiom--main--1 branch
which includes the Axiom graphics on two RedHat systems - one an
upgraded but older RedHat 7 system and the other an up to date
RedHat 9 system. The graphics look great and I think we need to
get this into the Savannah archive asap. It seems to me that good
graphics makes a big difference in the "first impressions" people
have about computer algebra systems. I also plan to get this
into MathAction real soon.

\start
Date: Wed, 24 Nov 2004 20:38:30 +0100
From: =?ISO-8859-1?Q?G=E9rard?= Milmeister <Gerard Milmeister>
To: Camm Maguire
Subject: Re: [Gerard Milmeister: Axiom on FC3]

On Mon, 2004-11-22 at 10:46 -0500, Camm Maguire wrote:
> Greetings!
> 
> Tim Daly writes:
> 
> > Camm,
> > 
> > Have you tried FC3 builds yet? I know GCL runs on FC1 and FC2 but
> > I don't yet have a machine running FC3.
> > 
> 
> My suggestion is to configure with --disable-statsysbfd
> --enable-locbfd for now, and see if this fixes things.  If so, we can
> chase down any potentially new bfd problems thereafter. 

Can you let me know, when there is a snapshot in CVS that will work with
FC3?

A question: I have SBCL running well on FC3. Is it possible to switch? I
had some bad experience with GCL in the past.

\start
Date: Wed, 24 Nov 2004 15:30:00 -0500
From: Tim Daly
To: Bill Page
Subject: Re: [Axiom-mail] arch server support
Cc: Gilbert Baumslag

Bill,

> I would suggest that you include at least the following
> "official" url on your developer page:
> 
>   http://www.gnu.org/software/gnu-arch

Done. 

\start
Date: Wed, 24 Nov 2004 15:37:23 -0500
From: Tim Daly
To: Bill Page
Subject: Re: axiom--hyperdoc--1 branch 
Cc: Gilbert Baumslag

Bill,

re: the hyperdoc branch

The axiom--hyperdoc--1 branch includes modifications to pamphlet format
and compiles cleanly. The compiled files are not yet linked into the
proper executables, one of which is hyperdoc itself. I need to 

(a) add the linking stanzas and executable targets to the makefile
(b) upload and include the actual pages used by hyperdoc
(c) make the pages appear in the proper places in the mnt tree
(d) test hyperdoc under sman

Once these tasks are complete hyperdoc should run so it's nearly there.

Hyperdoc is programmable in an early form of html and we need to look
at developing it further, possibly into subject areas like linear
algebra.

\start
Date: 24 Nov 2004 15:00:52 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: [Gcl-devel] changes in binutils break gcl
Cc: Matthew Kenendy

Greetings!

The change was that three files are to be patched 

(o/sfaslbfd.c,binuntils/bfd/bfd-in.h,binutils/bfd/bfd-in2.h)

instead of just one (o/sfaslbfd.c).

Am including the patch here again.  If you left out the bfd*h patches,
gcl would not build with --enable-locbfd.  With the whole patch, gcl
should build against the local bfd, current Debian unstable bfd, and
the newer Suse/Mandrake/Fedora bfd.

Please keep me posted.

=============================================================================
=============================================================================
Index: o/sfaslbfd.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/sfaslbfd.c,v
retrieving revision 1.18
diff -u -r1.18 sfaslbfd.c
--- o/sfaslbfd.c	23 Aug 2004 23:09:23 -0000	1.18
+++ o/sfaslbfd.c	24 Nov 2004 16:00:09 -0000
@@ -256,7 +256,7 @@
 
     current=round_up(current,1<<s->alignment_power);
 
-    current+=s->_raw_size;
+    current+=bfd_section_size(b,s);
 
   }
   curr_size=(unsigned long)current;
@@ -281,7 +281,7 @@
 
     m=round_up(m,1<<s->alignment_power);
     s->output_section->vma=(unsigned long)m;
-    m+=s->_raw_size;
+    m+=bfd_section_size(b,s);
 	     
   }
 
@@ -346,7 +346,7 @@
 					     v,0,q)) 
        FEerror("Cannot get relocated section contents\n",0);
 
-     memcpy((void *)(unsigned long)s->output_section->vma,v,s->_raw_size);
+     memcpy((void *)(unsigned long)s->output_section->vma,v,bfd_section_size(b,s));
      
    }
  }
Index: binutils/bfd/bfd-in.h
===================================================================
RCS file: /cvsroot/gcl/gcl/binutils/bfd/bfd-in.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 bfd-in.h
--- binutils/bfd/bfd-in.h	9 Aug 2002 05:34:46 -0000	1.1.1.1
+++ binutils/bfd/bfd-in.h	24 Nov 2004 18:45:08 -0000
@@ -337,7 +337,8 @@
 #define bfd_get_section_lma(bfd, ptr) ((ptr)->lma + 0)
 #define bfd_get_section_alignment(bfd, ptr) ((ptr)->alignment_power + 0)
 #define bfd_section_name(bfd, ptr) ((ptr)->name)
-#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))
+#define bfd_section_size(bfd, ptr) ((ptr)->_raw_size)
+/* #define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr)) */
 #define bfd_section_vma(bfd, ptr) ((ptr)->vma)
 #define bfd_section_lma(bfd, ptr) ((ptr)->lma)
 #define bfd_section_alignment(bfd, ptr) ((ptr)->alignment_power)
Index: binutils/bfd/bfd-in2.h
===================================================================
RCS file: /cvsroot/gcl/gcl/binutils/bfd/bfd-in2.h,v
retrieving revision 1.3
diff -u -r1.3 bfd-in2.h
--- binutils/bfd/bfd-in2.h	22 Feb 2004 11:05:18 -0000	1.3
+++ binutils/bfd/bfd-in2.h	24 Nov 2004 18:45:08 -0000
@@ -342,7 +342,8 @@
 #define bfd_get_section_lma(bfd, ptr) ((ptr)->lma + 0)
 #define bfd_get_section_alignment(bfd, ptr) ((ptr)->alignment_power + 0)
 #define bfd_section_name(bfd, ptr) ((ptr)->name)
-#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))
+#define bfd_section_size(bfd, ptr) ((ptr)->_raw_size)
+/*#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))*/
 #define bfd_section_vma(bfd, ptr) ((ptr)->vma)
 #define bfd_section_lma(bfd, ptr) ((ptr)->lma)
 #define bfd_section_alignment(bfd, ptr) ((ptr)->alignment_power)
=============================================================================
=============================================================================
Tim Daly writes:

> Camm,
> 
> As far as I can see they are the same patch.
> What has changed?
> 
> Note that I applied the patch and now the saved image will not execute:
> 
> 
> make[3]: *** [/tmp/axiom/obj/linux/bin/bootsys] Error 134
> make[3]: Leaving directory `/tmp/axiom/src/boot'
> make[2]: *** [bootdir] Error 2
> make[2]: Leaving directory `/tmp/axiom/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/tmp/axiom'
> make: *** [all] Error 2

\start
Date: Wed, 24 Nov 2004 15:48:39 -0500
From: Tim Daly
To: Bill Page
Subject: Re: axiom--main--1 
Cc: Gilbert Baumslag

Bill,

re: the main branch

The axiom--main--1 branch needs a minor change to the axiom script
to make it start sman rather than AXIOMsys. There are a bunch of
options to sman which I need to document (in the sman.pamphlet).
Once the 'axiom' script calls sman rather than AXIOMsys the graphics
is always available.

I've attached the original form of the axiom command which we are
incrementally approaching. The current axiom command needs to pick
up the parts that handle the graphics options.

We also have to go into the input/Makefile.pamphlet and enable the
test cases which use graphics. These test cases should work but they
need testing. I believe most of them are under the 'SKIP' list
(around line 6420) in the Makefile.pamphlet

I also have been working with the CRC Handbook of Curves and Surfaces
making new test cases by drawing the graphs shown there. Axiom can draw
up to 9 graphs on the same image. I can reproduce some of the examples
but more needs to be done. It is basically tedious testing. I've found
one bug and I'll post it when I get a chance.

t

=================================================================

#!/bin/sh

# Start everything for AXIOM.
#
# axiom
#      [-ht   |-noht]	    whether to use HyperDoc
#      [-gr   |-nogr]	    whether to use Graphics
#      [-clef |-noclef]	    whether to use Clef
#      [-nag |-nonag]	    whether to use NAG
#      [-iw   |-noiw]	    start in interpreter window
#      [-ihere|-noihere]    start an interpreter buffer in the original window
#      [-nox]		    don't use X Windows
#      [-go  |-nogo]	    whether to start system
#      [-ws wsname]	    use named workspace
#      [-list]		    list workspaces only
#      [-grprog fname]	    use named program for Graphics
#      [-nagprog fname]	    use named program for Nag
#      [-htprog fname]	    use named program for HyperDoc
#      [-clefprog fname]    use named program for Clef
#      [-sessionprog fname] use named program for session
#      [-clientprog fname]  use named program for spadclient
#      [-h]		    show usage
#
#

MALLOCTYPE=3.1
export MALLOCTYPE

# 0. Basic utilities

ciao() {
	echo "Goodbye."
	exit 1
}

needsubopt () {
	echo "The $1 option requires an argument."
	ciao
}

colonjoin() {
	if [ "$1" = "" ] ; then
		echo "$2"
	elif [ "$2" = "" ] ; then
		echo "$1"
	else
		echo "$1:$2"
	fi
}

showuse() {
echo "axiom"
echo "     [-ht   |-noht]       whether to use HyperDoc"
echo "     [-gr   |-nogr]       whether to use Graphics"
echo "     [-clef |-noclef]     whether to use Clef"
echo "     [-nag |-nonag]       whether to use NAG"
echo "     [-iw   |-noiw]       start in interpreter window"
echo "     [-ihere|-noihere]    start an interpreter buffer in the original window."
echo "     [-nox]               don't use X Windows"
echo "     [-go  |-nogo]        whether to start system"
echo "     [-ws wsname]         use named workspace"
echo "     [-list]              list workspaces only"
#echo "     [-grprog fname]      use named program for Graphics"
#echo "     [-nagprog fname]      use named program for Nag"
#echo "     [-htprog fname]      use named program for HyperDoc"
#echo "     [-clefprog fname]    use named program for Clef"
#echo "     [-sessionprog fname] use named program for session"
#echo "     [-clientprog fname]  use named program for spadclient"
echo "     [-h]                 show usage"
}

# 1. Ensure the environment is set.

# Just process '-h'

if [ "$*" = "-h" ] ; then
     showuse
fi
SPADDEFAULT=/users/axiom/development/mnt/linuxglibc2.1

if [ "$AXIOM" = "" ] ; then
    echo "Your AXIOM shell variable is not set"
    echo "Trying to use the default of $SPADDEFAULT"
    AXIOM=$SPADDEFAULT
    export AXIOM
fi

if [ ! -d "$AXIOM" ] ; then
  echo "The directory for AXIOM, $AXIOM, does not exist."
  ciao
fi

SPAD=$AXIOM
export SPAD
ASHARPROOT=$AXIOM/asharp
export ASHARPROOT
PATH=$ASHARPROOT/bin:$PATH
export PATH


# Name the workspace directories.
rootwsdir=$AXIOM/bin
PATH=$rootwsdir:$PATH
export PATH

# 2. Process command line arguments.

# Defaults for command-line arguments.
# (Default workspace is depends on presence of -comp.)
list=no
comp=no
go=yes
wsname=AXIOMsys

asserts=""
incldirs=""
libdirs=""
compfiles=""
otheropts=""

while [ "$*" != "" ] ; do

	case $1 in
	-go)	go=yes ;;
	-nogo)	go=no ;;

	-ws)
		if [ "$2" = "" ] ; then needsubopt "$1" ; fi
		shift
		wsname="$1"
		;;

	-nagprog|-grprog|-htprog|-clefprog|-sessionprog|-clientprog|-paste)
		if [ "$2" = "" ] ; then needsubopt "$1" ; fi
		otheropts="$otheropts $1 $2"
		shift
		;;
	-clef|-noclef|-gr|-nogr|-ht|-noht|-iw|-noiw|-ihere|-noihere|-nox|-nag|-nonag)
		otheropts="$otheropts $1"
		;;

	-h)
		go=no
		;;
	-comp)	otheropts="$otheropts -nox"
		wsname=comp
		comp=yes
		;;

	-[AIL])
		if [ $comp = no ] ; then
			echo "The option $1 may only be given after -comp."
			ciao
		fi

		if [ "$2" = "" ] ; then needsubopt "$1" ; fi

		case $1 in
		-A) asserts=`colonjoin "$asserts" "$2"` ;;
		-L) libdirs=`colonjoin "$libdirs" "$2"` ;;
		-I) incldirs=`colonjoin "$incldirs" "$2"` ;;
		esac

		shift
		;;

	*.*)
		if [ $comp = no ] ; then
			echo "File names ($1) may only be given after -comp."
			ciao
		fi
		compfiles=`colonjoin "$compfiles" "$1"`
		;;

	*)	echo "Unknown option: $1"
		echo "To use a specific workspace use, e.g.: AXIOM -ws $1"
		ciao
		;;
	esac

	shift
done

# 5. Try to ensure a suitable workspace on this host.

if [ `expr $wsname : '.*/.*'` = 0 ] ; then
	serverws=$rootwsdir/$wsname
else
	serverws=$wsname
fi

if [ ! -f $serverws ] ; then
	echo "Cannot proceed without local workspace $localws."
	ciao
fi

# 6. Start processes

if [ $go = no ] ; then
	echo "Would now start the processes."
	exit 0
fi

echo "Starting the AXIOM Computer Algebra System (NAG Development Version)"
echo "Linux (glibc2.1) for Intel"
exec $AXIOM/lib/sman $otheropts -ws $serverws

\start
Date: 24 Nov 2004 15:07:29 -0500
From: Camm Maguire
To: =?iso-8859-1?q?G=E9rard?= Milmeister <Gerard Milmeister>
Subject: Re: [Gerard Milmeister: Axiom on FC3]

Greetings!

G=E9rard Milmeister <Gerard Milmeister> writes:

> On Mon, 2004-11-22 at 10:46 -0500, Camm Maguire wrote:
> > Greetings!
> > 
> > Tim Daly writes:
> > 
> > > Camm,
> > > 
> > > Have you tried FC3 builds yet? I know GCL runs on FC1 and FC2 but
> > > I don't yet have a machine running FC3.
> > > 
> > 
> > My suggestion is to configure with --disable-statsysbfd
> > --enable-locbfd for now, and see if this fixes things.  If so, we can
> > chase down any potentially new bfd problems thereafter. 
> 
> Can you let me know, when there is a snapshot in CVS that will work with
> FC3?
> 
> A question: I have SBCL running well on FC3. Is it possible to switch? I
> had some bad experience with GCL in the past.
> 

You should be ready to go right now under FC3 with two options:

1) source as is, configure with --disable-statsysbfd --enable-locbfd

or

2) Apply the patch below, then use any bfd you want.

Please let me know if this does not work for you.

Take care,

==========================
==========================
==========================
==
==========================
==========================
==========================
==
Index: o/sfaslbfd.c
==========================
==========================
=================
RCS file: /cvsroot/gcl/gcl/o/sfaslbfd.c,v
retrieving revision 1.18
diff -u -r1.18 sfaslbfd.c
--- o/sfaslbfd.c	23 Aug 2004 23:09:23 -0000	1.18
+++ o/sfaslbfd.c	24 Nov 2004 16:00:09 -0000
@@ -256,7 +256,7 @@
 
     current=round_up(current,1<<s->alignment_power);
 
-    current+=s->_raw_size;
+    current+=bfd_section_size(b,s);
 
   }
   curr_size=(unsigned long)current;
@@ -281,7 +281,7 @@
 
     m=round_up(m,1<<s->alignment_power);
     s->output_section->vma=(unsigned long)m;
-    m+=s->_raw_size;
+    m+=bfd_section_size(b,s);
 =09     
   }
 
@@ -346,7 +346,7 @@
 					     v,0,q)) 
        FEerror("Cannot get relocated section contents\n",0);
 
-     memcpy((void *)(unsigned long)s->output_section->vma,v,s->_raw_size);
+     memcpy((void *)(unsigned long)s->output_section->vma,v,bfd_section_si=
ze(b,s));
      
    }
  }
Index: binutils/bfd/bfd-in.h
==========================
==========================
=================
RCS file: /cvsroot/gcl/gcl/binutils/bfd/bfd-in.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 bfd-in.h
--- binutils/bfd/bfd-in.h	9 Aug 2002 05:34:46 -0000	1.1.1.1
+++ binutils/bfd/bfd-in.h	24 Nov 2004 18:45:08 -0000
@@ -337,7 +337,8 @@
 #define bfd_get_section_lma(bfd, ptr) ((ptr)->lma + 0)
 #define bfd_get_section_alignment(bfd, ptr) ((ptr)->alignment_power + 0)
 #define bfd_section_name(bfd, ptr) ((ptr)->name)
-#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))
+#define bfd_section_size(bfd, ptr) ((ptr)->_raw_size)
+/* #define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(p=
tr)) */
 #define bfd_section_vma(bfd, ptr) ((ptr)->vma)
 #define bfd_section_lma(bfd, ptr) ((ptr)->lma)
 #define bfd_section_alignment(bfd, ptr) ((ptr)->alignment_power)
Index: binutils/bfd/bfd-in2.h
==========================
==========================
=================
RCS file: /cvsroot/gcl/gcl/binutils/bfd/bfd-in2.h,v
retrieving revision 1.3
diff -u -r1.3 bfd-in2.h
--- binutils/bfd/bfd-in2.h	22 Feb 2004 11:05:18 -0000	1.3
+++ binutils/bfd/bfd-in2.h	24 Nov 2004 18:45:08 -0000
@@ -342,7 +342,8 @@
 #define bfd_get_section_lma(bfd, ptr) ((ptr)->lma + 0)
 #define bfd_get_section_alignment(bfd, ptr) ((ptr)->alignment_power + 0)
 #define bfd_section_name(bfd, ptr) ((ptr)->name)
-#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))
+#define bfd_section_size(bfd, ptr) ((ptr)->_raw_size)
+/*#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(pt=
r))*/
 #define bfd_section_vma(bfd, ptr) ((ptr)->vma)
 #define bfd_section_lma(bfd, ptr) ((ptr)->lma)
 #define bfd_section_alignment(bfd, ptr) ((ptr)->alignment_power)
==========================
==========================
==========================
==
==========================
==========================
==========================
==

\start
Date: Wed, 24 Nov 2004 15:50:35 -0500
From: Tim Daly
To: Gerard Milmeister
Subject: Re: [Gerard Milmeister: Axiom on FC3]
Cc: Camm Maguire, Gilbert Baumslag

Gemi,

The axiom build fails with FC3. I have a person who has an FC3 system
installed and he is going to send me a console log next time he tries
to build it.

If you have FC3, start emacs, start a shell buffer, and do a 
  
  make clean
  make

and send me the buffer so I can see why it fails. I don't have FC3
running here.

\start
Date: Wed, 24 Nov 2004 15:55:51 -0500
From: Tim Daly
To: Gerard Milmeister
Subject: Re: [Gerard Milmeister: Axiom on FC3]
Cc: Camm Maguire, Gilbert Baumslag

Gemi,

SBCL is more involved. In order to build Axiom the lisp has to support
some socket code. Older common lisps did not support sockets although
I believe all of the latest versions do.

So in order to make Axiom work on SBCL there are severals steps but
the very first is to take one of two paths (the first is preferred but
the second is ok)

 1) figure out how to do the socket code in common lisp in a portable
    way using #+ and #- for the different versions
 2) figure out how to link axiom's socket code into SBCL at build time

There are other problems. For instances, the makefiles need to use lisp
commands to build and save images. GCL has a save-system command. I 
don't know the equivalent command in SBCL so I don't know how to 
rewrite the save-system. 

It's technically possible to do. Axiom ran on about a dozen lisps, some
of them were not common lisp (e.g. vmlisp, maclisp, zetalisp) so most
of the axiom system is agnostic about the underlying lisp. The only
real issues are time and persistance.

If you're really interested we can start an SBCL branch and look at
the issues.

\start
Date: Wed, 24 Nov 2004 15:58:34 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: [Gcl-devel] changes in binutils break gcl
Cc: Matthew Kenendy

right. 3 files. some day i'll learn to read.

ok. i'm patching this now and i'll let you know how the build goes.

\start
Date: Wed, 24 Nov 2004 23:24:41 -0500
From: Tim Daly
To: William Sit
Subject: Re: help

William,

>I had Axiom installed for FC2. Now I like to add the graphics. How should I go
>about it?
>
>I also tried the arch site, but there the first thing I am supposed to do is to
>do a tla. What is tla? It does not seem to be in my FC2 system. Where can I
>download it and install it?


Graphics is already part of the build. In order to run the graphics
from inside Axiom you need to run the sman (superman) process. The sman
process starts the axiom process. When you execute a draw function in
Axiom it causes sman to start a graphics window. 

So you need to start the sman process.

Instead of typing
 axiom

type 
 sman 

you'll get a bunch of warning message which should be ignored and
then an axiom command shell should start. By default it should
start in the terminal window you're in but you could start it in
another window by typing:

 sman -iw

In any case, once you have the axiom command prompt try:

draw(sin(x),x=-10..10)
draw(sin(x*y),x=-10..10,y=-10..10)

In the near future I'll modify the standard axiom command so
it starts sman but there are still a few cleanup issues to be
worked out.

\start
Date: Thu, 25 Nov 2004 01:24:37 -0500
From: Tim Daly
To: Camm Maguire
Subject: latest patches

Camm,

I applied the patches you sent and the system build fails:

=============================================================
make[3]: *** [/tmp/axiom/obj/linux/bin/bootsys] Error 134
make[3]: Leaving directory `/tmp/axiom/src/boot'
make[2]: *** [bootdir] Error 2
make[2]: Leaving directory `/tmp/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/tmp/axiom'
make: *** [all] Error 2
=============================================================

at this point we've build a lisp image, used it to compile a
bunch of lisp files, then exited the image. We've saved the
image as "bootsys".

The bootsys image won't start.

\start
Date: Thu, 25 Nov 2004 05:51:53 -0500
From: Bill Page
To: Tim Daly
Subject: bug reporting

Tim,

On Sunday, November 21, 2004 11:11 PM you wrote:

> ... 
> At the moment bug reporting is a separate function from
> source code management. But I'd like to be able to track
> bugs and relate them to changesets. Arch currently has no
> way to do this but I've been if we couldn't use the Arch
> system to maintain a bugs/features directory. That is, you
> check in, update, and close bugs using the same tools as
> the rest of the code. So when you have a changeset that
> fixes a bug you can update the bug subdirectory as part
> of the changeset.
> 
> Comments?
> 

As an experiment I have just enabled the online Issue Tracker
system on MathAction. IssueTracker is built-in to the wiki
software (ZWiki) on which MathAction is based. This a simple
and easy to use system. It is not integrated with arch but in
principle it is quite easily modifiable and so we might be able
to do some of the things that you describe above more auto-
magically.

Please take a look at the page:

http://page.axiom-developer.org/zope/mathaction/FrontPage/issuetracker

or you can just go to the MathAction frontpage

http://page.axiom-developer.org/zope/mathaction

and click on "Issues" on the top menu line or the link
"Report Bugs here".

Try it and see how you like it. Some things are very
simple to configure so let me know if you have suggestions.

\start
Date: Thu, 25 Nov 2004 14:29:13 +0100
From: Martin Rubey
To: Camm Maguire
Subject: Re: proposal to create the Axiom Foundation (was: bounties etc.)
Cc: Bob McElrath, Bill Page

Hi all,

Bill: great!

Concerning Camm's thoughts:

I think that we cannot oblige anybody to maintain the work he submitted=
 in
order to gain a bounty. This would be a heavy burden on the submitter a=
nd on
the committee as well. Thus I'd propose that a submission is accepted o=
n an "as
is" basis, and it should be very clear whether a submission fulfils the=

requirements or not. I think a good example would be a MS Windows port =
of
axiom: The requirements would be (roughly)

* that axiom can be compiled according to step by step instructions

* passes "most" of the tests -- there might be some platform specific p=
roblems,
  of course, like pathnames and the like

* and the changes are documented.

Similarly, a bounty could be awarded for an SBCL port, when axiom compi=
les.

Special awards could be granted for especially good work.

In fact, I think there are quite a few tasks where a running thing woul=
d
already be great: pamphlet support on MathAction, a Windows port, an SB=
CL or
CMUCL port, compiling domains with Aldor, ... this list is *very* subje=
ctive,
of course.

I think we should advertise the bounties especially at universities in =
poorer
countries, a bounty of 100$ might be quite an award for some people!

It would be necessary to have a non-world-editable page where the bount=
ies are
advertised. The individual items from the Todo and WishList should link=
 to this
page.

Since Bill did already set up the infrastructure, here my proposals:

Windows port                     50$
pamphlet support for MathAction  50$
CMUCL/SBCL port                 100$
Aldor                           200$

Note that I really have *no* idea how much work these items represent. =
I'm
pretty sure that theire value is far beyond 200$. These prices might se=
rve as
starting values, however.

Sidenote: Many great mathematicians set out prices for proofs of conjec=
tures
they had. Best known are probably the prices of Paul Erd=F6s. These pri=
ces ranged
from 10$ (difficult problem) to (I think) 500$ (only for genius)...

In this spirit, we might set up a second row of bounties, like:

implementing Zeilberger 5$
fixing bug http://savannah.nongnu.org/bugs/?func=detailitem&item_id==
10530 5$

and so on.

BTW: How much money can we spend?

\start
Date: Thu, 25 Nov 2004 17:14:07 +0100
From: Martin Rubey
To: list
Subject: Re: proposal to create the Axiom Foundation (was: bounties etc.)
Cc: Camm Maguire, Bob McElrath, Bill Page, Tim Daly

Another issue: We need to make sure that we fund only projects somebody works
on anyway. 

Bill: is it possible to have a wiki page only members of the "foundation" can
edit, but anybody can comment on?

Martin

PS: It seems that we have already at least 100$ to spend!

\start
Date: Thu, 25 Nov 2004 12:09:12 -0500
From: Kostas Oikonomou
To: list
Subject: Building Axiom 11/15/2004 on Solaris 9 Sparc

Hello,

I am trying to compile the Axiom sources dated 11/15/2004 on a Sun Solari=
s 9 system.
The build ends with lisp dumping core:

-------------------------------------------------------------------------=
-------------------------
Loading /home/build/axiom/int/boot/npextras.lisp
Finished loading /home/build/axiom/int/boot/npextras.lisp
Compiling tytree1.lisp.
; (DEFUN |bfMDef| ...) is being compiled.
;; Warning: The variable |defOp| is not used.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=
=3
Finished compiling /home/build/axiom/obj/solaris/boot/tytree1.o.
618a making /home/build/axiom/mnt/solaris/doc/src/boot/axiom.sty from /ho=
me/build/axiom/src/doc/axiom.sty.pamphlet
3 making /home/build/axiom/mnt/solaris/doc/src/boot/boothdr.lisp.dvi from=
 /home/build/axiom/src/boot/boothdr.lisp.pamphlet
6 making /home/build/axiom/mnt/solaris/doc/src/boot/btincl2.lisp.dvi from=
 /home/build/axiom/src/boot/btincl2.boot.pamphlet
10 making /home/build/axiom/mnt/solaris/doc/src/boot/btpile2.boot.dvi fro=
m /home/build/axiom/src/boot/btpile2.boot.pamphlet
14 making /home/build/axiom/mnt/solaris/doc/src/boot/btscan2.boot.dvi fro=
m /home/build/axiom/src/boot/btscan2.boot.pamphlet
18 making /home/build/axiom/mnt/solaris/doc/src/boot/exports.lisp.dvi fro=
m /home/build/axiom/src/boot/exports.lisp.pamphlet
21 making /home/build/axiom/mnt/solaris/doc/src/boot/npextras.lisp.dvi fr=
om /home/build/axiom/src/boot/npextras.lisp.pamphlet
24 making /home/build/axiom/mnt/solaris/doc/src/boot/ptyout.boot.dvi from=
 /home/build/axiom/src/boot/ptyout.boot.pamphlet
28 making /home/build/axiom/mnt/solaris/doc/src/boot/tyextra.boot.dvi fro=
m /home/build/axiom/src/boot/tyextra.boot.pamphlet
32 making /home/build/axiom/mnt/solaris/doc/src/boot/typars.boot.dvi from=
 /home/build/axiom/src/boot/typars.boot.pamphlet
36 making /home/build/axiom/mnt/solaris/doc/src/boot/typrops.boot.dvi fro=
m /home/build/axiom/src/boot/typrops.boot.pamphlet
40 making /home/build/axiom/mnt/solaris/doc/src/boot/tytree1.boot.dvi fro=
m /home/build/axiom/src/boot/tytree1.boot.pamphlet
44 invoking make in /home/build/axiom/src/boot with parms:
SYS= solaris
LSP= /home/build/axiom/lsp
PART= cprogs
SPAD= /home/build/axiom/mnt/solaris
SRC= /home/build/axiom/src
INT= /home/build/axiom/int
OBJ= /home/build/axiom/obj
MNT= /home/build/axiom/mnt
Illegal Instruction - core dumped
make[3]: *** [/home/build/axiom/obj/solaris/bin/bootsys] Error 132
make[3]: Leaving directory `/home/build/axiom/src/boot'
make[2]: *** [bootdir] Error 2
make[2]: Leaving directory `/home/build/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/build/axiom'
make: *** [
bash-2.05$
bash-2.05$ cd ../../obj/solaris/bin
bash-2.05$ gdb -c core
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you =
are
welcome to change it and/or distribute copies of it under certain conditi=
ons.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for detail=
s.
This GDB was configured as "sparc-sun-solaris2.8".
Core was generated by `/home/build/axiom/obj/solaris/bin/lisp'.
Program terminated with signal 4, Illegal instruction.
#0  0x007affd0 in ?? ()
(gdb) q
bash-2.05$

-------------------------------------------------------------------------=
-------------------------

I would appreciate any advice on how to deal with the problem.

Here is a detailed file showing what I had to do to build Axiom.  Note th=
at I had to
tweak GCL a bit, as mentioned at the end of the file.

Thanks very much for your help.

					Kostas





Sources of November 15, 2004
==========================
===

Preliminaries:

export AXIOM=/home/build/axiom/mnt/solaris
export PATH=$AXIOM/bin:$PATH

Edit Makefile:
      tar -> gtar

make noweb

Edit the shell script "mnt/solaris/bin/document" to set

weave="$AXIOM/bin/lib/noweave -delay -x"


-------------------------------------------------------------------

1. Edit Makefile.pamphlet to add [11pt] and

\usepackage[hypertex,colorlinks=true,linkcolor=blue,filecolor=webgr=
een,extension=dvi]{hyperref}

to get hyperlinks.

2. Study Makefile.dvi, edit Makefile.pamphlet:

(a) Check the GCL version of GCL:

GCLVERSION=gcl-2.6.5

Then rm lsp/Makefile

NOTE: Axiom contains its own distribution of GCL!

(b)
<<environment>>=
SPD=$(shell pwd)
SYS=$(notdir $(AXIOM))
SPAD=${SPD}/mnt/${SYS}
LSP=${SPD}/lsp
<<GCLVERSION>>
AWK=gawk
GCLDIR=${LSP}/${GCLVERSION}
SRC=${SPD}/src
INT=${SPD}/int
OBJ=${SPD}/obj
MNT=${SPD}/mnt
ZIPS=${SPD}/zips
TMP=${OBJ}/tmp
SPADBIN=${MNT}/${SYS}/bin
INC=${SPD}/src/include
CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
INSTALL=/opt/axiom
COMMAND=/opt/axiom/bin/axiom
TANGLE=${SPADBIN}/lib/notangle

(c) Add a <<Makefile.solaris>> chunk in section 2.  Should have really be=
en
     "solaris9g".

(d) Edit lsp/Makefile.pamphlet and globaly change @tar to @$(TAR).


2. Building the GCL within Axiom (or outside of it, for that matter) is a=
 mess!

  - I had to edit the patch
	zips/gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
    supplied by Axiom so that it would match, and to put "patch -l" in th=
e
    Makefile, so that this patch would ignore blanks.
  - Do alias awk=gawk in the shell.
  - Do export CFLAGS=-I/opt/csw/include in the shell, otherwise BFD won=
't
    compile.  Why doesn't GCL use its own binutils subdirectory?

\start
Date: 25 Nov 2004 13:10:29 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: latest patches

Greetings!  OK, without having time right now to investigate this
completely, I'm making an educated guess that you happen to have the
very old bfd.h header on your system commensurate with that which we
have locally in the binutils directory, and that you are configuring
with the default --enable-statsysbfd.  I had not thought of this
posibility, and so therefore the following patch *on top of what I
sent previously* is better in any case (now in CVS as well):

=============================================================================
Index: o/sfaslbfd.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/sfaslbfd.c,v
retrieving revision 1.19
diff -u -r1.19 sfaslbfd.c
--- o/sfaslbfd.c	24 Nov 2004 16:01:04 -0000	1.19
+++ o/sfaslbfd.c	25 Nov 2004 18:03:52 -0000
@@ -337,6 +337,8 @@
 
    for (s=b->sections;s;s=s->next) {
      
+     unsigned long ss=bfd_section_size(b,s);
+
      if (!(s->flags & SEC_LOAD))
        continue;
      
@@ -346,9 +348,10 @@
 					     v,0,q)) 
        FEerror("Cannot get relocated section contents\n",0);
 
-     memcpy((void *)(unsigned long)s->output_section->vma,v,bfd_section_size(b,s));
+     memcpy((void *)(unsigned long)s->output_section->vma,v,ss);
      
    }
+
  }
    
   dum.sm.sm_object1=faslfile;
Index: binutils/bfd/bfd-in.h
===================================================================
RCS file: /cvsroot/gcl/gcl/binutils/bfd/bfd-in.h,v
retrieving revision 1.2
diff -u -r1.2 bfd-in.h
--- binutils/bfd/bfd-in.h	24 Nov 2004 18:46:15 -0000	1.2
+++ binutils/bfd/bfd-in.h	25 Nov 2004 18:03:52 -0000
@@ -337,8 +337,7 @@
 #define bfd_get_section_lma(bfd, ptr) ((ptr)->lma + 0)
 #define bfd_get_section_alignment(bfd, ptr) ((ptr)->alignment_power + 0)
 #define bfd_section_name(bfd, ptr) ((ptr)->name)
-#define bfd_section_size(bfd, ptr) ((ptr)->_raw_size)
-/* #define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr)) */
+#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))
 #define bfd_section_vma(bfd, ptr) ((ptr)->vma)
 #define bfd_section_lma(bfd, ptr) ((ptr)->lma)
 #define bfd_section_alignment(bfd, ptr) ((ptr)->alignment_power)
Index: binutils/bfd/bfd-in2.h
===================================================================
RCS file: /cvsroot/gcl/gcl/binutils/bfd/bfd-in2.h,v
retrieving revision 1.4
diff -u -r1.4 bfd-in2.h
--- binutils/bfd/bfd-in2.h	24 Nov 2004 18:46:16 -0000	1.4
+++ binutils/bfd/bfd-in2.h	25 Nov 2004 18:03:53 -0000
@@ -342,8 +342,7 @@
 #define bfd_get_section_lma(bfd, ptr) ((ptr)->lma + 0)
 #define bfd_get_section_alignment(bfd, ptr) ((ptr)->alignment_power + 0)
 #define bfd_section_name(bfd, ptr) ((ptr)->name)
-#define bfd_section_size(bfd, ptr) ((ptr)->_raw_size)
-/*#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))*/
+#define bfd_section_size(bfd, ptr) (bfd_get_section_size_before_reloc(ptr))
 #define bfd_section_vma(bfd, ptr) ((ptr)->vma)
 #define bfd_section_lma(bfd, ptr) ((ptr)->lma)
 #define bfd_section_alignment(bfd, ptr) ((ptr)->alignment_power)
=============================================================================
=============================================================================

I'm testing this now.  You can either wait until I run the gamut of
tests (a few days), or try this patch now if you have the time, and
think my guess is right.  You should have seen errors on the first
attempted load of a .o file ('aborted') if this hypothesis is right.

Take care,

Tim Daly writes:

> Camm,
> 
> I applied the patches you sent and the system build fails:
> 
> =============================================================
> make[3]: *** [/tmp/axiom/obj/linux/bin/bootsys] Error 134
> make[3]: Leaving directory `/tmp/axiom/src/boot'
> make[2]: *** [bootdir] Error 2
> make[2]: Leaving directory `/tmp/axiom/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/tmp/axiom'
> make: *** [all] Error 2
> =============================================================
> 
> at this point we've build a lisp image, used it to compile a
> bunch of lisp files, then exited the image. We've saved the
> image as "bootsys".
> 
> The bootsys image won't start.

\start
Date: Thu, 25 Nov 2004 16:13:15 -0500
From: Tim Daly
To: Charles Miller
Subject: axiom build

Chuck,

I've created a new branch (axiom--MACOSX--1) and downloaded it to
mac0895 so we can work on the MAC port.

This mac system lacks diff and make, both of which I've built in
my home directory.

This system also lacks latex. I've been looking around at the mac
websites for a package to install but the mac conventions are 
wildly different from the linux conventions and I cannot figure
out how to get tetex installed. Everything seems to want to interact
with the screen and I'm half-way around the world.

Please put a version of Latex on this box. Without that the axiom
build can't proceed.

\start
Date: Thu, 25 Nov 2004 16:14:53 -0500
From: Tim Daly
To: Mark Murray
Subject: axiom build

Mark,

I've tried to download axiom--BSD--1 both to my home directory
and to the /tmp directory on graveyard. Each time I've run out 
of space after the second patch. 

Is it possible to get more space on the box?

\start
Date: Thu, 25 Nov 2004 15:38:17 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: proposal to create the Axiom Foundation (was: bounties etc.)
Cc: Camm Maguire, Bob McElrath, Bill Page

Martin, Camm and Bob,

Please send me by email a user id and password that you want
to use to access the AxiomFoundation web page. (See discussion
below.)

On Thursday, November 25, 2004 11:14 AM Martin wrote:
> 
> Another issue: We need to make sure that we fund only projects
> somebody works on anyway. 
>

Martin, thank you for your suggestions on an initial bounty
list in your previous email.
 
> Bill: is it possible to have a wiki page only members of the 
> "foundation" can edit, but anybody can comment on?
> 

I have changed the edit security option of the AxiomFoundation
page so that it requires a login with user id and password before
being allowed to edit. This is a little awkward in that the
user id and password must be set up manually by me. The only
alternative would be to setup the AxiomFoundation page under
the Axiom Portal instead of MathAction. Axiom Portal has a full
user registration procedure and controlled access to specific
web pages.

But unless anyone has an objection, let's try it the manual
way on MathAction for a while. In principle I have no objection
to allowing open access since we can always track any changes
that are made and reverse them if necessary, but perhaps in this
particular case we need to be a little more cautious. In spite
of the edit password, users will still be able to submit
comments on the contents of the AxiomFoundation page.

If you go to the Axiom Foundation page at:

  http://page.axiom-developer.org/zope/mathaction/AxiomFoundation

you will see a section for Foundation Members Only. It contains
a link to the edit page which triggers the login prompt. Or
if you want, just go to the bottom of the page and fill in the
comment form. My plan is to periodically consolidate comments
made to AxiomFoundation into concise summaries of the decisions
of the Foundation members.

So, would the Axiom Foundation members please send me (by private
email) a user id and password that they would like me to setup
for them to use when editing the AxiomFoundation web page?

> 
> PS: It seems that we have already at least 100$ to spend!
>

Do you mean Bob McErath's "pledge" :

> Right now I volunteer $100 of my personal funds for Axiom
> work. (because I'm a single post-doc and don't have a lot
> of expenses ;)  What do people consider to be an important
> goal that is not already being worked on, that we could
> reasonably expect someone to pick up?  This kind of thing
> needs a rigorous definition for completion of the bounty,
> and test-cases accompanying it to ensure correctness.

Last time I looked the total donations received today via
paypal was $170. Together with Bob's contribution that would
already amount to $270 and the door has only been open for
about 8 hours. It's a start.

Paypal generates an email notice for each donation received.
I would be happy to include Foundation Member's email addresses
on the distribution list for these notices if you wish.

One thought I had was that perhaps we should allow another
gentler form of donation - a pledge such as Bob McElrath's
email above. Some users might find this less intrusive because
it doesn't immediately involve any new fangled e-money kind
of transaction. We could allow potential contributors to
submit a promise to make a donation with information on how
to contact them at a later time to collect.

Here is one other point to consider: Do we want to allow
people the option of having there names listed somewhere on
the Axiom website as contributors?

Finally, has anyone considered the amount of time that they
would like to serve as Axiom Foundation Members? I would like
to propose that each member plan on serving for at least one
year with an option to re-volunteer at the end of each year.
But this should be considered a loose commitment, especially
during the formative stage of the Foundation. Ideally, there
would be some kind of rotation among willing Axiom users
and developers with some continuity of membership from year
to year.

\start
Date: Thu, 25 Nov 2004 16:35:54 -0500
From: Tim Daly
To: Kostas Oikonomou, Camm Maguire
Subject: Re: Building Axiom 11/15/2004 on Solaris 9 Sparc

Kostas,

>I am trying to compile the Axiom sources dated 11/15/2004 on a Sun Solaris 9 system.
>The build ends with lisp dumping core:
>
>--------------------------------------------------------------------------------------------------
>Loading /home/build/axiom/int/boot/npextras.lisp
>Finished loading /home/build/axiom/int/boot/npextras.lisp
>Compiling tytree1.lisp.
>; (DEFUN |bfMDef| ...) is being compiled.
>;; Warning: The variable |defOp| is not used.

[....snip....]

>Illegal Instruction - core dumped
>make[3]: *** [/home/build/axiom/obj/solaris/bin/bootsys] Error 132
>make[3]: Leaving directory `/home/build/axiom/src/boot'
>make[2]: *** [bootdir] Error 2
>make[2]: Leaving directory `/home/build/axiom/src'
>make[1]: *** [srcdir] Error 2
>make[1]: Leaving directory `/home/build/axiom'
>make: *** [
>bash-2.05$
>bash-2.05$ cd ../../obj/solaris/bin
>bash-2.05$ gdb -c core
>GNU gdb 6.1
>Copyright 2004 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you are
>welcome to change it and/or distribute copies of it under certain conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB.  Type "show warranty" for details.
>This GDB was configured as "sparc-sun-solaris2.8".
>Core was generated by `/home/build/axiom/obj/solaris/bin/lisp'.
>Program terminated with signal 4, Illegal instruction.
>#0  0x007affd0 in ?? ()
>(gdb) q

This appears to be a failure in the saved image of lisp. The axiom build
first builds GCL and saves the image as obj/${SYS}/bin/lisp. This is the
first step.

This lisp image is used to compile the boot language compiler (in the
src/boot subdirectory). The compiled files for the boot language compiler
are loaded into a lisp and saved as obj/${SYS}/bin/bootsys. This is the
second step.

Clearly the saved bootsys image is failing but I don't know why.

Camm is the person most likely to know and I've copied him on this.


[... snip ...]

>Edit Makefile:
>      tar -> gtar

I assume that gtar is gnu-tar. I'll have to make the system aware
that the 'tar' command can change and fix this everywhere.


>make noweb
>
>Edit the shell script "mnt/solaris/bin/document" to set
>
>weave="$AXIOM/bin/lib/noweave -delay -x"

This doesn't seem necessary as I append the -delay to the command
whenever it is used. Did you find a case where this is missing?

>1. Edit Makefile.pamphlet to add [11pt] and
>
>\usepackage[hypertex,colorlinks=true,linkcolor=blue,filecolor=webgreen,extension=dvi]{hyperref}

As far as I know there are no hyperlinks in the Makefile.pamphlet files.
This will be more of an issue once I get the hyperdoc browser working.
The plan is to have the .dvi files viewed in-line in hyperdoc but the
details are still to be worked out. 

>2. Study Makefile.dvi, edit Makefile.pamphlet:
>
>(a) Check the GCL version of GCL:
>
>GCLVERSION=gcl-2.6.5
>
>Then rm lsp/Makefile
>
>NOTE: Axiom contains its own distribution of GCL!

Yes, this is true and a source of some discussion. Please search the
archive of this mailing list and you'll see the reasons pro-and-con.
Essentially GCL is there because (a) I need to change the image and
(b) Axiom needs to be tested with a known version. Both points have
been discussed and in the future this may change but there are other
things that need attention first.

[...snip...]

>(c) Add a <<Makefile.solaris>> chunk in section 2.  Should have really been
>     "solaris9g".

Please send me the chunk.

>(d) Edit lsp/Makefile.pamphlet and globaly change @tar to @$(TAR).

I'll fix this in the release version.


>2. Building the GCL within Axiom (or outside of it, for that matter) is a mess!
>
>  - I had to edit the patch
>	zips/gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
>    supplied by Axiom so that it would match, and to put "patch -l" in the
>    Makefile, so that this patch would ignore blanks.

I'll look into this. This should not fail in the production version.

>  - Do alias awk=gawk in the shell.

I'll look into this.

>  - Do export CFLAGS=-I/opt/csw/include in the shell, otherwise BFD won't
>    compile.  Why doesn't GCL use its own binutils subdirectory?

It is possible to get GCL to use its own binutils directory.
Check the configure script. One of the options allows you to do this.
The configure command is included in the lsp/Makefile.pamphlet file.
If you want a special version for solaris it needs a new chunk.

If you're interested in working on a solaris port further I can 
arrange for you to become a developer. We've set up an arch server
that has branches for various pieces of work. Look at
http://arch.axiom-developer.org

In order to be a developer with write access I need to get an ssh
key from you. On linux this is done with:

ssh-keygen -t dsa

which creates a file called .ssh/id_dsa.pub which you need to send to
me. Installing this key on the host will give you write access to the
arch archive.

I don't have a nearby solaris machine but there are a few in work.
I can probably get write access to one so I can help with the port.

\start
Date: Thu, 25 Nov 2004 17:55:28 -0500
From: Tim Daly
To: Bill Page
Subject: re: proposal to create the Axiom Foundation (was: bounties etc.)
Cc: Bill Page, Camm Maguire, Bob McElrath

Bill,

I wrote a $100 check for the foundation which will go out in tomorrow's mail.

\start
Date: Thu, 25 Nov 2004 18:07:05 -0500
From: Bill Page
To: Tim Daly
Subject: RE: proposal to create the Axiom Foundation (was: bounties etc.)

Thanks very much Tim. You really *are* too generous in your
personal support of this project! :))

On Thursday, November 25, 2004 5:55 PM Tim Daly
wrote:
> 
> Bill,
> 
> I wrote a $100 check for the foundation which will go out in 
> tomorrow's mail.

\start
Date: Thu, 25 Nov 2004 20:04:06 -0500
From: Bill Page
To: Tim Daly
Subject: Lulu publishing
Cc: Camm Maguire, Bill Page, Bob McElrath

Tim, et al.

This is my last "inspiration" of the day, I promise, but ...
it's a lulu :)

Have you heard about Lulu, the new "print on demand" book
publishers? They are for real and quite serious. I have a
friend who is publishing some very serious physics monographs
this way. Just to get an idea, see his books here:

http://people.lulu.com/users/index.php?fHomepage=42530

Dr. Kiehn is retired from the University of Houston and enjoying
the good life while he (finally) gets a chance to write the
books that he had always planned to write. But scientific
publishing being what it is today, he has had a very hard time
finding a publisher with whom he can agree on things like
royalties and exclusive copyrights etc. When I discussed it
with him recently he assured me that he was sure that he had
finally found the solution - Lulu. Now he can offer his books
for sale and expect a reasonable return to supplement his
retirement and he doesn't have to give up the chance that his
books might be published in the mainstream someday when people
begin to realize that topological thermodynamics is a really hot
subject.

See more about Lulu at the end of this email.

-------

Anyway, so here is my idea:

  I think the Axiom Foundation should publish the book that Tim
Daly has recently finished updating and revising:

       "AXIOM - The 30 Year Horizon"

http://page.axiom-developer.org/zope/Plone/refs/books/axiom-book2.pdf

This book is the essential replacement for the original book:

 "AXIOM - The Scientific Computation System"

by Richard Jenks and Robert Sutor and published by the
Numerical Algorithms Group, in Springer-Verlag, (c) 1992.

The new book weighs in at over 1000 pages and a dauntingly big
download and print job of anyone! But Lulu to the rescue...
Now anyone can order a convenient printed copy of the book
for a very reasonable price.

The Axiom Foundation (with Tim's and possibly NAG's approval
of course) could offer the new book for sale through Lulu.
Profits from the sale of the book could go to help fund the
Axiom Foundation initiatives that we have only just begun
to consider such as Bounty incentives for Axiom development
work.

Based on the cost and commission figures at

http://www.lulu.com/static/on-demand-books2.php

I think that setting a price of say $50 per book (quantity 1)
could yield a net royalty of about $20 for each book sold.
This could help promote Axiom is more than one way at the
same time.

Now, that is not all! Lulu now also sells software. (See more
below.)

So, the Foundation could also use Lulu to offer Axiom CDrom
"boxed sets" for end-user installation. Ok, so maybe that is
a bit premature right now, but I think we will get to that
stage pretty soon now.

(Does all this sound like a "too-good-to-be-true" sales pitch?
maybe I am getting just a little too enthusiastic, but I do
think that this might work.

As usual I look forward to your comments.

Regards,
Bill Page.


http://www.lulu.com/static/pr/11_03.php

Press Center

Lulu Brings the Power of On-Demand Publishing to Software
Open Source Developers Use Lulu to Sell Software CDs and Books

November 3, 2004 (Raleigh, North Carolina)-On-demand publishing
is not just for books anymore. Lulu, the company that gives
independent publishers free access to powerful tools for
publishing and distributing books, music and other digital
content, announced today that it would begin to provide those
same tools to independent software developers.

The first five software sets available on Lulu include popular
open source projects OpenOffice.org (an alternative to Microsoft
Office), Fedora (a version of the Linux operating system), Slash,
and Bugzilla. Also available is a preparation program for the
Cisco Certified Network Administrator (CCNA) test.

---------

http://www.lulu.com/static/on-demand-books1.php

Publishing a book through Lulu is easy, quick, and free.
Once you register and go through the process of uploading
your book and book covers, you or your customers can order
your book any time, in any quantity, and receive the real
thing by mail within a week.

Make your book available in paperback or ebook format through
the Lulu marketplace for free.

Lulu handles all transactions, order tracking, and shipping
on book orders. 

State-of-the-art print-on-demand technology allows each book
to be manufactured as it is purchased.

Purchase ISBN assignment through Lulu for retail distribution
through vendors like Amazon.com and BN.com.

Publishing a book requires no set-up fee, no minimum order,
and no exclusivity.

Set your own royalty. You earn the full amount of your royalty
for every book sold.

Lulu pays you monthly through PayPal. We earn only a 20%
commission on each sale. 

Choose between black and white or full-color interior printing.
All covers are full-color.

Three trim sizes: 6" x 9", 8.5" x 11" and 6.625" x 10.25"

Select perfect, saddle-stitched or spiral binding.

Bulk order discounts are automated in our shopping cart.

Hardback books, custom trim sizes and more are available in
quantities of 100 or more through Custom Orders.


\start
Date: Thu, 25 Nov 2004 21:15:32 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Lulu publishing
Cc: Camm Maguire, Bob McElrath

Bill,

Not a bad idea, actually.

>The Axiom Foundation (with Tim's and possibly NAG's approval
>of course) could offer the new book for sale through Lulu.

The book is partially composed of text released under the
Modifed-BSD license, partially composed of some text by
Martin Dunstan (the tutorial), who gave me permission to use
and freely republish it under the Modified-BSD.

The picture on the front (Blue Bayou) is by Jocelyn Guidry
(http://www.jocelynguidry.com) and I have her permission to freely
distribute it under the Modified-BSD.

The rest of the text, including composing it into tex, typesetting
the equations, etc. was written by me and I give the same permission
to use work under the Modified-BSD.

Of course, the graphics chapter needs work as does the cross reference
information in the back.  There is no such thing as a simple job.

Perhaps we could even cut a deal with the cheap CD place to include
a CD with Axiom on it. 

\start
Date: Fri, 26 Nov 2004 08:45:34 +0000
From: Mark Murray
To: Tim Daly
Subject: Re: axiom build 

root writes:
> Is it possible to get more space on the box?

Your home directory will be NFS mounted on a very slow box.

Graveyard:/usr/axiom has 5GB free and is for your exclusive use.

I've also installed an official port of GNU Arch (tla) on graveyard. As long 
as you have /usr/local/bin in your path, you should get it.

\start
Date: Fri, 26 Nov 2004 10:17:12 +0000
From: Mike Dewar
To: Tim Daly
Subject: Re: Lulu publishing
Cc: Camm Maguire, Bill Page, Bob McElrath

I don't think that NAG would object, provided that the terms of the
license were complied with (which is only that the copyright notices and
license text appear in the book, e.g. on the same page as the Library of
Congress/ISBN metadata).

I would also hope that the original contributors, particularly the
principle authors Dick Jenks and Bob Sutor, were acknowledged in an
appropriate way.

Keep up the good work!

Cheers, Mike.

On Thu, Nov 25, 2004 at 09:15:32PM -0500, Tim Daly wrote:
> Bill,
> 
> Not a bad idea, actually.
> 
> >The Axiom Foundation (with Tim's and possibly NAG's approval
> >of course) could offer the new book for sale through Lulu.
> 
> The book is partially composed of text released under the
> Modifed-BSD license, partially composed of some text by
> Martin Dunstan (the tutorial), who gave me permission to use
> and freely republish it under the Modified-BSD.
> 
> The picture on the front (Blue Bayou) is by Jocelyn Guidry
> (http://www.jocelynguidry.com) and I have her permission to freely
> distribute it under the Modified-BSD.
> 
> The rest of the text, including composing it into tex, typesetting
> the equations, etc. was written by me and I give the same permission
> to use work under the Modified-BSD.
> 
> Of course, the graphics chapter needs work as does the cross reference
> information in the back.  There is no such thing as a simple job.
> 
> Perhaps we could even cut a deal with the cheap CD place to include
> a CD with Axiom on it. 

\start
Date: Fri, 26 Nov 2004 09:46:45 -0500
From: Bill Page
To: Camm Maguire, Bob McElrath, Martin Rubey
Subject: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu
Cc: Mike Dewar

Members, et al.

Ok in my official capacity as Secretary to the Foundation, since
both Tim Daly and NAG (aka Mike Dewar) apparently agree to the
idea of publishing the new Axiom book at http://www.lulu.com ,
I would like to seek approval from the members of the Axiom
Foundation to proceed with making the necessary arrangements.

Would the members please let me know at least *positive* or
*negative* as soon as you get a chance? Thanks.

... And of course I was wondering if there were any volunteers
who would like to step forward to help me with doing this? :))

One issue that will have to be decided is what price to attach
to the sale of the book. I did a quick calculation based on
a size of 1000 pages and a royalty of $20 based on the information
at

  http://www.lulu.com/static/on-demand-books2.php

and I got a price of just under $50 per single copy. The
Foundation would recieve $20 from each sale. Does that sound
reasonable? Do you think I did the calculation correctly?

Regards,
Bill Page.

On Friday, November 26, 2004 5:17 AM Mike Dewar wrote:

> I don't think that NAG would object, provided that the terms
> of the license were complied with (which is only that the copyright
> notices and license text appear in the book, e.g. on the same page
> as the Library of Congress/ISBN metadata).
> 
> I would also hope that the original contributors, particularly the
> principle authors Dick Jenks and Bob Sutor, were acknowledged in
> an appropriate way.
>
> Keep up the good work!
>
>Cheers, Mike.

On Thu, Nov 25, 2004 at 09:15:32PM -0500, Tim Daly wrote:
> Bill,
> 
> Not a bad idea, actually.
> 
> >The Axiom Foundation (with Tim's and possibly NAG's approval
> >of course) could offer the new book for sale through Lulu.
> 
> The book is partially composed of text released under the
> Modifed-BSD license, partially composed of some text by
> Martin Dunstan (the tutorial), who gave me permission to use
> and freely republish it under the Modified-BSD.
> 
> The picture on the front (Blue Bayou) is by Jocelyn Guidry
> (http://www.jocelynguidry.com) and I have her permission to freely
> distribute it under the Modified-BSD.
> 
> The rest of the text, including composing it into tex, typesetting
> the equations, etc. was written by me and I give the same permission
> to use work under the Modified-BSD.
> 
> Of course, the graphics chapter needs work as does the cross reference
> information in the back.  There is no such thing as a simple job.
> 
> Perhaps we could even cut a deal with the cheap CD place to include
> a CD with Axiom on it. 

\start
Date: Fri, 26 Nov 2004 11:15:18 -0500
From: Bill Page
To: Camm Maguire, Bob McElrath, Martin Rubey
Subject: RE: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu
Cc: Mike Dewar

All,

One thing we should seriously consider I think is to
purchase an ISBN (International Standard Book Number)
for the new Axiom book. See:

  http://www.lulu.com/services/isbn.php

This is important because I can seriously imagine that
some universities *might* be interested in using the
Axiom book in a course on Computer Algebra and although
the book will still be available for free downloading
I expect that most university book stores would prefer
to be able to order copies of the book through the usual
channels.

What do you think?

Regards,
Bill Page.


On Friday, November 26, 2004 9:47 AM I wrote:

>Members, et al.
>
>Ok in my official capacity as Secretary to the Foundation, since
>both Tim Daly and NAG (aka Mike Dewar) apparently agree to the
>idea of publishing the new Axiom book at http://www.lulu.com ,
>I would like to seek approval from the members of the Axiom
>Foundation to proceed with making the necessary arrangements.
>
>Would the members please let me know at least *positive* or
>*negative* as soon as you get a chance? Thanks.

\start
Date: Fri, 26 Nov 2004 15:59:05 -0500
From: Bill Page
To: Tim Daly
Subject: arch@axiom-developer.org--axiom archive http	access

Tim,

This is just a quick note to let you know that last night I
modified the arch@axiom-developer.org--axiom archive to use
straight http access instead of relying on webdav. The reason
is that I discovered that some agressive firewalls do not allow
the necessary webdav access required to obtain the directory
listing. So now it is setup with the --listing option which
automatically creates .listing files and makes webdav access
unnecessary. This change should be transparent to everyone
since there is no change to how http-type archives are
registered and it does not affect sftp-type access at all.

Let me know if you see any problems with this.

\start
Date: Fri, 26 Nov 2004 17:05:53 -0500
From: Tim Daly
To: Bill Page
Subject: Re: arch@axiom-developer.org--axiom archive http access
Cc: Bill Page

ok. i doubt it will cause problems since there are only 3 people
using it so far and the instructions don't change. --t

\start
Date: Fri, 26 Nov 2004 17:22:25 -0500
From: Tim Daly
To: Bill Page
Subject: Re: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu
Cc: Camm Maguire, Mike Dewar, Bob McElrath

Bill,

I read the ISBN section and it seems reasonable. Before we order one
we should probably be sure we have a printable book worth buying.

Some work needs to be applied to make the book "publication ready".
I'll create a axiom--book--1 branch so we can work on it. 

We need to :
 * know what format they accept 
 * look at how cover art
 * work on an index
 * work on chapter 8 (graphics)
 * work on the algebra reference information

\start
Date: Fri, 26 Nov 2004 17:28:28 -0500
From: Tim Daly
To: Mike Dewar
Subject: Re: Lulu publishing
Cc: Camm Maguire, Bob McElrath, Bill Page

Mike,

There isn't an ISBN/Metadata page at the moment but there will be.
We'll add the license terms there as well as a statement that copyright
resides with the original holders (rather redundant but why not?).

Currently all of the original authors are listed on the cover, plus
Martin Dunstan (the tutorial section) and Jocelyn Guidry (the artist).

It's been policy to give credit to all contributors so any additional
people who work on the book would be added to that list.

\start
Date: Fri, 26 Nov 2004 17:30:51 -0500
From: Tim Daly
To: Mark Murray
Subject: re: axiom build

Mark,

re: /usr/axiom

If I could only remember things... thanks. 
I'm building axiom--BSD--1 there and will work changes from there.

\start
Date: Fri, 26 Nov 2004 18:51:51 -0500
From: Bill Page
To: Tim Daly
Subject: MathAction web stats
Cc: Camm Maguire, Bob McElrath

All,

Just in case the leisurely pace of discussion here might
have given anyone the wrong impression, I have created a
link to the usage statistics for the MathAction and Axiom
Portal web site.

  http://page.axiom-developer.org/usage

The statistics show that usage has been rising steadily.
I was also very pleased to see the number of downloads of
the Axiom book - a remarkable 895 hits! (Look for the link
"/zope/Plone/refs/books/axiom-book2.pdf" in the table of
Total URLs.) I think that this counts both whole file
downloads and single pages-at-a-time reads, but still it
is must larger than I expected. Also take a look at the
number of downloads of Axiom itself (axiom.20040418.tgz
is an earlier binary release of Axiom for RedHat).

If you have any questions about these statistics, please
ask.

\start
Date: Sat, 27 Nov 2004 13:53:05 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu
Cc: Bill Page, Camm Maguire, Mike Dewar, Bob McElrath

root writes:

 > Before we order one we should probably be sure we have a printable book
 > worth buying.

I also think that we shouldn't hurry here. Two questions: 

* How much will the publishing cost. (Or is there really only a per book
  price?)

* How long does the publishing process take? I assume that the book won't be
  ready for Christmas, even if we hurry now :-)

Maybe it would be sensible to have the book published just in time with axiom
1.0. In this case advertising would be more efficient, probably.

\start
Date: Sat, 27 Nov 2004 13:03:46 -0500
From: Stephen Wilson
To: Marcus Better
Subject: Re: [Axiom-mail] Function returning UnivariateTaylorSeries

Hello Marcus,


I've been looking at your problem. Im afraid I dont have a
solution. However in trying to debug the code I discovered where the
system error is generated.

Tim, could you read this and give me an idea where in the axiom code I
might look for the problem? The domain vector is not being constructed
properly, leading to the problem below:

Basicly, the call is failing in the conversion to Outputform
(in pscat.spad). A call to center(%) from UnivariateTaylorSeries is
returning some interesting entities when F00 is parameterized over
POLY INT.  center() is returning (in Lisp) the integer 0, rather
than the list (0 . 0) [representing univaraiate polynomial zero]. This
integer is utimately passed to the polynomial zero? predicate, which
causes the system error.

I added two PPRINT forms to the lisp corresponding to coerce(%):
Outputform (the lisp funtion |UTSCAT-;coerce;SOf;5|) which illustrates
the problem:

 -------------------------------------------
(1) -> P := Foo(POLY INT, new()$Symbol)

   (1)  Foo(Polynomial Integer,%A)
                                                                 Type:
                                                                 Domain
(2) -> bar()$P

0                                              <-- return result of center()
(|newGoGet| #<vector 08feaab8> 15 . |zero?|)   <-- lookup the zero? function
   >> System error:
   Caught fatal error [memory may be damaged]
 -------------------------------------------

Now in changing the code for Foo by adding explicit package calls for
the 0 constants:

 --------------------------------------------
 )abbrev package FOO Foo
 Foo(K,z): Exports == Implementation where
   K : Ring
   z : Symbol
 
   Exports ==> with
     bar: () -> UnivariateTaylorSeries(K,z,0$K)
 
   Implementation ==> add
     bar ==
       st := generate(const(1)$MappingPackage2(K, K), 0$K)$Stream(K)
       series(st)$UnivariateTaylorSeries(K,z,0$K)
 -------------------------------------------

recompiling and run again:

 -------------------------------------------
(1) -> P := Foo(POLY INT, new()$Symbol)

   (1)  Foo(Polynomial Integer,%A)
                                                                 Type:
                                                                 Domain
(2) -> bar()$P

(|elt| (|Polynomial| (|Integer|)) 0)           <-- return result of center()
(|newGoGet| #<vector 08feaab8> 15 . |zero?|)   <-- lookup the zero? function
   >> System error:
   Caught fatal error [memory may be damaged]
 -------------------------------------------

Note now the return result of center() has changed.

The newGoGet _is_ returning the proper zero? for the SMP domain.

In the first case above (center returning integer zero) adding lisp by
hand of the form `(if (zerop |cen|) (setq |cen| '(0 . 0)))' results in
bar() returning as you would expect.

Tim, where might I find the code which generates the domain vectors?
center() simply does a (qrefelt $ 8) - $ being the domain vector for
the given UnivariateTaylorSeries. 

With luck I might be able to solve this. If not at least I'll learn
something.

Sincerely,
Steve


On Thu, Nov 25, 2004 at 05:27:09PM +0100, Marcus Better wrote:
> Hello,
> 
> I am trying to create a function (in a spad package) that will compute 
> some coefficients and assemble them into a Taylor series, which it will 
> return. I run into some strange errors. I simplified the code as much as 
> possible, so that it looks like this:
> 
> --------------------------------------------
> )abbrev package FOO Foo
> Foo(K,z): Exports == Implementation where
>   K : Ring
>   z : Symbol
> 
>   Exports ==> with
>     bar: () -> UnivariateTaylorSeries(K,z,0)
> 
>   Implementation ==> add
>     bar ==
>       st := generate(const(1)$MappingPackage2(K, K), 0)$Stream(K)
>       series(st)$UnivariateTaylorSeries(K,z,0)
> -------------------------------------------
> 
> This will work when called as
> 
>   bar()$Foo(INT, new()$Symbol)
> 
> but writing instead
> 
>   bar()$Foo(POLY INT, new()$Symbol)
> 
> gives me
> 
>    >> System error:
>    Caught fatal error [memory may be damaged]
> 
> The same goes for FRAC INT instead of POLY INT. Moreover, doing
> 
>   bar$Foo(INT, new()$Symbol)
> 
> returns
> 
>   theMap(FOO;bar;Uts;1,312)
> 
> as it should, but
> 
>   bar$Foo(FRAC INT, new()$Symbol)
> 
> gives the "Caught fatal error" message again.
> 
> (In my real code I need other types than INT, of course.)
> 
> I don't have a clue how to solve this. In particular, I would like to 
> pass the z argument directly to the function, but that did not succeed 
> so far.
> 
> I use axiom-0.20040831-1 on Debian Sarge i386.

\start
Date: Sat, 27 Nov 2004 13:56:41 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Re: [Axiom-mail] Function returning UnivariateTaylorSeries
Cc: Marcus Better

Stephen, Marcus,

I'll look into this further. Thanks for the analysis so far. --t


\start
Date: Sat, 27 Nov 2004 12:22:54 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: Re: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu
Cc: Camm Maguire, Mike Dewar, Bob McElrath

--- Tim Daly wrote:

> Bill,
> 
> I read the ISBN section and it seems reasonable. Before we order one
> we should probably be sure we have a printable book worth buying.
>
> Some work needs to be applied to make the book "publication ready".
> I'll create a axiom--book--1 branch so we can work on it. 
> 
> We need to :
>  * know what format they accept 
>  * look at how cover art
>  * work on an index
>  * work on chapter 8 (graphics)
>  * work on the algebra reference information

Exciting stuff!  I for one would probably be interested in buying a
copy of the book as opposed to printing one, and I agree an ISBN number
and the possibility of printing the book as a textbook seem like good
ideas.  When you say work on index, how much work is needed?  That's
one thing even TeX couldn't automate, and I've never figured out how to
tell when I'm done indexing something.

(Must get computer back on internet...  going insane... Axiom and
Maxima withdrawal... auugh. ;-)

\start
Date: Sat, 27 Nov 2004 20:54:44 +0000 (GMT Standard Time)
From: Arthur Norman
To: Cliff Yapp
Subject: ISBNs...
Cc: Bill Page, Camm Maguire, Mike Dewar, Bob McElrath

>> I read the ISBN section and it seems reasonable. Before we order one
>> we should probably be sure we have a printable book worth buying.

I would imagine that if one attaches an ISBN to a document then that 
document must be considered TOTALLY FROZEN, so otherwise the ISBN would 
not be a useful unique identification. I would certainly feel upset if I 
told my students what book to buy and went to the trouble of telling them 
what ISBN to check for and found that what they bought differed in even 
the most minor way (eg pagination) from the version I based any of my 
course handouts on. So I think you will all need to decide just how 
stable the book wants to be how soon... oe whether people will want to 
keep adding in updates and improvements...
               Arthur

\start
Date: Sat, 27 Nov 2004 22:57:54 -0500
From: Tim Daly
To: Arthur Norman
Subject: Re: ISBNs...
Cc: Bill Page, Camm Maguire, Mike Dewar, Bob McElrath

Arthur,

Good point. However Axiom is a moving target and it is reasonable to 
issue both "printing with corrections" provided they are not too frequent
and "second edition" versions at regular intervals. Both things happen
without notice now as I have textbooks that have added corrections as
well as "fourth editions" of several books. Indeed, my college calc
text must be up to its 75th edition by now :-)

I don't know that the ISBN numbering system will allow you to order
a particular edition. I know that my copy of K&R is half the thickness
of the currently published version but I believe they share ISBNs.

Personally I'd rather have an up-to-the-minute edition rather than one
with known errors or missing chapters. This was not possible before
print on demand. 

However, I can see your point about student editions differing from
last years edition. One could argue that your bookstore should order
you a new edition every semester if required. As a professor I've 
actually taught from pre-prints (e.g. the famous Lyons Unix book
and a book on Lisp internals) and I've even had profs inflict their
own notes on me instead of a textbook.

I'll look at the lulu.com site and see if there is a way to accommodate
your concern.

\start
Date: Sun, 28 Nov 2004 01:48:26 -0500
From: Tim Daly
To: Bill Page
Subject: publishing the axiom book
Cc: Gilbert Baumslag, Camm Maguire, Mike Dewar, Bob McElrath

*,

Since we've decided to make the book available using www.lulu.com's
print-on-demand services I've been setting up a way we can work on it.

The clear goal is to have a quality publication.

We'd also like it to remain free-as-in-speech so we're working under
the agreement that anything checked into the archive is your own work.
You agree that the work is released under the Modified-BSD agreement
on the copyright page. Note that this is a license so you actually
retain the copyright but agree to allow free copy and distribution.
(If there are discussions on this point please post them to the
axiom-legal@nongnu.org list and do not copy the other lists).

Changes to the book will be regulary pushed back into the axiom
distribution. The two may diverge for a while but will be kept
in sync as much as possible.

Credit is free to share and, per policy, is given as generously
as possible. If you contribute to the book you should add your
name to the list of authors on the front page. Please make sure
the front page formats properly.

And, no, you won't make a dime on royalties. I'm one of the original
authors and haven't seen money from it. So if you're thinking that
this will be an income stream you're mistaken. The funds for this
effort, if there are any, are intended to go to the Axiom Foundation
(of which I'm not an official member but suspect I have an influence).
The idea is to try to pay people to do subprojects from funds that
the book generates. Visit
  http://page.axiom-developer.org/zope/mathaction/AxiomFoundation


It would be nice if we could figure out a way to get lulu.com to
either create and ship CDs with the book or possibly just ship
CDs we make for them. I don't see anything on their site about
it but it's always fun to be the first, right?

Cooperate. Don't check in the .tex or .dvi file. 
Only the book.pamphlet and CHANGELOG file should be modified.
Check the pages you've modified and the surrounding pages to see
if you've broken anything.

Check the whole book at least once before you send changes back.
Minor changes in a page can ripple quite far, especially where
graphics images are concerned. Breaking other people's careful
work will not earn you bonus points :-)

Note that we'd like the book to be self-contained so try to 
keep everything in the book.pamphlet file. There are better ways
of organizing this but we'll have to debate them before changing
this procedure.

There are various things that need to be cleaned up.

In general you have to be very careful to edit axiom output so
that it line breaks properly. There are numerous examples in
the book :-) And don't cheat. Use real axiom output, modulo line
breaking issues. You can get most of the way there by typing
   )set output tex on
to the axiom command prompt. Axiom will output the tex for the
expression. 

Working with axiom in an emacs shell buffer and the book.pamphlet in a
second buffer is very effective. Also remember that if xdvi is
visiting a file then it will automatically reflect changes to the .dvi
file when it gets focus. Thus if you start xdvi in a separate process
you can edit, make, visit xdvi and see the changes quickly.

Chapter 8 needs the graphics work recreated. This involves first
solving the problems of getting latex to put more than one image
on a page and making the images appear on the pages where they
belong.

In order to run the graphics you will need the latest version of 
axiom. I'll include instructions below.

Chapter 9 could use further examples of domains and packages.
If you add to or modify this chapter it would also be useful to
send me a .input file with the commands so I can add them to the
automated test cases.

Given the size of chapter 9 we might consider splitting the book
into two parts, one a users guide and one a reference manual. I
leave that up for discussion and debate.

Chapter 10 has drawing function output that need to be included.

Chapter 15 needs revision.

Chapter 16 (aka Chapter 1) should be Appendix 1, similarly with
following chapters.

Appendix A and following needs work. The information is there but
I have to rewrite the latex commands.

Appendix H has been moved up to the "ISBN" page where it traditionally
appears.

The diagrams on the inner covers of the original book should probably
become a new chapter that explains these in more detail. 

We really could use a chapter on developing Axiom code. Either
an analysis of an existing domain or the construction of a new
domain with appropriate advice would be excellent. This would be
a chance to have your spiffy new domain both contributed and
recognized.


==============================================================
Instructions
==============================================================

Visit http://axiom.axiom-developer.org and click on the 
[ Developers ] link or:

==============================================================
Getting started with tla:
==============================================================

If you already have a tla command skip to the next section.

To get a working tla you can get axiom from the anonymous CVS by:

mkdir ~/bin                   <-- change ~/bin to someplace writable 
                                  on your path. I have a bin in my homedir
export CVS_RSH=ssh
cvs -d:ext:anoncvs@savannah.gnu.org/cvsroot/axiom co axiom/zips/tla-1.1.tar.gz
cd axiom/zips
tar -zxf tla-1.1.tar.gz
cd tla-1.1/src
mkdir =build
cd =build
../configure --prefix ~/bin   
make
make install
export PATH=~/bin:$PATH

There are later versions of tla on the net but this is sufficient
for you to get started.

==============================================================
Using tla to get any archive from axiom-developer.org
==============================================================

This will allow you to fetch the axiom tla archives

If you already have set up your tla identity skip to the next section

tla my-id "First Last <userid@place.com>"
tla register-archive arch@axiom-developer.org--axiom http://axiom-developer.org/archive/axiom
tla my-default-archive arch@axiom-developer.org--axiom


==============================================================
Using tla to get the book
==============================================================

tla get book--main--1

==============================================================
Making the book
==============================================================

cd book--main--1*
make

Note that there are two other commands for make
  make clean    -- remove the cruft and leave book.dvi and noweb
  make pristine -- remove everything but book.pamphlet changes

==============================================================
changing the book
==============================================================

To change the book you have two choices.
If you do not have write permission to the book archive:

cp book.pamphlet book.pamphlet.org
while 
 edit the book.pamphlet
 make
 xdvi book.dvi
(until done)
diff -Naur book.pamphlet.org book.pamphlet >book.patch
mail the book.patch file to Tim Daly

(Note that if you type:  'xdvi book.dvi &' then xdvi will
 continue to run and every time you remake the book it will
 automatically reflect the changes. This is very useful)

==============================================================
updating the book directly
==============================================================

You need write access. See http://axiom.axiom-developer.org,
follow the [ Developers ] link, make a key and send me a note.

==============================================================
Graphics in Axiom
==============================================================

You need the latest version of Axiom from the Savannah CVS

cd /tmp                     <-- or someplace where you want axiom
export CVS_RSH=ssh
cvs -z3 -d:ext:anoncvs@savannah.gnu.org/cvsroot/axiom co axiom
cd axiom
export AXIOM=/tmp/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
make
.... (get coffee)
sman  (lots of warnings but the axiom interpreter should start)
draw(sin(x), x=-10..10)
draw(sin(x*y), x=-10..10, y=-10..10)

The sman process will eventually be merged into the axiom command
as soon as I finish up the graphics integration. The sman (superman)
process is used to communicate between the axiom interpreter and the
graphics process. If you just start axiom directly with the axiom
command rather than the sman command the draw function won't do anything.


             -- or --


You need the latest version of Axiom from the arch website

cd /tmp                     <-- or someplace where you want axiom
tla get axiom--main--1 axiom
cd axiom
export AXIOM=/tmp/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
make
.... (get coffee)
sman  (lots of warnings but the axiom interpreter should start)
draw(sin(x), x=-10..10)
draw(sin(x*y), x=-10..10, y=-10..10)

The sman process will eventually be merged into the axiom command
as soon as I finish up the graphics integration. The sman (superman)
process is used to communicate between the axiom interpreter and the
graphics process. If you just start axiom directly with the axiom
command rather than the sman command the draw function won't do anything.

\start
Date: Sun, 28 Nov 2004 02:05:14 -0500
From: Tim Daly
To: Kostas Oikonomou
Subject: Re: Building Axiom 11/15/2004 on Solaris 9 Sparc

Kostas,

re: gcl-2.6.5 out of CVS

>I've done some more work on building Axiom, and I now understand the whole
>structure a little better.
>
>However, I cannot get past the problem of lisp dumping core, that I reported
>in my initial mail.  Just to remind you,
>
>make[3]: Entering directory `/home/build/axiom/src/boot'
>44 invoking make in /home/build/axiom/src/boot with parms:
>SYS= sol9gcc
>LSP= /home/build/axiom/lsp
>PART= cprogs
>SPAD= /home/build/axiom/mnt/sol9gcc
>SRC= /home/build/axiom/src
>INT= /home/build/axiom/int
>OBJ= /home/build/axiom/obj
>MNT= /home/build/axiom/mnt
>Illegal Instruction - core dumped
>make[3]: *** [/home/build/axiom/obj/sol9gcc/bin/bootsys] Error 132
>make[3]: Leaving directory `/home/build/axiom/src/boot'
>make: *** [all] Error 2
>bash-2.05$
>
>Now I've tried using both 2.6.5 and 2.6.3, and the same problem occurred.
>Since I sometimes suspect gcc, I also tried lowering the optimization in the top-level
>Makefile.pamphlet from -O3 to -O2.  That didn't help either.  However, I noticed that
>the o/ directory still gets built with -O3.  That could be a problem. I can't think of
>an easy fix right now.
>
>I don't know much about lisp, so at this point I'd like to ask your advice about how
>to proceed.
>
>For example,. I read on the GCL website that there some known problems with gcc on Solaris:
>------------------------------------------------------------------------------------------------------------------
>NEW! (20040823) An errata page to 2.6.5 on Sun Solaris has been added here . This fixes a problem
>which may arise in the loader with certain gcc/ld combinations when C optimization is in force.
>------------------------------------------------------------------------------------------------------------------
>Is it worth getting GCL 2.6.5 out of cvs?  Or would it be better to try an older version, like 2.6.1?

						Kostas
Camm has suggested some fixes but I've been unable to build Axiom
on the GCL-2.6.5 distributed with Axiom + the new patches.

Later today (it's early sunday morn at the moment) I'll get the latest
CVS version and try to build Axiom on that version. If that works I'll
upload it and you can try the build on it. 

\start
Date: Sun, 28 Nov 2004 15:54:58 +0100
From: Martin Rubey
To: Stephen Wilson
Subject: Re: [Axiom-mail] Function returning UnivariateTaylorSeries
Cc: Marcus Better

Dear Stephen, Marcus, ...

this is a bug I ran across as well. A workaround might be to explicitely pass
the center to dthe package. However, it would be really great if this bug could
be resolved, because it makes my code very awkward to read. By the way: is
there an entry in the bug database yet?

)abbrev package FOO Foo                                     
Foo(K,z,c): Exports == Implementation where                           
  K : Ring                                                          
  z : Symbol                                                        
  c : K  
                                                                  
  Exports == with
    bar: () -> UnivariateTaylorSeries(K,z,c)

  Implementation ==> add                                            
    bar ==                                    
      st := generate(const(1)$MappingPackage2(K, K), c)$Stream(K) 
      series(st)$UnivariateTaylorSeries(K,z,c)

\start
Date: Sun, 28 Nov 2004 11:45:17 -0500
From: Tim Daly
To: Kostas Oikonomou
Subject: Re: Building Axiom 11/15/2004 on Solaris 9 Sparc

Kostas,

>Thanks.  Please send me a note when you are successful.
>
>In the meantime I've verified that whatever the problem is, on Solaris at least,
>it does not seem to depend on gcc. I've tried gcc 2.95.3 with optimizations
>lowered to 2 everywhere, with the same result.
>
>				Kostas
>
>
ok. I've created a new branch (axiom--solaris--1) to deal with the 
solaris porting effort. See http://arch.axiom-developer.org

I'll build a version of axiom on the latest GCL and if it successfully
compiles and completes tests you can download it and try it. Sometime
this week I'm going to try to get access to a solaris system and see
if I can work on the problem directly.

\start
Date: Sun, 28 Nov 2004 14:00:32 -0500
From: Bill Page
To: Tim Daly
Subject: RE: publishing the axiom book

All,

Tim, thanks very much for laying out the detailed plans for
publishing the new Axiom book (books?). I hope we hear from
several people willing to help. I will definitely be one of
them.

There is now a web page on MathAction to help document our
decisions and plans for the publishing project: 

http://page.axiom-developer.org/zope/mathaction/AxiomBook

It is open for editing and comments to all. Comments and updates
would be most appreciated!

On Sunday, November 28, 2004 1:48 AM Tim Daly wrote:

> ...
> 
> It would be nice if we could figure out a way to get lulu.com
> to either create and ship CDs with the book or possibly just
> ship CDs we make for them. I don't see anything on their site
> about it but it's always fun to be the first, right?

Apparently this is quite possible. When asked about his experience
with Lulu, Robert Kiehn (an established Lulu author, see my
previous email) recently wrote to me:

> Lulu does not print over 700 pages.
> You will need to divide the work into 2 volumes
> The Printing cost paper back is about 4.50 base plus 2 cents
> a page.
> There are NO up front costs.
> You add  on what ever royalty you want.  They get 20% - you
> get 80 % of the royalty that you decide.
> You can design the covers.
> You keep all copyrights.  (meaning that you can quit Lulu
> anytime) You do not have to buy copies from them, they construct
> them on demand and bill the customer for shipping and costs and
> royalties, and send you a check for your 80% of the royalties.
> However, they are now offering hard back copies in print runs
> of over 100.
> You can also add a CD ROM to the fly leaf.
> ***
> I do not think you can get a better deal.
> 

So yes, we can add a copy of Axiom on CDrom to each book!

> 
> Given the size of chapter 9 we might consider splitting the
> book into two parts, one a users guide and one a reference manual.
> I leave that up for discussion and debate.
>

Yes! I am very much in favour of this idea. I think even the older
Jenks and Sutor book was too large for most purposes. Perhaps we
could go one step further and further divide the volumes into

- Basic Axiom - a beginning user's guide
- Advanced Axiom - user's guide
- Axiom Reference - complete reference manual

Besides the page limit that Robert Kiehn mentioned above, another
good reason is "marketing". We could plan to keep the Basic Axiom
book reasonable short and even lower in price, say < $25. The
others could be priced a little higher. Making this division might
also let us put something in print sooner.

\start
Date: Sun, 28 Nov 2004 20:22:27 -0500
From: Tim Daly
To: Kostas Oikonomou, Camm Maguire
Subject: Re: Building Axiom 11/15/2004 on Solaris 9 Sparc

Camm, Kostas,

>> Wait until I get the system ported to the gcl-2.6.5a (my name for the
>> latest GCL CVS). I'll send you a note. Things have moved so I have to
>> rework my patches.
>
>Ok, I will wait.

The axiom--solaris--1 build uses the latest GCL from the CVS directory.
Axiom will not build properly on the latest GCL due to some change in
the common lisp. The filenames are coming out lower case which they
never did before.

Camm: are you aware of any symbol case changes in GCL? It appears that
the function 'localdatabase' (src/interp/daase.lisp.pamphlet) no longer
finds the library file because the case is wrong. In particular, the
compile and the case is wrong thus:

==========================================================================
4158 making /tmp/axiom/int/algebra/VECTOR.spad from /tmp/axiom/src/algebra/vector.spad.pamphlet
4157 making /tmp/axiom/int/algebra/VECTOR.NRLIB from /tmp/axiom/int/algebra/VECTOR.spad
                        AXIOM Computer Algebra System 
              Version of Sunday November 28, 2004 at 14:29:56 
[...snip...]
------------------------------------------------------------------------
   initializing NRLIB VECTOR for Vector 
   compiling into NRLIB VECTOR 
[...snip...]
Compiling /tmp/axiom/int/algebra/VECTOR.NRLIB/code.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
Finished compiling /tmp/axiom/int/algebra/VECTOR.NRLIB/code.lsp.
------------------------------------------------------------------------
   )library cannot find the file vector.

(1) -> 4156-0c making /tmp/axiom/mnt/linux/algebra/VECTOR.o from /tmp/axiom/int/algebra/VECTOR.NRLIB
==========================================================================


Kostas: this will not affect your problem as the failure does not
happen until axiom is well into the build. So download the axiom--solaris--1
code and try to compile it thus:


cd /tmp (or whereever)
tla get axiom--solaris--1 axiom
cd axiom
export AXIOM=/tmp/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH
make

see how far the build gets and let me know. That will tell us whether
GCL can at least build itself on solaris. Meanwhile I'll try to debug
the symbol case problem in GCL.

\start
Date: Mon, 29 Nov 2004 00:16:36 -0500
From: Stephen Wilson
To: Tim Daly
Subject: Re: [Axiom-mail] Function returning UnivariateTaylorSeries
Cc: Marcus Better

Tim, Marcus, *

I've been trying to hunt this down, and am making slow progress
(learning how to use Axiom was a snap compared to learning how to hack
it;) 

The first question I tried to answer was `is the problem
introduced at the time of domain instantiation, or at compile
time?', Now I'm asking `is the problem introduced at compile time, or
during the interpreters coersion to OutputForm?'

I still dont know which end to look at, as what follows will
illustrate. 

Tim, any suggestions at all would be appreciated (suggestions which
turn out to be dead ends are just fine, since Im learning a lot).
Some of this might have to do with the database, which I know you have
written most (all?) of.

The database is being set to hold information which is, strictly
speeking, invalid for the Foo package, but the conflict is sometimes
resolved, sometimes not.  In particular, the OPERATIONALIST being
generated for the domain (which I think of at the mement as a mapping
from a constructor name to a list of export/signature pairs).

For me, this is a kicker:

--------------------------------------
-- prob.spad is Marcus's Foo package

   Re-reading browse.daase
(1) -> )lisp (setq |$DALYMODE| t)

Value = T
(1) -> )co prob.spad
       
       -- After compilation we can query the database

(1) -> (getdatabase '|Foo| 'OPERATIONALIST)

Value = ((|bar| (((|UnivariateTaylorSeries| |#1| |#2| 0)) 18)))


       -- Note here we have the signature (|UnivariateTaylorSeries|
       -- |#1| |#2| 0). I think |#1| |#2| are placeholders for the
       -- `functor' arguments of Foo, which will be filled in _after_
       -- the package is instantiated with some parameters. 
       --
       -- We have:

(1) -> P := Foo(POLY INT, new()$Symbol)

   (1)  Foo(Polynomial Integer,%A)
                                                                 Type: Domain
(2) -> (getdatabase '|Foo| 'OPERATIONALIST)

Value = ((|bar| (((|UnivariateTaylorSeries| |#1| |#2| 0)) 18)))
(2) -> bar()$P

 
   >> System error:
   Caught fatal error [memory may be damaged]

protected-symbol-warn called with (NIL)
(2) -> (getdatabase '|Foo| 'OPERATIONALIST)

Value = ((|$unique|) (|bar| (((|UnivariateTaylorSeries| |#1| |#2| 0))
18 T ELT)))

      -- Now the database has changed. My guess is caching.
      --
      -- Regardless, lets spoof the database query, giving the true
      -- polynomial zero:

(2) -> (setq -new-foo-alist '((|bar| (((|UnivariateTaylorSeries| |#1|
|#2| (0 . 0))) 18))))

Value = ((|bar| (((|UnivariateTaylorSeries| |#1| |#2| (0 . 0))) 18)))
(1) -> (setq -hide-gdbase #'getdatabase)

Value = #<compiled-function GETDATABASE>

(2) -> (defun getdatabase (con key) (if (and (eq con '|Foo|) (eq key
'OPERATIONALIST)) -new-foo-alist (funcall -hide-gdbase con key)))

Value = GETDATABASE
(2) -> bar()$P

               2     3     4     5     6     7     8     9     10
               11
   (2)  %A + %A  + %A  + %A  + %A  + %A  + %A  + %A  + %A  + %A   + O(%A  )
                        Type: UnivariateTaylorSeries(Polynomial Integer,%A,0)

-------------------------------------------------------------

I have a vague idea how the database queries are passed through the
interpreter during the problematic stage of coersion to OutputForm. 

However, I think a critical relationship is given by the following simple
trace.

Starting from a clean compile of Foo, no spooffed database lookups:

--------------------------------------------------------------

  -- |UnivariateTaylorSeries;| is the domain constructor for UTS

(2) -> (trace |UnivariateTaylorSeries;|)

Value = (|UnivariateTaylorSeries;|)

  -- |FOO;bar;Uts;1| is Foo's bar function.

(2) -> (trace |FOO;bar;Uts;1|)

Value = (|FOO;bar;Uts;1|)
(2) -> (trace |coerceInteractive|)

Value = (|coerceInteractive|)
(2) -> P := Foo(POLY INT, new()$Symbol) -- uninteresting traces generated

    
(3) -> bar()$P -- interesting

  1> (|FOO;bar;Uts;1| #<vector 086eae8c>)
    2> (|UnivariateTaylorSeries;| #<vector 08f9c150> %B (0 . 0))  <--- *** PROPER !
    <2 (|UnivariateTaylorSeries;| #<vector 086eaccc>)
  <1 (|FOO;bar;Uts;1| ((0 . 0) "NonNullStream" #<compiled-function
    |STREAM;gen!0|> . #<vector 086ead90>))
  1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
    (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
    #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>)
    (|UnivariateTaylorSeries| (|Polynomial| (|Integer|)) %B 0))
  <1 (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
    (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
    #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>))
  1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
    (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
    #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>)
    (|UnivariateTaylorSeries| (|Polynomial| (|Integer|)) %B 0))
  <1 (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
    (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
    #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>))

  1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
  (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
  #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>)
  (|OutputForm|))
    2> (|UnivariateTaylorSeries;| #<vector 08f9c150> %B 0)   <--- *** IMPROPER !
    <2 (|UnivariateTaylorSeries;| #<vector 086eac94>)
 
   >> System error:
   Caught fatal error [memory may be damaged]

protected-symbol-warn called with (NIL)

--------------------------------------------------------------------		      

Interestingly, if you redo the above, but with the database being
spoofed, you do not end up generating the impoper call of the UTS
constuctor |UnivariateTaylorSeries;| _at all_ during coercion to
output form. 

During compilation, since the zero in the Foo package is constant,
perhaps the database _should_ contain the `real' zero in the
operationalist. However, as the trace shows above, it is _possible_ to
find the correct zero with which to instantiate the UTS domain
(although the correct instantiation was generated by a function within
the domain, not from inside the interpreter).

So, if anything, could I get a suggestion as to where one would like
see the bug fixed? Of the two options I see available, perhaps one is
more proper when taking the system as a whole into consideration ( a
view which I lack, unfortunately).

Should we be trusting the database info as generated during compilation
to be correct, or should we beef up the interpreters coersion routines
to do the lookups?

I hope this is not all noise.

On Sat, Nov 27, 2004 at 01:56:41PM -0500, root wrote:
> Stephen, Marcus,
> 
> I'll look into this further. Thanks for the analysis so far. --t

\start
Date: Mon, 29 Nov 2004 08:42:26 -0500
From: Tim Daly
To: Patrizia Gianni, Bertfried Fauser
Subject: MEGA conference

Bertfried,

Patrizia Gianni sent me this link to the MEGA conference
(http://mega.dm.unipi.it)
Effective Methods in Algebraic Geometry

You'd be much more suited to this conference than I would.

There has been some motion, although glacial, on the clifford algebra
work on my part. I bought a book "Clifford Algebras with Numeric
and Symbolic Computations" and have been staggering my way thru a
couple papers. Can't say that I "get it" yet but I'm trying.

Patrizia,

Bertfried is an expert in Clifford Algebra and is more likely a 
suitable person for the conference.

I'm excited about the AJCA work. Once it exists please let me know
where I can reach it. I'd love to try it since, as you know, the whole
idea of an active journal is dear to my heart.

On the axiom developer mailing list we've been discussing a generalization
of the idea calling it a "doyen". See
http://page.axiom-developer.org/zope/mathaction/Doyen

The idea in a nutshell is to create a scientific platform with a few features
   1) boots from CD 
      a) allows distribution at conferences
      b) allows people to try it without installing to hard disk
      c) allows installation to hard disk
   2) supports a range of scientific software in a common manner
      a) "browser" style front-end with scientific plugins
      b) math (axiom, reduce, maxima), science (molgen, feyncalc, R, etc)
      c) free and open source software
   3) has a mother/daughter network arrangement
      a) doyen CD is a "daughter" with standard software
      b) doyen website is a "mother" with downloadable software, papers, etc.
      c) allows private collaboration on literate programs thru the website
      d) allows public publication of literate programs on website 
      e) "click to install" from website to local host
   4) uses a "wiki" front end
      a) allows remote changes to websites (the "wiki" software)
      b) provides a wiki as a local common front-end to science software
      c) shared architecture makes website-local access seamless
      d) allows remote, shared development of literate programs

The dream idea is that you can go to a conference (e.g MEGA) to present
a paper. Everybody at the conference got a copy of the Doyen CD in their
conference materials. The CD can be booted on any machine without affecting
hard drives (so-called "Live CDs" like KNOPPIX).

You give your talk from the website. People can click on your literate 
program paper on the website, have it automatically downloaded, installed
and ready to run while you are giving your presentation. Thus the audience
can "execute" your paper while you give your talk.

Notice that this is not specific to Axiom but is useful for general
science programs.

\start
Date: Mon, 29 Nov 2004 10:06:22 -0500
From: Tim Daly
To: Kostas Oikonomou
Subject: rebuild

the configure line is actually in the lsp/Makefile.pamphlet

generally axiom does all of its work in int, obj, and mnt

int is a scratch area for things that are system independent and
machine generated (like lsp, c, etc)

obj is a scratch area for things that are system dependent and
machine generated (like .o files)

mnt is the "ship" subdirectory. the mnt subdirectory can be copied
anywhere and represents a complete, working axiom 

in general, you can just delete int, obj, and mnt and axiom should
only rebuild those directories. in fact, the most general goal of
the makefiles is to minimize work so it should be true that you
can delete individual files and the top level make should do the
minimum amount of work necessary to rebuild a working axiom.

thus, if you want to hack lisp but want to rebuild the system otherwise
you can just "rm -rf int obj mnt"

\start
Date: Mon, 29 Nov 2004 18:14:09 +0100
From: Nate Daly
To: list
Subject: Re: publishing the axiom book

Hi,

I've looked into some of the questions that have come up about
publishing with lulu.com and these are the answers I've gotten:

1. What formats do they accept?
------------------------------------------

Short answer: They accept many different formats but they print
PDF files and anything submitted in a non-PDF format will first
be converted to PDF.

The full list of acceptable formats (for conversion to PDF) is
available here: http://www.lulu.com/help/node/view/48

But I have faith that between the lot of us we can generate the PDF
ourselves and ensure that it will look the way we want. :-)


2. Will they do on-demand publishing for a book+cd combination?
---------------------------------------------------------------------------------------

quoted from: http://www.lulu.com/services/custom/book_cd_dvd.php
 > Books with Companion CDs or DVDs
 >
 > Trying to provide your content in multiple formats? Are you
 > looking for a print on demand solution for both your printed
 > book and its companion CD or DVD? Lulu offers our Book + CD
 > combination to all current and new Lulu authors and publishers.
 > Books with companion discs are now available for minimum
 > print runs of 100. Production time is 15 business days from the
 > final approval of your content and cover artwork.
 >
 >  - Available with paperback or hardcover books
 >  - Disc can be affixed to the back cover in a sleeve or packaged
 >     separately in a DVD box
 >  - CD face can be screen printed in 1-, 2-, or 5-color options

Pricing for this is apparently done on a more case-by-case basis
and there is a form supplied on the same page (see above) where
you can specify details about book size & binding, cd packaging,
quantity, etc. and have a sales associate contact you to provide
details on pricing.


3. How does the ISBN system work with multiple revisions of the
    same book/publication?
---------------------------------------------------------------------------------------

Before dealing with that question, I think it's important to know
_why_ we want an ISBN. As far as I can tell, the only real advantage
we gain by having an ISBN is that book retailers could, in theory,
then sell the book. But if we're planning to sell it ourselves through
lulu.com, I see absolutely no advantage to having one. And it's not
free. The basic ISBN package costs $34.95, and that's basically just
to have the number. The ISBN Plus package is $149 which would
add us to the Ingram's book database (Ingram is the largest book
wholesaler in the US) which would automagically allow book
retailers like Amazon, Barnes & Noble, and Borders to sell the book.

Also of note is the fact that with the ISBN Plus package, the printing
will be done by a different firm and they do NOT do color printing!
My memory is fuzzy, but I seem to recall there being many beautiful
color illustrations in the original Axiom book. If that is still the case,
then the ISBN Plus package is out of the question.

That being said, in order to retain an ISBN across multiple revisions
of a book you are only permitted to make what they call "minor"
changes.

quoted from: http://www.lulu.com/help/node/view/91
 > Minor revisions include fixing typographical errors, misspellings
 > or cross-references, adjusting fonts or replacing a cover. If your
 > changes go beyond this, you must create a new book project,
 > publish it and purchase a different ISBN.

Non-minor changes include:
 > Substantial changes to content or organization of material, such as:
 >  - Adding, removing or moving text
 >  - Adding or removing chapters or an index
 >  - Changing the sequence of chapters
 >
 > Changes that differ from how your book is listed in Books In Print:
 >  - Title - No changes can be made.
 >  - Author(s) - You cannot add or remove authors.
 >  - Publication year (the copyright year you entered on Project Details)
 >  - Page count
 >  - Edition (the version you entered on Project Details)
 >  - Category

So basically I think most of the changes we would want to make
would require a new ISBN, at least as far as lulu.com is concerned.


Anyway. I hope that helps some.

\start
Date: Mon, 29 Nov 2004 15:08:48 -0500
From: Balbir Thomas
To: list
Subject: sman: fails to start

Hi,
I wanted to try out axiom graphics so I checked out the cvs code and
built it on debian woody. However sman fails to start and dies with the
following error message :

mandelbrot:/home/bt/archive/axiom# sman -noclef
sman:main entered
sman:process_options entered
sman:set_up_defaults entered
sman:set_up_defaults exit
sman:process_arguments entered
  sman -noclef -gr -nag -ht -noiw -ihere -ihere -ws '$AXIOM/bin/AXIOMsys' -grprog '$AXIOM/lib/viewman' -nagprog '$AXIOM/lib/nagman' -htprog '$AXIOM/bin/hypertex -s' -clefprog '' -sessionprog '$AXIOM/lib/session' -clientprog '$AXIOM/lib/spadclient' -rm '(null)' -rv '(null)' -paste '(null)'
  sman:process_arguments exit
  sman:process_options exit
  ptyopen: Failed to grant access to slave device: No such file or directory
  ptyopen: Failed to get name of slave device: No such file or directory
  ptyopen: Failed to open slave: Bad address
  sman:start_the_local_spadclient: $AXIOM/lib/spadclient
  fork_Axiom: Failed to reopen server: No such file or directory
  /bin/sh: line 1: /home/bt/archive/axiom/mnt/linux/bin/hypertex: No such file or directory
  /bin/sh: line 1: exec: /home/bt/archive/axiom/mnt/linux/bin/hypertex: cannot execute: No such file or directory
  /bin/sh: line 1: /home/bt/archive/axiom/mnt/linux/lib/nagman: No such file or directory
  /bin/sh: line 1: exec: /home/bt/archive/axiom/mnt/linux/lib/nagman: cannot execute: No such file or directory


  This is when running as root with the -noclef option. I tried other
  permutations too as described by Tim's mail on the developer list. I
  do have dchroot installed, and adding a line like "stable /dev/pts"
  does not help either (I am not sure what I am doing here :-).

  Am I missing something ?

  sincerely
  B Thomas

\start
Date: Mon, 29 Nov 2004 17:34:08 -0500
From: Tim Daly
To: Balbir Thomas
Subject: Re: sman: fails to start

Try 

sman -nonag -noht -noclef

\start
Date: Mon, 29 Nov 2004 17:35:44 -0500
From: Tim Daly
To: Balbir Thomas
Subject: Re: sman: fails to start

Try 

sman -nonag -noht -noclef

\start
Date: Mon, 29 Nov 2004 17:40:38 -0500
From: Tim Daly
To: Balbir Thomas
Subject: Re: sman: fails to start

nevermind. i reread your note.

try adding -debug and send me the output.
for some reason it appears that nagman is not executable.

\start
Date: Mon, 29 Nov 2004 18:20:40 -0500
From: Tim Daly
To: Balbir Thomas
Subject: Re: sman: fails to start

another thought. is the AXIOM variable set properly?

\start
Date: Tue, 30 Nov 2004 09:21:47 +1000
From: Mike Thomas
To: Camm Maguire, Mike Thomas
Subject: RE: [Gcl-devel] ANSI test Windows OPEN.* failures

Hi Camm.

| I see exactly the same thing you report below in Linux.
|
| cell-error-name might still just be a placeholder symbol.  See
| unixport/ansi_cl.lisp.
|
| error system still needs lots of work, but this should not be your
| problem at present, unless I misunderstand again!
|
| Please keep us posted.

These were indeed fruitful comments.

I decided last night to assume that the GCL error handling bugs are the same
on Linux as on Windows and that the real problem to solve in building Axiom
was not the error handling but the root cause of the error.

It turned out that the Spad compiler was unable to create a new file if the
file's proposed directory did not exist.  I solved this with
"ENSURE-DIRECTORIES-EXIST" in the function "get-io-index-stream" in
"src/interpreter/nlib.lisp.pamphlet" and when I left for work this morning
the spad compiler was happily doing algebra in the LAYER0COPY target in the
Makefile.

Why the Linux version of:

  (open index-file :direction :io :if-exists :overwrite
		       :if-does-not-exist :create)

apparently builds the directory automatically I must yet discover, but now
that I know where the error is, that should not be a problem.

I was using CVS GCL to build Axiom.

\start
Date: 29 Nov 2004 19:20:24 -0500
From: Camm Maguire
To: Kostas Oikonomou
Subject: Re: Building Axiom 11/15/2004 on Solaris 9 Sparc

Greetings, and please excuse the delay in my reply (holiday weekend
here).

I am reasonably confident you have one of two possible problems on
solaris:

1) Recent Solaris ld can place the .text section at other locations
   than at the beginning of the file.  The first patch at

        http://www.gnu.org/software/gcl/ERRATA-2.6.5.html

   fixes this.  This was needed for an ACL2 build on more recent
   solaris, for example.  We didn't catch it before 2.6.5 was released
   as the solaris machine to which I had access was not updated as of
   that time.

2) If gmp is not found externally, GCL will build its own copy.  I
   occasionally have seen gmp's configure mis-guess the solaris
   version, and compile in v9 extensions on a machine which could not
   handle them.  If this is the case, you should be able to see the
   effect on multiplying two bignums in the first lisp image,
   mnt/???/bin/lisp.  This can be fixed by explicitly providing the
   host type to the gmp subconfigure -- please let me know if you feel
   this is applicable and I will supply details.

In addition, as you may know, binutils upstream has made some binary
incompatible changes since 2.6.5 was released.  I think the last patch
at the aforementioned page should work with all extant versions, but
this still has to be tested.  In the meantime, I highly recommend
using the binutils in the GCL source directory.  This can be achieved
by using --disable-statsysbfd --enable-locbfd at the GCL configure
command line.  Tim can show you which pamphlet stanza you need I
think.

As an aside, I originally wrote an interface for bfd relocations as
both an aid to portability for this great GCL feature, and as a means
to offload this tedious highly platform specific component.  The goal
was to use an external bfd library and keep the build modular.  We
have since learned from binutils upstream that they have no intention
of any outside code using libbfd, will break the api at any time, and
indeed recommend distros removing the .so link needed to compile
against the library dynamically.  In principle, the soname of the
library could track api changes, but in practice this happens so often
as to force a rebuild of all GCL software every few months or so.  We
therefore link in statically, but the danger here is that someone
moves the binary between compilation machine to runtime machine where
the two have incompatible bfd libs present -- in such a case, GCL's
compiler::link function will break.  So in sum, as much as I dislike
such forking of other people's code, (sheepish smile in Tim's
direction), the best option we have now is to use the local bfd copy
-- resulting images should be then completely portable.  Furthermore,
Aurelien has written excellent MacOSX support which to my
understanding has not yet been accepted in the official binutils
upstream.  If we come to the conclusion that there is no modular
external portable relocation engine we can use, and rather must
supply our own, then we will either be developing the local binutils
tree on a regular basis, or moving gradually over time to the older
relocation option native to GCL (--enable-custreloc at the configure
command line, only on sparc and i386 at present).

One last note no bfd -- not sure if your situation is the same, but
on the solaris machine to which I have access, there is a longstanding
mismatch between the bfd headers and the binary libraries available on
the system.  I *had* to use the local bfd for this reason, at least on
this machine.  (If you want to test bfd, fire up the lisp, (defun foo
(x) x), then (compile 'foo)).

Finally, you are welcome to use CVS head, but I ask that you try to
stay away until it is released if possible.  We need to be able to
work n this version without the fear of breaking existing apps to
achieve our intended goal for the next release -- full ANSI
compliance.  2.6.5 has gone through an enormous amount of testing, and
should be a solid platform for axiom and other apps for the time
being.  This said, if the items on the ERRATA page above are too
annoying, we can push out a 2.6.6.

Take care,


Kostas Oikonomou writes:

> Hello,
> 
> I am trying to compile the Axiom sources dated 11/15/2004 on a Sun Solaris 9 system.
> The build ends with lisp dumping core:
> 
> --------------------------------------------------------------------------------------------------
> Loading /home/build/axiom/int/boot/npextras.lisp
> Finished loading /home/build/axiom/int/boot/npextras.lisp
> Compiling tytree1.lisp.
> ; (DEFUN |bfMDef| ...) is being compiled.
> ;; Warning: The variable |defOp| is not used.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling /home/build/axiom/obj/solaris/boot/tytree1.o.
> 618a making /home/build/axiom/mnt/solaris/doc/src/boot/axiom.sty from /home/build/axiom/src/doc/axiom.sty.pamphlet
> 3 making /home/build/axiom/mnt/solaris/doc/src/boot/boothdr.lisp.dvi from /home/build/axiom/src/boot/boothdr.lisp.pamphlet
> 6 making /home/build/axiom/mnt/solaris/doc/src/boot/btincl2.lisp.dvi from /home/build/axiom/src/boot/btincl2.boot.pamphlet
> 10 making /home/build/axiom/mnt/solaris/doc/src/boot/btpile2.boot.dvi from /home/build/axiom/src/boot/btpile2.boot.pamphlet
> 14 making /home/build/axiom/mnt/solaris/doc/src/boot/btscan2.boot.dvi from /home/build/axiom/src/boot/btscan2.boot.pamphlet
> 18 making /home/build/axiom/mnt/solaris/doc/src/boot/exports.lisp.dvi from /home/build/axiom/src/boot/exports.lisp.pamphlet
> 21 making /home/build/axiom/mnt/solaris/doc/src/boot/npextras.lisp.dvi from /home/build/axiom/src/boot/npextras.lisp.pamphlet
> 24 making /home/build/axiom/mnt/solaris/doc/src/boot/ptyout.boot.dvi from /home/build/axiom/src/boot/ptyout.boot.pamphlet
> 28 making /home/build/axiom/mnt/solaris/doc/src/boot/tyextra.boot.dvi from /home/build/axiom/src/boot/tyextra.boot.pamphlet
> 32 making /home/build/axiom/mnt/solaris/doc/src/boot/typars.boot.dvi from /home/build/axiom/src/boot/typars.boot.pamphlet
> 36 making /home/build/axiom/mnt/solaris/doc/src/boot/typrops.boot.dvi from /home/build/axiom/src/boot/typrops.boot.pamphlet
> 40 making /home/build/axiom/mnt/solaris/doc/src/boot/tytree1.boot.dvi from /home/build/axiom/src/boot/tytree1.boot.pamphlet
> 44 invoking make in /home/build/axiom/src/boot with parms:
> SYS= solaris
> LSP= /home/build/axiom/lsp
> PART= cprogs
> SPAD= /home/build/axiom/mnt/solaris
> SRC= /home/build/axiom/src
> INT= /home/build/axiom/int
> OBJ= /home/build/axiom/obj
> MNT= /home/build/axiom/mnt
> Illegal Instruction - core dumped
> make[3]: *** [/home/build/axiom/obj/solaris/bin/bootsys] Error 132
> make[3]: Leaving directory `/home/build/axiom/src/boot'
> make[2]: *** [bootdir] Error 2
> make[2]: Leaving directory `/home/build/axiom/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/home/build/axiom'
> make: *** [
> bash-2.05$
> bash-2.05$ cd ../../obj/solaris/bin
> bash-2.05$ gdb -c core
> GNU gdb 6.1
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "sparc-sun-solaris2.8".
> Core was generated by `/home/build/axiom/obj/solaris/bin/lisp'.
> Program terminated with signal 4, Illegal instruction.
> #0  0x007affd0 in ?? ()
> (gdb) q
> bash-2.05$
> 
> --------------------------------------------------------------------------------------------------
> 
> I would appreciate any advice on how to deal with the problem.
> 
> Here is a detailed file showing what I had to do to build Axiom.  Note that I had to
> tweak GCL a bit, as mentioned at the end of the file.
> 
> Thanks very much for your help.
> 
> 					Kostas
> 
> 
> 
> 
> 
> Sources of November 15, 2004
> ============================
> 
> Preliminaries:
> 
> export AXIOM=/home/build/axiom/mnt/solaris
> export PATH=$AXIOM/bin:$PATH
> 
> Edit Makefile:
>       tar -> gtar
> 
> make noweb
> 
> Edit the shell script "mnt/solaris/bin/document" to set
> 
> weave="$AXIOM/bin/lib/noweave -delay -x"
> 
> 
> -------------------------------------------------------------------
> 
> 1. Edit Makefile.pamphlet to add [11pt] and
> 
> \usepackage[hypertex,colorlinks=true,linkcolor=blue,filecolor=webgreen,extension=dvi]{hyperref}
> 
> to get hyperlinks.
> 
> 2. Study Makefile.dvi, edit Makefile.pamphlet:
> 
> (a) Check the GCL version of GCL:
> 
> GCLVERSION=gcl-2.6.5
> 
> Then rm lsp/Makefile
> 
> NOTE: Axiom contains its own distribution of GCL!
> 
> (b)
> <<environment>>=
> SPD=$(shell pwd)
> SYS=$(notdir $(AXIOM))
> SPAD=${SPD}/mnt/${SYS}
> LSP=${SPD}/lsp
> <<GCLVERSION>>
> AWK=gawk
> GCLDIR=${LSP}/${GCLVERSION}
> SRC=${SPD}/src
> INT=${SPD}/int
> OBJ=${SPD}/obj
> MNT=${SPD}/mnt
> ZIPS=${SPD}/zips
> TMP=${OBJ}/tmp
> SPADBIN=${MNT}/${SYS}/bin
> INC=${SPD}/src/include
> CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
> INSTALL=/opt/axiom
> COMMAND=/opt/axiom/bin/axiom
> TANGLE=${SPADBIN}/lib/notangle
> 
> (c) Add a <<Makefile.solaris>> chunk in section 2.  Should have really been
>      "solaris9g".
> 
> (d) Edit lsp/Makefile.pamphlet and globaly change @tar to @$(TAR).
> 
> 
> 2. Building the GCL within Axiom (or outside of it, for that matter) is a mess!
> 
>   - I had to edit the patch
> 	zips/gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
>     supplied by Axiom so that it would match, and to put "patch -l" in the
>     Makefile, so that this patch would ignore blanks.
>   - Do alias awk=gawk in the shell.
>   - Do export CFLAGS=-I/opt/csw/include in the shell, otherwise BFD won't
>     compile.  Why doesn't GCL use its own binutils subdirectory?

\start
Date: 29 Nov 2004 20:25:01 -0500
From: Camm Maguire
To: Mike Thomas
Subject: RE: [Gcl-devel] ANSI test Windows OPEN.* failures
Cc: Mike Thomas

Greetings!

Mike Thomas writes:

> Hi Camm.
> 
> | I see exactly the same thing you report below in Linux.
> |
> | cell-error-name might still just be a placeholder symbol.  See
> | unixport/ansi_cl.lisp.
> |
> | error system still needs lots of work, but this should not be your
> | problem at present, unless I misunderstand again!
> |
> | Please keep us posted.
> 
> These were indeed fruitful comments.
> 
> I decided last night to assume that the GCL error handling bugs are the same
> on Linux as on Windows and that the real problem to solve in building Axiom
> was not the error handling but the root cause of the error.
> 
> It turned out that the Spad compiler was unable to create a new file if the
> file's proposed directory did not exist.  I solved this with
> "ENSURE-DIRECTORIES-EXIST" in the function "get-io-index-stream" in
> "src/interpreter/nlib.lisp.pamphlet" and when I left for work this morning
> the spad compiler was happily doing algebra in the LAYER0COPY target in the
> Makefile.
> 
> Why the Linux version of:
> 
>   (open index-file :direction :io :if-exists :overwrite
> 		       :if-does-not-exist :create)
> 
> apparently builds the directory automatically I must yet discover, but now
> that I know where the error is, that should not be a problem.
> 

Wonderful news, Mike!  You da man!  Please let me know if discovering
this error poses any problems.

> I was using CVS GCL to build Axiom.
> 

An even better data point.  But in general, I'd like to try to avoid
depending on CVS head for building other apps until release.  We will
draw quite a few distracting bug reports that way, I think.

\start
Date: 29 Nov 2004 20:46:35 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Building Axiom 11/15/2004 on Solaris 9 Sparc
Cc: Kostas Oikonomou

Greetings!

Tim Daly writes:

> Kostas,
> 
> re: gcl-2.6.5 out of CVS
> 
> >I've done some more work on building Axiom, and I now understand the whole
> >structure a little better.
> >
> >However, I cannot get past the problem of lisp dumping core, that I reported
> >in my initial mail.  Just to remind you,
> >
> >make[3]: Entering directory `/home/build/axiom/src/boot'
> >44 invoking make in /home/build/axiom/src/boot with parms:
> >SYS= sol9gcc
> >LSP= /home/build/axiom/lsp
> >PART= cprogs
> >SPAD= /home/build/axiom/mnt/sol9gcc
> >SRC= /home/build/axiom/src
> >INT= /home/build/axiom/int
> >OBJ= /home/build/axiom/obj
> >MNT= /home/build/axiom/mnt
> >Illegal Instruction - core dumped
> >make[3]: *** [/home/build/axiom/obj/sol9gcc/bin/bootsys] Error 132
> >make[3]: Leaving directory `/home/build/axiom/src/boot'
> >make: *** [all] Error 2
> >bash-2.05$
> >
> >Now I've tried using both 2.6.5 and 2.6.3, and the same problem occurred.
> >Since I sometimes suspect gcc, I also tried lowering the optimization in the top-level
> >Makefile.pamphlet from -O3 to -O2.  That didn't help either.  However, I noticed that
> >the o/ directory still gets built with -O3.  That could be a problem. I can't think of
> >an easy fix right now.
> >
> >I don't know much about lisp, so at this point I'd like to ask your advice about how
> >to proceed.
> >
> >For example,. I read on the GCL website that there some known problems with gcc on Solaris:
> >------------------------------------------------------------------------------------------------------------------
> >NEW! (20040823) An errata page to 2.6.5 on Sun Solaris has been added here . This fixes a problem
> >which may arise in the loader with certain gcc/ld combinations when C optimization is in force.
> >------------------------------------------------------------------------------------------------------------------
> >Is it worth getting GCL 2.6.5 out of cvs?  Or would it be better to try an older version, like 2.6.1?
> 
> 						Kostas
> 
> 
> 
> Camm has suggested some fixes but I've been unable to build Axiom
> on the GCL-2.6.5 distributed with Axiom + the new patches.
> 

OK, perhaps we can look into this now.  I just started with a clean
2.6.5, applied the bfd patch at the bottom of
http://www.gnu.org/software/gcl/ERRATA-2.6.5.html, and built the
Debian axiom package successfully.  I'd use axiom CVS, but I'm not
sure how to splice in a gcl tree from somewhere else in the main build
sequence.

> Later today (it's early sunday morn at the moment) I'll get the latest
> CVS version and try to build Axiom on that version. If that works I'll
> upload it and you can try the build on it. 
> 

If we can avoid this, I'd appreciate it.

\start
Date: 29 Nov 2004 20:52:35 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Building Axiom 11/15/2004 on Solaris 9 Sparc
Cc: Kostas Oikonomou

Greetings!

Tim Daly writes:

> Camm, Kostas,
> 
> >> Wait until I get the system ported to the gcl-2.6.5a (my name for the
> >> latest GCL CVS). I'll send you a note. Things have moved so I have to
> >> rework my patches.
> >
> >Ok, I will wait.
> 
> The axiom--solaris--1 build uses the latest GCL from the CVS directory.
> Axiom will not build properly on the latest GCL due to some change in
> the common lisp. The filenames are coming out lower case which they
> never did before.
> 
> Camm: are you aware of any symbol case changes in GCL? It appears that
> the function 'localdatabase' (src/interp/daase.lisp.pamphlet) no longer
> finds the library file because the case is wrong. In particular, the
> message ")library cannot find the file..." is issued at the end of a
> compile and the case is wrong thus:
> 

CVS head has had substantial pathname work committed to resolve
various ansi incompatibilities as revealed in the ansi test suite.  I
can look into pinpointing where this issue arises if needed.  But just
a note -- we intend to implement readtable-case (another missing ansi
feature) shortly.  When done, to my understanding, you can set the
readtable to convert to uppercase automatically.

Please let me know if this issue is pressing, or whether we can rely
on 2.6.5 until 2.7.0 is ready.

Take care,

> ==========================================================================
> 4158 making /tmp/axiom/int/algebra/VECTOR.spad from /tmp/axiom/src/algebra/vector.spad.pamphlet
> 4157 making /tmp/axiom/int/algebra/VECTOR.NRLIB from /tmp/axiom/int/algebra/VECTOR.spad
>                         AXIOM Computer Algebra System 
>               Version of Sunday November 28, 2004 at 14:29:56 
> [...snip...]
> ------------------------------------------------------------------------
>    initializing NRLIB VECTOR for Vector 
>    compiling into NRLIB VECTOR 
> [...snip...]
> Compiling /tmp/axiom/int/algebra/VECTOR.NRLIB/code.lsp.
> End of Pass 1.  
> End of Pass 2.  
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
> Finished compiling /tmp/axiom/int/algebra/VECTOR.NRLIB/code.lsp.
> ------------------------------------------------------------------------
>    )library cannot find the file vector.
> 
> (1) -> 4156-0c making /tmp/axiom/mnt/linux/algebra/VECTOR.o from /tmp/axiom/int/algebra/VECTOR.NRLIB
> ==========================================================================
> 
> 
> Kostas: this will not affect your problem as the failure does not
> happen until axiom is well into the build. So download the axiom--solaris--1
> code and try to compile it thus:
> 
> 
> cd /tmp (or whereever)
> tla get axiom--solaris--1 axiom
> cd axiom
> export AXIOM=/tmp/axiom/mnt/linux
> export PATH=$AXIOM/bin:$PATH
> make
> 
> see how far the build gets and let me know. That will tell us whether
> GCL can at least build itself on solaris. Meanwhile I'll try to debug
> the symbol case problem in GCL.

\start
Date: Tue, 30 Nov 2004 12:19:11 +1000
From: Mike Thomas
To: Camm Maguire
Subject: RE: [Gcl-devel] ANSI test Windows OPEN.*failures
Cc: Mike Thomas

Hi Camm.

| > I was using CVS GCL to build Axiom.
| >
|
| An even better data point.  But in general, I'd like to try to avoid
| depending on CVS head for building other apps until release.  We will

I think for the next few months there may only be me running Axiom on
Windows - also the Windows code in HEAD is much cleaner than in 2.6.5 so I
feel easier about using it.  Having said that I do agree with your point
about bug reports and I intend to backport anything I find as I go along.

Cheers

\start
Date: Mon, 29 Nov 2004 21:59:57 -0500
From: Tim Daly
To: Mike Thomas
Subject: RE: [Gcl-devel] ANSI test Windows OPEN.*failures
Cc: Camm Maguire

Mike,

You have a windows port of axiom in semi-working condition?

\start
Date: Mon, 29 Nov 2004 22:04:00 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: Building Axiom 11/15/2004 on Solaris 9 Sparc
Cc: Kostas Oikonomou

Camm,

I merged the patches you sent me and axiom failed to build so 
rather than do things a patch at a time I tried to get the 
latest CVS and do a complete build.

This was only for the axiom--solaris--1 branch and is not intended
to go into the main branch of axiom until GCL 2.7.0 is released.
My build is only an attempt to get the solaris port working.

However it did uncover an interesting bug. My best guess, so far,
is that pathname-name returns a different case than it used to.
I'm going to investigate this later this evening if I get time.

\start
Date: Tue, 30 Nov 2004 13:11:53 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: [Gcl-devel] ANSI test Windows OPEN.*failures
Cc: Camm Maguire

Hi Tim.

| You have a windows port of axiom in semi-working condition?

Yes, for the first time since June.  Text only, no XDR, NAG, sockets etc,
still a bug in database building but sufficient to do stuff like DE
solutions.  Slightly more stable with respect to errors than last time -
still a long way to go I'm afraid.

I'm thinking it might soon be time to check the changes into CVS - some
cleanup required yet.  I noticed that you were pushing the idea of GNU arch,
but I understand that the Windows version is not complete so I'm loath to go
that way (also too lazy to fac the prospect of another source control
system, I'm sorry to say).  If you approve, I might ask for CVS write access
to put those changes in before I have a hard disk crash or something.


BTY, I'm trawling the code to try and turn off the Saturn code but haven't
found it. Any idea?  I recall going through this before but can't track down
the email.

\start
Date: Tue, 30 Nov 2004 14:54:55 +1000
From: Mike Thomas
To: Tim Daly
Subject: Earlier Saturn Query

Hi again

| BTY, I'm trawling the code to try and turn off the Saturn code but haven't
| found it. Any idea?  I recall going through this before but can't
| track down
| the email.


This was a #+ issue in "patches.lisp.pamphlet" which didn't account for the
existence of Windows.  Never-the-less I think it is something which should
be switchable via ")set output".

\start
Date: Tue, 30 Nov 2004 00:39:20 -0500
From: Tim Daly
To: Mike Thomas
Subject: re: [Gcl-devel] ANSI test Windows OPEN.*failures
Cc: Camm Maguire

excellent. can you tar it up somewhere so i can download it and 
do a diff?

\start
Date: Tue, 30 Nov 2004 16:00:50 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: [Gcl-devel] ANSI test Windows OPEN.*failures

Hi Tim.

I've replied privately about getting the changes to you. Meanwhile, here'=
s
an appetizer (I'm running here under the MSYS shell which built the image=
,
but the executable seems to be just as happily launched by clicking under
the Explorer):

miketh@WATER /c/cvs/head/axiom
$ axiom
Warning: I don't know if clef is supported on your system (MINGW32_NT-5.1=
)
so cl
ef is disabled.
 You can try it by issuing "clef -e
/c/cvs/head/axiom/mnt/windows/bin/AXIOMsys "
 command.
 If it works, please report to list.
open_server: No such file or directory
                        AXIOM Computer Algebra System
              Version of Tuesday November 30, 2004 at 14:45:27
-------------------------------------------------------------------------=
---
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-

(1) -> 1+2

   (1)  3
                                                        Type:
PositiveInteger
(2) -> )set message autoload off
(2) -> series(sin(a*x),x = 0)

               3        5        7          9            11
              a   3    a   5    a    7     a     9      a      11      12
   (2)  a x - -- x  + --- x  - ---- x  + ------ x  - -------- x   + O(x  =
)
               6      120      5040      362880      39916800
                        Type: UnivariatePuiseuxSeries(Expression
Integer,x,0)
(3) -> series(sin(a*x),x = %pi/4)

   (3)
                                           2    a %pi
                                          a sin(-----)
         a %pi          a %pi      %pi            4         %pi 2
     sin(-----) + a cos(-----)(x - ---) - ------------ (x - ---)
           4              4         4           2            4
   +
        3    a %pi                4    a %pi
       a cos(-----)              a sin(-----)
               4         %pi 3           4         %pi 4
     - ------------ (x - ---)  + ------------ (x - ---)
             6            4           24            4
   +
      5    a %pi                6    a %pi                7    a %pi
     a cos(-----)              a sin(-----)              a cos(-----)
             4         %pi 5           4         %pi 6           4
%pi 7

     ------------ (x - ---)  - ------------ (x - ---)  - ------------
(x - ---)
          120           4           720           4          5040
4
   +
      8    a %pi                9    a %pi
     a sin(-----)              a cos(-----)
             4         %pi 8           4         %pi 9
     ------------ (x - ---)  + ------------ (x - ---)
         40320          4         362880          4
   +
        10    a %pi
       a  sin(-----)
                4         %pi 10          %pi 11
     - ------------- (x - ---)   + O((x - ---)  )
          3628800          4               4
                     Type: UnivariatePuiseuxSeries(Expression
Integer,x,pi/4)
(4) -> y := operator =92y

   (4)  y
                                                          Type:
BasicOperator
(5) -> deq := x**3 * D(y x, x, 3) + x**2 * D(y x, x, 2) - 2 * x * D(y x=
,x) +
2 *
 y x = 2 * x**4

         3 ,,,       2 ,,         ,               4
   (5)  x y   (x) + x y  (x) - 2xy (x) + 2y(x)= 2x

                                            Type: Equation Expression
Integer
(6) -> solve(deq, y, x)

   (6)
                 5      3      2               3     2      3      3     =
2
                x  - 10x  + 20x  + 4         2x  - 3x  + 1 x  - 1 x  - 3x=
  -
1
   [particular= --------------------,basis=
[-------------,------,------------]]

                         15x                       x          x         x
Type: Union(Record(particular: Expression Integer,basis: List Expression
Integer
),...)
(7) ->

\start
Date: Tue, 30 Nov 2004 17:14:23 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: Earlier Saturn Query

One last message for the day, Tim, after a further half hour of testing on
Windows.

| | BTY, I'm trawling the code to try and turn off the Saturn code
| but haven't
| | found it. Any idea?  I recall going through this before but can't
| | track down
| | the email.
|
|
| This was a #+ issue in "patches.lisp.pamphlet" which didn't
| account for the
| existence of Windows.  Never-the-less I think it is something which should
| be switchable via ")set output".

Once I fixed that problematic Saturn output, there was no apparent
instability while running commands from the Axiom book at the command line
prompt. This is not to minimise the large amount of programming left to add
missing secondary functionality on Windows as mentioned earlier today but,
most importantly, the mathematics seems to be fully up to scratch (pad) and
I would expect that you could release a text only Windows binary in your
next release cycle.

\start
Date: Tue, 30 Nov 2004 03:07:41 -0500
From: Balbir Thomas
To: list
Subject: Re: sman: fails to start

Hi,
I am listing the output of running sman with -debug
and axiom below. "axiom" dies on startup too.

***OUTPUT of "sman -debug" (I am not sure if this is what you wanted):

sman:main entered
sman:process_options entered
sman:set_up_defaults entered
sman:set_up_defaults exit
sman:process_arguments entered
  sman -clef -gr -nag -ht -noiw -ihere -ihere -ws '$AXIOM/bin/AXIOMsys' -grprog '$AXIOM/lib/viewman' -nagprog '$AXIOM/lib/nagman' -htprog '$AXIOM/bin/hypertex -s' -clefprog '' -sessionprog '$AXIOM/lib/session' -clientprog '$AXIOM/lib/spadclient' -rm '(null)' -rv '(null)' -paste '(null)' 
sman:process_arguments exit
sman:process_options exit
ptyopen: Failed to grant access to slave device: No such file or directory
ptyopen: Failed to get name of slave device: No such file or directory
ptyopen: Failed to open slave: Bad address
sman:start_the_local_spadclient: $AXIOM/bin/clef -f $AXIOM/lib/command.list -e   $AXIOM/lib/spadclient
fork_Axiom: Failed to reopen server: No such file or directory
ptyopen: Failed to grant access to slave device: No such file or directory
ptyopen: Failed to get name of slave device: No such file or directory
ptyopen: Failed to open slave: Bad address
clef trying to get the initial terminal settings: Invalid argument
/bin/sh: line 1: /home/bt/archive/axiom/mnt/linux/lib/nagman: No such file or directory
/bin/sh: line 1: exec: /home/bt/archive/axiom/mnt/linux/lib/nagman: cannot execute: No such file or directory
/bin/sh: line 1: /home/bt/archive/axiom/mnt/linux/bin/hypertex: No such file or directory
/bin/sh: line 1: exec: /home/bt/archive/axiom/mnt/linux/bin/hypertex: cannot execute: No such file or directory


***OUTPUT of "axiom" :

ptyopen: Failed to grant access to slave device: No such file or directory
ptyopen: Failed to get name of slave device: No such file or directory
ptyopen: Failed to open slave: Bad address
clef trying to get terminal initial settings: Bad file descriptor
open serverPath failed: No such file or directory
dup2 0 failed: Bad file descriptor
dup2 1 failed: Bad file descriptor
dup2 2 failed: Bad file descriptor
clef trying to dup2: Bad file descriptor


***However AXIOMsys works fine :

bt@mandelbrot:~/archive/axiom$ which AXIOMsys
/home/bt/archive/axiom/mnt/linux/bin/AXIOMsys
bt@mandelbrot:~/archive/axiom$AXIOMsys

                        AXIOM Computer Algebra System 
              Version of Monday November 29, 2004 at 19:13:50 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
(1) ->)quit


***The axiom variable is set properly as shown below :

bt@mandelbrot:~/archive/axiom$ which axiom
/home/bt/archive/axiom/mnt/linux/bin/axiom
bt@mandelbrot:~/archive/axiom$ which sman
/home/bt/archive/axiom/mnt/linux/bin/sman
bt@mandelbrot:~/archive/axiom$

There is no nagman in the path though. Was it supposed 
to be built too ? It may be pertinent to note I am running
these programs without "make install". Is this necessary ?
Or is it enough to set AXIOM and PATH ?

sincerely
B Thomas

On Mon, Nov 29, 2004 at 05:40:38PM -0500, root wrote:
> nevermind. i reread your note.
> 
> try adding -debug and send me the output.
> for some reason it appears that nagman is not executable.

\start
Date: Tue, 30 Nov 2004 10:49:22 +0100
From: Martin Rubey
To: Mike Thomas
Subject: RE: Earlier Saturn Query

WOW, this is great, wonderful, brilliant news! RELEASE!

Martin

Mike Thomas writes:
 > Once I fixed that problematic Saturn output, there was no apparent
 > instability while running commands from the Axiom book at the command line
 > prompt. This is not to minimise the large amount of programming left to add
 > missing secondary functionality on Windows as mentioned earlier today but,
 > most importantly, the mathematics seems to be fully up to scratch (pad) and
 > I would expect that you could release a text only Windows binary in your
 > next release cycle.

\start
Date: Tue, 30 Nov 2004 06:46:03 -0500
From: Tim Daly
To: list
Subject: development process

In the past few years Axiom development has been a process where all
code changes happened on my local machine. I interacted with people
on a 1-on-1 basis, applied new code, managed local "broken" development
branches, and built new features. Once these features were working they
were tested on all the platforms I had available to me in my local
compile farm in my basement.

Clearly this process has flaws. The main problem is that it does not
scale. A second problem is that all of the parallel changes are 
wrapped into one big development swamp on my local machine (long time
readers will recognize axiomgnu/new which still exists here).

So, in order to develop a process which scales I've been looking at
the way Linus Torvolds does kernel development to try to understand
how to coordinate many people doing development in parallel. The
paramount problem is how to release quality software that is stable
and well tested.

It's not obvious to anyone but there is a long path of "process" steps
I have been taking to try to make sure that Axion "just works". Now
that the process is more open we will all end up following that process.
So I feel the need to explain the "development model" so everyone is on
the same page. Feel free to give me feedback as this is a cooperative
effort.

=====================================================================
Remember that the goal is to release a quality piece of software that
is well tested, well documented, and "just works".
=====================================================================

At the present time there are about 1/2 dozen tasks that I've "exposed"
to the world (see http://arch.axiom-developer.org). I have a dozen more
in the local code swamp that need to be exposed. They will show up as
time and interest permits.

Suppose a developer shows up with a problem, say porting axiom to the
Itanium.

Step 1 of the process is that a new "arch branch" will get created.

(Likely the branch will be named axiom--itanium--1).  This branch will
allow any developer interested in the problem to be able to read and
modify the code at will. We can experiment with any changes we want in
the "itanium" branch".

Step 2 is the documentation phase. 

All changes that survive the struggle to get itanium to work need to be
properly documented. This is my own mania, I realize, but it's part
of the 30 year horizon nonsense. We're writing code that our children
will have to change. Thus all changes need explanations that will 
make sense in the future.

Step 3 is the testing phase. 

We have to get the system to build and run on a couple Itanium
platforms to ensure that it works somewhere other than on our desk.

At this point we have a completed "axiom--itanium--1" branch and
have solved the problem of getting axion to run on the Itanium....

-------------------------------------------------------------------

Step 4 is the integration phase.

The problem to be solved here is to merge the axiom--itanium--1
branch into the axiom--main--1 branch.

There are two issues; integration and compile-farm.

First, the axiom--main--1 branch has moved.  Other developers have
been integrating their code, possibly changing the same file we changed.
So we need to merge our code into the axiom--main--1 branch. Clearly
this could be done automatically but I do it by hand so I can check
each change. (Machines don't care about quality.)

Step 5 is the compile farm (issue two)

Second, once we've integrated our changes into the axiom--main--1
the build process for axiom--main--1 has to pass the "compile farm".
That is, we need to build axiom on all of the different platforms
and make sure that our new itanium hacks don't break the main build
on other platforms.

-------------------------------------------------------------------

Step 6 is the savannah CVS change

At this point we've changed, documented, and tested a big new feature
for axiom. Now we need to check in the changes to the savannah CVS.
The changes are now going out to the world. For a lot of reasons
this step is likely to happen months after starting step 1. 

The hard part is that developers are now going to see new features
appear in the branches (e.g. graphics appears to work) but it seems to
take forever to get it into the savannah CVS. I know this feeling as
I've had various pieces of axiom running long before the world knew.
People who knew things like graphics were working wanted it NOW but 
quality is much more important than speed when releasing features.


Step 7 is the binary release

Several of the platforms have binary-only releases. These need to 
be packaged from the CVS version so they match the published reality.
Thus all of these binaries need to be recompiled and tested.

Step 8 is the spreading-tarball problem.

Several sites keep old tarballs of source around. This is convenient
but problematic as I occasionally get bug reports from old tarballs
which have been fixed in the CVS.

====================================================================
Arch? ARCH?! We don't need arch!!!
====================================================================

Why arch? Why not CVS? I've been using CVS for the past few years and
now I've run into the same problem that the Linux kernel people
solved. The problem is that CVS is unable to handle "changesets" and
"branching" easily. EASILY. Arch can.


Changesets are a group of changes to several files that are all handled
as one big change. Thus if we make a fix that involves 10 files we can
apply and retract the changes all at one time. This is technically 
possible with CVS if you carefully tag every file before applying the
change. However there are thousands of files in axiom and mistakes
are very hard to correct. Arch allows this to occur as one command.
So CVS treats each file change as different and arch combines many
semantically-related changes into one "changeset".

Branching can also be done in CVS but Arch also handles this problem
in a much more refined way. Since there will be many parallel development
efforts the ability to branch easily is important. Arch just does it 
better. 


I realize that switching to Arch is a learning curve and none of us
need yet another learning curve. But consider the fact that the kernel
has switched fron CVS to BitKeeper, a proprietary piece of code for
exactly the same reason; to manage the complexity better you need
better tools. Worldwide group development is hard.

So individually it will be painful but process-wise it will be easier.
I'll provide cookbooks schemes to anyone who asks and also provide
copies on the http://arch.axiom-developer.org page to minimize the
learning and the pain.

I ask for your patience as we open up the development process.
There is no such thing as a simple job.

\start
Date: Tue, 30 Nov 2004 22:04:27 +1000
From: Mike Thomas
To: Camm Maguire
Subject: RE: [Gcl-devel] ANSI test Windows OPEN.* failures

Camm Maguire wrote:

>>file's proposed directory did not exist.  I solved this with
>>"ENSURE-DIRECTORIES-EXIST" in the function "get-io-index-stream" in
>>"src/interpreter/nlib.lisp.pamphlet" and when I left for work this morning
>>the spad compiler was happily doing algebra in the LAYER0COPY target in the
>>Makefile.
>>
>>Why the Linux version of:
>>
>>  (open index-file :direction :io :if-exists :overwrite
>>		       :if-does-not-exist :create)
>>
>>apparently builds the directory automatically I must yet discover, but now
>>that I know where the error is, that should not be a problem.
>>
> 
> 
> Wonderful news, Mike!  You da man!  Please let me know if discovering
> this error poses any problems.

You'll be pleased to know I finally managed to set up a reasonably 
stable DeMudi Linux system and checked out HEAD GCL's "open" - it does 
not unexpectedly make non-existent directories per my earlier guess.  I 
think that the Windows Axiom build is producing harmless 
which lead to the need for the directory "AHYP.erlib"; it was that 
directory which caused the major barf on Windows.

The database build bug looks like a pathname bug which I will also have 
to track down when I have more time - until then I am copying the daase 
files by hand halfway through the build.

Putting all this aside, I've today built Axiom on two Windows boxes - XP 
(PIV) and 2000 Pro (AMD64) and once built it runs like a 'ken bought 
one' on both machines (text only).  Now that I'm understanding the Axiom 
source code layout a little better I'm finding it relatively easy to 
work with - it reminds me of Haskell.

It's now 10 pm, I started at 5.30 am and we're in the middle of a beta 
release at work so I'm going to sleep otherwise I won't survive the week.

\start
Date: Tue, 30 Nov 2004 07:51:35 -0500
From: Tim Daly
To: Mike Thomas
Subject: Re: Earlier Saturn Query

Mike,

I can give you a userid on axiom-developer.org and you take upload
a tar-gzip file there.

\start
Date: Tue, 30 Nov 2004 15:18:29 +0100
From: Marcus Better
To: Martin Rubey
Subject: Re: Function returning UnivariateTaylorSeries

(Martin: My remark about Zero()$K was incorrect.)

A(nother) workaround is to have the function return Any:

-----------------------------------------------------------------
)abbrev package FOO Foo
Foo(K,z): Exports == Implementation where
   K : Ring
   z : Symbol

   Exports ==> with
     bar: () -> Any

   Implementation ==> add
     bar ==
       st := generate(const(1)$MappingPackage2(K, K), 0)$Stream(K)
       ans := series(st)$UnivariateTaylorSeries(K,z,0)
       coerce(ans)$AnyFunctions1(UnivariateTaylorSeries(K,z,0))
-----------------------------------------------------------------

\start
Date: Tue, 30 Nov 2004 07:23:28 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Question about building

It's been a while since I have build Axiom, so perhaps my question is
no longer relevant, but assuming things haven't changed...

If I remember correctly, Axiom needs to know at the start of the build
process where it is going to be installed.  Gentoo's portage system
(package management) builds all programs in a temporary directory, and
after a successful build moves the resulting files to their final
location.  (Basically portage assumes the configure - make - make
install routine works normally.)  Is there a way an Axiom build can be
relocated after it has been built, or is its initial knowledge of its
final resting place intrinsic to the build?

People were asking about CASs on the gentoo-scientific email list, so
it brought the question to my mind again.  I would like to create an
ebuild for axiom, but I'm not quite sure how to make it work with what
I remember of Axiom's build system.

\start
Date: Tue, 30 Nov 2004 09:52:00 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Question about building

C Y,

Actually Axiom stores no information about the build location.
The $AXIOM shell variable is used during build to tell the
build process 2 pieces of information. Suppose that the variable
is set as follows:

export AXIOM=/home/daly/axiom/mnt/linux
             ^^^^^^^^^^^^^^^^
             build location
                                  ^^^^^
                                  target 

so the '/home/daly/axiom' is where you put the axiom sources.
This could be anywhere, e.g. '/var/spool/my-long-fancy-name'

The 'linux' portion tells the build process what kind of target
system you want to build for. The various possible target systems
are listed in the top level Makefile.pamphlet (or the Makefile.dvi
generated from that pamphlet file).

Axiom is designed to build with the minimum possible rebuilding
effort. The system is broken into 4 parts: src, int, obj, and mnt.
It is designed so you could put the source and int directories
on a master location and then NFS mount read-only these two
directories. If you do this properly it should be possible to
do a complete build for, say a linux system from the master
location and then doing an NFS mount on a solaris system and
changing the target you can build for solaris. The obj directory
is the only place where system-dependent files live. The src and
int directories are system-independent and can be mounted onto
any type of system.

The mnt directory is a complete, working axiom system. It does
not know where it lives. So the $AXIOM shell variable has a 
second use. At runtime the axiom command looks at the $AXIOM
shell variable to find out where it lives.

So once you build an axiom system in your home directory you can
copy the mnt subdirectory to /usr/local/axiom, set the AXIOM variable to
export AXIOM=/usr/local/axiom/mnt/linux
and now axiom knows where it lives.

Once you build and copy the mnt subdirectory all of the rest of the
axiom build can be erased. Everything needed lives under mnt.

So you can see that the AXIOM shell variable has two different uses,
one at compile time and one at runtime.

As to a configure-make-make install process, that is evolving slowly.
For the algebra portion of axiom the configure process makes no sense
as it is designed primarly for C programs and axiom is written in lisp.
But as I continue to get the C portions of axiom working (like the graphics)
I'll need to build a proper configure.

Hope this helps clear up the confusion.

\start
Date: Tue, 30 Nov 2004 09:55:09 -0500
From: Tim Daly
To: Bill Page, Mike Thomas
Subject: Axiom on Windows

Bill, Mike,

Once I get a tgz of the code pile the plan is to set up an arch
branch with the code. That way the three of us as well as anybody
else who feels inclined can work on the code.

\start
Date: Tue, 30 Nov 2004 11:09:43 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Question about building

On Tuesday, November 30, 2004 10:23 AM C Y wrote:
> 
> If I remember correctly, Axiom needs to know at the start of the
> build process where it is going to be installed.
>
> Gentoo's portage system (package management) builds all programs
> in a temporary directory, and after a successful build moves the
> resulting files to their final location.

The way the Axiom build is setup right now it is just a little non-
standard. If you cd to the directory where you have the Axiom source
and they type

  ./configure

All you will see a message telling you how to set the AXIOM variable
and how to modify the PATH (on linux systems). Unlike the standard
gnu approach, ./configure does not do anything else. It does not
even set these variables. You have to do that manually.

After the variables are set you can do

  make

as normally. However the Axiom Makefile does not include any 'install'
target. You also have to do that manually. You can run Axiom directly
from where it was built, but if you want to, you can copy everything
under the mnt directory where ever you want it on your system, e.g.

  cp -rp mnt /usr/local/axiom

Then of course you have to modify the AXIOM and PATH variables
accordingly. It is usually convenient to do this by modifying
the 'axiom' startup script. Or alternatively you can set these in
your .bashrc file at log in.

> (Basically portage assumes the configure - make - make install
> routine works normally.)

See above. The current Axiom build is not "normal" in this regard.
Anyone feel like submitting a patch to fix it?

> Is there a way an Axiom build can be relocated after it has been
> built,

Yes, see above.

> or is its initial knowledge of its final resting place intrinsic
> to the build?

No. No such problem.

> 
> People were asking about CASs on the gentoo-scientific email list,
> so it brought the question to my mind again.  I would like to create
> an ebuild for axiom, but I'm not quite sure how to make it work with
> what I remember of Axiom's build system.

Great! Please go ahead and set up an ebuild for axiom. If you have
problems ask here.

\start
Date: Tue, 30 Nov 2004 10:09:56 -0500
From: Tim Daly
To: Bill Page, Mike Thomas
Subject: Axiom on Windows

Bill,

Minor correction. In fact, axiom does have a 'make install'.
By default 'make install' will install the mnt subdirectory
into /usr/local/axiom and the axiom command in /usr/local/axiom/bin.

The configure process doesn't do anything yet but it will.
The main reason it doesn't do anything is that there is no
way to set a shell variable from a running program like configure
that survives the program exit (as far as I know). If there were
then the 'configure' script would ask you for the type of system
and automatically set the shell variables for AXIOM and PATH.

\start
Date: Wed, 1 Dec 2004 09:33:11 +1000
From: Mike Thomas
To: Martin Rubey
Subject: RE: Earlier Saturn Query

Hi Martin,

| WOW, this is great, wonderful, brilliant news! RELEASE!

Thanks.  Let's get it organised first and backported to GCL 2.6.5 as used by
Axiom.

\start
Date: Wed, 1 Dec 2004 09:38:34 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: Earlier Saturn Query

Hi Tim.

| I can give you a userid on axiom-developer.org and you take upload
| a tar-gzip file there.

OK, I'm having trouble ftping:

$ ftp ftp.axiom-developer.org
Connected to ftp.axiom-developer.org.
Connection closed by remote host.


Should I be using ssh? (Various public keys attached in case the answer is
yes.)

Cheers

Mike Thomas.

------=_NextPart_000_010C_01C4D789.869FFDA0
	name="id_dsa.pub"
	filename="id_dsa.pub"

ssh-dss =
AAAAB3NzaC1kc3MAAACBAOAkpwjq065savmvaxsjLRqxq8iwwrIqxoSWvsggCAgmIdEwZVVQg=
wkX/T+GLOpNaYAko1uFgGeVMuodc4sYnMMqDJDpqhKx7Q8Ke63v37tkaWO29kOMUl1gx1tKAK=
xBNzhwszuZdLr06obRu2Ougi39fWnEq3Cu0qLUPYdf2LDTAAAAFQDaZx8ECK2SrILc0K5TX7R=
3BeBb4QAAAIAn+zb5zHNSpY7hDLtyxrT1yV1lBEco5rJGxNq0aBdd4/4wu+I1oo/6NbcjXp+h=
ZJY/yVH10rAcubVyEmZO2Cv27xC3O400kqKjyLtT9tQG5qZObfNNXikQP0wL6wwAoVpvFiVAi=
7nkNak2onKEigjokkcL7/Go9sSTdHWyEz6nLgAAAIEAhon3PJziTzesED4hRQvnoZiu+Rbfn/=
/zAJUjf1OJ8BOCtK4qYPBrTGuU/wdSCPwXWtmO7rwlq3zUR4z9TYkMatktt1u7eSeCINmpmNd=
+DHIbfr5I1cOFEkw7BrSkUmZ3mdd8WgbypsJokWZILxMN7VRaqQA8GvQTjnVUK5pLJrg= =
Mike Thomas@SNOWPEA=0A=

------=_NextPart_000_010C_01C4D789.869FFDA0
	name="identity.pub"
	filename="identity.pub"

1024 35 =
1382673706034090484401965082464281844666751751612964233859660706825003437=
8692034137236798630202027688214655903254897711118247772249592884724455972=
4582238744245808018246229426994332804446266188880317837455372860690434051=
3981694463318408576257927991180875928483938522113937265084881623270061866=
57107671629112329 miketh@NASTURTIUM=0A=

------=_NextPart_000_010C_01C4D789.869FFDA0--

\start
Date: Tue, 30 Nov 2004 19:24:39 -0500
From: Tim Daly
To: Mike Thomas
Subject: Re: Earlier Saturn Query

scp local-file-name mthomas@axiom-developer.org:/home/mthomas
 
or if you want to copy subdirs use

scp -pr local-file-name mthomas@axiom-developer.org:/home/mthomas

scp works just like cp except for the url info.

\start
Date: Tue, 30 Nov 2004 21:33:25 -0500
From: Tim Daly
To: Camm Maguire
Subject: pathname-name behavior change

Camm,

I traced the problem in the GCL CVS HEAD that I tried to use.
This is a check of a broken axiom system vs a working axiom using 2.6.5
I know that CVS HEAD is not ready yet but this change will surely 
break axiom.


====================================================================
first we trace the failing axiom function
====================================================================
(1) -> )lisp (trace localdatabase)

Value = (LOCALDATABASE)
(1) -> )library ZMOD

  1> (LOCALDATABASE (ZMOD) NIL)
   )library cannot find the file zmod.
  <1 (LOCALDATABASE #<hash-table 08508d58>)

====================================================================
then we narrow it down to the failing lisp function
====================================================================
(1) -> )lisp (trace pathname-name)

Warning: PATHNAME-NAME is being redefined.
Value = (PATHNAME-NAME)

====================================================================
we load the interpreted localdatabase code
====================================================================
(1) -> )lisp (load "/tmp/axiom/int/interp/daase.lisp")

Value = T

====================================================================
and try the failing function again. Notice that given a symbol the
pathname-name function returns a lowercase string
====================================================================
(1) -> )library ZMOD

  1> (LOCALDATABASE (ZMOD) NIL)
    2> (PATHNAME-NAME ZMOD)
    <2 (PATHNAME-NAME "zmod")
   )library cannot find the file zmod.
  <1 (LOCALDATABASE #<hash-table 08508d58>)

====================================================================
in a working axiom we do the same thing but given a symbol the
pathname-name function returns an uppercase string
====================================================================
(1) -> )library ZMOD

  1> (LOCALDATABASE (ZMOD) NIL)
    2> (PATHNAME-NAME ZMOD)
    <2 (PATHNAME-NAME "ZMOD")
   IntegerMod is now explicitly exposed in frame initial 
   IntegerMod will be automatically loaded when needed from 
      /tmp/axiom/int/algebra/ZMOD.NRLIB/code
  <1 (LOCALDATABASE #<hash-table 0837e118>)

(1) -> 

\start
Date: Tue, 30 Nov 2004 21:47:54 -0500
From: Stephen Wilson
To: Tim Daly
Subject: Re: pathname-name behavior change
Cc: Camm Maguire

Hello,


>     2> (PATHNAME-NAME ZMOD)
>     <2 (PATHNAME-NAME "zmod")

Aside from the case problem, this seems strange in that pathname-name
is supposed to take only a string, a stream, or a pathname object as
argument -- not a symbol -- according to the Hyperspec. CMUCL, for
example, agrees on this.

\start
Date: Tue, 30 Nov 2004 22:50:22 -0500
From: Tim Daly
To: Stephen Wilson
Subject: Re: pathname-name behavior change
Cc: Camm Maguire

Steve,

CLtL Ref Manual ISBN 0-932376-41-X p413

"Any argument called pathname in this manual may actually be a
pathname, a string or symbol, or a stream."

has this changed?

\start
Date: Tue, 30 Nov 2004 23:06:46 -0500
From: Stephen Wilson
To: Tim Daly
Subject: Re: pathname-name behavior change

Tim,

>From my electronic copy of CLtl 2nd edition:

X3J13 voted in March 1988 (PATHNAME-SYMBOL)   to change the language
so that a symbol is never allowed as a pathname argument. More
specifically, the following functions are changed to disallow a symbol
as a pathname argument:

pathname          pathname-device     namestring 
truename          pathname-directory  file-namestring 
parse-namestring  pathname-name       directory-namestring 
merge-pathnames   pathname-type       host-namestring 
pathname-host     pathname-version    enough-namestring


Sincerely,
Steve

On Tue, Nov 30, 2004 at 10:50:22PM -0500, root wrote:
> Steve,
> 
> CLtL Ref Manual ISBN 0-932376-41-X p413
> 
> "Any argument called pathname in this manual may actually be a
> pathname, a string or symbol, or a stream."
> 
> has this changed?

\start
Date: Tue, 30 Nov 2004 23:17:29 -0500
From: Stephen Wilson
To: Tim Daly
Subject: Re: pathname-name behavior change
Cc: Camm Maguire

Tim,

   Here is a working link to the relevent page in CLtL:

    http://www.supelec.fr/docs/cltl/clm/node214.html

   And in the Hyperspec, the definition of a pathname designator:

    http://www.lispworks.com/reference/HyperSpec/Body/26_glo_p.htm#pathname_designator

Steve

On Tue, Nov 30, 2004 at 11:06:46PM -0500, Stephen Wilson wrote:
> 
> Tim,
> 
> >From my electronic copy of CLtl 2nd edition:
> 
> X3J13 voted in March 1988 (PATHNAME-SYMBOL)   to change the language
> so that a symbol is never allowed as a pathname argument. More
> specifically, the following functions are changed to disallow a symbol
> as a pathname argument:
> 
> pathname          pathname-device     namestring 
> truename          pathname-directory  file-namestring 
> parse-namestring  pathname-name       directory-namestring 
> merge-pathnames   pathname-type       host-namestring 
> pathname-host     pathname-version    enough-namestring
> 
> 
> Sincerely,
> Steve
> 
> On Tue, Nov 30, 2004 at 10:50:22PM -0500, root wrote:
> > Steve,
> > 
> > CLtL Ref Manual ISBN 0-932376-41-X p413
> > 
> > "Any argument called pathname in this manual may actually be a
> > pathname, a string or symbol, or a stream."
> > 
> > has this changed?




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