diff --git a/book/2004-11.txt b/book/2004-11.txt new file mode 100644 index 0000000..e38dcb7 --- /dev/null +++ b/book/2004-11.txt @@ -0,0 +1,13108 @@ +\start +Date: Mon, 1 Nov 2004 09:51:22 -0500 +From: Tim Daly +To: mark@grondar.org +Subject: [Axiom-developer] PREFIX question +Cc: axiom-developer@nongnu.org, daly@idsi.net + +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: [Axiom-developer] 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 + + +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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: daly@idsi.net +Subject: [Axiom-developer] FreeBSD patches +Cc: axiom-developer@nongnu.org + +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 after other +standard headers, because those headers often depend on . +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 @@ + <> + + @ ++\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]]. ++<>= ++# 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 ++ ++<> ++<> ++<> ++<> ++<> ++<> ++<> ++<> ++ ++@ + \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]]. + <>= + # 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} ++<>= ++# 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 @@ + + <>= + 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 @@ + + <> + ++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. + + <>= +-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 + + <> ++ ++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} + <>= + @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} + + <> + <> +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 + #include + #include ++#if !defined(FREEBSDplatform) && !defined(MACOSXplatform) + #include ++#endif + #include + #include + #include +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 + + <> + <> +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 @@ + <>= + ${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 @@ + <> + + <> ++ ++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} + <>= + (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. + <>= +@@ -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} + <>= + (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} + <>= ++${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 + #include ++#if !defined(FREEBSDplatform) && !defined(MACOSXplatform) + #include ++#endif + + #include + #include +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 +-#include + #include ++#if !defined(FREEBSDplatform) && !defined(MACOSXplatform) ++#include ++#endif + + #include + #include +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. +-<>= +-#if defined(LINUXplatform) || defined (ALPHAplatform)|| defined(RIOSplatform) || defined(SUN4OS5platform) ||defined(SGIplatform) ||defined(HP10platform) || defined(MACOSXplatform) +-@ + \section{License} + <>= + /* +@@ -74,7 +67,7 @@ + struct sigaction in,out; + in.sa_handler = action; + /* handler is reinstalled - calls are restarted if restartSystemCall */ +-<> ++#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 + #include + #include +-#include + #include + #include ++#if !defined(FREEBSDplatform) && !defined(MACOSXplatform) ++#include ++#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. +-<>= +-#if defined(MACOSXplatform) +- bsdSignal(SIGCHLD, null_fnct,RestartSystemCalls); +-#else +- bsdSignal(SIGCLD, null_fnct,RestartSystemCalls); +-#endif +-@ + \section{License} + <>= + /* +@@ -364,7 +352,11 @@ + close(fd); + } + } +-<> ++#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. +-<>= +-#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(MACOSXplatform) +-@ +-<>= +-#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) +-@ + \section{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 + +-<> ++#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 +-<> ++#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} + + <> ++ ++clean: ++ + @ + \eject + \begin{thebibliography}{99} + + +\start +Date: Sat, 30 Oct 2004 10:12:53 +0100 +From: Mark Murray +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] FreeBSD patches + +This is a multipart MIME message. + +--==_Exmh_-7609217490 +Content-Type: text/plain; charset=us-ascii + +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 after other standard +headers, because those headers often depend on . 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 +Content-Type: text/plain ; name="Axiom.diff"; charset=us-ascii +Content-Description: Axiom.diff +Content-Disposition: attachment; filename="Axiom.diff" + +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 @@ + <> + + @ ++\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]]. ++<>= ++# 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 ++ ++<> ++<> ++<> ++<> ++<> ++<> ++<> ++<> ++ ++@ + \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]]. + <>= + # 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} ++<>= ++# 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 @@ + + <>= + 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 @@ + + <> + ++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. + + <>= +-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 + + <> ++ ++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} + <>= + @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} + + <> + <> +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 + #include + #include ++#if !defined(FREEBSDplatform) && !defined(MACOSXplatform) + #include ++#endif + #include + #include + #include +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 + + <> + <> +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 @@ + <>= + ${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 @@ + <> + + <> ++ ++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} + <>= + (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. + <>= +@@ -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} + <>= + (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} + <>= ++${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 + #include ++#if !defined(FREEBSDplatform) && !defined(MACOSXplatform) + #include ++#endif + + #include + #include +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 +-#include + #include ++#if !defined(FREEBSDplatform) && !defined(MACOSXplatform) ++#include ++#endif + + #include + #include +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. +-<>= +-#if defined(LINUXplatform) || defined (ALPHAplatform)|| defined(RIOSplatform) || defined(SUN4OS5platform) ||defined(SGIplatform) ||defined(HP10platform) || defined(MACOSXplatform) +-@ + \section{License} + <>= + /* +@@ -74,7 +67,7 @@ + struct sigaction in,out; + in.sa_handler = action; + /* handler is reinstalled - calls are restarted if restartSystemCall */ +-<> ++#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 + #include + #include +-#include + #include + #include ++#if !defined(FREEBSDplatform) && !defined(MACOSXplatform) ++#include ++#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. +-<>= +-#if defined(MACOSXplatform) +- bsdSignal(SIGCHLD, null_fnct,RestartSystemCalls); +-#else +- bsdSignal(SIGCLD, null_fnct,RestartSystemCalls); +-#endif +-@ + \section{License} + <>= + /* +@@ -364,7 +352,11 @@ + close(fd); + } + } +-<> ++#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. +-<>= +-#if defined(SUN4OS5platform) ||defined(ALPHAplatform) || defined(HP10platform) || defined(LINUXplatform) || defined(MACOSXplatform) +-@ +-<>= +-#if defined(SUNplatform) || defined(HP9platform) || defined(LINUXplatform) || defined(MACOSXplatform) +-@ + \section{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 + +-<> ++#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 +-<> ++#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} + + <> ++ ++clean: ++ + @ + \eject + \begin{thebibliography}{99} + +--==_Exmh_-7609217490-- + +\start +Date: Tue, 2 Nov 2004 12:52:50 +0100 (CET) +From: Bertfried Fauser +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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 +From: "Page, Bill" +To: "'Bertfried.Fauser@uni-konstanz.de'" +Date: Tue, 2 Nov 2004 10:42:46 -0500 +Subject: RE: [Axiom-developer] 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----- +> From: Bertfried Fauser [mailto:fauser@spock.physik.uni-konstanz.de] +> Sent: Tuesday, November 02, 2004 6:53 AM +> To: axiom-developer@nongnu.org +> Subject: [Axiom-developer] Installing AXIOM on Mandrake +> +> +> 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) +> +> 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: [Axiom-developer] 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 +From: Camm Maguire +Date: 02 Nov 2004 12:14:47 -0500 +To: Magnus Larsson +Subject: Re: [Axiom-developer] 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@uni-konstanz.de +Subject: Re: [Axiom-developer] 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: "Page, Bill" +Subject: RE: [Axiom-developer] 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: "Page, Bill" +To: "'aisaac@american.edu'" +Subject: [Axiom-developer] 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: "Page, Bill" +To: 'Martin Rubey' +Subject: RE: [Axiom-developer] 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----- +> From: Martin Rubey [mailto:martin.rubey@univie.ac.at] +> Sent: Tuesday, November 02, 2004 11:56 AM +> To: Page, Bill +> Subject: RE: [Axiom-developer] Installing AXIOM on Mandrake +> +> +> 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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: C Y +To: "Andrey G. Grozin" , Christopher Chamber +Subject: Re: [Axiom-developer] 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: daly@idsi.net +Subject: [Axiom-developer] Active arch braches listed somewhere? + +Greetings! Just wondering. + +\start +Date: Wed, 3 Nov 2004 09:32:33 -0500 +From: Tim Daly +To: camm@enhanced.com +Subject: [Axiom-developer] 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: "Page, Bill" +To: 'C Y' +Subject: RE: [Axiom-developer] LaTeX output + +On Wednesday, November 03, 2004 8:12 AM C Y +smustudent1@yahoo.com 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: "Page, Bill" +To: 'Tim Daly' +Subject: RE: [Axiom-developer] Active arch branches listed somewhere? + +Tim, + +On Wednesday, November 03, 2004 9:25 AM Camm Maguire +wrote: + +> Subject: [Axiom-developer] 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: "Page, Bill" +To: 'Tim Daly' +Subject: RE: [Axiom-developer] 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@drdc-rddc.gc.ca +Subject: Re: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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: + +dmentre@linux-france.org--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: [Axiom-developer] 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: "Page, Bill" +To: "'Andrey G. Grozin'" +Subject: RE: [Axiom-developer] 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: [Axiom-developer] 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@enhanced.com, Bill.Page@drdc-rddc.gc.ca +Subject: [Axiom-developer] 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: C Y +To: Camm Maguire , Tim Daly +Subject: Re: [Axiom-developer] 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: [Axiom-developer] 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: smustudent1@yahoo.com +Subject: Re: [Axiom-developer] 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: C Y +Subject: Re: [Axiom-developer] 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: C Y +To: Tim Daly +Subject: Re: [Axiom-developer] Active arch branches listed somewhere? +Cc: camm@enhanced.com + +--- 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: smustudent1@yahoo.com +Subject: Re: [Axiom-developer] Active arch branches listed somewhere? +Cc: camm@enhanced.com + +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: "'C Y'" +Subject: RE: [Axiom-developer] 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: [Axiom-developer] 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----- +> From: +> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> .org] On Behalf Of Pierre Doucy +> Sent: Thursday, November 04, 2004 11:43 AM +> To: Camm Maguire +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] 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. +> > > +> > + +> -----Original Message----- +> From: +> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> .org] On Behalf Of Tim Daly +> Sent: Wednesday, November 03, 2004 12:27 PM +> To: Bill.Page@drdc-rddc.gc.ca +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] 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. +> + +> -----Original Message----- +> From: +> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> .org] On Behalf Of Tim Daly +> Sent: Thursday, November 04, 2004 11:01 AM +> To: smustudent1@yahoo.com +> Cc: camm@enhanced.com; axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] Active arch branches listed somewhere? +> ... + +>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: [Axiom-developer] 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: +dmentre@linux-france.org--2004-code + /home/david/{archives}/2004-code + +# the copy of this repository on linux-france.org: +dmentre@linux-france.org--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: + + +--=-=-= +Content-Disposition: inline; filename=hook +Content-Description: arch hook + +#!/bin/sh + +# Original script from: Sascha Silbe + +# 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: daly@idsi.net +Subject: Re: [Axiom-developer] CVS, Arch, Darcs +Cc: camm@enhanced.com, Bill.Page@drdc-rddc.gc.ca + +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: "cf" +To: +Subject: [Axiom-developer] (no subject) +Cc: axiom-math@nongnu.org + +12 November 2004 + +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 ?? + +Yours sincerely, + +C. Frangos. + +------ +Constantine Frangos. +Professor +Dept. of Mathematics and Statistics +Rand Afrikaans University +P O Box 524 +Auckland Park 2006 +South Africa + +Tel: +27-11-489-2452 +Fax: +27-11-489-2832 +e-mail: cf@rau.ac.za (work) + cfrangos@telkomsa.net (home) + +\start +Date: Fri, 12 Nov 2004 10:16:20 -0500 +From: root +To: cfrangos@telkomsa.net +Subject: [Axiom-developer] 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 "daly@idsi.net" and I can try to figure out +what failed. + +\start +Date: Sun, 14 Nov 2004 17:38:54 +1100 +From: Jason White +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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: root +To: cfrangos@telkomsa.net +Subject: [Axiom-developer] 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: root +To: cfrangos@telkomsa.net +Subject: [Axiom-developer] 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 "daly@idsi.net" and copy the list + "axiom-developer@nongnu.org": + +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: Tue, 16 Nov 2004 17:17:24 -0400 +From: SunTrust +To: Axiom-developer +Subject: [Axiom-developer] Internet Banking with Bill Pay Fees Waived + + + + + + + + + + + + + + +
+

 

+

Dear SunTrust Bank Customer,

+ +

SunTrust Internet Banking with Bill Pay has become even better. We are + waiving monthly fees for SunTrust Internet Banking with Bill Pay and SunTrust + PC Banking with Bill Pay for all our clients.

+

As an additional security measure, you need to activate this new feature + by signing on to Internet + Banking. Please verify your preferred email address and the information + that SunTrust uses to confirm your identity.

+

In the Update Internet Banking service area you can also view the accounts + you currently have tied to your Internet Banking service, to view whether + Bill Pay is enabled on a particular account, and to request other accounts + to be added to your Internet Banking service.

+

To do so, simply sign on + to Internet Banking.
+
+

+ +

 

+

SunTrust Internet Banking
+

+
+gutenberg farce pizzicato towboat estop magnet physic vanish charlotte batavia catlike wigmake essay astigmatic emblazon bigot earthshaking checkerboard officialdom budget abound autonomic deprecate + +\start +Date: Wed, 17 Nov 2004 09:30:51 -0500 +From: root +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] superman +Cc: gilbert@sci.ccny.cuny.edu + +*, + +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 'daly@idsi.net' 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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: RE: [Axiom-developer] superman +Cc: gilbert@sci.ccny.cuny.edu + +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:daly@idsi.net] +> Sent: Wednesday, November 17, 2004 9:31 AM +> To: axiom-developer@nongnu.org +> Cc: gilbert@sci.ccny.cuny.edu; daly@idsi.net +> Subject: [Axiom-developer] 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: daly@idsi.net +Subject: Re: [Axiom-developer] superman +Cc: gilbert@sci.ccny.cuny.edu + +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, + +root 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 'daly@idsi.net' 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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: Urban Legends (was: [Axiom-developer] 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----- +> From: Page, Bill [mailto:Bill.Page@drdc-rddc.gc.ca] +> Sent: Wednesday, November 17, 2004 9:30 AM +> To: 'daly@idsi.net' +> Cc: gilbert@sci.ccny.cuny.edu; axiom-developer@nongnu.org +> Subject: RE: [Axiom-developer] superman +> +> 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:daly@idsi.net] +> > Sent: Wednesday, November 17, 2004 9:31 AM +> > To: axiom-developer@nongnu.org +> > Cc: gilbert@sci.ccny.cuny.edu; daly@idsi.net +> > Subject: [Axiom-developer] 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: daly@idsi.net +Subject: Re: [Axiom-developer] CVS, Arch, Darcs +Cc: Bill.Page@drdc-rddc.gc.ca + +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: axiom-developer@nongnu.org, gilbert@sci.ccny.cuny.edu +Subject: [Axiom-developer] 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@enhanced.com +Subject: [Axiom-developer] call for papers +Cc: gilbert@sci.ccny.cuny.edu + +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: "Page, Bill" +To: 'Tim Daly' +Subject: [Axiom-developer] development on Savannah +Cc: camm@enhanced.com + +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----- +> From: Tim Daly [mailto:daly@rio.sci.ccny.cuny.edu] +> Sent: Wednesday, November 17, 2004 9:33 AM +> To: camm@enhanced.com +> Cc: gilbert@sci.ccny.cuny.edu; axiom-developer@nongnu.org; +> daly@idsi.net +> Subject: [Axiom-developer] call for papers +> +> 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@enhanced.com +Subject: [Axiom-developer] breathtaking vision +Cc: gilbert@sci.ccny.cuny.edu + +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@drdc-rddc.gc.ca +Subject: [Axiom-developer] savannah webcvs +Cc: gilbert@sci.ccny.cuny.edu + +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: "Page, Bill" +To: 'Tim Daly' +Subject: [Axiom-developer] RE: savannah webcvs +Cc: "Page, Bill" + +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: daly@idsi.net +Subject: Re: [Axiom-developer] superman +Cc: gilbert@sci.ccny.cuny.edu + +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, + +root 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 'daly@idsi.net' 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 \(E-mail\)" +Subject: Re: [Axiom-developer] RE: Wikis +Cc: "Page, Bill" + +What's wrong with the Wiki we have? + +\start +Date: Wed, 17 Nov 2004 12:06:16 -0500 +From: "Page, Bill" +To: 'Martin Rubey' , "Bill Page (E-mail)" +Subject: RE: [Axiom-developer] RE: Wikis +Cc: "Page, Bill" + +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 ... + +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----- +> From: Martin Rubey [mailto:martin.rubey@univie.ac.at] +> Sent: Wednesday, November 17, 2004 12:01 PM +> To: Bill Page (E-mail) +> Cc: 'Tim Daly'; axiom-developer@nongnu.org; Page, Bill; daly@idsi.net +> Subject: Re: [Axiom-developer] RE: Wikis +> +> +> What's wrong with the Wiki we have? + +\start +Date: Wed, 17 Nov 2004 12:18:26 -0500 +From: Tim Daly +To: camm@enhanced.com +Subject: [Axiom-developer] 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 (E-mail)" +Subject: [Axiom-developer] Re: Wikis +Cc: zwiki@zwiki.org, "Page, Bill" + +Page, Bill [Bill.Page@drdc-rddc.gc.ca] 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: "Page, Bill" +To: 'Bob McElrath' , "Bill Page (E-mail)" +Subject: [Axiom-developer] RE: Wikis +Cc: "Page, Bill" , zwiki@zwiki.org + +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.page1@sympatico.ca +Subject: [Axiom-developer] Re: Wikis +Cc: "Page, Bill" , zwiki@zwiki.org + +Page, Bill [Bill.Page@drdc-rddc.gc.ca] 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: "Page, Bill" +To: 'Bob McElrath' +Subject: [Axiom-developer] bounties +Cc: bill.page1@sympatico.ca, zwiki@zwiki.org + +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----- +From: Bob McElrath [mailto:bob+zwiki@mcelrath.org] +Sent: Wednesday, November 17, 2004 3:33 PM +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org; Page, Bill; zwiki@zwiki.org +Subject: Re: Wikis + + +Page, Bill [Bill.Page@drdc-rddc.gc.ca] 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: [Axiom-developer] 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: "Page, Bill" +To: 'Camm Maguire' +Subject: RE: [Axiom-developer] 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.page1@sympatico.ca +Subject: [Axiom-developer] Re: bounties +Cc: shess@lifshitz.physics.ucdavis.edu, "Page, Bill" , zwiki@zwiki.org + +Page, Bill [Bill.Page@drdc-rddc.gc.ca] 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: root +To: camm@enhanced.com +Subject: [Axiom-developer] 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: dpt@lotus.bostoncoop.net (Dylan Thurston) +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: dpt@math.harvard.edu +Subject: Re: [Axiom-developer] 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: "Weiss, Juergen" +To: "Camm Maguire" +Subject: RE: [Axiom-developer] CVS, Arch, Darcs +Cc: Bill.Page@drdc-rddc.gc.ca + +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----- +> From: axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org +> [mailto:axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org] +> On Behalf Of Camm Maguire +> Sent: Wednesday, November 17, 2004 4:20 PM +> To: daly@idsi.net +> Cc: Bill.Page@drdc-rddc.gc.ca; axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] CVS, Arch, Darcs +> +> 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: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] 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: root +To: weiss@uni-mainz.de +Subject: Re: [Axiom-developer] CVS, Arch, Darcs +Cc: camm@enhanced.com, Bill.Page@drdc-rddc.gc.ca + +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: root +To: martin.rubey@univie.ac.at +Subject: Re: [Axiom-developer] 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: +Subject: RE: [Axiom-developer] CVS, Arch, Darcs +Cc: camm@enhanced.com + +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: root +Subject: Re: [Axiom-developer] CVS, Arch, Darcs / bounties + +root [daly@idsi.net] 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: +Subject: [Axiom-developer] 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: "'root'" +Subject: [Axiom-developer] 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: root +To: bill.page1@sympatico.ca +Subject: [Axiom-developer] 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: [Axiom-developer] Re: proposal to create the Axiom Foundation (was: bounties etc.) +Cc: 'Camm Maguire' + +Bill Page [bill.page1@sympatico.ca] 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: [Axiom-developer] 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: [Axiom-developer] 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: root +To: cfrangos@telkomsa.net +Subject: [Axiom-developer] 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 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@enhanced.com +Subject: [Axiom-developer] [gemi@bluewin.ch: Axiom on FC3] +Cc: gemi@bluewin.ch + +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. + +Gérard, + +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 + +------- Start of forwarded message ------- +Subject: Axiom on FC3 +From: =?ISO-8859-1?Q?G=E9rard?= Milmeister +To: daly@rio.sci.ccny.cuny.edu +Date: Fri, 19 Nov 2004 02:24:38 +0100 + +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: root +To: acl2@lists.cc.utexas.edu +Subject: [Axiom-developer] Re: order of arguments of (choose k n) in books/arithmetic/binomial.lisp +Cc: acl2@lists.cc.utexas.edu + +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: daly@idsi.net +Subject: [Axiom-developer] Re: [gemi@bluewin.ch: Axiom on FC3] +Cc: gemi@bluewin.ch + +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: G=E9rard Milmeister +> Subject: Axiom on FC3 +> To: daly@rio.sci.ccny.cuny.edu +> Date: Fri, 19 Nov 2004 02:24:38 +0100 +> +> 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: [Axiom-developer] 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: daly@idsi.net +Subject: Re: [Axiom-developer] Calculemus + +Greetings! + +root 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: axiomlegal.com@rio.sci.ccny.cuny.edu +Subject: [Axiom-developer] 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@axiomlegal.com +Subject: [Axiom-developer] 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: [Axiom-developer] 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<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<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' , "\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 , 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 , cf_data = = +0x0}, cc = { +> t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', cc_name= + = 0x0, +> cc_self = 0x8383798 , 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 , 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 , 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 , 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 , +> multiple_definition = 0x806e3e2 , +> multiple_common = 0x806e3ec , add_to_set = 0x806e= +3f6 , +> constructor = 0x806e400 , warning = 0x806e40a , +> undefined_symbol = 0x806e414 , +> reloc_overflow = 0x806e434 , +> reloc_dangerous = 0x806e454 , +> unattached_reloc = 0x806e474 , notice = 0x806e47= +e } +> 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 , 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 , 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: root +To: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] arch server support +Cc: gilbert@sci.ccny.cuny.edu + +*, + +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: [Axiom-developer] 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<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<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<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<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' , "\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 , 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 , cf_data = += 0x0}, cc = { +> > t = 16 '\020', flag = 0 '\0', s = 0 '\0', m = 0 '\0', cc_na= +me = 0x0, +> > cc_self = 0x8383798 , 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 , 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 , 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 , 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 , +> > multiple_definition = 0x806e3e2 , +> > multiple_common = 0x806e3ec , add_to_set = 0x80= +6e3f6 , +> > constructor = 0x806e400 , warning = 0x806e40a , +> > undefined_symbol = 0x806e414 , +> > reloc_overflow = 0x806e434 , +> > reloc_dangerous = 0x806e454 , +> > unattached_reloc = 0x806e474 , notice = 0x806e= +47e } +> > 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 , 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 , 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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] RE: [Axiom-mail] arch server support +Cc: gilbert@sci.ccny.cuny.edu + +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: root +To: camm@enhanced.com +Subject: Re: [Axiom-developer] Re: [Gcl-devel] changes in binutils break gcl +Cc: mkennedy@gentoo.org + +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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] 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 +To: Camm Maguire +Subject: [Axiom-developer] Re: [gemi@bluewin.ch: 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: root +To: Bill.Page@drdc-rddc.gc.ca +Subject: [Axiom-developer] Re: [Axiom-mail] arch server support +Cc: gilbert@sci.ccny.cuny.edu + +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: root +To: bill.page1@sympatico.ca +Subject: [Axiom-developer] Re: axiom--hyperdoc--1 branch +Cc: gilbert@sci.ccny.cuny.edu + +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: daly@idsi.net +Subject: Re: [Axiom-developer] Re: [Gcl-devel] changes in binutils break gcl +Cc: mkennedy@gentoo.org + +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<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<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) +============================================================================= +============================================================================= +root 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: root +To: bill.page1@sympatico.ca +Subject: [Axiom-developer] Re: axiom--main--1 +Cc: gilbert@sci.ccny.cuny.edu + +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 +Subject: [Axiom-developer] Re: [gemi@bluewin.ch: Axiom on FC3] + +Greetings! + +G=E9rard 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<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<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: root +To: gemi@bluewin.ch +Subject: [Axiom-developer] Re: [gemi@bluewin.ch: Axiom on FC3] +Cc: camm@enhanced.com, gilbert@sci.ccny.cuny.edu + +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: root +To: gemi@bluewin.ch +Subject: [Axiom-developer] Re: [gemi@bluewin.ch: Axiom on FC3] +Cc: camm@enhanced.com, gilbert@sci.ccny.cuny.edu + +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: root +To: camm@enhanced.com +Subject: Re: [Axiom-developer] Re: [Gcl-devel] changes in binutils break gcl +Cc: mkennedy@gentoo.org + +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: root +To: wyscc@cunyvm.cuny.edu +Subject: [Axiom-developer] 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: root +To: camm@enhanced.com +Subject: [Axiom-developer] 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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] 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: [Axiom-developer] 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: Martin Rubey +Subject: [Axiom-developer] Re: proposal to create the Axiom Foundation (was: bounties etc.) +Cc: Camm Maguire , 'Bob McElrath' , Bill Page , daly@idsi.net + +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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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) +<>= +SPD=$(shell pwd) +SYS=$(notdir $(AXIOM)) +SPAD=${SPD}/mnt/${SYS} +LSP=${SPD}/lsp +<> +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 <> 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: daly@idsi.net +Subject: [Axiom-developer] 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, + +root 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: root +To: cfm@ms.unimelb.edu.au +Subject: [Axiom-developer] 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: root +To: mark@grondar.org +Subject: [Axiom-developer] 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: "Page, Bill" +To: 'Martin Rubey' +Subject: [Axiom-developer] 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: root +To: ko@research.att.com, camm@enhanced.com +Subject: Re: [Axiom-developer] 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 <> 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: root +To: Bill.Page@drdc-rddc.gc.ca +Subject: Re: [Axiom-developer] RE: proposal to create the Axiom Foundation (was: bounties etc.) +Cc: bill.page1@sympatico.ca, camm@enhanced.com, bob@mcelrath.org + +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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] RE: proposal to create the Axiom Foundation (was: bounties etc.) +Cc: axiom-developer@nongnu.org + +Thanks very much Tim. You really *are* too generous in your +personal support of this project! :)) + +On Thursday, November 25, 2004 5:55 PM root daly@idsi.net +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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] Lulu publishing +Cc: camm@enhanced.com, bill.page1@sympatico.ca, bob@mcelrath.org + +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. + +References: + +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: root +To: bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] Lulu publishing +Cc: camm@enhanced.com, bob@mcelrath.org, bill.page1@sympatico.ca + +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: daly@idsi.net +Subject: [Axiom-developer] 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: root +Subject: Re: [Axiom-developer] Lulu publishing +Cc: camm@enhanced.com, bill.page1@sympatico.ca, bob@mcelrath.org + +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: "Page, Bill" +To: camm@enhanced.com, bob@mcelrath.org, 'Martin Rubey' +Subject: [Axiom-developer] [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu +Cc: 'Mike Dewar' , bill.page1@sympatico.ca + +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: "Page, Bill" +To: "'camm@enhanced.com'" , "'bob@mcelrath.org'" , 'Martin Rubey' +Subject: [Axiom-developer] RE: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu +Cc: 'Mike Dewar' , "'bill.page1@sympatico.ca'" + +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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] arch@axiom-developer.org--axiom archive http access +Cc: "'bill.page1@sympatico.ca'" + +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: root +To: bill.page1@sympatico.ca +Subject: [Axiom-developer] Re: arch@axiom-developer.org--axiom archive http access +Cc: bill.page1@sympatico.ca + +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: root +To: bill.page1@sympatico.ca +Subject: [Axiom-developer] Re: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu +Cc: bill.page1@sympatico.ca, camm@enhanced.com, miked@nag.co.uk, bob@mcelrath.org + +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: root +To: miked@nag.co.uk +Subject: Re: [Axiom-developer] Lulu publishing +Cc: camm@enhanced.com, bob@mcelrath.org, bill.page1@sympatico.ca + +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: root +To: markm@FreeBSD.org +Subject: Re: [Axiom-developer] 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: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] MathAction web stats +Cc: "'camm@enhanced.com'" , bill.page1@sympatico.ca, "'bob@mcelrath.org'" + +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: daly@idsi.net +Subject: [Axiom-developer] Re: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu +Cc: bill.page1@sympatico.ca, camm@enhanced.com, miked@nag.co.uk, bob@mcelrath.org + +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: [Axiom-developer] 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| # 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| # 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: root +To: wilsons@multiboard.com +Subject: [Axiom-developer] Re: [Axiom-mail] Function returning UnivariateTaylorSeries +Cc: marcusb@math.su.se + +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) +To: daly@idsi.net, bill.page1@sympatico.ca +From: C Y +Subject: Re: [Axiom-developer] Re: [AxiomFoundation] publishing of "Axiom - The 30 Year Horizon" at Lulu +Cc: bill.page1@sympatico.ca, camm@enhanced.com, miked@nag.co.uk, bob@mcelrath.org + +--- root 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: C Y +Subject: [Axiom-developer] ISBNs... +Cc: bill.page1@sympatico.ca, camm@enhanced.com, miked@nag.co.uk, bob@mcelrath.org + +>> 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: root +To: acn1@cam.ac.uk +Subject: [Axiom-developer] Re: ISBNs... +Cc: bill.page1@sympatico.ca, camm@enhanced.com, miked@nag.co.uk, bob@mcelrath.org + +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: root +To: Bill.page1@sympatico.ca +Subject: [Axiom-developer] publishing the axiom book +Cc: gilbert@sci.ccny.cuny.edu, axiom-math@nongnu.org, camm@enhanced.com, miked@nag.co.uk, bob@mcelrath.org + +*, + +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 " +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 daly@idsi.net + +(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: root +To: ko@research.att.com +Subject: Re: [Axiom-developer] 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-developer] 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: root +To: ko@research.att.com +Subject: Re: [Axiom-developer] Building Axiom 11/15/2004 on Solaris 9 Sparc +Reply-To: daly@idsi.net + +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: +Subject: RE: [Axiom-developer] 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: root +To: ko@research.att.com, camm@enhanced.com +Subject: Re: [Axiom-developer] 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: root +Subject: [Axiom-developer] 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 = # + +(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| #) + 2> (|UnivariateTaylorSeries;| # %B (0 . 0)) <--- *** PROPER ! + <2 (|UnivariateTaylorSeries;| #) + <1 (|FOO;bar;Uts;1| ((0 . 0) "NonNullStream" # . #)) + 1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial| + (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream" + # . #) + (|UnivariateTaylorSeries| (|Polynomial| (|Integer|)) %B 0)) + <1 (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial| + (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream" + # . #)) + 1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial| + (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream" + # . #) + (|UnivariateTaylorSeries| (|Polynomial| (|Integer|)) %B 0)) + <1 (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial| + (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream" + # . #)) + + 1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial| + (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream" + # . #) + (|OutputForm|)) + 2> (|UnivariateTaylorSeries;| # %B 0) <--- *** IMPROPER ! + <2 (|UnivariateTaylorSeries;| #) + + >> 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: root +To: gianni@dm.unipi.it, Bertfried Fauser +Subject: [Axiom-developer] 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: ko@research.att.com +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: thomas.1037@osu.edu +Subject: Re: [Axiom-developer] sman: fails to start + +Try + +sman -nonag -noht -noclef + +\start +Date: Mon, 29 Nov 2004 17:35:44 -0500 +From: root +To: thomas.1037@osu.edu +Subject: Re: [Axiom-developer] sman: fails to start + +Try + +sman -nonag -noht -noclef + +\start +Date: Mon, 29 Nov 2004 17:40:38 -0500 +From: root +To: thomas.1037@osu.edu +Subject: Re: [Axiom-developer] 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: root +To: thomas.1037@osu.edu +Subject: Re: [Axiom-developer] 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: [Axiom-developer] 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: [Axiom-developer] 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) +> <>= +> SPD=$(shell pwd) +> SYS=$(notdir $(AXIOM)) +> SPAD=${SPD}/mnt/${SYS} +> LSP=${SPD}/lsp +> <> +> 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 <> 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: [Axiom-developer] 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: daly@idsi.net +Subject: Re: [Axiom-developer] Building Axiom 11/15/2004 on Solaris 9 Sparc +Cc: ko@research.att.com + +Greetings! + +root 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: daly@idsi.net +Subject: Re: [Axiom-developer] Building Axiom 11/15/2004 on Solaris 9 Sparc +Cc: ko@research.att.com + +Greetings! + +root 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: [Axiom-developer] 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: root +To: mike.thomas@brisbane.paradigmgeo.com +Subject: Re: [Axiom-developer] RE: [Gcl-devel] ANSI test Windows OPEN.*failures +Cc: camm@enhanced.com, mthomas@gil.com.au + +Mike, + +You have a windows port of axiom in semi-working condition? + +\start +Date: Mon, 29 Nov 2004 22:04:00 -0500 +From: root +To: camm@enhanced.com +Subject: Re: [Axiom-developer] Building Axiom 11/15/2004 on Solaris 9 Sparc +Cc: ko@research.att.com + +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: +Subject: RE: [Axiom-developer] RE: [Gcl-devel] ANSI test Windows OPEN.*failures +Cc: camm@enhanced.com, mthomas@gil.com.au + +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: +Subject: [Axiom-developer] 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: root +To: mike.thomas@brisbane.paradigmgeo.com +Subject: Re: [Axiom-developer] RE: [Gcl-devel] ANSI test Windows OPEN.*failures +Cc: camm@enhanced.com, mthomas@gil.com.au + +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: +Subject: RE: [Axiom-developer] RE: [Gcl-devel] ANSI test Windows OPEN.*failures +Cc: mthomas@gil.com.au + +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 axiom-developer@nongnu.org. +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: "Mike Thomas" , +Subject: RE: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: [Axiom-developer] 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: root +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: [Axiom-developer] 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: root +To: mike.thomas@brisbane.paradigmgeo.com +Subject: Re: [Axiom-developer] Earlier Saturn Query +Cc: mike.thomas@brisbane.paradigmgeo.com + +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: [Axiom-developer] 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)) +----------------------------------------------------------------- + +-- +----------------------------------------------------------------- +Marcus Better +Department of Mathematics Tel. +46 8 164539 +Stockholm University Fax +46 8 6126717 +SE-106 91 Stockholm +Sweden http://www.math.su.se +----------------------------------------------------------------- + +\start +Date: Tue, 30 Nov 2004 07:23:28 -0800 (PST) +From: C Y +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: smustudent1@yahoo.com +Subject: [Axiom-developer] 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.page1@enhanced.com, mthomas@gil.com.au +Subject: [Axiom-developer] 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: "'C Y'" +Subject: RE: [Axiom-developer] 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.page1@enhanced.com, mthomas@gil.com.au +Subject: [Axiom-developer] 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: [Axiom-developer] 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: +Subject: RE: [Axiom-developer] 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 +Content-Type: application/octet-stream; + name="id_dsa.pub" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: attachment; + 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 +Content-Type: application/octet-stream; + name="identity.pub" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: attachment; + 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: root +To: mike.thomas@brisbane.paradigmgeo.com +Subject: Re: [Axiom-developer] 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: root +To: camm@enhanced.com +Subject: [Axiom-developer] 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 #) + +==================================================================== +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 #) + +==================================================================== +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 #) + +(1) -> + +\start +Date: Tue, 30 Nov 2004 21:47:54 -0500 +From: Stephen Wilson +To: root +Subject: Re: [Axiom-developer] pathname-name behavior change +Cc: camm@enhanced.com + +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: root +To: wilsons@multiboard.com +Subject: Re: [Axiom-developer] pathname-name behavior change +Cc: camm@enhanced.com + +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: root +Subject: Re: [Axiom-developer] 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: root +Subject: Re: [Axiom-developer] pathname-name behavior change +Cc: camm@enhanced.com + +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? + + + + diff --git a/changelog b/changelog index d3885b7..b534a56 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,5 @@ +20140424 tpd src/axiom-website/patches.html 20140424.01.tpd.patch +20140424 tpd book/2004-11.txt regularize 20140423 tpd src/axiom-website/patches.html 20140423.05.tpd.patch 20140423 tpd book/2004-10.txt regularize 20140423 tpd src/axiom-website/patches.html 20140423.04.tpd.patch diff --git a/src/axiom-website/patches.html b/src/axiom-website/patches.html index b7ca399..d7e2be8 100644 --- a/src/axiom-website/patches.html +++ b/src/axiom-website/patches.html @@ -4306,6 +4306,8 @@ book/2004-08.txt regularize book/2004-09.txt regularize 20140423.05.tpd.patch book/2004-10.txt regularize +20140424.01.tpd.patch +book/2004-11.txt regularize