diff --git a/book/2004-05.txt b/book/2004-05.txt
new file mode 100644
index 0000000..282d301
--- /dev/null
+++ b/book/2004-05.txt
@@ -0,0 +1,8441 @@
+\start
+Date: Sat, 01 May 2004 09:09:24 +0200
+From: David MENTRE
+To: daly@idsi.net
+Subject: Machine clusters & Axiom (was: Re: [Axiom-developer] Re: [Gcl-devel] gcl sockets)
+
+Hello Tim,
+
+root writes:
+
+> (b) in the long term there is a sub-effort to put Axiom on a beowulf.
+> I have access to a 128 node cluster with 2Ghz processors on each node.
+> Of course getting Axiom running in small-grain parallel mode (as
+> opposed to an independent Axiom on each node) is a hard problem
+> on its own. I've done some initial experiments with a matrix domain
+> (parallel matrix multiply) but not much since then. I was hoping to
+> have a student to work on this but that fell thru.
+
+As a side note, I've done my PhD in a research team looking at those
+cluster issues (and my own PhD was on the shared memory topic). I doubt
+that you can gain any speedup on a beowulf-like cluster for fine grain
+computations, due to high cost of communications (to much latency, to
+little bandwidth). However, coarse grain parallelism (e.g. one long
+Axiom computation par node) seems to me much more doable.
+
+\start
+Date: 03 May 2004 10:12:42 -0400
+From: Camm Maguire
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] Re: SLIME
+
+The following message is a courtesy copy of an article
+that has been posted to comp.lang.lisp as well.
+
+Greetings, and thanks!
+
+Helmut Eller writes:
+
+> Camm Maguire writes:
+>
+> > What is involved in getting a gcl backend in?
+>
+> A minimal backend requires:
+>
+> 1) a socket interface to open server sockets and a way to wrap client
+> sockets into a stream. I once tried to write a GCL backend for
+> SLIME and already failed here. IIRC, GCL's socket interface uses
+> some sort of callbacks and I was unable to adapt it to our needs.
+> I think it would be the best if GCL adopts Franz' socket interface.
+> OpenMCL has done that and this was a great help. Their interface
+> is quite nice and doesn't need any callbacks.
+>
+
+Is this interface simply documented anywhere? Don't have access to
+Franz lisp. We've been discussing our socket interface recently, and
+perhaps now would be the time to solicit opinions on what an optimal
+interface would look like. I take it the Franz interface also suits
+the web/mod_lisp people well?
+
+> 2) an interface to the debugger. This basically means a way to
+> produce the list of backtrace frames and a function to print frames
+> nicely. Functions to access the variables in a frame would be nice
+> but are not absolutely necessary.
+>
+
+Not a problem here.
+
+> 3) gray streams.
+>
+
+?? What are these?
+
+> This should be enough for the most basic functionality, like
+> evaluating, simple debugging and apropos. For more comfort like
+> M-. and compiler note trapping we need more interfaces, but this can
+> be added later.
+>
+> > Is anyone available to
+> > help with this, as I'm a bit tied up at the moment.
+>
+> I'd be happy to answer questions, but I don't like to write C code for
+> GCL (which is probably needed).
+>
+
+OK, then perhaps we have the basis for a dialog, as I'd feel
+comfortable with the C/GCL coding side.
+
+\start
+Date: Mon, 3 May 2004 09:29:21 -0400
+From: Tim Daly
+To: rjf@berkeley.edu
+Subject: [Axiom-developer] franz socket interface
+Cc: camm@enhanced.com, axiom-developer@nongnu.org, e9626484@stud3.tuwien.ac.at
+
+Richard,
+
+I'm looking at attaching Axiom as a mod-lisp apache process.
+It requires sockets. We have several options to choose from.
+Hellmut suggested that we try to be compatible with Franz's
+implementation. I think this is a reasonable idea as it would
+be better to have a compatible implementation. Can you point me
+at some documentation for Franz's sockets or point me at someone
+who knows?
+
+\start
+Date: Mon, 03 May 2004 16:45:54 +0200
+From: Helmut Eller
+To: daly@idsi.net
+Subject: [Axiom-developer] Re: franz socket interface
+Cc: camm@enhanced.com, axiom-developer@nongnu.org, rjf@berkeley.edu
+
+Tim Daly writes:
+
+> Richard,
+>
+> I'm looking at attaching Axiom as a mod-lisp apache process.
+> It requires sockets. We have several options to choose from.
+> Hellmut suggested that we try to be compatible with Franz's
+> implementation. I think this is a reasonable idea as it would
+> be better to have a compatible implementation. Can you point me
+> at some documentation for Franz's sockets or point me at someone
+> who knows?
+
+Franz' documentation is here:
+
+
+and OpenMCL's here:
+
+
+\start
+Date: Mon, 3 May 2004 19:48:21 +0200 (CEST)
+From: Bertfried Fauser
+To: Tim Daly
+Subject: [Axiom-developer] creating high quality pdf files
+
+Dear Tim,
+
+there was an discussion about creating high quality pdf files from TeX
+source (respectively ps files). I benefitted from a short Makefile a
+colleague of mine, Jan Kruerger, hacked in to compile his thesis.
+ The relevat part for teh AXIOM book is the one which gives the
+options to the p2pdf command, so that good 1.3 fonts (thumbnails etc) are
+created. pdfs created this way look quite good.
+
+Perhaps this helps for texing a smoth pdf version of teh AXIOM book, which
+could be uploaded to svannah's file area?
+
+====== Makefile by Jan Krueger ==========
+=
+= edit all places wher <...> occures
+= make (does a coplete TeXing, including index, bibtex, etc
+= make clean (obvious)
+= make pdf (creates pdf-files from ps source)
+=
+=========================================
+
+# $Id: Makefile,v 1.8 2004/04/28 date owner Exp $
+
+MAINTEXFILE =
+
+all: dvi pspdf
+
+world: dvi pdf ps
+
+clean:
+ rm -f ${MAINTEXFILE}.dvi ${MAINTEXFILE}.ps ${MAINTEXFILE}.pdf ${MAINTEXFILE}.aux \
+ ${MAINTEXFILE}.log ${MAINTEXFILE}.lof ${MAINTEXFILE}.toc ${MAINTEXFILE}.tpm\
+ ${MAINTEXFILE}.bbl ${MAINTEXFILE}.blg ${MAINTEXFILE}.ind ${MAINTEXFILE}.idx\
+ ${MAINTEXFILE}.ilg ${MAINTEXFILE}.out ${MAINTEXFILE}.bak *.log
+
+dvi: ${MAINTEXFILE}.dvi
+
+pdf: ${MAINTEXFILE}-fromps.pdf
+
+pspdf: ${MAINTEXFILE}-fromps.pdf
+
+ps: ${MAINTEXFILE}.ps
+
+${MAINTEXFILE}.dvi: ${MAINTEXFILE}.tex ${MAINTEXFILE}.bbl ${MAINTEXFILE}.ind
+ latex ${MAINTEXFILE}.tex
+ latex ${MAINTEXFILE}.tex
+
+${MAINTEXFILE}.bbl: .bib
+ latex ${MAINTEXFILE}.tex
+ bibtex ${MAINTEXFILE}
+
+${MAINTEXFILE}.ind: ${MAINTEXFILE}.idx
+ latex ${MAINTEXFILE}.tex
+ makeindex ${MAINTEXFILE}
+
+${MAINTEXFILE}-fromps.pdf: ${MAINTEXFILE}.dvi
+ dvips -Ppdf -G0 ${MAINTEXFILE}.dvi -o ${MAINTEXFILE}.ps
+ ps2pdf -sPAPERSIZE=a4 -dMaxSubsetPct=100 -dCompatibilityLevel=1.3 \
+ -dSubsetFonts=true -dEmbedAllFonts=true ${MAINTEXFILE}.ps \
+ ${MAINTEXFILE}.pdf
+# this line may make troubles but is not really needed
+# thumbpdf --modes=dvips ${MAINTEXFILE}.pdf
+ latex ${MAINTEXFILE}.tex
+ dvips -Ppdf -G0 ${MAINTEXFILE}.dvi -o ${MAINTEXFILE}.ps
+# on my box pdftime is not installed
+# pdftime ${MAINTEXFILE}.ps
+ ps2pdf -sPAPERSIZE=a4 -dMaxSubsetPct=100 -dCompatibilityLevel=1.3 \
+ -dSubsetFonts=true -dEmbedAllFonts=true ${MAINTEXFILE}.ps \
+ ${MAINTEXFILE}.pdf
+ mv ${MAINTEXFILE}.pdf .pdf
+ cp .pdf /publishin?directory/
+ rm ${MAINTEXFILE}.ps
+ dvips ${MAINTEXFILE}.dvi -o ${MAINTEXFILE}.ps
+
+${MAINTEXFILE}.ps: ${MAINTEXFILE}.dvi
+ dvips ${MAINTEXFILE}.dvi -o ${MAINTEXFILE}.ps
+
+
+\start
+Date: Mon, 3 May 2004 20:50:07 -0400
+From: root
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] creating high quality pdf files
+
+bf, thanks. i'll look at it in more detail when i can.
+i'm teaching wed and then heading to the east coast computer
+algebra day in canada so it may take a while. -- t
+
+
+\start
+Date: Tue, 4 May 2004 01:59:37 -0400
+From: "Page, Bill"
+To: axiom-mail@nongnu.org
+Subject: [Axiom-developer] Collaborative mathematics on the Axiom Portal latex wiki
+Cc: "Bertfried Fauser \(E-mail\)"
+
+Axiom Users;
+
+Here is a rather more ambitious demonstration of how to
+create web pages containing mathematics
+
+http://page.axiom-developer.org/zope/Plone/Members/wspage
+
+To see how this page is coded, log on with your user id
+and click on the 'edit' tab.
+
+If you do not have a user id, please click 'join' and
+have a look at this web site. Take the time to experiment
+and let me know if you have any problems.
+
+I hope this new interactive web facility will help Axiom
+users communicate with each other using standard mathematical
+notation, permit easier collaboration on Axiom projects
+and the creation of better quality documentation. If you
+have any questions, please ask.
+
+\start
+Date: Thu, 6 May 2004 19:06:31 +0200 (CEST)
+From: Bertfried Fauser
+To: David MENTRE
+Subject: Re: [Axiom-developer] creating high quality pdf files
+
+On Thu, 6 May 2004, David MENTRE wrote:
+
+Dear David,
+
+> > The relevat part for teh AXIOM book is the one which gives the
+> > options to the p2pdf command, so that good 1.3 fonts (thumbnails etc) are
+> > created. pdfs created this way look quite good.
+>
+> My own opinion on this is that substituing latex by pdflatex does the
+> job. Is the PDF version of the Axiom Book I have made of less quality
+> that you were expected (appart of graphics, of course ;)?
+
+I had problems to use pdflatex with more advanced tex files (eg using
+pstricks) so I had to use a different approch. Since on this group ps2pdf
+was mentioned, it was just a point to make that one can give there
+arguments so that 1.3 fonts are used and tumbnails are produced etc. Of
+course, more advanced features of pdf can be incorporated only by
+pdflatex, but see above
+ I was not arguaing against your pdf file anyway.
+
+\start
+Date: Thu, 06 May 2004 18:58:01 +0200
+From: David MENTRE
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] creating high quality pdf files
+
+Hello Bertfried,
+
+Bertfried Fauser writes:
+
+> The relevat part for teh AXIOM book is the one which gives the
+> options to the p2pdf command, so that good 1.3 fonts (thumbnails etc) are
+> created. pdfs created this way look quite good.
+
+My own opinion on this is that substituing latex by pdflatex does the
+job. Is the PDF version of the Axiom Book I have made of less quality
+that you were expected (appart of graphics, of course ;)?
+
+\start
+Date: Thu, 06 May 2004 19:45:58 +0200
+From: David MENTRE
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] creating high quality pdf files
+
+Bertfried Fauser writes:
+
+> I had problems to use pdflatex with more advanced tex files (eg using
+> pstricks) so I had to use a different approch.
+
+Ok, thanks, I did not had this issue in mind.
+
+> I was not arguaing against your pdf file anyway.
+
+and my intent was not to defend my pdf file in anyway. I was just
+arguing on the simplest way to do the job (remember our motto? ;-)
+
+\start
+Date: Thu, 6 May 2004 20:12:46 +0200 (CEST)
+From: Bertfried Fauser
+To: David MENTRE
+Subject: Re: [Axiom-developer] creating high quality pdf files
+
+On Thu, 6 May 2004, David MENTRE wrote:
+
+Dear David,
+
+you might have a look at the AXIOM+LaTeX Wiki of Bill Page
+http:/page.axiom-developer.org/zope/Plone/Members/Bertfried
+where on my FrontPage lots of pstricks and AMS LaTeX is used, some of
+which pdflatex (unfortunately) does not swallow. However, it is really
+fun to see it on a web server working...
+
+\start
+Date: 06 May 2004 16:19:17 -0400
+From: Camm Maguire
+To: Jeff Dalton
+Subject: [Axiom-developer] Re: [Gcl-devel] Re: Server sockets with GCL?
+Cc: tdjohns1@rockwellcollins.com,Chris Hall
+
+Greetings!
+
+A few observations regarding sockets in GCL:
+
+1) There appears to be hooks in the current code for functions which
+ were later removed, perhaps as a result of the KCL->GCL migration.
+ Look at nsocket.c for the commented out empty function update,
+ etc.
+
+2) From what I can tell, the server function passed to si::socket is
+ therefore not currently used. I've checked all the references to
+ object0->c.c... and unless I've missed something, this
+ functionality has been removed.
+
+3) The code in file.d goes with the routines in nsocket.c. The code
+ in sockets.c appears to be tcltk specific, going with
+ gcl-tk/comm.c. The magic header bytes are indeed gcl specific
+ additions to the protocol to the gcltkserver, presumably as a
+ failsafe. Search for 'magic' in gcl-tk/comm.c.
+
+4) Fixing this is not hard -- its just that it is not clear what is
+ best to do. As we all know, there is no socket standard in the
+ ANSI spec. It has been expressed that compatibility with allegro
+ would be desirable, at least for SLIME, but there appears to be no
+ multiplexing ability in their implementation. Presumably this is
+ because they count on the user relying on threads for their
+ multitasking. The dominant socket server paradigm of which I am
+ aware is 1) bind 2) listen 3) accept 4) fork/spawn, whatever on the
+ new socket. This would be simple to implement in GCL via fork()
+ (no Windows), but this would mean running one image per connection,
+ which is quite a lot of memory. Threads reduce this hurdle, but
+ they are much harder in lisp, where one has to worry about the GC.
+ We won't be able to do that any time soon, at least without some
+ detailed pointers/examples of other treatments. So this might
+ indicate that either 1) a multiplexing based on select() or 2) a
+ SIGIO based multitasking system might be preferable. I've had a
+ bit of trouble with SIGIO signal handlers restarting some system
+ calls on exit in the past -- don't know if this is a permanent
+ problem.
+
+ Presumably one does want to assign some function to handle the i/o
+ on the socket *in the background* while returning control to the
+ user, no? Would it not also be preferable to have some sort of
+ attach/detach procedure like in gdb to connect and disconnect from
+ a running process?
+
+ BTW, noticed on allegro's site that SSL is only supported in
+ Enterprise versions. I've written my own ssl socket multiplexer
+ (non-server) in C, which in principle is easily integratable into
+ GCL if an interface can be decided upon, using openssl, so maybe
+ this would be attractive.
+
+5) Speaking of fork(), I just noticed that we are not even compiling
+ in run-process and the like, at least on linux. Does anyone want
+ this back?
+
+Take care,
+
+
+Jeff Dalton writes:
+
+> Quoting Chris Hall :
+>
+> > > What I'm confused about is how to take the results obtained from
+> > > calling ACCEPT-SOCKET-CONNECTION and derive a pair of streams.
+> >
+> > I'd like to do this, too, but after looking at the existing C socket
+> > code that I can find in GCL and reading what Camm has to say, it seems
+> > it some work needs to be done on the C side. I am, when I can spend
+> > the time, learning what I can about C socket programming on Linux.
+>
+> When I did socket stuff in GCL in order to write an HTTP server,
+> I wrote a function called accept-socket-connection that returned
+> an df (ie, an int), and I wrote something called fdopen that
+> would return a Lisp input or output stream. Then
+>
+> (defun socket-connection-stream (s)
+> (let ((fd (accept-socket-connection s)))
+> (make-two-way-stream
+> (fdopen fd :input)
+> (fdopen fd :output))))
+>
+> fdopen was named after the C procedure that makes a FILE from an fd.
+>
+> I could then do normal I/O with the resulting stream.
+>
+> All of this was reasonably straightforward to do using the C
+> interface.
+>
+> I'm not sure how freely available my code is, though it's supposed
+> to become open source as part of O-Plan (an AI planning system)
+> at some point.
+>
+> However, I'd be ahppy to try to help other people with such
+> things where I can.
+>
+> BTW, is there any documentation for the GCL C interface.
+> My copy of the KCL manual was destroyed in a fire, and I
+> couldn't find anything on-line.
+
+\start
+Date: Thu, 6 May 2004 16:18:31 -0500
+From:
+To: camm@enhanced.com
+Subject: [Axiom-developer] Re: Server sockets with GCL?
+Cc: hall.cj@verizon.net, tdjohns1@rockwellcollins.com, jeff@inf.ed.ac.uk
+
+This is a multipart message in MIME format.
+--=_alternative 00750D6D86256E8C_=
+Content-Type: text/plain; charset="us-ascii"
+
+>Greetings!
+>
+>A few observations regarding sockets in GCL:
+
+(a lot of interesting and useful stuff snipped)
+
+It is now clear to me that the level of familiarity with GCL's history
+and the physical source file dependencies required to make these changes
+is well above my current expertise. Although I might be able to make the
+code work for my platform and distro, I don't have the means to test that
+I haven't broken one or more implementations on other platforms, nor to
+generalize the build and configuration process.
+
+Regarding the issues of fork() and threads, yes, I would expect a general
+implementation of threads to be necessary to make server sockets as useful
+as in other languages (or maybe as in other Lisp implementations, as you
+note).
+
+However, in the particular situation I face at the moment, my "server"
+need
+not be able to (and in fact, cannot currently) serve multiple concurrent
+clients. Thus, I would be using the server socket only with one client at
+a time.
+
+My main need for now is a function to listen "passively" and produce
+the same sort of thing produced by SI::SOCKET. I'm not particular whether
+the form I employ is a keyword-based option on SI::SOCKET or another
+function
+like ACCEPT-SOCKET-CONNECTION altogether.
+
+Tom Johnson
+
+
+A few observations regarding sockets in GCL:
+(a lot of interesting and useful stuff snipped)
+
+It is now clear to me that the level of familiarity with GCL's history
+and the physical source file dependencies required to make these changes
+is well above my current expertise. Although I might be able to make the
+code work for my platform and distro, I don't have the means to test that
+I haven't broken one or more implementations on other platforms, nor to
+generalize the build and configuration process.
+
+Regarding the issues of fork() and threads, yes, I would expect a general
+implementation of threads to be necessary to make server sockets as useful
+as in other languages (or maybe as in other Lisp implementations, as you
+note).
+
+However, in the particular situation I face at the moment, my "server" need
+not be able to (and in fact, cannot currently) serve multiple concurrent
+clients. Thus, I would be using the server socket only with one client at

+a time.
+
+My main need for now is a function to listen "passively" and produce
+the same sort of thing produced by SI::SOCKET. I'm not particular whether
+the form I employ is a keyword-based option on SI::SOCKET or another function
+like ACCEPT-SOCKET-CONNECTION altogether.
+
+Tom Johnson
+
+
+\start
+Date: 07 May 2004 11:51:03 -0400
+From: Camm Maguire
+To:
+Subject: [Axiom-developer] Re: [Gcl-devel] Re: Server sockets with GCL?
+Cc: hall.cj@verizon.net
+
+Greetings!
+
+ writes:
+
+> >Greetings!
+> >
+> >A few observations regarding sockets in GCL:
+> (a lot of interesting and useful stuff snipped)
+> It is now clear to me that the level of familiarity with GCL's history
+> and the physical source file dependencies required to make these changes
+> is well above my current expertise. Although I might be able to make t=
+he
+> code work for my platform and distro, I don't have the means to test that
+> I haven't broken one or more implementations on other platforms, nor to
+> generalize the build and configuration process.
+> Regarding the issues of fork() and threads, yes, I would expect a general
+> implementation of threads to be necessary to make server sockets as useful
+> as in other languages (or maybe as in other Lisp implementations, as you
+> note).
+> However, in the particular situation I face at the moment, my "server" ne=
+ed
+> not be able to (and in fact, cannot currently) serve multiple concurrent
+> clients. Thus, I would be using the server socket only with one client=
+ at
+> a time.
+> My main need for now is a function to listen "passively" and produce
+> the same sort of thing produced by SI::SOCKET. I'm not particular whet=
+her
+> the form I employ is a keyword-based option on SI::SOCKET or another func=
+tion
+> like ACCEPT-SOCKET-CONNECTION altogether.
+> Tom Johnson
+
+OK, for this 'quick and dirty':
+
+1) Apply the patch below
+2) In GCL: (defun foo (x) x) (setq s (si::socket 1919 :server 'foo))
+ (setq q (si::accept s))
+3) In some other window, either netcat or telnet localhost 1919
+4) IN GCL: accept should return with a cons containing a two way
+ stream
+5) In other window, type hello
+6) In GCL: (read-line (car q)) ; should give "hello"
+7) In GCL: (format (car q) "there~%")
+8) there should appear in other window.
+
+Not quite ready to commit this as the dummy server function is pretty
+ugly. I think the original intent might have been to define handlers
+via the SIGIO-INTERRUPT symbol and the SET-SIGIO-FOR-FD function.
+
+Do we want to specify a server function in this case, and if so, what
+do we want it to do and when?
+
+Take care,
+
+==========================
+==========================
+==========================
+==
+Index: o/file.d
+==========================
+==========================
+=================
+RCS file: /cvsroot/gcl/gcl/o/file.d,v
+retrieving revision 1.21.4.1.2.7
+diff -u -r1.21.4.1.2.7 file.d
+--- o/file.d 3 May 2004 21:35:58 -0000 1.21.4.1.2.7
++++ o/file.d 7 May 2004 15:40:40 -0000
+@@ -38,6 +38,13 @@
+ #define IN_FILE
+ #include "include.h"
+
++#ifdef HAVE_NSOCKET
++#include
++#include
++#include
++#include
++#endif
++
+ #ifdef HAVE_READLINE
+ #define kclgetc(FP) rl_getc_em(FP)
+ #define kclungetc(C, FP) rl_ungetc_em(C, FP)
+@@ -2302,6 +2309,36 @@
+
+ @)
+
++@(static defun accept (strm)
++int fd,n;
++struct sockaddr_in addr;
++@
++
++ if (type_of(strm)!=t_stream)
++ FEwrong_type_argument(sLstream,strm);
++ if (strm->sm.sm_mode!=smm_two_way)
++ FEerror("~S is not a two way stream",1,strm);
++ strm=STREAM_INPUT_STREAM(strm);
++ if (type_of(strm)!=t_stream)
++ FEwrong_type_argument(sLstream,strm);
++ if (strm->sm.sm_mode!=smm_socket)
++ FEerror("~S is not a socket stream",1,strm);
++ fd=SOCKET_STREAM_FD(strm);
++ n=sizeof(addr);
++ fd=accept(fd,(struct sockaddr *)&addr, &n);
++ if (fd < 0) {
++ perror("ERROR ! accept on socket failed in sock_accept_connection");
++ fflush(stderr);
++ @(return `Cnil`);
++ }
++ strm = make_two_way_stream
++ (make_socket_stream(fd,gcl_sm_input,Cnil,Cnil,Cnil,Cnil),
++ make_socket_stream(fd,gcl_sm_output,Cnil,Cnil,Cnil,Cnil));
++ strm=make_cons(strm,make_simple_string(inet_ntoa(addr.sin_addr)));
++ @(return `strm`);
++
++@)
++
+ DEF_ORDINARY("MYADDR",sKmyaddr,KEYWORD,"");
+ DEF_ORDINARY("MYPORT",sKmyport,KEYWORD,"");
+ DEF_ORDINARY("ASYNC",sKasync,KEYWORD,"");
+@@ -2441,6 +2478,7 @@
+ make_si_function("FREAD",Lfread);
+ #ifdef HAVE_NSOCKET
+ make_si_function("SOCKET",Lsocket);
++ make_si_function("ACCEPT",Laccept);
+ #endif
+ make_function("STREAMP", Lstreamp);
+ make_function("INPUT-STREAM-P", Linput_stream_p);
+@@ -2476,8 +2514,8 @@
+ char *str;
+ {
+ object faslfile, data;
+-#ifdef UNIX
+-#ifdef BSD
++#ifndef SEEK_TO_END_OFILE
++#if defined(UNIX) && defined(BSD)
+ FILE *fp;
+ int i;
+ #ifdef HAVE_AOUT
+Index: o/read.d
+==========================
+==========================
+=================
+RCS file: /cvsroot/gcl/gcl/o/read.d,v
+retrieving revision 1.14.4.1.2.2.2.4
+diff -u -r1.14.4.1.2.2.2.4 read.d
+--- o/read.d 6 Nov 2003 16:16:53 -0000 1.14.4.1.2.2.2.4
++++ o/read.d 7 May 2004 15:41:02 -0000
+@@ -2095,9 +2095,9 @@
+ token->st.st_self[i++] = char_code(c);
+ }
+ FINISH:
+-#ifdef DOES_CRLF
++/*#ifdef DOES_CRLF*/
+ if (i > 0 && token->st.st_self[i-1] == '\r') i--;
+-#endif
++/*#endif*/
+ token->st.st_fillp = i;
+ /* no disadvantage to returning an adjustable string */
+
+
+\start
+Date: Fri, 07 May 2004 06:41:49 -1000
+From: Chris Hall
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] Re: [Gcl-devel] Re: Server sockets with GCL?
+
+--=-=-=
+
+Camm Maguire writes:
+
+> Greetings!
+>
+> A few observations regarding sockets in GCL:
+>
+> 1) There appears to be hooks in the current code for functions which
+> were later removed, perhaps as a result of the KCL->GCL migration.
+> Look at nsocket.c for the commented out empty function update,
+> etc.
+
+Yup, saw those, and wondered what led to their 'inactivation'.
+
+>
+> 2) From what I can tell, the server function passed to si::socket is
+> therefore not currently used. I've checked all the references to
+> object0->c.c... and unless I've missed something, this
+> functionality has been removed.
+
+Eeep! I think I started looking at that, got distracted, and then
+forgot all about it. Doh.
+
+>
+...
+>
+> 4) Fixing this is not hard -- its just that it is not clear what is
+> best to do. As we all know, there is no socket standard in the
+> ANSI spec. It has been expressed that compatibility with allegro
+> would be desirable, at least for SLIME, but there appears to be no
+> multiplexing ability in their implementation. Presumably this is
+> because they count on the user relying on threads for their
+> multitasking. The dominant socket server paradigm of which I am
+> aware is 1) bind 2) listen 3) accept 4) fork/spawn, whatever on the
+> new socket. This would be simple to implement in GCL via fork()
+> (no Windows), but this would mean running one image per connection,
+> which is quite a lot of memory. Threads reduce this hurdle, but
+> they are much harder in lisp, where one has to worry about the GC.
+> We won't be able to do that any time soon, at least without some
+> detailed pointers/examples of other treatments. So this might
+> indicate that either 1) a multiplexing based on select() or 2) a
+> SIGIO based multitasking system might be preferable. I've had a
+> bit of trouble with SIGIO signal handlers restarting some system
+> calls on exit in the past -- don't know if this is a permanent
+> problem.
+
+As I mentioned in a related thread, I would like to (humbly) suggest the
+select() option - for your reasons here and others mentioned in my
+related post.
+
+>
+> Presumably one does want to assign some function to handle the i/o
+> on the socket *in the background* while returning control to the
+> user, no?
+
+If we go the select() route, couldn't we use a defstruct/plist/object to
+hold functions to be called for the various events (data_available,
+connection_lost, etc.)? This defstruct/plist/object would be returned
+from/created by the function creating the associated socket.
+
+As I understand select(), one uses an associated map of fd's for it to
+monitor - with just a wee bit of abstraction, mightn't it be possible to
+have it use a map of socket defstructs/plist/objects?
+
+I'll come clean - a lot of my ideas are cribbed from the Python standard
+lib 'asyncore'. A brief API description is available at:
+
+http://www.python.org/doc/current/lib/module-asyncore.html
+
+> Would it not also be preferable to have some sort of
+> attach/detach procedure like in gdb to connect and disconnect from
+> a running process?
+
+Yes! Then wouldn't we be able to get a REPL perhaps as well?
+
+>
+> BTW, noticed on allegro's site that SSL is only supported in
+> Enterprise versions. I've written my own ssl socket multiplexer
+> (non-server) in C, which in principle is easily integratable into
+> GCL if an interface can be decided upon, using openssl, so maybe
+> this would be attractive.
+
+I think in today's networking world, it would be very attractive. It
+might even put GCL one up against the other Lisps. ;-)
+
+>
+> 5) Speaking of fork(), I just noticed that we are not even compiling
+> in run-process and the like, at least on linux. Does anyone want
+> this back?
+
+Sounds good to me. :-D
+
+\start
+Date: Fri, 7 May 2004 13:29:58 -0500
+From:
+To: camm@enhanced.com
+Subject: [Axiom-developer] Re: Server sockets with GCL?
+Cc: hall.cj@verizon.net
+
+This is a multipart message in MIME format.
+--=_alternative 00659F2586256E8D_=
+Content-Type: text/plain; charset="us-ascii"
+
+>OK, for this 'quick and dirty':
+>
+>1) Apply the patch below
+
+(snip)
+
+I really didn't expect you to go to all of that trouble, but
+thanks very much!!! I haven't yet tried it out, but now that I
+see the patch, I understand the foreign function interface
+machanics a lot better. I was most confused by that tkconnect
+specific stuff.
+
+Regards,
+
+Tom Johnson
+
+OK, for this 'quick and dirty':
+
+1) Apply the patch below
+
+I really didn't expect you to go to all of that trouble, but
+thanks very much!!! I haven't yet tried it out, but now that I
+see the patch, I understand the foreign function interface
+machanics a lot better. I was most confused by that tkconnect
+specific stuff.
+
+\start
+Date: Sun, 9 May 2004 13:58:24 -0700
+From: Bob McElrath
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] building axiom
+
+--azLHFNyN32YCQGCU
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+Content-Transfer-Encoding: quoted-printable
+
+Axiom doesn't seem to compile itself out of CVS. I had to:
+ cd mnt
+ mkdir linux
+ cd linux
+ ln -s bin ../bin
+I think the makefile should be doing this...
+
+So I decided to change a little something in Axiom (you know, getting
+acquainted with everything). Specifically I want it to output Booleans
+as {\tt true} and {\tt false} rather than true and false when in tex
+mode:
+ )set output tex on
+which appears when using the TeXmacs interface, for instance. I added:
+ str = "true" => "{\tt true}"
+ str = "false" => "{\tt false}"
+in src/algebra/tex.spad.pamphlet:556 which I'm sure is not the best way
+to accomplish this...
+
+
+
+\start
+Date: Tue, 11 May 2004 19:46:33 -0400
+From: root
+To: david.mentre@wanadoo.fr
+Subject: Re: [Axiom-developer] creating high quality pdf files
+Cc: Bertfried.Fauser@uni-konstanz.de
+
+Bertfried, David,
+
+Sorry for the long delay in reply. I was away at ECCAD in Canada
+and had no email access.
+
+Is there a way to get the graphics into the pdf file?
+
+
+\start
+Date: Tue, 11 May 2004 23:11:03 -0400
+From: root
+To: Bill.Page@drdc-rddc.gc.ca
+Subject: [Axiom-developer] Re: Axiom on Zaurus
+
+no progress on axiom on clisp yet.
+
+there is a version of axiom for the zaurus but it requires glibc
+and the default zaurus build is libc6.
+
+\start
+Date: Wed, 12 May 2004 10:07:11 +0200 (CEST)
+From: Bertfried Fauser
+To: root
+Subject: Re: [Axiom-developer] creating high quality pdf files
+Cc: Bertfried.Fauser@uni-konstanz.de
+
+On Tue, 11 May 2004, root wrote:
+
+Dear Tim,
+
+a) using pdflatex, simply put the images into the tex source as ever. If
+images means pstricks, then one needs some workaround using the pdftricks
+package, but that needs to change the tex code (at least of the preamble).
+I havn't checked if it really works
+
+b) using dvips, ps2pdf, the only thing is to use the options which I
+forwarded in the makefile of my colleague, essential is to tell dvips that
+you want to have the ps files pre-prepared for generating pdf, ps2pdf
+needs to know to do some 1.3 fonts etc. Images are no problem here,
+essentially this can be done for every dvi file
+
+\start
+Date: 12 May 2004 10:22:33 +0200
+From: WZocher@t-online.de (Wolfgang Zocher)
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] creating high quality pdf files
+
+root writes:
+
+>
+> Is there a way to get the graphics into the pdf file?
+>
+Sure! pdflatex is a full featured latex with some restrictions concerning the
+types of pictures to be included. The savest way is to include *.pdf or *.png.
+If you have *.eps figures epstopdf will do the job of conversion, I'm not
+quite sure how to convert from eps to png but I think ImageMagick will be the
+tool of choice.
+
+btw.: you also can use mostly all of your pstricks stuff! Try pdftricks!
+
+\start
+Date: 12 May 2004 11:38:28 -0400
+From: Camm Maguire
+To: Tim Daly
+Subject: [Axiom-developer] Re: FeynCalc
+
+Greetings!
+
+Tim Daly writes:
+
+> Where do I find FeynCalc?
+>
+
+http://www.feyncalc.org/
+
+\start
+Date: 12 May 2004 11:13:18 -0400
+From: Camm Maguire
+To: daly@idsi.net
+Subject: [Axiom-developer] FeynCalc...
+
+Greetings! it has been proposed on the maxima list to translate
+FeynCalc ( a mathematica package) to maxima. I've inquired a bit --
+no responses yet. There is a semi-automated line of approach using
+mockmma, a program written by Richard Fateman. I'm wondering if there
+is any similar facility for porting mathematica code into axiom.
+
+\start
+Date: Wed, 12 May 2004 10:40:10 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: [Axiom-developer] FeynCalc
+
+Where do I find FeynCalc?
+
+\start
+Date: Wed, 12 May 2004 11:04:05 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: [Axiom-developer] Re: FeynCalc
+
+Cool, I'm just reading about SU(N) algebras in Quantum Field Theory.
+
+Bertfried is looking at Clifford algebras and it has set me off
+learning some group theory related to physics. I'll put it on
+the list to look at but I'm kinda lagged, having just returned
+from being off the net for a week.
+
+\start
+Date: Wed, 12 May 2004 11:49:53 -0400
+From: "Bill Page"
+To:
+Subject: RE: [Axiom-developer] Re: Axiom on Zaurus
+
+Tim,
+
+Where can I find the version of axiom for th zaurus? I think I can probably
+figure out how to install glibc.
+
+\start
+Date: Wed, 12 May 2004 11:43:53 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: [Axiom-developer] Re: FeynCalc
+
+re: translation. not that I'm aware of. it is rumored that there is
+a free version of the mma viewer but i dont' know where it is. if
+there is then maybe we can figure out the file format.
+
+\start
+Date: Wed, 12 May 2004 11:09:23 -0400
+From: Tim Daly
+To: alenka_zajka@mail.ru
+Subject: [Axiom-developer] OpenMath
+Cc: elena@orcca.on.ca
+
+Elena,
+
+I looked briefly at the OpenMath support in Axiom.
+I don't believe it is implemented in the best way as it seems
+to jump off to an underlying C program rather than implement
+it as Axiom code. Ideally you should be able to say:
+
+ )set output OpenMath on
+
+similar to the way TeX is handled. I'm going to look at what
+it might take to get this working (and, as a side-effect, get
+a better understanding of how TeX can be changed since we need
+to fix TeXmacs also).
+
+You should be able to pass an expression to Axiom with the
+current setup. Let me know if we need to change the input
+side of the system (the Java code I wrote).
+
+\start
+Date: 12 May 2004 12:21:08 -0400
+From: Camm Maguire
+To: Tim Daly
+Subject: [Axiom-developer] Re: FeynCalc
+
+Greetings!
+
+Tim Daly writes:
+
+> Cool, I'm just reading about SU(N) algebras in Quantum Field Theory.
+>
+> Bertfried is looking at Clifford algebras and it has set me off
+> learning some group theory related to physics. I'll put it on
+> the list to look at but I'm kinda lagged, having just returned
+> from being off the net for a week.
+>
+
+Great! In general, is there any experience at mathematica -> axiom
+translation, maybe even a program to get part way through?
+
+Take care,
+
+\start
+Date: Wed, 12 May 2004 12:23:48 -0400
+From: Tim Daly
+To: xli96@uwo.ca
+Subject: [Axiom-developer] Red Flag Linux
+
+Xin Li,
+
+> I remember, you said you hope to make Axiom adapt to Red Flag Linux
+> http://www.redflag-linux.com/eindex.html
+> I know this company is in Beijing. it's very near to my home.
+> if anything I can help, It will be my pleasure.
+
+The basic idea is to get some sort of a cooperative project that
+will make Axiom useful for the Asian university users. I understand
+that there is a joint effort between China, Japan, and South Korea
+to develop a local version of Linux and I'd like to see Axiom running
+on that version.
+
+I've already ported Axiom to Red Flag Linux in our lab.
+
+If you know people related to that effort I'd like to make contact
+with them.
+
+\start
+Date: Wed, 12 May 2004 20:17:05 +0200 (CEST)
+From: Bertfried Fauser
+To: Tim Daly
+Subject: [Axiom-developer] Re: pdf makefile
+
+On Wed, 12 May 2004, Tim Daly wrote:
+
+Dear Tim,
+
+> Axiom book which properly includes the graphics on the front page.
+> I'll see what I can steal from the makefile to add to axiom's makefile.
+
+I tried it on a linux box and got no thumbnails, while the same on a sparc
+solaris got nice tumbnails etc also. This might be a version problem of
+the ghostscript used, the solaris runs ggv (gnome ghostview) as interface,
+you might see the uncommented lines where tumbnails etc are craeted, but
+on my solaris box these programs where not found.
+
+> Since the book.tex file does not use bibtex entries the make stops
+> part way thru. I'll have to fix this.
+
+This makefile was just a quick hack of a colleague of mine for TeXing his
+PhD thesis, so its quite stupid and assumed that a makeindex and / or a
+bibtex is used, of course this has to be changed. My point was just to
+deliver the options for dvips and ps2pdf so that pdf files look good on
+screen too.
+
+By the way, is it possible to pass an argumat to a makefile, like the
+filename, or needs every tex document its own makefile then? In this cae
+it might be useful (and nice to look at for others) to create a bibtex
+database, which could be used by all AXIOM TeX files. Such a bibtex
+database could be made public over the web and might be a good source for
+looking for AXIOM usage and or related technical stuff.
+
+\start
+Date: Wed, 12 May 2004 12:15:18 -0400
+From: Tim Daly
+To: Bertfried Fauser , David MENTRE
+Subject: [Axiom-developer] pdf makefile
+
+Bertfried,
+
+I used your Makefile and successfully built a pdf version of the
+Axiom book which properly includes the graphics on the front page.
+I'll see what I can steal from the makefile to add to axiom's makefile.
+Since the book.tex file does not use bibtex entries the make stops
+part way thru. I'll have to fix this.
+
+\start
+Date: Wed, 12 May 2004 12:27:56 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: [Axiom-developer] free MMA notebook reader
+
+http://www.wolfram.com/products/mathreader
+
+is a viewer for notebook documents created with MMA.
+I'm looking to see if they document the file format.
+
+\start
+Date: Wed, 12 May 2004 13:06:26 -0400
+From: Tim Daly
+To: smustudent1@yahoo.com
+Subject: Re: [Axiom-developer] Re: FeynCalc
+Cc: camm@enhanced.com
+
+C Y,
+
+> It's not clear to me how this would help, unless
+> you are looking to duplicate the graphical display
+> of Mathematica.
+
+Actually, I'm writing up the (new) quarterly Axiom report and this
+is something we eventually need. I think we could get part way there
+with a (latex -> dvi -> advi -> borderless miniwindow) kind of hack.
+
+It was a misunderstanding on my part as I was unaware that MMA files
+were ascii. I took the long way around and got the viewer and, while
+trying to find out how to use it discovered that I didn't really
+need it.
+
+> Having Axiom and Maxima versions of Feyncalc would be
+> really excellent - each system could serve as a check
+> on the accuracy of the other. Keeping both current would
+> be a bit of work though.
+
+Do you consider FeynCalc useful and worth the effort to port?
+If so, it might make a useful test case for writing some programs
+to extract MMA information. There is still a long distance between
+MMA and Axiom and, unfortunately, the path travels thru someone's
+eyes and out their fingers.
+
+\start
+Date: Wed, 12 May 2004 10:51:48 -0700 (PDT)
+From: C Y
+To: Tim Daly , camm@enhanced.com
+Subject: Re: [Axiom-developer] Re: FeynCalc
+
+Free viewer? Do you mean this?
+
+http://www.wolfram.com/products/mathreader/
+
+It's not clear to me how this would help, unless
+you are looking to duplicate the graphical display
+of Mathematica. The concepts will have to be
+translated from Mathematica's world to Axiom's (or
+Maxima's for that matter) and that will be the
+hard part.
+
+As I understand it, Dr. Fateman's mockmma package
+could be used to do a rough translation, which would
+then need much work and probably some redesign to
+actually take the rest of the way to a reliable working
+program. I'm guessing Axiom is more different from
+Mathematica than Maxima is, at least in approach.
+Undoubtedly an Axiom version of Feyncalc would be
+a powerful tool though - perhaps the different design
+decisions of Axiom would actually be an asset :-).
+
+Having Axiom and Maxima versions of Feyncalc would be
+really excellent - each system could serve as a check
+on the accuracy of the other. Keeping both current would
+be a bit of work though.
+
+CY
+
+--- Tim Daly wrote:
+> re: translation. not that I'm aware of. it is rumored that there is
+> a free version of the mma viewer but i dont' know where it is. if
+> there is then maybe we can figure out the file format.
+
+\start
+Date: Wed, 12 May 2004 13:35:54 -0400
+From: Tim Daly
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: [Axiom-developer] Re: pdf makefile
+
+> > Axiom book which properly includes the graphics on the front page.
+> > I'll see what I can steal from the makefile to add to axiom's makefile.
+>
+> I tried it on a linux box and got no thumbnails, while the same on a sparc
+> solaris got nice tumbnails etc also. This might be a version problem of
+> the ghostscript used, the solaris runs ggv (gnome ghostview) as interface,
+> you might see the uncommented lines where tumbnails etc are craeted, but
+> on my solaris box these programs where not found.
+
+Both the .ps and the .pdf files came out with the correctly embedded
+graphics on Linux RH9.
+
+>
+> > Since the book.tex file does not use bibtex entries the make stops
+> > part way thru. I'll have to fix this.
+>
+> This makefile was just a quick hack of a colleague of mine for TeXing his
+> PhD thesis, so its quite stupid and assumed that a makeindex and / or a
+> bibtex is used, of course this has to be changed. My point was just to
+> deliver the options for dvips and ps2pdf so that pdf files look good on
+> screen too.
+
+Yeah, the options are useful. I'll look at setting this up.
+
+>
+> By the way, is it possible to pass an argumat to a makefile, like the
+> filename, or needs every tex document its own makefile then?
+
+There is an axiom command 'document' that gets built which knows about
+pamphlet files and creates .dvi files. I'm going to hack that command
+so you can request the target file format (dvi, ps, pdf). You should
+be able to use it by doing:
+
+export PATH=$AXIOM/bin:$PATH
+document foo <=== note: note foo.pamphlet, just foo
+
+currently 'document' extracts the .tex and creates a .dvi file.
+
+I really should figure out how to transfer this information from the
+configure script and make it part of the configuration. Plus configure
+should check that the various pdf/ps/bibtex commands exist and work.
+
+> filename, or needs every tex document its own makefile then? In this cae
+> it might be useful (and nice to look at for others) to create a bibtex
+> database, which could be used by all AXIOM TeX files. Such a bibtex
+> database could be made public over the web and might be a good source for
+> looking for AXIOM usage and or related technical stuff.
+
+Actually, there is an axiom.bib.pamphlet file that contains a huge amount
+of bib references. I just haven't posted it yet. I'll add it to the TODO
+list. I ripped out the bibtex step when I posted the book because I wanted
+the book to be as close to a standalone file as I could get (module the
+graphics).
+
+I'm working on a second book about fundamental math concepts (like
+polynomial gcd) which is using the bibtex step so I'll need it
+eventually. The book is intended for beginning Axiom computer algebra
+users and is based on D.E. Littlewood's "The Skeleton Keys of Mathematics".
+
+\start
+Date: Wed, 12 May 2004 12:10:18 -0700
+From: Bob McElrath
+To: C Y
+Subject: Re: [Axiom-developer] Re: FeynCalc
+Cc: camm@enhanced.com
+
+--93POaeCRlRW5//kc
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+Content-Transfer-Encoding: quoted-printable
+
+C Y [smustudent1@yahoo.com] wrote:
+> Having Axiom and Maxima versions of Feyncalc would be
+> really excellent - each system could serve as a check
+> on the accuracy of the other. Keeping both current would
+> be a bit of work though.
+
+I would be very, very interested in such a thing, however, maintaining
+three separate codebases would really really suck.
+
+The Mathematica language is the largest I have ever seen. It attempts
+to be all things, list-based, object-based, functional, patterns,
+interpreted, compiled, and of course has an extremely large library.
+Automatic translation from Mathematica may be near impossible. Frankly
+I think the size of the language makes it poorly suited to almost all
+tasks, and I hope Axiom and Maxima do not attempt to emulate it.
+
+Rather, it may be easier to develop a MMA export mode for Axiom/Maxima
+for the purpose of comparing solutions. An export mode doesn't need to
+understand the entire MMA language. I would like to see a large,
+cross-system test suite which could be used to validate and improve all
+systems. Perhaps this:
+ http://www.math.unm.edu/~wester/cas_review.html
+would be a good starting point.
+
+In any case, I am extremely interested in this and would like to help.
+I have a pile of Maple code for my use, dealing with supersymmetric
+lagrangians, feynman rules, etc, and I intend to re-implement it in
+Axiom or Maxima, and doing so as part of a larger package would be
+ideal.
+
+\start
+Date: Wed, 12 May 2004 12:56:46 -0400
+From: Tim Daly
+To: camm@enhanced.com
+Subject: [Axiom-developer] free MMA notebook reader
+
+I've downloaded Mathreader and looked around the HighEnergyPhysics
+notebook. Unfortunately it doesn't compute anything but I believe
+we have a site license for MMA.
+
+I see the file format is ascii. I think I can find a driver to
+decode that :-)
+
+\start
+Date: Wed, 12 May 2004 19:15:25 -0700 (PDT)
+From: C Y
+To: Bob McElrath
+Subject: Re: [Axiom-developer] Re: FeynCalc
+Cc: camm@enhanced.com
+
+--- Bob McElrath wrote:
+> C Y [smustudent1@yahoo.com] wrote:
+> > Having Axiom and Maxima versions of Feyncalc would be
+> > really excellent - each system could serve as a check
+> > on the accuracy of the other. Keeping both current would
+> > be a bit of work though.
+>
+> I would be very, very interested in such a thing, however,
+> maintaining three separate codebases would really really suck.
+
+True, but unavoidable if people want the system to work on different
+systems. My hope would be that once the basic ports are complete, as
+changes are made to the Mathematica codebase the maintainers of the
+Maxima and/or Axiom ports would be able to examine those changes and
+take the appropriate steps in their codebases. Essentially, the
+developers doing the new scientific coding would keep doing the
+Mathematica thing and the porters could just impliment that in the
+other systems. May or may not be workable - partially it depends on
+how actively developed the Feyncalc software is.
+
+> The Mathematica language is the largest I have ever seen. It
+> attempts to be all things, list-based, object-based, functional,
+> patterns, interpreted, compiled, and of course has an extremely
+> large library. Automatic translation from Mathematica may be near
+> impossible.
+
+That was my general impression as well. I don't advocate automatic
+translation. You never know - perhaps Axiom or Maxima might someday
+take over as the primary Feyncalc platform - a Mathematica license as
+an entry fee for running Feyncalc can be a hefty price for a physics
+department, particularly if they anticipate a lot of users.
+
+> Frankly I think the size of the language makes it poorly suited to
+> almost all tasks, and I hope Axiom and Maxima do not attempt to
+> emulate it.
+
+AFAIK most of Axiom and Maxima's language decisions were made a long
+time ago.
+
+> Rather, it may be easier to develop a MMA export mode for
+> Axiom/Maxima for the purpose of comparing solutions. An export
+> mode doesn't need to understand the entire MMA language. I would
+> like to see a large, cross-system test suite which could be used to
+> validate and improve all systems. Perhaps this:
+> http://www.math.unm.edu/~wester/cas_review.html
+> would be a good starting point.
+
+Something of the sort has been discussed before - I don't know what the
+status of it is.
+
+> In any case, I am extremely interested in this and would like to
+> help. I have a pile of Maple code for my use, dealing with
+> supersymmetric lagrangians, feynman rules, etc, and I intend to
+> re-implement it in Axiom or Maxima, and doing so as part of a larger
+> package would be ideal.
+
+Sounds interesting! For what it's worth, there has been some work done
+previously translating Maple code to Maxima - can't recall the details
+at the moment.
+
+\start
+Date: Thu, 13 May 2004 09:43:10 +0200
+To: "Bill Page"
+From: David MENTRE
+Subject: Re: [Axiom-developer] Re: Axiom on Zaurus
+
+"Bill Page" writes:
+
+> Where can I find the version of axiom for th zaurus? I think I can probably
+> figure out how to install glibc.
+
+Thanks to Camm hard work, the debian package of arm is available for ARM
+arch (i.e. Zaurus CPU). You can start from that. Camm has given on this
+list details on how to decompress a .deb into something usable (I think
+it is an ar archive).
+
+http://packages.debian.org/testing/math/axiom
+
+(click on the arm button at the bottom of the page to have the debian
+package)
+
+\start
+Date: Thu, 13 May 2004 10:16:10 +0100
+From: Mike Dewar
+To: Tim Daly
+Subject: Re: [Axiom-developer] Re: FeynCalc
+Cc: camm@enhanced.com
+
+On Wed, May 12, 2004 at 01:06:26PM -0400, Tim Daly wrote:
+> C Y,
+>
+> > It's not clear to me how this would help, unless
+> > you are looking to duplicate the graphical display
+> > of Mathematica.
+>
+> Actually, I'm writing up the (new) quarterly Axiom report and this
+> is something we eventually need. I think we could get part way there
+> with a (latex -> dvi -> advi -> borderless miniwindow) kind of hack.
+Why bother? MMA's output mechanism is identical to that of presentation
+MathML (they basically donated it to the W3C group), so if you got Axiom
+to generate presentation MathML instead of OutputFormat then you could
+use Mozilla or Internet Explorer (or any other MathML viewer) to display
+your mathematical output. It would be much faster than going via dvi,
+and provide some limited cut-and-paste interoperability with Mathematica
+and MathML.
+
+\start
+Date: Thu, 13 May 2004 10:03:12 +0100
+From: Mike Dewar
+To: Tim Daly
+Subject: Re: [Axiom-developer] OpenMath
+Cc: elena@orcca.on.ca, alenka_zajka@mail.ru, Mike Dewar
+
+Hi Tim (and Elena),
+
+There are two separate issues here. The first is the problem of reading
+and writing streams of OpenMath tokens. It is this which uses the
+underlying C Library code (which by the way will probably be obsolote
+soon: we are hoping to finalise OpenMath 2 in the next week or two).
+The second is the question of serialising Axiom objects in OpenMath
+encodings. This is done in Axiom code via the OpenMath category, but is
+only implemented for a few domains.
+
+Cheers, Mike.
+
+On Wed, May 12, 2004 at 11:09:23AM -0400, Tim Daly wrote:
+> Elena,
+>
+> I looked briefly at the OpenMath support in Axiom.
+> I don't believe it is implemented in the best way as it seems
+> to jump off to an underlying C program rather than implement
+> it as Axiom code. Ideally you should be able to say:
+>
+> )set output OpenMath on
+>
+> similar to the way TeX is handled. I'm going to look at what
+> it might take to get this working (and, as a side-effect, get
+> a better understanding of how TeX can be changed since we need
+> to fix TeXmacs also).
+>
+> You should be able to pass an expression to Axiom with the
+> current setup. Let me know if we need to change the input
+> side of the system (the Java code I wrote).
+
+\start
+Date: Thu, 13 May 2004 09:47:00 -0400
+From: root
+To: miked@nag.co.uk
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru, miked@nag.co.uk, elena@orcca.on.ca
+
+Mike Dewar wrote:
+> There are two separate issues here. The first is the problem of reading
+> and writing streams of OpenMath tokens. It is this which uses the
+> underlying C Library code (which by the way will probably be obsolote
+> soon: we are hoping to finalise OpenMath 2 in the next week or two).
+> The second is the question of serialising Axiom objects in OpenMath
+> encodings. This is done in Axiom code via the OpenMath category, but is
+> only implemented for a few domains.
+
+Where can I get the new library?
+
+Mike Dewar wrote:
+> > Tim Daly wrote
+> > Actually, I'm writing up the (new) quarterly Axiom report and this
+> > is something we eventually need. I think we could get part way there
+> > with a (latex -> dvi -> advi -> borderless miniwindow) kind of hack.
+> Why bother? MMA's output mechanism is identical to that of presentation
+> MathML (they basically donated it to the W3C group), so if you got Axiom
+> to generate presentation MathML instead of OutputFormat then you could
+> use Mozilla or Internet Explorer (or any other MathML viewer) to display
+> your mathematical output. It would be much faster than going via dvi,
+> and provide some limited cut-and-paste interoperability with Mathematica
+> and MathML.
+
+
+It is clear from numerous discussions that Axiom needs to develop a
+notebook-like interface. Several people told me that they don't use
+Axiom specifically because it lacks a notebook.
+
+So, what are the choices?
+
+MMA uses ascii text as their notebook representation. It would be useful
+to generate "compatible" input/output so we could use the same front-end.
+However, the front-end is closed, proprietary, and expensive. Donating
+the representation of the math to W3C doesn't address the real issue.
+
+I can't use the Maple front-end for the same reasons.
+
+I'd like to use Integre's (formerly IBM's) techexplorer and MathML editor
+but their license specifically states that I can't:
+
+ The license rights granted hereunder are limited to
+ non-commercial personal use of the Software. Without limitation, the
+ license rights granted hereunder DO NOT include the right to use the
+ Software from within a commercial third-party application that
+ requires use of the Software, unless that third party publisher has
+ purchased a distribution license from Integre. Please contact Integre
+ with questions about use of the Software within third party
+ applications.
+
+Thus I'm left with no choice but to waste a year of my life drawing
+pretty pictures of characters on a screen. OpenMath and MathML only
+address a very small portion of the problem and, worse yet, add limits
+to the data representation I can choose. And I don't see how to carry
+Axiom's Types in OpenMath's data representation. Another incompatible
+notebook simply fragments the computational mathematics domain into
+yet another pointless "camp". Believe me, I'd much rather spend my
+time using other people's work and get on with making the math better.
+
+frustrated in ny,
+
+\start
+Date: Thu, 13 May 2004 15:20:26 +0200
+From: David MENTRE
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] OpenMath
+Cc: miked@nag.co.uk, alenka_zajka@mail.ru, elena@orcca.on.ca
+
+Hello Tim,
+
+root writes:
+
+> It is clear from numerous discussions that Axiom needs to develop a
+> notebook-like interface. Several people told me that they don't use
+> Axiom specifically because it lacks a notebook.
+
+Wasn't TeXmacs intended to do such a notbook interface?
+
+\start
+Date: Thu, 13 May 2004 10:18:54 -0400
+From: root
+To: david.mentre@wanadoo.fr
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru, elena@orcca.on.ca, miked@nag.co.uk
+
+I believe TeXmacs is intended as a general-purpose math front-end.
+Unfortunately the reaction I hear is that TeXmacs presents itself
+as an editor rather than a notebook. The look-and-feel is different.
+Editors are like wives, you usually only have one and it is very
+hard to change.
+
+It is possible to use the TeXmacs sources to get 90% of the work
+done and change the presentation to be more notebook-like. It seems,
+based on my limited discussions, that the key issues are the folding
+paradigm and the notebook-to-pamphlet data compatibility (i.e. changing
+the notebook changes the pamphlet and vice-versa).
+
+Bill Page's wiki might be an interesting alternative path. I tried to
+write a webpage that "folds" but my javascript isn't up to the task.
+And I'm still pondering how to get the wiki pages back into the
+booklet/pamphlet/tex format. Ideally you could change the book in the
+wiki and have it reflected in the pdf.
+
+
+\start
+Date: Thu, 13 May 2004 16:02:48 +0200 (CEST)
+From: Bertfried Fauser
+To: root
+Subject: Re: [Axiom-developer] OpenMath
+Cc: miked@nag.co.uk, alenka_zajka@mail.ru, elena@orcca.on.ca
+
+On Thu, 13 May 2004, root wrote:
+
+Dear Tim,
+
+> Editors are like wives, you usually only have one and it is very
+> hard to change.
+
+Am I allowed to put this into my "quotations" box? ;-))
+
+> It is possible to use the TeXmacs sources to get 90% of the work
+> done and change the presentation to be more notebook-like. It seems,
+> based on my limited discussions, that the key issues are the folding
+> paradigm and the notebook-to-pamphlet data compatibility (i.e. changing
+> the notebook changes the pamphlet and vice-versa).
+
+This woudl amount to post two ToDo points to challenge teh TeXmacs
+developers
+
+* Add a folding mechanism which allows to fold and unfold in several
+document hirarchies like paragraphs, secions, chapters
+
+* Add an export filter which produces pamphelt files from TeXmacs
+documents
+
+I think at least the first should be possible for them, since all
+applications would benefit from such a feature, the second, hmmm..
+
+> Bill Page's wiki might be an interesting alternative path. I tried to
+> write a webpage that "folds" but my javascript isn't up to the task.
+> And I'm still pondering how to get the wiki pages back into the
+> booklet/pamphlet/tex format. Ideally you could change the book in the
+> wiki and have it reflected in the pdf.
+
+The latex+wiki is really beyond everything I was intended to belive!!
+However, it looks odd, if renered text (included as image) and usual text
+(rendered by the html engine/browser) are mixed. Moreover, it is a bit of
+cheating involved. The creator of such a page has to deal with bootom down
+LaTeX and wiki(html) formating issues. This is fare away from being a
+wysiwyg application.
+ Really challenging would be a web site where you can drag and drop
+elements arrond (among them there may be AXIOM_INPUT elements and
+AXIOM_OUTPUT elemenst) without going into the details of formating.
+However, this seems to be a remote thing to think of.
+
+So the pragmatical question:
+
+What is the present AXIOM comunity and would it enlarge (gramatically) if
+a GUI (other than TeXmacs) would be awailable?
+
+\start
+Date: Thu, 13 May 2004 15:44:06 +0200 (CEST)
+From: Bertfried Fauser
+To: root
+Subject: Re: [Axiom-developer] OpenMath
+Cc: miked@nag.co.uk, alenka_zajka@mail.ru, elena@orcca.on.ca
+
+On Thu, 13 May 2004, root wrote:
+
+Dear All,
+
+> It is clear from numerous discussions that Axiom needs to develop a
+> notebook-like interface. Several people told me that they don't use
+> Axiom specifically because it lacks a notebook.
+
+what's wrong with TeXmacs?
+
+Please note:
+
+- I saw a book entirely written in "Matehmatica", printed it looks (in my
+ eyes) awful. It's hard to beat (AMS,La,..)TeX
+
+- The maple gui of Maple 9.0 has turned many people away from the product
+ (if those who announced to do so really did). This interface does not
+ support presentations, eg on a conference, and has a very very limited
+ typographical capability.
+
+- If you spend too much effort into a GUI, most likely the backend will
+ suffer. A person from scientific computing, some times ago told me that
+ Maple is really going for the engineers and students, not primarily for
+ scientists. If AXIOM would / will try to do this, I think the typed
+ language will be a barrier never surmounted by engineers, and most
+ students and even many scientists.
+
+- A point may be, that AXOM is still not available for windows (am I
+ right?)
+
+So my conclusion would be to take TeXmacs, and to try to have an export
+function of AXIOM "worksheets" to ps/pdf. Pdf can be used for
+presentations, even if real computations are not possible.
+
+The main point of concern is, to specify the targeted user....
+
+\start
+Date: Thu, 13 May 2004 16:19:03 +0200
+From: David MENTRE
+To: daly@idsi.net
+Subject: TeXmacs & notbook (was: Re: [Axiom-developer] OpenMath)
+
+Hello Tim,
+
+root writes:
+
+> the key issues are the folding paradigm
+
+Ok, I understand that (the small triangles to hide/show a paragraph).
+
+> and the notebook-to-pamphlet data compatibility (i.e. changing the
+> notebook changes the pamphlet and vice-versa).
+
+What do you exactly mean by this? Do you mean import of pamphlets into
+TeXmacs and export of TeXmacs doc into pamphlet? By pamphlet, you mean
+the current noweb+latex, right?
+
+\start
+Date: Thu, 13 May 2004 10:27:10 -0400
+From: root
+To: david.mentre@wanadoo.fr
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru, elena@orcca.on.ca, miked@nag.co.uk
+
+I suppose the most rational path is to throw the effort into making
+a "mode"? of TeXmacs that is more notebook-like.
+
+\start
+Date: Thu, 13 May 2004 16:15:05 +0200
+From: David MENTRE
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] OpenMath
+Cc: miked@nag.co.uk, alenka_zajka@mail.ru, elena@orcca.on.ca
+
+Hello Bertfried,
+
+Bertfried Fauser writes:
+
+> - A point may be, that AXOM is still not available for windows (am I
+> right?)
+
+The GCL port to windows has made great progresses those last months so
+Axiom on Windows should much easier now.
+
+> So my conclusion would be to take TeXmacs, and to try to have an export
+> function of AXIOM "worksheets" to ps/pdf. Pdf can be used for
+> presentations, even if real computations are not possible.
+
+TeXmacs can export to PDF.
+
+\start
+Date: Thu, 13 May 2004 11:37:30 -0400
+From: root
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru, miked@nag.co.uk, elena@orcca.on.ca
+
+> > Editors are like wives, you usually only have one and it is very
+> > hard to change.
+>
+> Am I allowed to put this into my "quotations" box? ;-))
+
+sure. the analogy is even stronger. you'll notice, if you switch
+editors or remarry, that almost nothing you learned from the first
+transfers to the second. And for some really nasty breakups (e.g.
+moving from MS Word to emacs) that you've lost everything you own.
+and things get really ugly if you use special phrases from your
+old editor with your new one, usually from force of habit.
+i'll stop now :-)
+
+
+\start
+Date: Thu, 13 May 2004 11:30:30 -0400
+From: root
+To: david.mentre@wanadoo.fr
+Subject: Re: TeXmacs & notbook (was: Re: [Axiom-developer] OpenMath)
+
+re: pamphlets-to-notebook
+
+The hard part seems to be to make them isomorphic. I expect the
+edits in either to be reflected in the other (long term: viewing
+info as a pamphlet, as code, as a notebook, as a point in a type
+lattice, are each facets of a crystal looking at the same underlying
+data representation).
+
+Currently, by pamphlet I do mean the noweb+latex but in the long
+term this is certain to change and grow (we already have a booklet
+format which I'm only using in the CATS test suite, which hasn't
+yet been exported to the world).
+
+\start
+Date: Thu, 13 May 2004 15:40:57 +0100
+From: Mike Dewar
+To: root
+Subject: Re: [Axiom-developer] OpenMath
+Cc: elena@orcca.on.ca, alenka_zajka@mail.ru
+
+On Thu, May 13, 2004 at 09:47:00AM -0400, Tim Daly wrote:
+> Where can I get the new library?
+There isn't one as yet. I don't know whether a library similar to the
+old INRIA one will be produced, the world has moved on and people tend
+to be using OpenMath much more as a document format than an interchange
+mechanism. For those that do want to use it as an interchange
+mechanism, Java libraries that use mechanisms like SOAP, XML-RPC etc.
+are more useful than the old TCP/IP-based one.
+
+> MMA uses ascii text as their notebook representation. It would be useful
+> to generate "compatible" input/output so we could use the same front-end.
+> However, the front-end is closed, proprietary, and expensive. Donating
+> the representation of the math to W3C doesn't address the real issue.
+I'd have thought that it did. Everything else that you need is already
+freely available in browsers, implemented according to defined or
+de-facto standards. You can do text layout in XHTML, implement fancy
+folding menus with javascript, handle graphics with plug-ins to get
+interactivity and render the Maths with MathML. If you want a hard-copy
+on the other hand, then its very easy to write an XSL stylesheet to
+produce LaTeX from your original document, or you can probably find
+existing tools to do this on the web. This isn't fantasy by the way,
+its exactly what we are doing at NAG with our documentation and its
+proving very successful.
+
+> Thus I'm left with no choice but to waste a year of my life drawing
+> pretty pictures of characters on a screen. OpenMath and MathML only
+> address a very small portion of the problem and, worse yet, add limits
+> to the data representation I can choose.
+I don't see how they limit your data representation, especially since
+they are both based on XML and thats just Lisp with fancy brackets :-)
+
+> And I don't see how to carry
+> Axiom's Types in OpenMath's data representation. Another incompatible
+You use the OMATTR constructor to attribute the object with its Axiom
+type. (In OpenMath 2 you can make this stronger by declaring it to be a
+semantic attribute.) MathML has an element called "semantics" which
+allows you to do a similar thing, there is a whole document devoted to
+this problem at http://www.w3.org/TR/mathml-types/.
+
+> notebook simply fragments the computational mathematics domain into
+> yet another pointless "camp". Believe me, I'd much rather spend my
+> time using other people's work and get on with making the math better.
+Thats why if I were in your position I would try and use generic
+technologies inside a browser, rather than do something ad-hoc.
+
+> frustrated in ny,
+> Tim
+
+\start
+Date: Thu, 13 May 2004 11:25:48 -0400
+From: root
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] OpenMath
+Cc: miked@nag.co.uk, alenka_zajka@mail.ru, elena@orcca.on.ca
+
+I agree that the notebook form is painful and limited for some
+things but it clearly has the attention of users. I want much
+more from the user interface. I'm sure there will be better
+ideas when we reach the 30 year horizon but what will they be?
+
+Frankly, I'd like a user interface that knows much more about
+the mathematics, both for specific domain lookup (ala the javadoc
+hierarchy) so that I can find information about a domain and the
+categories it belongs to, the lattice of types where it resides,
+the pamphlets that are related to it, the published papers where
+it is referenced, and websites that are related.
+
+I also want the user interface to know much more about the user's
+intentions, by watching what the user is doing. I know this sounds
+a lot like clippy but in the long term I can fork off whole processors
+to scan the mathematics literature. In the short term I want the user
+interface to experiement with collecting and representing information
+about the task I'm trying to do.
+
+The user interface needs to know about the language and the compiler
+and it needs to know examples of the functions I'm trying to call.
+
+All of which means that there needs to be a great deal of information
+provided by Axiom to the front-end and tight coupling to things like
+context-sensitive menu items.
+
+I suggest we form a plan that addresses all of the concerns
+e.g. mathml, openmath, notebook-like, texmacs, tex, ps, pdf,
+pamphlets, etc.
+
+If we target the texmacs codebase we could likely get help from them
+and also benefit both of us.
+
+\start
+Date: Thu, 13 May 2004 08:09:31 -0700
+From: Bob McElrath
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] OpenMath
+Cc: miked@nag.co.uk, alenka_zajka@mail.ru, elena@orcca.on.ca
+
+--VywGB/WGlW4DM4P8
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+Content-Transfer-Encoding: quoted-printable
+
+Bertfried Fauser [fauser@spock.physik.uni-konstanz.de] wrote:
+> On Thu, 13 May 2004, root wrote:
+> The latex+wiki is really beyond everything I was intended to belive!!
+> However, it looks odd, if renered text (included as image) and usual text
+> (rendered by the html engine/browser) are mixed.
+
+This is because the axiom site is inside Plone, and Plone needs a
+ploneCustom.css file to specify a few things for latexwiki. See my
+site: http://mcelrath.org/Notes which does not use plone. I've put a
+lot of effort into making the latex text look natural with the
+surrounding browser text. Also try the "preferences" link in the upper
+left corner.
+
+> Moreover, it is a bit of
+> cheating involved. The creator of such a page has to deal with bootom down
+> LaTeX and wiki(html) formating issues. This is fare away from being a
+> wysiwyg application.
+
+In general, I do not think a web page would be an appropriate interface
+for Axiom. Furthermore, png/gif's embedded in web pages for the math is
+really a short-term hack because MathML isn't ready for prime time, and
+is not desirable in the long run.
+
+However, Mozilla has just about all the elements necessary to build a
+notebook interface. It can render MathML already, and an interface can
+be drawn in XUL... Perhaps this would be better than extending
+TeXmacs, since the "notebook" doesn't fit so naturally in the editor
+paradigm.
+
+\start
+Date: Thu, 13 May 2004 16:54:27 -0700 (PDT)
+From: C Y
+To: daly@idsi.net, miked@nag.co.uk
+Subject: Re: [Axiom-developer] OpenMath
+Cc: alenka_zajka@mail.ru, elena@orcca.on.ca, miked@nag.co.uk
+
+--- root wrote:
+>
+> It is clear from numerous discussions that Axiom needs to develop a
+> notebook-like interface. Several people told me that they don't use
+> Axiom specifically because it lacks a notebook.
+
+Perhaps a GUI developed for one CAS, if it uses a sufficiently open
+license, could become the "standard" UI that everyone can plug their
+programs into? I've thought about this when considering an McCLIM GUI
+for Maxima - if it is written without using Maxima code itself, and
+licensed under the BSD license, Axiom could then use the same UI code
+and just make the bridge between the interface graphics and the Axiom
+syntax. Indeed, if sockets communication is used, in theory ANY system
+could use it as an interface.
+
+> So, what are the choices?
+>
+> MMA uses ascii text as their notebook representation. It would be
+> useful to generate "compatible" input/output so we could use the
+> same front-end. However, the front-end is closed, proprietary, and
+> expensive. Donating the representation of the math to W3C doesn't
+> address the real issue.
+
+I think we can scratch any commercial GUI as a potential interface.
+
+> I can't use the Maple front-end for the same reasons.
+>
+> I'd like to use Integre's (formerly IBM's) techexplorer and MathML
+> editor but their license specifically states that I can't:
+
+[snip]
+
+> Thus I'm left with no choice but to waste a year of my life drawing
+> pretty pictures of characters on a screen.
+
+Here's my opinion, for what it's worth. Don't worry about a notebook
+interface anytime soon - there's a lot more to do on the Axiom core
+first. An interface should be considered when Axiom is stable and
+feature complete enough for a major push into end user territory, at
+least IMHO. Maxima has essentially chosen to set the priorities on
+making a completely solid math core (at least as much as possible :-)
+and THEN worrying about a GUI to sell it to the users. Axiom may be
+further along on the math core part, so perhaps y'all are already
+there. Anyway, if you feel it would be a waste of your time to do a
+GUI then my advice is don't worry about it - do what you like and/or
+think is a good use of your time. Serious users will be fine with the
+text interface, and adding a GUI too early might lead people to expect
+more than is currently there. Just some thoughts.
+
+> OpenMath and MathML only
+> address a very small portion of the problem and, worse yet, add
+> limits to the data representation I can choose. And I don't see how
+> to carry Axiom's Types in OpenMath's data representation. Another
+> incompatible notebook simply fragments the computational mathematics
+> domain into yet another pointless "camp". Believe me, I'd much rather
+
+> spend my time using other people's work and get on with making the
+> math better.
+
+I don't think the notebooks fragment the community any more than the
+systems themselves do - it isn't reasonable to, say, expect Mathematica
+to open a Maple notebook since the feature sets are different. My
+ideal answer to the open source math notebook question (probably
+different from everyone else's ;-) would be:
+
+a) be lisp based (since the two largest open source symbolic CASs are
+in lisp, and they will have the most incentive to maintain them, it
+makes a certain amount of sense. Plus all the goodness of doing it in
+lisp in the first place.)
+
+b) would utilize things like cl-typesetting and cl-pdf to have native
+ability to export nicely formatted documents, and also export to clean
+LaTeX for TeX fans and MathML for web. Any math expression the
+interface doesn't know how to render is simply rendered as it is see in
+the input.
+
+c) would have all the logic dealing with communication with and
+translation of various CASs contained in one place, and well documented
+to allow for easily adapting the system to another CAS.
+
+d) would have its own interactive graphing capabilities tuned to CAS
+oriented tasks, both for better graphing and to eliminate cross
+platform plotting issues.
+
+e) more stuff I'm not thinking of right now, and any brilliant UI ideas
+anybody has had but has had no framework to try them out. Another
+benefit of Lisp would be that extensions would be simple to write and
+add, if the codebase and apis are clean and well defined. For example,
+a package like Feyncalc could load interface elements specifically
+designed to help with high energy physics type work. Or for a lab a
+package could be coded where the interface essentially becomes whatever
+is ideal for each stage of the lab - the instructor could limit the UI
+to show only the relevant components, and define some custom ones if
+desired. I'm guessing doing such things in a non lisp language in a
+cross platform matter wouldn't be so straightforward, but that's just a
+guess.
+
+Drawbacks - lots of people don't know lisp and don't want to learn,
+which might limit people from wanting to customize the GUI, McCLIM
+would need to have backends implimented on platforms the CASs are
+interested in running on, implimenting 3D interactive plotting would
+take some work (probably true anywhere though).
+
+TeXmacs is very, very nice for editing a document and inserting some
+math here and there. But from what I understand it doesn't have the
+flexibility to do things like Mathematica's button panels (pros may not
+like em but they're a godsend when new users are working), interactive
+graphics, or 2D input. Perhaps it will eventually become the frontend
+of choice, but my instincts tell me that an interface designed
+specifically to be an interface to a CAS might be better for certain
+types of use.
+
+\start
+Date: Thu, 13 May 2004 20:48:24 -0400
+From: root
+To: smustudent1@yahoo.com
+Subject: Re: [Axiom-developer] OpenMath
+
+C Y,
+
+Does McCLIM run on GCL?
+Where can I find it?
+And where can I find info on cl-pdf?
+I'm much rather code it in lisp, especially since it would then be
+easy to "lift" it to the axiom level.
+
+\start
+Date: Thu, 13 May 2004 17:51:48 -0700 (PDT)
+From: C Y
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] OpenMath
+
+--- root wrote:
+> C Y,
+>
+> Does McCLIM run on GCL?
+
+Not currently - I think GCL still has ANSI issues to work out. I'm
+sure it will happen at some point, but the McCLIM team has focused on
+implimenting the spec first, and porting will probably come later.
+(Although, I've never actually tried on the newer CVS ansi images -
+perhaps it would be simpler than I think.)
+
+> Where can I find it?
+
+http://clim.mikemac.com/
+
+> And where can I find info on cl-pdf?
+
+http://www.fractalconcept.com/asp/html/cl-pdf.html (Examples are
+pretty nifty.)
+
+Also possibly related is
+http://www.fractalconcept.com/asp/html/cl-typesetting.html The example
+document shows a basic mathematics example.
+
+> I'm much rather code it in lisp, especially since it would then be
+> easy to "lift" it to the axiom level.
+
+Agreed. :-). I imagine you probably have lots if ideas, but I had an
+idea for a "parenthesis matching plus" GUI mode to help people entering
+expressions keep track of nesting. Syntax used is Maxima's but it
+would probably work the same way for Axiom, if you're interested.
+http://maxima.sourceforge.net/wiki/index.php/CY%27s%20conceptual%20stuff
+
+We bounced a lot of GUI thoughts back and forth on the Maxima list
+before we decided we should get a math program built :-). Worth
+keeping an eye on are the STIX fonts (www.stixfonts.org) which
+hopefully could someday do for an McCLIM gui what Mathematica's fonts
+do for their UI, only hopefully looking better while doing it ;-).
+
+
+\start
+Date: Fri, 14 May 2004 09:19:02 +0200 (CEST)
+From: Bertfried Fauser
+To: C Y
+Subject: Re: [Axiom-developer] OpenMath
+Cc: Bill Page
+
+Hi,
+
+can you imagine that people are afraid of lisp? A further web location
+which is doing the _lispification of everything_ "LoE" is
+
+http://www.cliki.net/index
+
+regarding Bills LaTeX-wiki, perhaps this is the ultimative lispified
+version. Is there a lisp-port of (La(TeX)) also available :-0
+
+\start
+Date: Fri, 14 May 2004 05:12:56 -0400
+From: root
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] OpenMath
+Cc: bill.page1@sympatico.ca
+
+xml is lisp syntax for people who are afraid of parens :-)
+
+I'll look at the cliki.net on the morrow. thanks. --t
+
+\start
+Date: Fri, 14 May 2004 05:58:37 -0400
+From: root
+To: bill.page1@sympatico.ca
+Subject: [Axiom-developer] wiki
+Cc: axiom-developer@nongnu.org, daly@idsi.net
+
+been looking at the wiki. great stuff.
+
+i'm working on another book.
+perhaps i'll try to develop it using your wiki as an experiment.
+
+\start
+Date: 14 May 2004 11:06:30 +0200
+From: WZocher@t-online.de (Wolfgang Zocher)
+To: axiom-developer
+Subject: Re: [Axiom-developer] OpenMath
+
+C Y writes:
+[snip]
+
+> Here's my opinion, for what it's worth. Don't worry about a notebook
+> interface anytime soon - there's a lot more to do on the Axiom core
+> first. An interface should be considered when Axiom is stable and
+> feature complete enough for a major push into end user territory, at
+> least IMHO. Maxima has essentially chosen to set the priorities on
+> making a completely solid math core (at least as much as possible :-)
+> and THEN worrying about a GUI to sell it to the users. Axiom may be
+> further along on the math core part, so perhaps y'all are already
+> there. Anyway, if you feel it would be a waste of your time to do a
+> GUI then my advice is don't worry about it - do what you like and/or
+> think is a good use of your time. Serious users will be fine with the
+> text interface, and adding a GUI too early might lead people to expect
+> more than is currently there. Just some thoughts.
+
+I truly second your thoughts. Thanks for sharing them with us!
+
+\start
+Date: 14 May 2004 10:56:59 +0200
+From: WZocher@t-online.de (Wolfgang Zocher)
+To: axiom-developer
+Subject: [Axiom-developer] Syntax Axiom-XL
+
+Hi,
+
+does anybody know of a formal (BNF) description of the Axiom Extension
+Language?
+
+\start
+Date: Fri, 14 May 2004 10:25:25 +0100
+From: Mike Dewar
+To: Wolfgang Zocher
+Subject: Re: [Axiom-developer] Syntax Axiom-XL
+
+Hi Wolfgang,
+
+If by the "Axiom Extension Language" you mean Axiom-XL (later Aldor),
+then this is contained in section 22 of the User Guide which was
+distributed with Axiom when it was a NAG product. You can find the
+latest version of this document on the Aldor website
+http://www.aldor.org.
+
+If you mean either the language accepted by the old Axiom compiler
+("spad") or the interperter, then I'm not aware of a formal grammar for
+either.
+
+Kind regards, Mike.
+
+On Fri, May 14, 2004 at 10:56:59AM +0200, Wolfgang Zocher wrote:
+> Hi,
+>
+> does anybody know of a formal (BNF) description of the Axiom Extension
+> Language?
+
+\start
+Date: Fri, 14 May 2004 11:32:33 -0400
+From: root
+To: WZocher@t-online.de
+Subject: [Axiom-developer] Axiom BNF
+
+The Aldor (external C-based compiler) and the Spad (internal lisp compiler)
+accept approximately the same language except that Aldor wants trailing
+semi-colons and has some extensions/modifications for dealing with the
+fact that it has to run standalone.
+
+The BNF in the book or at the aldor.org site should be nearly correct
+for the Spad compiler.
+
+\start
+Date: Fri, 14 May 2004 11:56:26 -0400
+From: root
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] OpenMath
+Cc: bill.page1@sympatico.ca
+
+BF,
+
+I looked at the cliki.net website.
+I see Maxima is listed under the Mathematics link.
+I couldn't find a package for graphics under lisp
+but I found out that there is a tcl/tk toolkit link in GCL.
+Once I figure out how to handle the sockets issue I'll look
+into the tck/tk link.
+Thanks for the ref.
+
+\start
+Date: Fri, 14 May 2004 08:28:21 -0700 (PDT)
+From: C Y
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] OpenMath
+Cc: bill.page1@sympatico.ca
+
+--- root wrote:
+> BF,
+>
+> I looked at the cliki.net website.
+> I see Maxima is listed under the Mathematics link.
+
+An Axiom entry would probably also be appropriate.
+
+> I couldn't find a package for graphics under lisp
+
+Yes, I don't think there is really a good one yet. McCLIM has some
+sort of 2D graphing capabilities under development, but I don't know
+much about it - scigraph I think they call it?
+
+> but I found out that there is a tcl/tk toolkit link in GCL.
+
+Eurrrg. I don't know if that has been tested in a serious way in
+years. I recall some discussion about it a while back on the gcl
+archives - Camm, if you're on this list can you give us a status
+update?
+
+I don't know if tcl/tk is the best environment for a notebook interface
+- it would probably be difficult to port a gcl/tcl/tk GUI to other
+lisps. If only gcl support is important than it might be a way to go.
+Otherwise, if a cross-implimentation UI must be developed I'd recommend
+McCLIM over tcl/tk - IIRC dealing with the tcl/tk code in xmaxima
+wasn't much fun.
+
+> Once I figure out how to handle the sockets issue I'll look
+> into the tck/tk link. Thanks for the ref.
+
+Since Maxima is GPL I guess the socket code itself can't be used, but
+you might be able to use the technique?
+
+Maybe this would also be of help:
+
+http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/io/sockets/0.html
+
+\start
+Date: Mon, 17 May 2004 02:19:33 -0400
+From: root
+To: miked@nag.co.uk
+Subject: Re: [Axiom-developer] OpenMath
+
+Mike,
+
+When you finalize the next draft standard could you point me at a copy?
+
+It seems the best path forward would be to:
+
+ modify the domains to serialize their data
+ this is required to properly output the openmath
+
+ modify OpenMath domain to work with )set output openmath on
+ this makes openmath work like all of the other output streams
+
+ move OpenMath off the C code base and onto the latest standard
+ keeping up with the world at large.
+
+\start
+Date: Mon, 17 May 2004 11:40:29 +0200 (CEST)
+From: "m.rubey"
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] Questions
+
+I'm trying to port Christian Krattenthaler's Mathematica program rate (=
+german for "guess!"), which guesses formulas for sequences of numbers
+given the first few terms, however, I failed somehow.
+
+Here are my questions, which proved to be obstacles: (I tried to be as
+concise as possible)
+
+--------------------- first obstacle ------------------------
+
+
+it seems that I need an own version of product:
+
+(1) -> f == n +-> product(product(i,i=1..j),j=1..n)
+ Type:
+Void
+(2) -> f(n)
+
+ n j
+ ++-++ ++-++
+ (2) | | | | i
+ | | | |
+ j= 1 i= 1
+ Type: Expression
+Integer
+(3) -> f(3)
+ Loading /home/rubey/axiom/mnt/linux/algebra/PI.o for domain
+ PositiveInteger
+ Compiling function f with type PositiveInteger -> Expression Integer
+
+
+ >> Error detected within library code:
+ not a kernel
+
+protected-symbol-warn called with (NIL)
+
+Note that I would want my program to spit out a sum as in (2), but
+certainly I would want it to be evaluable.
+
+Furthermore, I'm having a problem spitting out something like
+
+product(x^i,i=1..n)
+
+where x is a fractional polynomial over PF 2, for example... What's the
+type of this thing, EXPR PF 2 does not work, of course. I cannot simply
+take EXPR INT, since my factors can be functions from INT into any
+(infinite) field.
+
+I tried
+
+ g(i:INT):FRAC UP(x,PF 2) == x^i+1
+
+however, this does not work, of course:
+
+f(n:INT):FRAC UP(x,PF 2) == product(g(i),i=1..n)
+
+a little better is
+
+ f(n:INT):FRAC UP(x,PF 2) == reduce(*,[g(i) for i in 1..n])
+
+in which case I don't get f(n) for symbolic n however...
+
+In fact, it seems to me that I'd need a EXPR domain which does not need
+OrderedSet...
+
+Any ideas?
+
+----------------------------------------------------------------
+--------------------- second question --------------------------
+
+why don't these functions compile ???
+
+Tst(xx, F): Exports == Implementation where
+ xx: Symbol
+ F: Field
+ UP ==> UnivariatePolynomial
+
+ Exports == with
+ tst: (UP(xx, F)) -> Polynomial F
+
+ Implementation == add
+ tst(poly) == poly::Polynomial F
+
+-- ((|::| |poly| (|Polynomial| F)))
+-- ****** level 1 ******
+-- $x:= (:: poly (Polynomial F))
+-- $m:= (Polynomial F)
+-- $f:=
+-- ((((|poly| # #) (|$Information| #) (~= # # #) (= # # #) ...)))
+--
+-- >> Apparent user error:
+-- Cannot coerce poly
+-- of mode (UnivariatePolynomial xx F)
+-- to mode (Polynomial F)
+
+Tst1(xx, F): Exports == Implementation where
+ xx: Symbol
+ F: Field
+ UP ==> UnivariatePolynomial
+
+ Exports == with
+ tst: () -> UP(xx, F)
+
+ Implementation == add
+ tst() ==
+ xy: UP(xx, F) := monomial(1,1)$UP(xx, F)
+
+ (1+xy*xy)
+-- works
+
+Tst2(xx, F): Exports == Implementation where
+ xx: Symbol
+ F: Field
+ UP ==> UnivariatePolynomial
+
+ Exports == with
+ tst: () -> UP(xx, F)
+
+ Implementation == add
+ tst() == (1+xy^2)
+
+-- (+ 1 (IF | << xy >> | |false| |true|))
+-- ****** level 3 ******
+-- $x:= xy
+-- $m:= (Boolean)
+-- $f:=
+-- ((((|$Information| #) (~= # # #) (= # # #) (|coerce| # # #) ...)))
+--
+-- >> Apparent user error:
+-- cannot compile (+ (One) (IF xy false true))
+--
+
+Tst3(xx, F): Exports == Implementation where
+ xx: Symbol
+ F: Field
+ UP ==> UnivariatePolynomial
+
+ Exports == with
+ tst: () -> UP(xx, F)
+
+ Implementation == add
+ tst() == xx::UP(xx, F)
+
+-- ((|::| |xx| (|UnivariatePolynomial| |xx| F)))
+-- ****** level 1 ******
+-- $x:= (:: xx (UnivariatePolynomial xx F))
+-- $m:= (UnivariatePolynomial xx F)
+-- $f:=
+-- ((((|$Information| #) (~= # # #) (= # # #) (|coerce| # # #) ...)))
+--
+-- >> Apparent user error:
+-- Cannot coerce xx
+-- of mode (Symbol)
+-- to mode (UnivariatePolynomial xx F)
+
+
+\start
+Date: Tue, 18 May 2004 10:49:11 -0400
+From: David Escott
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] Book instructions
+
+Could someone please repost the instructions on how to build the book. I
+think that mailman has replaced all the email addresses with
+@bogus.example.com in the archives.
+
+And what tarball is it in the zips folder? The only possibility seems to
+be tla-1.1 which I think is the source for tla and not for the book.
+
+\start
+Date: 18 May 2004 16:07:01 -0400
+From: Camm Maguire
+To: David MENTRE
+Subject: Re: Machine clusters & Axiom (was: Re: [Axiom-developer] Re: [Gcl-devel] gcl sockets)
+
+Greetings!
+
+David MENTRE writes:
+
+> Hello Tim,
+>
+> root writes:
+>
+> > (b) in the long term there is a sub-effort to put Axiom on a beowulf.
+> > I have access to a 128 node cluster with 2Ghz processors on each node.
+> > Of course getting Axiom running in small-grain parallel mode (as
+> > opposed to an independent Axiom on each node) is a hard problem
+> > on its own. I've done some initial experiments with a matrix domain
+> > (parallel matrix multiply) but not much since then. I was hoping to
+> > have a student to work on this but that fell thru.
+>
+> As a side note, I've done my PhD in a research team looking at those
+> cluster issues (and my own PhD was on the shared memory topic). I doubt
+> that you can gain any speedup on a beowulf-like cluster for fine grain
+> computations, due to high cost of communications (to much latency, to
+> little bandwidth). However, coarse grain parallelism (e.g. one long
+> Axiom computation par node) seems to me much more doable.
+>
+
+Agreed. In general, I know of no broad area of symbolic computation
+which would present an easy basis for coarse grain factorization. And
+the systems we are discussing don't seem to do numerical work much,
+though if they did, the obvious thing to do would be to interface with
+blas/lapack interfaces, which can be made binary compatible with
+automatically tuned versions (atlas, which can be multithreaded) and
+possibly parallel versions, e.g. pblas, scalapack.
+
+\start
+Date: 18 May 2004 17:01:21 -0400
+From: Camm Maguire
+To: "Siver Andrey"
+Subject: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima , feyncalc@feyncalc.org
+
+Greetings, and thanks for your interest in this project!
+
+In general, we are still assessing the best way to proceed, and are
+hoping to get a response from the feyncalc developers on their
+opinions. The topic has been raised in both maxima and axiom groups,
+in both of which there is considerable interest to proceed. There is a
+tool called mockmma which supplies a mathematica-like interface in
+lisp, and a parser which is most likely the easiest way to get
+started. I've successfully compiled it in ansi gcl, but haven't yet
+had time for much more.
+
+Take care,
+
+"Siver Andrey" writes:
+
+> Hi.
+>
+> I saw your message on the FeynCalc forum and it was interested me.
+>
+> How is it possible for me to partcipate in the project of the designing F=
+eynCalc-like package for MAXIMA?
+>
+> By the way, MAXIMA is not the only free software CAS as I know. AXIOM has=
+ open sourses at present.
+>
+> Andrey Siver,
+>
+> Russia, Protvino
+
+\start
+Date: Tue, 18 May 2004 18:24:09 -0400
+From: root
+To: camm@enhanced.com
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, siver@mx.ihep.su, feyncalc@feyncalc.org
+
+Are the algorithms described anywhere?
+
+While a GCL version might be of interest I think there is much to
+be learned by trying to port and properly document the algorithms.
+
+\start
+Date: Tue, 18 May 2004 17:19:20 -0400
+From: root
+To: escott@fas.harvard.edu
+Subject: Re: [Axiom-developer] Book instructions
+
+David,
+
+The book is built automatically into:
+
+(yourpath)/axiom/mnt/linux/doc/book.dvi
+
+\start
+Date: Tue, 18 May 2004 14:24:16 -0700 (PDT)
+From: C Y
+To: Camm Maguire
+Subject: Re: [Axiom-developer] OpenMath
+Cc: bill.page1@sympatico.ca, Bertfried.Fauser@uni-konstanz.de
+
+--- Camm Maguire wrote:
+
+> > Eurrrg. I don't know if that has been tested in a serious way in
+> > years. I recall some discussion about it a while back on the gcl
+> > archives - Camm, if you're on this list can you give us a status
+> > update?
+>
+> There was a serious user of gcl-tk on the gcl list recently. To my
+> knowledge the interface is quite servicable. There is nothing
+> particularly gcl specific about the tk interface code to my
+> knowledge. And TK itself is likely far more portable and widely used
+> than McCLIM, even perhaps than lisp in general :-).
+
+True, at least with regards to McCLIM at this point.
+
+> There is also cl-gtk, which works in GCL.
+>
+> The big issue in my eyes here is that no one likely wants to be a GUI
+> expert, so something that is as trouble free as possible has a higher
+> premium than something elegant or advanced in terms of UI concepts.
+
+Yes, I suppose that's true. But elegant and advanced might be useful
+when trying to lure in new users.
+
+> So honestly I think the best route for newish projects is to use
+> cl-gtk, relying on the enormous user base of gtk, the compiled
+> efficiency of the code, and friendly tools like glade for making user
+> interfaces graphically. One can even change the UI with a runtime
+> sources xml type file.
+
+That might be a good way to start - has the gtk interface matured
+recently?
+
+> Lisp is so great in general that there is an aversion to doing things
+> outside it, but I think this can just slow things down after a point.
+
+Short term, probably. Long term... well, in long term we can just
+impliment the features of whatever other interfaces have been written
+using lisp, once the supporting libraries are ready :-P.
+
+\start
+Date: 18 May 2004 17:16:18 -0400
+From: Camm Maguire
+To: C Y
+Subject: Re: [Axiom-developer] OpenMath
+Cc: bill.page1@sympatico.ca, Bertfried.Fauser@uni-konstanz.de
+
+Greetings!
+
+C Y writes:
+
+> --- root wrote:
+> > BF,
+> >
+> > I looked at the cliki.net website.
+> > I see Maxima is listed under the Mathematics link.
+>
+> An Axiom entry would probably also be appropriate.
+>
+> > I couldn't find a package for graphics under lisp
+>
+> Yes, I don't think there is really a good one yet. McCLIM has some
+> sort of 2D graphing capabilities under development, but I don't know
+> much about it - scigraph I think they call it?
+>
+> > but I found out that there is a tcl/tk toolkit link in GCL.
+>
+> Eurrrg. I don't know if that has been tested in a serious way in
+> years. I recall some discussion about it a while back on the gcl
+> archives - Camm, if you're on this list can you give us a status
+> update?
+>
+
+There was a serious user of gcl-tk on the gcl list recently. To my
+knowledge the interface is quite servicable. There is nothing
+particularly gcl specific about the tk interface code to my
+knowledge. And TK itself is likely far more portable and widely used
+than McCLIM, even perhaps than lisp in general :-).
+
+There is also cl-gtk, which works in GCL.
+
+The big issue in my eyes here is that no one likely wants to be a GUI
+expert, so something that is as trouble free as possible has a higher
+premium than something elegant or advanced in terms of UI concepts.
+So honestly I think the best route for newish projects is to use
+cl-gtk, relying on the enormous user base of gtk, the compiled
+efficiency of the code, and friendly tools like glade for making user
+interfaces graphically. On ecan even change the UI with a runtime
+sources xml type file.
+
+Lisp is so great in general that there is an aversion to doing things
+outside it, but I think this can just slow things down after a point.
+
+Take care,
+
+> I don't know if tcl/tk is the best environment for a notebook interface
+> - it would probably be difficult to port a gcl/tcl/tk GUI to other
+> lisps. If only gcl support is important than it might be a way to go.
+> Otherwise, if a cross-implimentation UI must be developed I'd recommend
+> McCLIM over tcl/tk - IIRC dealing with the tcl/tk code in xmaxima
+> wasn't much fun.
+>
+> > Once I figure out how to handle the sockets issue I'll look
+> > into the tck/tk link. Thanks for the ref.
+>
+> Since Maxima is GPL I guess the socket code itself can't be used, but
+> you might be able to use the technique?
+>
+> Maybe this would also be of help:
+>
+> http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/io/sockets/0.html
+
+\start
+Date: Wed, 19 May 2004 09:15:25 +0200 (CEST)
+From: Bertfried Fauser
+To: root
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: camm@enhanced.com, maxima@www.ma.utexas.edu, siver@mx.ihep.su, feyncalc@feyncalc.org
+
+On Tue, 18 May 2004, root wrote:
+
+> Are the algorithms described anywhere?
+>
+> While a GCL version might be of interest I think there is much to
+> be learned by trying to port and properly document the algorithms.
+
+Hi,
+
+as fare as I understand the package (havn't though done much with it, so I
+might be wrong), it is designed for very "practical" purpose (ie
+phenomenology.) Many problems can be subsummarized in a larger frame of
+mathematics. Given the type system of AXIOM, it would be, in my eyes, a
+fraud to implement something like "Dirac matrixes" and trace rules, while
+this is a closed structure in a *-autonomous category. However, I am still
+not able myself to give AXIOM code for such a vast general thing.
+
+Most CAS do _not_ document actual algorithms. Its even very difficult (as
+a non expert)= to find/lookup the currently favored algorithms (for say
+comparison with own better(?) ones). So I consider the pamphlet idea to be
+one of the most important of AXIOM and would support a FeynCalc package
+iff its really _fully_ documented via pamphlet format _including_ all
+algorithmical details.
+
+\start
+Date: Wed, 19 May 2004 08:13:34 -0400
+From: root
+To: camm@enhanced.com
+Subject: Re: [Axiom-developer] OpenMath
+Cc: Bertfried.Fauser@uni-konstanz.de, bill.page1@sympatico.ca
+
+CY, Camm,
+
+I spent last night running the gcl-tk demos in GCL. The secret to
+getting them to run, which you probably already know, is to
+preceed loading the demo code with:
+
+(in-package "TK")
+(tkconnect)
+
+which didn't seem to be documented anywhere.
+
+Anyway, most of them worked although I got some strange error messages
+and undefined variables for some cases (e.g. demos-4.2/widget.lisp)
+(I was surprise to learn that ".t" was a valid lisp identifier.
+What mind could construct such a beast?)
+
+I'll scratch up a simple example once I figure out how to write a tcl/tk
+program.
+
+What language is the maxima GUI written in?
+Can we generalize that to work for Axiom?
+That way we can share GUI efforts between Axiom and Maxima.
+
+\start
+Date: Wed, 19 May 2004 08:06:50 -0400
+From: root
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, siver@mx.ihep.su
+
+> Most CAS do _not_ document actual algorithms. Its even very difficult (as
+> a non expert)= to find/lookup the currently favored algorithms (for say
+> comparison with own better(?) ones).
+
+I'm also the lead developer on Magnus, another special-purpose computer
+algebra system, and I'm having the same struggle. I'm currently writing
+documentation for the system and need to describe the algorithms, some
+of which have never been written down before. It is a painful process
+to describe an algorithm from computer code, especially when it is
+written by programmers who don't really understand the theory.
+
+We need to keep the theory and the code together and have each one
+explain the other. How else can you show that the code does what it
+is intended to do?
+
+That's why I'm interested in the papers behind FeynCalc. If we can
+get it into a literate format the code can be maintained for several
+systems. But if we have to maintain and port code without the
+underlying theory the task is hopeless.
+
+\start
+Date: Wed, 19 May 2004 08:27:03 -0700
+From: Bob McElrath
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, siver@mx.ihep.su
+
+Bertfried Fauser [fauser@spock.physik.uni-konstanz.de] wrote:
+>
+> Hi,
+>
+> as fare as I understand the package (havn't though done much with it, so I
+> might be wrong), it is designed for very "practical" purpose (ie
+> phenomenology.) Many problems can be subsummarized in a larger frame of
+> mathematics. Given the type system of AXIOM, it would be, in my eyes, a
+> fraud to implement something like "Dirac matrixes" and trace rules, while
+> this is a closed structure in a *-autonomous category. However, I am still
+> not able myself to give AXIOM code for such a vast general thing.
+
+The *purpose* of FeynCalc is to be a general purpose framework for doing
+quantum field theory calculations. That is, dirac matrices, trace
+rules, Feynman rules from Lagrangians, representations for fields and
+the like.
+
+It also contains code for doing one-loop integrals. This same code
+exists in several places (I know of a fortan library "ff" and a Maple
+package "xloops" as well), and I can point to the papers if people
+desire. But the loop code is only half of FeynCalc.
+
+The actual algorithms are straightforward, but very tedious to
+calculate, so thus the results are collected into libraries like
+FeynCalc. There are yet a handful of obstacles in dealing with
+divergences that have kept us from writing a fully automatic method of
+computing these loop integrals. At one loop I think it can be fully
+automatic, but I do not think this is something a non-expert would want
+to tackle.
+
+The "algorithms" are documented in QFT textbooks such as Peskin &
+Schroeder "An Introduction to Quantum Field Theory", Weinberg "Quantum
+Theory of Fields", etc. This is a one-year graduate level physics
+course. The decomposition of loop integrals into scalar integrals was
+done by Passarino and Veltman
+ http://dx.doi.org/10.1016/0550-3213(79)90234-7
+though these days it's not the only way...
+
+\start
+Date: Wed, 19 May 2004 09:14:38 -0700
+From: Richard Fateman
+To: stavros.macrakis@verizon.net
+Subject: Re: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, Bertfried.Fauser@uni-konstanz.de, camm@enhanced.com, feyncalc@feyncalc.org, siver@mx.ihep.su
+
+To illustrate one of the pitfalls, consider the well-known
+books "Numerical Recipes in X" for various programming languages
+X (Fortran, C, Pascal, Lisp??).
+Some people are very enthusiastic about these books, but they
+are usually people who area not experts in numerical methods.
+The attraction of the recipes is that they are easy to understand.
+The problem with the recipes is that they are easy to understand,
+and are therefore not robust and/or efficient.
+
+An analogy might be to airplanes. You probably feel safer
+in a Boeing 747 -- a plane which is too complicated for you to
+understand, but which has been extensively tested,
+than an ultra-light airplane using a lawn-mower engine and
+built out of wood and nylon fabric. Even though the ultra-light
+airplane might be understandable to you.
+
+You can use an algorithm copied out of Numerical recipes, (or
+from von zur Gathen's Modern Computer Algebra,) but these would be like
+the ultra-light version. Containing the 10% of the code that
+does most of the problem, most of the time, but sweeps some
+problems under the rug.
+
+If you want something engineered to be robust and efficient,
+you will have to look elsewhere, perhaps in Maxima, Axiom, etc.
+Or maybe not even in those systems.
+
+besides which, if you have theory and code together, they
+may not be mutually supportive. One of the problems is
+that they may not even agree!
+
+A better approach may be to have the code derived automatically
+and correctly from the theory, and then automatically optimized.
+A difficult problem in general, but something done in part
+by compilers.
+
+RJF
+
+Stavros Macrakis wrote:
+
+>>We need to keep the theory and the code together and have
+>>each one explain the other. How else can you show that the
+>>code does what it is intended to do?
+>>
+>>
+>
+>That is a very hard problem in general.
+>
+>Good algorithms (as opposed to naïve ones) are often connected to theory
+>in complicated ways -- just look at published algorithms. Then the
+>practical implementation of the algorithm is often connected to the
+>published algorithm in complicated ways.
+>
+>"Literate programming" is effective when the algorithm has a nice
+>hierarchical structure, but there are many tricks that good algorithm
+>designers and programmers use which don't fit well into that structure.
+>Some years ago, I participated in a conference on transformational
+>programming where Tarjan talked about this... it was humbling.
+>
+>Personally, I think this is a fascinating area, but it really is a
+>research problem in itself. So if your goal is solving physics/math
+>problems, I would recommend that you be pragmatic about how far you go
+>in trying to systematize the transition from theory to code.
+
+\start
+Date: Wed, 19 May 2004 13:02:14 -0400
+From: Tim Daly
+To: bob+maxima@mcelrath.org
+Subject: [Axiom-developer] linear time algorithm
+Cc: maxima@www.ma.utexas.edu, bertfried.fauser@uni-konstanz.de, camm@enhanced.com, fateman@cs.berkeley.edu, feyncalc@feyncalc.org, siver@mx.ihep.su
+
+In fact I've faced the same issue with my work on the Andrews-Curtis
+Conjecture. Simply put, this takes a finite representation of a special
+group and applies one of 12 transformation functions iteratively
+looking for the identity element.
+
+The initial algorithm is clear but garbage collects like mad (lisp).
+The second iteration modifies list storage in place but string-conses.
+The third algorithm modifies strings in place but copies on overflow.
+The fourth algorithm caches power-of-2 strings (binary buddy).
+
+So the literate program explains the theory and then explains the
+first algorithm. Next it explains the problem and its subsequent
+refinement. Only the last refinement is extracted but the "thought
+processes" leading from the initial implementation up to the efficient
+form of the algorithm are presented.
+
+Simply because the code is highly optimized is no reason not to
+include the theory or the steps across the impedence gap.
+
+\start
+Date: Wed, 19 May 2004 13:36:16 -0400
+From: Tim Daly
+To: bkocay.cs.umanitoba.ca@rio.sci.ccny.cuny.edu
+Subject: [Axiom-developer] The Hopcroft-Tarjan Planarity Algorithm paper
+
+Dr Kocay,
+
+Your paper, "The Hopcroft-Tarjan Planarity Algorithm" has come up
+on our mailing list as an example of a well-written paper which
+presents nearly-runnable code.
+
+I'm looking at the problem of "literate programming" which combines
+research papers and runnable code in one document. I'm gathering examples
+of papers which present clear pseudo-code and creating Axiom[*] programs
+which implement the pseudo-code, combined with the original paper in
+one document.
+
+I'd like permission to use your paper as a canonical example of
+literate programming.
+
+Tim Daly
+axiom@tenkan.org
+daly@idsi.net
+
+[*] Axiom is a free, general purpose computer algebra system
+http://savannah.nongnu.org/projects/axiom
+
+\start
+Date: Wed, 19 May 2004 18:03:37 +0200 (CEST)
+From: Bertfried Fauser
+To: Bob McElrath
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, siver@mx.ihep.su
+
+On Wed, 19 May 2004, Bob McElrath wrote:
+
+Dear Bob,
+
+ thank you for your explanation. Are there Hopf algebra methods and
+recently made advances also implemented in FeynCalc? The package Rafal and
+I developed, benefitted is speed and conceptual design cery much from Hopf
+algebraic techniques.
+ From a technical point of view, its algorithmically more sound to
+try to work in the Epstein-Glaser (etc pp) framework and *not* in the
+momentum (Feynman graph) picture, since the physical process is split up
+in an infinite series of integrals to be evaluated. AFAIK Hopf algebraic
+techniques seem to be the only way to come up with concise _and_
+algorithmically effective solutions.
+
+ I am off for three weeks, and will look into FeynCalc, I can
+imagine to help withits portation to AXIOM though for several personal
+reasons. If you are interested in the things I have in mind, you may
+consider the recent JPysA article on Quantum fieldtheory and Hopf algebra
+cohomology, by Brouder,BF,Frabetti and Oeckl. Many of the calculations
+there were checked by the above mentioned package, though it was _not_
+designed for that purpose.
+
+PS:
+
+> The "algorithms" are documented in QFT textbooks such as Peskin &
+> Schroeder
+
+Would you really make this a claim? I still think, that without expert
+knowledge one cannot derive even simple results out of these sources...
+
+\start
+Date: Wed, 19 May 2004 13:39:50 -0400
+From: Tim Daly
+To: "Vladimir Bondarenko"
+Subject: [Axiom-developer] Axiom project status
+Cc: axiom-developer@nongnu.org, daly@idsi.net
+
+Vladimir,
+
+Axiom is alive and being further developed. The latest version is at
+http://savannah.nongnu.org/projects/axiom
+
+\start
+Date: Wed, 19 May 2004 18:18:22 +0200 (CEST)
+From: Bertfried Fauser
+To: Tim Daly
+Subject: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, Stavros Macrakis , siver@mx.ihep.su
+
+On Wed, 19 May 2004, Tim Daly wrote:
+
+Dear Tim,
+
+ I agree on your thougth, and will respond to a few things later, I
+wonder how you manage to do all these things...
+
+Just one remark:
+
+> First, claims are made which cannot be reproduced. Citing results of
+> the program runs without presenting the programs is equivalent to
+> citing theorems without providing proofs. How can a referee properly
+> review such work? Physics and chemistry require reproduced results
+> before claims are accepted.
+
+curiously, the clifford package emerged out of the mind of Rafal whene
+refereeing a paper based on extensive mathematica computations. Since he
+had no chance to recalculate or understand, he programed a set of maple
+(just that was on his computer) routines to check the claims (which were
+found true by teh way), having the code, and the effort done, he embarked
+to compleete the functionality, by now, over 120 functions and over 750
+pasges of documentation shipping with the package, where you will find
+even unpublished math, so I hope for such a future for AXIOM, but as you
+mention it needs to be portable on the basis of peopel not program code.
+
+> It's a hard problem but we have 30 years to solve it.
+>
+> Tim "the 30 year horizon" Daly
+
+\start
+Date: Wed, 19 May 2004 10:52:25 -0400
+From: Tim Daly
+To: "Stavros Macrakis"
+Subject: [Axiom-developer] FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, bertfried.fauser@uni-konstanz.de, camm@enhanced.com, feyncalc@feyncalc.org, siver@mx.ihep.su
+
+I know this is a research problem though hardly one that merits papers
+on the subject, I guess.
+
+My goal isn't to solve physics/math problems. My goal is to build a system
+that will be used by computational mathematicians 30 years from now. Once
+this is the stated goal several things become clear.
+
+One clear problem that every system suffers from is that the research
+papers are disconnected from the code. Mathematicians do the research
+and programmers do the code. Usually it is the same person with two
+mindsets. So the math mindset writes the theory with theorems and
+proofs then publishes it, possibly making claims (with no way to
+verify the claims by others). The programmer mindset writes the code
+which hopefully correctly implements the theory but never publishes it.
+Or publishes it as a "contribution" to some system.
+
+Consider the issues this raises for computational mathematicians.
+
+First, claims are made which cannot be reproduced. Citing results of
+the program runs without presenting the programs is equivalent to
+citing theorems without providing proofs. How can a referee properly
+review such work? Physics and chemistry require reproduced results
+before claims are accepted.
+
+Second, the programs are either not available or published as
+contributions. In the first case who is to know if the actual reason
+for an algorithmic speedup turns out to be a compiler switch rather
+than some theoretical reason like term ordering in a groebner basis
+computation? Since it is unpublished the code is likely to die thus
+undermining both the basis for the claim and the possibility that
+other researchers can build on the work.
+
+The second case is even worse in some sense. I have 1100 domains
+in Axiom (some of which I wrote) and 100+ algorithms in Magnus
+with no theoretical documentation; indeed most have no documentation
+at all. In the 30 year view how is the next generation supposed to
+build upon the work we've done so far? How can they see the evolution
+of algorithms? How can they maintain the code without the theory?
+
+Axiom represents over 30 years and over 300 man-years of research.
+I don't believe that there will be funding to build systems that are
+this large and this general. Even if one funded such an effort we
+end up with a lot of rework that virtually no-one wants to do.
+
+So I'm proposing a goal for the 30 year horizon. We need to make an
+effort to collect the theory and the code and reunite the two. I
+realize that there are issues.
+
+One issue is, as you point out, that code has to deal with grubby
+details which the theory can skip. But real design choices are made
+when reducing theory to practice and these design choices greatly
+affect the results. We need to encourage the practice of explaining
+these design decisions. For example, how are infinite objects (like
+groups) represented? We have learned that in simple domains like
+polynomials there are a wide range of design choices (dense, sparse,
+recursive, etc) that are appropriate for different problems.
+
+Another issue is that current systems don't "reach up" close enough to
+the theory. The gap between the theory and the implementation (I call
+it the impedance mismatch) is too large for most systems. For
+instance, Magnus is implemented in C++ which is WAY too close to the
+machine and very, very far away from Infinite Group Theory (the Magnus
+domain). Thus the burden of crossing this gap falls on the
+programmer. Systems like Axiom are much closer to the mathematics. But
+not close enough. We need systems that span this gap in carefully
+structured ways so we can be efficient without being obscure.
+This is one of the root causes of your comment that "the
+practical implementation of the algorithm is often connected to the
+published algorithm in complicated ways". The implemented algorithm
+should not be much longer than the published one.
+
+If we look at the 30 year horizon it is clear that all papers in
+computational mathematics will be online. We must set standards
+now, or at least strive for good examples, that make it possible
+to use the research effectively. In today's terms we should be
+able to "drag and drop" a computational mathematics paper onto
+a system like Axiom and have it immediately available. (In 30
+year terms Axiom should know the "intentional stance" of the
+researcher and automatically incorporate the algorithms).
+
+One of the key problems is that "Computational Mathematics" is
+like "Computer Science" was 30 years ago. Comp Sci was a branch
+of the Math dept (numerical analysis), Engineering (circuit
+minimization), or Business (spreadsheets). It was not recognized
+as its own subject with yet.
+
+Today Computational Mathematics is growing out of Math (research
+papers with no code), Comp Sci (research papers in polynomial
+representation), Physics (clifford algebras, hopf algebras), or
+Engineering (matrix methods), etc. It is not recognized as its
+own subject yet (at least not everywhere. Risc-Linz, UWO, Waterloo,
+and a few other places seem to have done so).
+
+My current religious zealotism and wild-eyed, irrational planning
+(I admit it's over-the-top-painful) claim is that we need to start
+with an old idea "Literate Programming" and evolve it to suit the
+needs of the next generation Computational Mathematician. Thus
+all of Axiom (and soon Magnus) has been rewritten into TeX documents.
+There are no C, Lisp, Spad, Makefile, etc files. Now I'm trying to
+ensure that new code added to the system includes the theory (or
+at least permission to use the paper so I can write the literate
+document).
+
+Thus I would really like to see the papers that provide the theory for
+FeynCalc as well as the code. If I can write one of the algorithms in
+Axiom in a few dozen lines that would be much clearer than a few
+thousand lines of C and I'd have the research paper attached.
+
+It's a hard problem but we have 30 years to solve it.
+
+\start
+Date: Wed, 19 May 2004 13:31:30 -0400
+From: Tim Daly
+To: bob+maxima@mcelrath.org
+Subject: [Axiom-developer] fyi... Planarity algorithm
+Cc: maxima@www.ma.utexas.edu, bertfried.fauser@uni-konstanz.de, camm@enhanced.com, fateman@cs.berkeley.edu, feyncalc@feyncalc.org, siver@mx.ihep.su
+
+Kocay, William "The Hopcroft-Tarjan Planarity Algorithm"
+http://bkocay.cs.umanitoba.ca/G&G/articles/Planarity.pdf
+
+A readably clear explanation with pseudo-code.
+A nearly-literate program.
+
+Another nearly-literate program is
+
+Agrawal, M., Kayal, N. and Saxena, N "PRIMES is in P"
+http://www.cse.iitk.ac.in/primality.pdf
+
+which contains not only the theory but also pseudo-code, a time-complexity
+analysis, loop termination proofs, and loop-invariant statements.
+A near-perfect literate program. I have permission to make it into a
+literate Axiom program and use it as a canonical example.
+
+Both are beautiful pieces of work that tackle reasonably hard theory
+yet get very close to practice. Unfortunately the very last step,
+providing code, still needs to be done.
+
+\start
+Date: Wed, 19 May 2004 09:16:52 -0700
+From: Bob McElrath
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+
+Bertfried Fauser [fauser@spock.physik.uni-konstanz.de] wrote:
+> On Wed, 19 May 2004, Bob McElrath wrote:
+>
+> Dear Bob,
+>
+> thank you for your explanation. Are there Hopf algebra methods and
+> recently made advances also implemented in FeynCalc? The package Rafal and
+> I developed, benefitted is speed and conceptual design cery much from Hopf
+> algebraic techniques.
+
+I do not know...
+
+> From a technical point of view, its algorithmically more sound to
+> try to work in the Epstein-Glaser (etc pp) framework and *not* in the
+> momentum (Feynman graph) picture, since the physical process is split up
+> in an infinite series of integrals to be evaluated. AFAIK Hopf algebraic
+> techniques seem to be the only way to come up with concise _and_
+> algorithmically effective solutions.
+
+Interesting, I will look into this. I know only the feynman graph
+picture, and have not even carried out very many loop calculations.
+
+> I am off for three weeks, and will look into FeynCalc, I can
+> imagine to help withits portation to AXIOM though for several personal
+> reasons. If you are interested in the things I have in mind, you may
+> consider the recent JPysA article on Quantum fieldtheory and Hopf algebra
+> cohomology, by Brouder,BF,Frabetti and Oeckl. Many of the calculations
+> there were checked by the above mentioned package, though it was _not_
+> designed for that purpose.
+
+I am rather toward the user-of-FeynCalc side rather than the
+invent-new-field-theoretic-techniques side. If your Hopf algebra
+methods are more efficent then I'm very interested...
+
+I think the future of mathematics is for experts (such as yourself)
+implementing and maintaining their favorite piece of math. Clearly math
+software can't evolve like normal Open Source because of the expertise
+involved. But it is critical for math to be open, especially as it
+becomes more and more complicated, and more things become intractible to
+do by hand.
+
+FeynCalc involves a significant amount of "interface" for writing
+lagrangians, etc that may not be appropriate for literal translation,
+due to language differences. It may be worth thinking hard about a
+re-implementation of the functionality rather than a direct port.
+
+> > The "algorithms" are documented in QFT textbooks such as Peskin &
+> > Schroeder
+>
+> Would you really make this a claim? I still think, that without expert
+> knowledge one cannot derive even simple results out of these sources...
+
+I agree.
+
+
+\start
+Date: Wed, 19 May 2004 17:53:03 +0200 (CEST)
+From: Bertfried Fauser
+To: Stavros Macrakis
+Subject: RE: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, siver@mx.ihep.su
+
+On Wed, 19 May 2004, Stavros Macrakis wrote:
+
+> Good algorithms (as opposed to na=EFve ones) are often connected to theor=
+y
+> in complicated ways -- just look at published algorithms. Then the
+> practical implementation of the algorithm is often connected to the
+> published algorithm in complicated ways.
+
+Hi,
+
+9I am in the unfortunate situation to have to develop the code for
+my research on my own, or in a two person collaboration. Of course, being
+not a programmer, my algorithms are for sure badly implemented. However,
+"help" I received in the past, was mostly inspired from the conventional
+theory and _failed!_ in many cases to produce correct results.
+
+9Trying to check my code against theorems, it was not so seldom,
+that the program failed to produce the claim. In a few of these cases not
+the program but the theorems were wrong! (assuming mostly things for
+granted which are not, so that pathological situations occure). Doing such
+work, I think, can only perfomed by persons which are living in both parts
+of the game, ....
+
+> "Literate programming" is effective when the algorithm has a nice
+> hierarchical structure, but there are many tricks that good algorithm
+> designers and programmers use which don't fit well into that structure.
+
+Hence, for challenging problems, ie new math! and phys!, I would _reject_
+the lates goodies programmers can provide and favour to have a stable, as
+simple as possible, if possible provable algorithm. New goodies, may be
+later added (in a separate pamphlet file , also by people who do not
+fully understand the theory and purpose of the program. They can then
+check against the slow but stable code. This method at least led me to
+stable and reasonable fast code, which at the and was relatively complex.
+
+9On the other hand, concrete mathematics (see the book of this name
+coathored by D. Knuth) will at the end be also effective mathematics. If a
+problem is _really_ understood, it will have a plain (that is not
+necessarily a simple!) solution which can be straightly implemented.
+
+> Personally, I think this is a fascinating area, but it really is a
+> research problem in itself. So if your goal is solving physics/math
+> problems, I would recommend that you be pragmatic about how far you go
+> in trying to systematize the transition from theory to code.
+
+9Of course, pragmatism is dictated by ones owns idioticy, so I feel
+personaly already dissabled anough not to accept further constratints ;-)
+
+ciao
+BF.
+
+PS: There are algorithms, which were provedto be optimal in a certain
+sense by the mathematician Gian-Carlo Rota and coworkes. What hencforths
+can be done is just efficiency in implementation, a rather wide field
+in itself, ideed.
+
+\start
+Date: Wed, 19 May 2004 10:55:20 -0400
+From: "Stavros Macrakis"
+To:
+Subject: RE: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: camm@enhanced.com, maxima@www.ma.utexas.edu, siver@mx.ihep.su, feyncalc@feyncalc.org
+
+> We need to keep the theory and the code together and have
+> each one explain the other. How else can you show that the
+> code does what it is intended to do?
+
+That is a very hard problem in general.
+
+Good algorithms (as opposed to naive ones) are often connected to
+theory
+in complicated ways -- just look at published algorithms. Then the
+practical implementation of the algorithm is often connected to the
+published algorithm in complicated ways.
+
+"Literate programming" is effective when the algorithm has a nice
+hierarchical structure, but there are many tricks that good algorithm
+designers and programmers use which don't fit well into that structure.
+Some years ago, I participated in a conference on transformational
+programming where Tarjan talked about this... it was humbling.
+
+Personally, I think this is a fascinating area, but it really is a
+research problem in itself. So if your goal is solving physics/math
+problems, I would recommend that you be pragmatic about how far you go
+in trying to systematize the transition from theory to code.
+
+\start
+Date: Wed, 19 May 2004 14:02:38 -0700
+From: Bob McElrath
+To: Stavros Macrakis
+Subject: Re: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, Bertfried.Fauser@uni-konstanz.de, camm@enhanced.com, feyncalc@feyncalc.org, siver@mx.ihep.su
+
+Stavros Macrakis [stavros.macrakis@verizon.net] wrote:
+> > We need to keep the theory and the code together and have
+> > each one explain the other. How else can you show that the
+> > code does what it is intended to do?
+>
+> That is a very hard problem in general.
+
+Test cases.
+
+While this does not *prove* the correctness of the code in a
+mathematical sense, it does in a monte-carlo sense. I note that both
+maxima and axiom have test suites.
+
+I do not think new mathematical code or subsystems should be accepted
+unless they are accompanied by a thorough test suite.
+
+\start
+Date: Wed, 19 May 2004 16:01:09 -0700 (PDT)
+From: C Y
+To: daly@idsi.net, camm@enhanced.com
+Subject: Re: [Axiom-developer] OpenMath
+Cc: Bertfried.Fauser@uni-konstanz.de, bill.page1@sympatico.ca
+
+--- root wrote:
+
+> What language is the maxima GUI written in?
+> Can we generalize that to work for Axiom?
+> That way we can share GUI efforts between Axiom and Maxima.
+
+If you mean xmaxima, it's written in tcl/tk and communicates via
+socket. My guess is it would be trivially simple for someone who knows
+tcl/tk to adapt it to work with Axiom as long as Axiom supports the
+same communication method, assuming this is something you want to do.
+xmaxima, to my understanding, is little more than a tcl/tk framework
+around the maxima command shell.
+
+As long as Axiom is able to communicate via a socket, my guess is it
+would be possible to make any GUI which is sufficiently general in its
+programming style to work with both systems. I'm not sure xmaxima is
+what you're looking for in a GUI though.
+
+\start
+Date: Wed, 19 May 2004 16:50:49 -0700 (PDT)
+From: C Y
+To: daly@idsi.net, Stavros Macrakis
+Subject: Re: [Axiom-developer] FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, bertfried.fauser@uni-konstanz.de, siver@mx.ihep.su
+
+--- Tim Daly wrote:
+> I know this is a research problem though hardly one that merits
+> papers on the subject, I guess.
+
+Actually it probably does, although I'm not quite sure in what field.
+
+> My goal isn't to solve physics/math problems. My goal is to build
+> a system that will be used by computational mathematicians 30
+> years from now. Once this is the stated goal several things become
+> clear.
+
+[snip]
+
+> First, claims are made which cannot be reproduced. Citing results of
+> the program runs without presenting the programs is equivalent to
+> citing theorems without providing proofs. How can a referee properly
+> review such work? Physics and chemistry require reproduced results
+> before claims are accepted.
+
+A minor but I think important point is that such concerns are a very
+sound argument for making a computer algebra system portable across
+multiple computer systems and lisp implimentations. Even a properly
+documented mathematical program depends on the proper (or at least
+expected) behavior from the software on top of which it runs. Getting
+identical results from different lisps/operating systems/platforms is a
+good check that all levels of the system are operating as expected when
+solving a problem.
+
+> Second, the programs are either not available or published as
+> contributions. In the first case who is to know if the actual reason
+> for an algorithmic speedup turns out to be a compiler switch rather
+> than some theoretical reason like term ordering in a groebner basis
+> computation? Since it is unpublished the code is likely to die thus
+> undermining both the basis for the claim and the possibility that
+> other researchers can build on the work.
+
+Indeed.
+
+> The second case is even worse in some sense. I have 1100 domains
+> in Axiom (some of which I wrote) and 100+ algorithms in Magnus
+> with no theoretical documentation; indeed most have no documentation
+> at all. In the 30 year view how is the next generation supposed to
+> build upon the work we've done so far? How can they see the evolution
+> of algorithms? How can they maintain the code without the theory?
+
+I'd say its not worse, but it does replace "impossible" with "extremely
+difficult". Closed and vanished code can never be puzzled out,
+undocumented code can be figured out if the motivation is sufficiently
+strong. In most cases it will not be, and the work will still be lost,
+so I agree the practical results in the two cases will be similar.
+
+> Axiom represents over 30 years and over 300 man-years of research.
+> I don't believe that there will be funding to build systems that are
+> this large and this general. Even if one funded such an effort we
+> end up with a lot of rework that virtually no-one wants to do.
+
+Indeed, funding would be made more difficult by the existance of
+commercial competitors as well - funding for re-inventing the wheel
+would be even harder to find than someone willing to do the work.
+
+> So I'm proposing a goal for the 30 year horizon. We need to make an
+> effort to collect the theory and the code and reunite the two. I
+> realize that there are issues.
+>
+> One issue is, as you point out, that code has to deal with grubby
+> details which the theory can skip. But real design choices are made
+> when reducing theory to practice and these design choices greatly
+> affect the results. We need to encourage the practice of explaining
+> these design decisions.
+
+Yes.
+
+> For example, how are infinite objects (like
+> groups) represented? We have learned that in simple domains like
+> polynomials there are a wide range of design choices (dense, sparse,
+> recursive, etc) that are appropriate for different problems.
+>
+> Another issue is that current systems don't "reach up" close enough
+> to the theory. The gap between the theory and the implementation (I
+> call it the impedance mismatch) is too large for most systems. For
+> instance, Magnus is implemented in C++ which is WAY too close to the
+> machine and very, very far away from Infinite Group Theory (the
+> Magnus domain). Thus the burden of crossing this gap falls on the
+> programmer. Systems like Axiom are much closer to the mathematics.
+> But not close enough. We need systems that span this gap in carefully
+> structured ways so we can be efficient without being obscure.
+
+Agreed. I would argue, though, that the priority list should look
+something like this:
+
+1. Well documented and understood.
+2. Efficient (without being platform specific)
+
+Computers are fast enough in this day and age that the far more
+important problem is to understand what is happening. If an application
+demands sacrificing portability and clarity for speed, that's where a
+special purpose program is useful. Then perhaps Axiom could output the
+logic that solves the problem on the Axiom level in some programming
+language, and let the programmers fiddle from that point.
+
+> This is one of the root causes of your comment that "the
+> practical implementation of the algorithm is often connected to the
+> published algorithm in complicated ways". The implemented algorithm
+> should not be much longer than the published one.
+
+Well, at the very least an implimentation of the algorithm is likely to
+need to tell Axiom things assumed in the paper. I suspect this would
+be one of the sticky points in this type of work - implicit
+assumptions made through much of a subfield, but which are hard for
+newcomers to find and adsorb. By the same token, it could prove
+helpful to be able to easily look back on what those assumptions are.
+
+> If we look at the 30 year horizon it is clear that all papers in
+> computational mathematics will be online. We must set standards
+> now, or at least strive for good examples, that make it possible
+> to use the research effectively. In today's terms we should be
+> able to "drag and drop" a computational mathematics paper onto
+> a system like Axiom and have it immediately available. (In 30
+> year terms Axiom should know the "intentional stance" of the
+> researcher and automatically incorporate the algorithms).
+
+Which brings up the issue of making sure a paper knows what to tell
+Axiom. I suspect what might happen (and might be a good way of doing
+it) is that Axiom based papers will reference other Axiom based papers
+as dependancies for their paper. (I guess this is what you've had in
+mind Tim?) In some sense, perhaps it would even be possible to examine
+the implications of some alternative algorithm on other papers - i.e.
+are the results obtained using *new algorithm* in the papers that
+depend on *old algorithm* impacted by the change?
+
+[snip]
+
+> My current religious zealotism and wild-eyed, irrational planning
+> (I admit it's over-the-top-painful) claim is that we need to start
+> with an old idea "Literate Programming" and evolve it to suit the
+> needs of the next generation Computational Mathematician. Thus
+> all of Axiom (and soon Magnus) has been rewritten into TeX documents.
+> There are no C, Lisp, Spad, Makefile, etc files. Now I'm trying to
+> ensure that new code added to the system includes the theory (or
+> at least permission to use the paper so I can write the literate
+> document).
+
+Two questions:
+
+1) Are you hoping to eventually integrate Magnus's capabilities into
+Axiom?
+
+2) Is there some systematic approach that should be put in place for
+how to go back and document what's already there? I.E., start with the
+most basic code and document one's way up the capabilities?
+
+\start
+Date: Wed, 19 May 2004 17:13:49 -0700 (PDT)
+From: C Y
+To: Bob McElrath , Bertfried.Fauser@uni-konstanz.de
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, siver@mx.ihep.su
+
+--- Bob McElrath wrote:
+
+> The *purpose* of FeynCalc is to be a general purpose framework
+> for doing quantum field theory calculations. That is, dirac
+> matrices, trace rules, Feynman rules from Lagrangians,
+> representations for fields and the like.
+
+This brings up an interesting point. Much of the discussion so far has
+been on how to incorporate new knowledge into Axiom/etc as it is
+discovered/created, but for a lot of uses the PRACTICAL value of a CAS
+is doing repeated calculations within a subset of mathematics.
+Modeling physical systems, for example, most likely allows one to make
+some assumptions that a general purpose CAS wouldn't or shouldn't make.
+
+If Axiom is to be useful to people in a field outside pure mathematical
+research (such as high energy physics) there should be a way for them
+to have a HighEnergyPhysics.pamphlet file or some such that immediately
+lets Axiom know about the standard assumptions in the field. That way,
+anyone wanting to write a paper using Axiom in the HighEnergyPhysics
+field could simply load that file and have a mathematical environment
+corresponding to the one they use to do their work. I guess Feyncalc
+in a sense is such a tool for Mathematica, but given the strictness of
+Axiom's environment I wouldn't be surprised if Feyncalc itself might
+benefit from a more general definition file.
+
+> The actual algorithms are straightforward, but very tedious to
+> calculate, so thus the results are collected into libraries like
+> FeynCalc.
+
+Perhaps it would be useful to make the distinction between mathematical
+research using a CAS and the CAS as a scientific tool. Axiom clearly
+wants to be a mathematical research level CAS - does it make sense to
+add abilities which are mostly practical in nature? I.e., would Axiom
+want to be the place to do quick calculations for a physics paper, as
+well as an environment to interact with high level mathematical
+research? I don't think the two are mutually exclusive, but I'm
+thinking there does need to be a way for the casual user to be isolated
+from advanced mathematical issues and define a more confined working
+environment.
+
+\start
+Date: Wed, 19 May 2004 17:25:12 -0700 (PDT)
+From: C Y
+To: Bob McElrath , Stavros Macrakis
+Subject: Re: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, Bertfried.Fauser@uni-konstanz.de, siver@mx.ihep.su
+
+--- Bob McElrath wrote:
+> Stavros Macrakis [stavros.macrakis@verizon.net] wrote:
+> > > We need to keep the theory and the code together and have
+> > > each one explain the other. How else can you show that the
+> > > code does what it is intended to do?
+> >
+> > That is a very hard problem in general.
+>
+> Test cases.
+
+I think he's refering to the difficulties of defining a protocal to use
+when performing this task. Clearly test cases are needed, but they
+don't address the issue of how to document a complex algorithm being
+reworked into complex code in general. Proving the correctness of the
+translation is beyond the scope of literate programming, and probably
+beyond the ability of any software in existance right now. There are
+techniques like the B method to prove that what the code gives you is
+what you designed, and help you create a design that does precisely
+what you want, but I rather doubt such tools are practical for this
+level of mathematical work.
+
+> While this does not *prove* the correctness of the code in a
+> mathematical sense, it does in a monte-carlo sense. I note that both
+> maxima and axiom have test suites.
+
+What the test suites do is prove that the program is function as it
+should in the environment and that changes to other parts of the
+codebase haven't caused changes, not that the mathematics are correct.
+In a test suite, you must tell the program what the answer is and then
+the program attempts to reach the answer. The variables are whether
+the algorithm is correct, whether a change elsewhere breaks the code in
+question, and whether the supporting OS/environment is functioning
+correctly. But the first case is not specific to a test suite - it is
+used when writing the algorithm and/or debugging it for math errors.
+The second case is useful when checking a bugfix or change hasn't
+caused larger changes, but again does not ensure that the mathematics
+are correct. The third use is strictly for installation.
+
+> I do not think new mathematical code or subsystems should be accepted
+> unless they are accompanied by a thorough test suite.
+
+\start
+Date: Wed, 19 May 2004 18:21:44 -0700 (PDT)
+From: C Y
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, bertfried.fauser@uni-konstanz.de, camm@enhanced.com, stavros.macrakis@verizon.net, feyncalc@feyncalc.org, siver@mx.ihep.su
+
+--- root wrote:
+> The pamphlet is intended to reference other pamphlets thru the
+> bibliogrphy. Pamphlets are intended to stay very close to the
+> what scientists know and extending it carefully. The next step
+> is to introduce semantic latex tags like \concept{ }
+
+So, it won't be possible to load the pamphlet from the paper into Axiom
+and have the algorithm(s) defined there available?
+
+> > 2) Is there some systematic approach that should be put in place
+> > for how to go back and document what's already there? I.E.,
+> > start with the most basic code and document one's way up the
+> > capabilities?
+>
+> erm,... I retype the papers from pdf format to TeX format and then
+> include the code (making it a pamphlet). Almost no-one posts TeX
+> so there appears to be no choice. Fateman has been looking at
+> recognizers for file formats but a push to collect and store the TeX
+> files would save a tremendous amount of time. In the last year I've
+> retyped approx 500 pages of pdf to TeX.
+
+Ouch. What I ment though was when you said there were 1100 domains in
+Axiom with no theoretical documentation - is that what the paper
+conversion is addressing?
+
+\start
+Date: Wed, 19 May 2004 22:48:14 -0400
+From: root
+To: bob+axiom@mcelrath.org
+Subject: Re: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, stavros.macrakis@verizon.net, Bertfried.Fauser@uni-konstanz.de, siver@mx.ihep.su
+
+Bob,
+
+> Test cases.
+>
+> While this does not *prove* the correctness of the code in a
+> mathematical sense, it does in a monte-carlo sense. I note that both
+> maxima and axiom have test suites.
+>
+> I do not think new mathematical code or subsystems should be accepted
+> unless they are accompanied by a thorough test suite.
+
+I've been collecting test cases from different computer algebra systems.
+The effort is called CATS (Computer Algebra Test Suite).
+
+One of the problems with current systems, like Axiom, is that people
+write some algebra then write some test cases. The test cases are not
+comprehensive, don't test corner cases, and don't test failure modes.
+And, most egregious is, they are not documented. The tests given
+an answer but is it the right answer? So current test cases are only
+really useful as regression tests looking for what's broken.
+
+So the idea is to collect the various test suites, document the
+underlying math and set up pamphlet files which contain code for
+each of the various systems. You can get the Axiom code pile with
+the CATS work using the tla from Gnu-arch.
+
+The idea is to develop a test suite that would be similar to the
+NIST (National Institute of Standards and Technology) classification
+scheme for numerical software but this time for symbolic software.
+Currently there is no classification scheme and no agreed-upon
+test suite.
+
+There are few enough computational mathematicians. We shouldn't waste
+their time duplicating tests in areas that others have already done.
+Besides, tests are best when written by others :-)
+
+Thus, CATS.
+
+\start
+Date: Wed, 19 May 2004 23:28:05 -0400
+From: root
+To: smustudent1@yahoo.com
+Subject: Re: [Axiom-developer] OpenMath
+Cc: camm@enhanced.com, bill.page1@sympatico.ca, Bertfried.Fauser@uni-konstanz.de
+
+> If you mean xmaxima, it's written in tcl/tk and communicates via
+> socket. My guess is it would be trivially simple for someone who knows
+> tcl/tk to adapt it to work with Axiom as long as Axiom supports the
+> same communication method, assuming this is something you want to do.
+> xmaxima, to my understanding, is little more than a tcl/tk framework
+> around the maxima command shell.
+>
+> As long as Axiom is able to communicate via a socket, my guess is it
+> would be possible to make any GUI which is sufficiently general in its
+> programming style to work with both systems. I'm not sure xmaxima is
+> what you're looking for in a GUI though.
+
+Sigh, guess i'm gonna have to learn tcl.
+I'll look at xmaxima and see what it might require.
+
+I'm looking at what kind of tools there might be to do a notebook.
+
+It's mostly research to see what tools are available to do a GUI
+in front of Axiom. I'm at the point of collecting ideas to see
+what comes to mind. If we're going to do a new "notebook" we
+might as well design the next generation of notebooks (though
+the term is somewhat limiting).
+
+\start
+Date: Wed, 19 May 2004 21:48:52 -0400
+From: root
+To: smustudent1@yahoo.com
+Subject: Re: [Axiom-developer] FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, bertfried.fauser@uni-konstanz.de, camm@enhanced.com, stavros.macrakis@verizon.net, feyncalc@feyncalc.org, siver@mx.ihep.su
+
+> Which brings up the issue of making sure a paper knows what to tell
+> Axiom. I suspect what might happen (and might be a good way of doing
+> it) is that Axiom based papers will reference other Axiom based papers
+> as dependancies for their paper. (I guess this is what you've had in
+> mind Tim?) In some sense, perhaps it would even be possible to examine
+> the implications of some alternative algorithm on other papers - i.e.
+> are the results obtained using *new algorithm* in the papers that
+> depend on *old algorithm* impacted by the change?
+
+The pamphlet is intended to reference other pamphlets thru the
+bibliogrphy. Pamphlets are intended to stay very close to the
+what scientists know and extending it carefully. The next step
+is to introduce semantic latex tags like \concept{ }
+
+
+> Two questions:
+>
+> 1) Are you hoping to eventually integrate Magnus's capabilities into
+> Axiom?
+
+Yes. Magnus represents a competely new challenge because it contains
+almost no algorithms. Almost everything is a procedure and may not
+terminate. You kick off several algorithms in parallel and let them
+compete for a solution. Infinite Group Theory is provably non-algorithmic
+for almost every question.
+
+>
+> 2) Is there some systematic approach that should be put in place for
+> how to go back and document what's already there? I.E., start with the
+> most basic code and document one's way up the capabilities?
+
+erm,... I retype the papers from pdf format to TeX format and then
+include the code (making it a pamphlet). Almost no-one posts TeX
+so there appears to be no choice. Fateman has been looking at
+recognizers for file formats but a push to collect and store the TeX
+files would save a tremendous amount of time. In the last year I've
+retyped approx 500 pages of pdf to TeX.
+
+\start
+Date: Thu, 20 May 2004 00:00:52 -0400
+From: root
+To: smustudent1@yahoo.com
+Subject: Re: [Axiom-developer] FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, bertfried.fauser@uni-konstanz.de, camm@enhanced.com, stavros.macrakis@verizon.net, feyncalc@feyncalc.org, siver@mx.ihep.su
+
+> > The pamphlet is intended to reference other pamphlets thru the
+> > bibliogrphy. Pamphlets are intended to stay very close to the
+> > what scientists know and extending it carefully. The next step
+> > is to introduce semantic latex tags like \concept{ }
+> So, it won't be possible to load the pamphlet from the paper into Axiom
+> and have the algorithm(s) defined there available?
+
+ummm, pamphlets contain the algorithms. If they reference other
+algorithms it would be thru the bibliograpy. I have a bibtex file
+for the current Axiom pamphlets but have not yet incorporated it
+into the released build.
+
+The comment about "staying close to what scientists know" is a
+reference to the fact that most papers today use TeX. The noweb
+technology by Norman Ramsey make some very simple extensions to
+the TeX markup to support literate programs. So a pamphlet without
+code is essentially a TeX document. Adding code requires learning
+two new markup tags and two commands and now you can extract the
+code (the notangle command) and extract the paper (the noweave command).
+
+The comment about \concept{} is a reference to the fact that TeX
+is a syntactic markup. I want to extend TeX with semantic markup
+tags. These would not affect the print format of a paper. However
+they would tag "concepts" that would be pushed into a semantic
+network (ref: KROPS, my pre-axiom area of research). This would
+allow us to search papers for ideas rather than strings.
+
+> > erm,... I retype the papers from pdf format to TeX format and then
+> > include the code (making it a pamphlet). Almost no-one posts TeX
+> > so there appears to be no choice. Fateman has been looking at
+> > recognizers for file formats but a push to collect and store the TeX
+> > files would save a tremendous amount of time. In the last year I've
+> > retyped approx 500 pages of pdf to TeX.
+
+> Ouch. What I ment though was when you said there were 1100 domains in
+> Axiom with no theoretical documentation - is that what the paper
+> conversion is addressing?
+
+Yes. I have permission to use several phd thesis papers and several
+research papers but some of them were either professionally typeset
+or done in other markup languages (such as IBM script) so there is no
+TeX available. I'm hand-typing them back into TeX and combining them
+with the domains they document. See dhmatrix.spad.pamphlet which is
+from Richard Paul's PhD thesis in robotics and documents
+Denavit-Hartenberg Matrices, a special kind of homogeneous
+transformation matrix implemented in Axiom. I really wish authors
+would adopt the open source model and publish the raw TeX documents.
+
+\start
+Date: Fri, 26 Mar 2004 18:55:21 -0000
+From: Camm Maguire
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] bugzilla
+
+Greetings! OK -- alas it is in python:
+
+=============================================================================
+#!/usr/bin/python2.3 -S
+# -*- python -*-
+# reportbug - Report a bug in the Debian distribution.
+# Written by Chris Lawrence
+# Copyright (C) 1999-2004 Chris Lawrence
+#
+# This program is freely distributable per the following license:
+#
+LICENSE="""\
+Permission to use, copy, modify, and distribute this software and its
+documentation for any purpose and without fee is hereby granted,
+provided that the above copyright notice appears in all copies and that
+both that copyright notice and this permission notice appear in
+supporting documentation.
+
+I DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL I
+BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
+DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
+WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+SOFTWARE."""
+#
+# Version 2.48; see changelog for revision history
+# $Id: reportbug,v 1.20 2004/02/17 23:37:33 lawrencc Exp $
+
+import site
+
+VERSION = "reportbug 2.48"
+COPYRIGHT = VERSION + '\nCopyright (C) 1999-2004 Chris Lawrence '
+DEBUGGER = 'lawrencc@debian.org'
+DEFAULT_BTS = 'debian'
+
+import sys, os
+sys.path = [os.curdir, '/usr/share/reportbug'] + sys.path
+
+import optparse, re, os, pwd, time, locale, commands, checkversions
+import rfc822, smtplib, reportbug, cStringIO, socket, debianbts, checkbuildd
+import gettext, popen2
+
+from rbtempfile import TempFile, open_write_safe
+
+from reportbug import MODE_EXPERT, MODE_ADVANCED, MODE_NOVICE, MODE_STANDARD
+from reportbug_exceptions import *
+from optparse import OptionParser, OptionValueError
+import textwrap
+
+import email
+from email.MIMEMultipart import MIMEMultipart
+from email.MIMEText import MIMEText
+from email.MIMEAudio import MIMEAudio
+from email.MIMEImage import MIMEImage
+from email.MIMEBase import MIMEBase
+from email.MIMEMessage import MIMEMessage
+from email.Header import Header
+from email import Encoders
+
+# Ignore the f*cking deprecation warnings that slipped into a stable release
+#import warnings
+#warnings.filterwarnings("ignore", category=DeprecationWarning)
+
+try:
+ gettext.install('reportbug')
+except IOError:
+ pass
+
+import reportbug_ui_text as ui
+
+# Magic constant time
+MIN_USER_ID = 250
+
+quietly = False
+
+# Lame empty exception used later to save some coding
+class NoMessage(Exception):
+ pass
+
+# Cheat for now.
+# ewrite() may put stuff on the status bar or in message boxes depending on UI
+def ewrite(*args):
+ return quietly or ui.log_message(*args)
+
+# Lame message when we store a report as a temp file.
+def stopmsg(filename):
+ ui.long_message(
+ 'reportbug stopped; your incomplete report is stored as "%s".\n'
+ 'This file may be located in a temporary directory; if so, it might '
+ 'disappear without any further notice.\n', filename)
+
+# Obscene hack :)
+def system(cmdline):
+ try:
+ x = os.getcwd()
+ except OSError:
+ os.chdir('/')
+ os.system(cmdline)
+
+def show_report(text, use_pager=True):
+ if not use_pager:
+ ewrite(text)
+ return
+
+ pager = os.environ.get('PAGER', 'sensible-pager')
+ os.popen(pager, 'w').write(text)
+
+def spawn_editor(message, filename, default_editor=None):
+ if not default_editor:
+ editor = (os.environ.get('VISUAL') or os.environ.get('EDITOR') or
+ '/usr/bin/sensible-editor')
+ else:
+ editor = default_editor
+
+ if not editor:
+ ewrite('No editor found!\n')
+ return (message, 0)
+
+ edname = os.path.basename(editor.split()[0])
+
+ # Move the cursor for lazy buggers like me; add your editor here...
+ ourline = 0
+ for (lineno, line) in enumerate(file(filename)):
+ if line == '\n' and not ourline:
+ ourline = lineno + 2
+ elif line.strip() == reportbug.NEWBIELINE:
+ ourline = lineno + 2
+
+ opts = ''
+ if 'vim' in edname:
+ # Force *vim to edit the file in the foreground, instead of forking
+ opts = '-f '
+
+ if ourline:
+ if edname in ('vi', 'nvi', 'vim', 'elvis', 'gvim', 'kvim'):
+ opts = '-c :%d' % ourline
+ elif (edname in ('elvis-tiny', 'gnuclient', 'ee', 'pico', 'nano') or
+ 'emacs' in edname):
+ opts = '+%d' % ourline
+ elif edname in ('jed', 'xjed'):
+ opts = '-g %d' % ourline
+ elif edname == 'kate':
+ opts = '--line %d' % ourline
+
+ if '&' in editor or edname == 'kate':
+ ewrite("Spawning %s in background; please press Enter when done "
+ "editing.\n", edname)
+ else:
+ ewrite("Spawning %s...\n", edname)
+
+ result = system("%s %s '%s'" % (editor, opts, filename))
+
+ if result:
+ ewrite('Warning: possible error exit from %s: %d\n', edname, result)
+
+ if not os.path.exists(filename):
+ ewrite('Bug report file %s removed!', filename)
+ sys.exit(1)
+
+ if '&' in editor: return (None, 1)
+
+ newmessage = file(filename).read()
+
+ if newmessage == message:
+ ewrite('No changes were made in the editor.\n')
+
+ return (newmessage, newmessage != message)
+
+def handle_editing(filename, dmessage, options, sendto, attachments, package,
+ editor=None):
+ if not editor:
+ editor = options.editor
+ message = None
+ skip_editing = False
+ while 1:
+ if not skip_editing:
+ (message, changed) = spawn_editor(message or dmessage, filename,
+ editor)
+ skip_editing = False
+ if not message:
+ x = ''
+ while x != 'y':
+ x = ui.select_options('Done editing', 'Ynq',
+ {'y': 'Continue (editing done).',
+ 'n': "Don't continue yet.",
+ 'q': 'Exit without sending report.'})
+ if x == 'q':
+ stopmsg(filename)
+ sys.exit(1)
+
+ message = file(filename).read()
+ changed = True
+
+ prompt = 'Submit this report on %s (e to edit)' % package
+ if options.kudos:
+ prompt = 'Send this message (e to edit)'
+ ewrite("Message will be sent to %s\n", sendto)
+ elif options.outfile:
+ ewrite("Report will be saved as %s\n", options.outfile)
+ else:
+ ewrite("Report will be sent to %s\n", sendto)
+
+ if attachments:
+ ewrite('Attachments:\n')
+ for name in attachments:
+ ewrite(' %s\n', name)
+
+ menuopts = "Ynaceilmp"
+ if not changed: menuopts = "ynacEilmp"
+
+ x = ui.select_options(prompt, menuopts,
+ {'y': 'Submit the bug report via email.',
+ 'n': "Don't submit the bug report; instead, "
+ "save it in a temporary file.",
+ 'a': "Attach a file.",
+ 'i': "Include a text file.",
+ 'c': "Change editor and re-edit.",
+ 'e': 'Re-edit the bug report.',
+ 'l': 'Pipe the message through the pager.',
+ 'p': 'Print message to stdout.',
+ 'm': "Choose a mailer to edit the report."})
+ if x in ('a', 'i'):
+ if x == 'i':
+ attachfile = ui.get_filename('Choose a text file to include: ')
+ else:
+ attachfile = ui.get_filename('Choose a file to attach: ')
+ if attachfile:
+ attachfile = os.path.expanduser(attachfile)
+ if os.path.exists(attachfile):
+ if x == 'i':
+ fp = file(attachfile)
+ message += '\n*** %s\n%s' % (attachfile, fp.read())
+ fp.close()
+ fp, filename2 = TempFile()
+ fp.write(message)
+ fp.close()
+ os.unlink(filename)
+ filename = filename2
+ else:
+ attachments.append(attachfile)
+ skip_editing = True
+ else:
+ ewrite("Can't find %s to include!\n", attachfile)
+ elif x == 'c':
+ ed = ui.get_filename('Choose editor: ', default=options.editor)
+ if ed:
+ editor = ed
+ elif x == 'm':
+ mailers = [(x, "") for x in reportbug.MUA.keys()]
+ mailers.sort()
+ mailer = ui.menu('Choose a mailer for your report', mailers,
+ 'Select mailer: ', default='', empty_ok=True)
+ if mailer:
+ mailer = reportbug.MUA.get(mailer)
+ if mailer:
+ options.mua = mailer
+ break
+ skip_editing = True
+ elif x == 'n':
+ stopmsg(filename)
+ sys.exit(1)
+ elif x in ('l', 'p'):
+ skip_editing = True
+ if x == 'l':
+ pager = os.environ.get('PAGER', 'sensible-pager')
+ os.popen(pager, 'w').write(message)
+ else:
+ sys.stdout.write(message)
+ elif x == 'y':
+ if message == dmessage:
+ x = ui.select_options(
+ 'Report is unchanged. Edit this report or quit', 'Eqs',
+ {'q': "Don't submit the bug report; instead, save it "
+ "in a temporary file and quit.",
+ 'e': 'Re-edit the bug report.',
+ 's': 'Send report anyway.'})
+ if x == 'q':
+ stopmsg(filename)
+ sys.exit(1)
+ break
+ elif x == 's':
+ ewrite('Sending empty report anyway...\n')
+ break
+ else:
+ break
+
+ return file(filename).read()
+
+def find_package_for(filename, notatty=False, pathonly=False):
+ ewrite("Finding package for '%s'...\n", filename)
+ (newfilename, packages) = reportbug.find_package_for(filename, pathonly)
+ if newfilename != filename:
+ filename = newfilename
+ ewrite("Resolved as '%s'.\n", filename)
+ if not packages:
+ ewrite("No packages match.\n")
+ return (filename, None)
+ elif len(packages) > 1:
+ if notatty:
+ print "Please re-run reportbug selecting one of these packages:"
+ for package in packlist:
+ print " "+package
+ sys.exit(1)
+
+ packlist = packages.items()
+ packlist.sort()
+ packs = []
+ for pkg, files in packlist:
+ if len(files) > 3:
+ files[3:] = ['...']
+ packs.append( (pkg, ', '.join(files) ) )
+
+ package = ui.menu("Multiple packages match: ", packs, 'Select one '
+ 'of these packages: ', any_ok=True)
+ return (filename, package)
+ else:
+ package = packages.keys()[0]
+ ewrite("Using package '%s'.\n", package)
+ return (filename, package)
+
+def get_other_package_name(others):
+ return ui.menu("Please enter the name of the package in which you "
+ "have found a problem, or choose one of these bug "
+ "categories:", others, "Enter a package: ", any_ok=True,
+ default='')
+
+def get_package_name(bts='debian', mode=MODE_EXPERT):
+ others = debianbts.SYSTEMS[bts]['otherpkgs']
+ prompt = "Please enter the name of the package in which you have found "\
+ "a problem"
+ if others:
+ prompt += ", or type 'other' to report a more general problem."
+ else:
+ prompt += '.'
+
+ package = ui.get_string(prompt, force_prompt=True)
+ if not package:
+ return
+ if others and package and package == 'other':
+ package = get_other_package_name(others)
+
+ if mode < MODE_EXPERT:
+ if package in ('bugs.debian.org', 'debbugs'):
+ if ui.yes_no('Are you reporting a problem with this program '
+ '(reportbug)', 'Yes, this is actually a bug in '
+ 'reportbug.', 'No, this is really a problem in the '
+ 'BTS itself.'):
+ package = 'reportbug'
+
+ if package in ('general', 'project', 'debian-general', 'base'):
+ if not ui.yes_no(
+ "Are you sure this bug doesn't apply to a specific package?",
+ 'Yes, this bug is truly general.',
+ 'No, this is not really a general bug.', False):
+ return get_package_name(bts, mode)
+
+ if package == 'wnpp':
+ if not ui.yes_no(
+ 'Are you sure you want to file a WNPP report?',
+ 'Yes, I am a developer or know what I\'m doing.',
+ 'No, I am not a developer and I don\'t know what wnpp means.',
+ False):
+ return get_package_name(bts, mode)
+
+ return package
+
+def special_prompts(package, bts, ui):
+ prompts = debianbts.SYSTEMS[bts].get('specials')
+ if prompts:
+ pkgprompts = prompts.get(package)
+ if pkgprompts:
+ return pkgprompts(package, bts, ui)
+ return
+
+def offer_configuration(options):
+ if not options.configure:
+ ui.long_message('Welcome to reportbug! Since it looks like this is '
+ 'the first time you have used reportbug, we are '
+ 'configuring its behavior. These settings will be '
+ 'saved to the file "%s", which you will be free to '
+ 'edit further.\n\n', reportbug.USERFILE)
+ mode = ui.menu('Please choose the default operating mode for reportbug.',
+ reportbug.MODES, 'Select mode: ', options.mode,
+ order=reportbug.MODELIST)
+
+ if 0: # Disabled since the others don't work
+ interface = ui.menu('Please choose the default '
+ 'interface for reportbug.', reportbug.UIS,
+ 'Select interface: ', options.interface)
+ else:
+ interface = 'text'
+
+ online = ui.yes_no('Will reportbug often have direct '
+ 'Internet access? (You should answer yes to this '
+ 'question unless you know what you are doing and '
+ 'plan to check whether duplicate reports have been '
+ 'filed via some other channel.)',
+ 'Yes, reportbug should assume it has access to the '
+ 'network always.',
+ 'No, I am only online occasionally to send and '
+ 'receive mail.',
+ default=(not options.offline))
+
+ def_realname, def_email = reportbug.get_email()
+ realname = ui.get_string('What real name should be used for sending bug '
+ 'reports? [%s]' %
+ (options.realname or def_realname),
+ options=[def_realname], force_prompt=True)
+ from_addr = ui.get_string('Which of your email addresses should be used '
+ 'when sending bug reports? [%s]' %
+ (options.email or def_email),options=[def_email],
+ force_prompt=True)
+
+ stupidmode = not ui.yes_no(
+ 'Do you have a "mail transport agent" (MTA) like Exim, Postfix or '
+ 'SSMTP configured on this computer?',
+ 'Yes, I can run /usr/sbin/sendmail without horrible things happening. '
+ 'If you can send email from this machine without setting an SMTP Host '
+ 'in your mailer, you should choose this answer.',
+ 'No, I need to use an SMTP Host or I don\'t know if I have an MTA.',
+ (not options.smtphost))
+
+ smtphost = options.smtphost or ''
+ if stupidmode:
+ smtphost = ui.get_string(
+ 'Do you know your SMTP host? Usually it\'s called something like '
+ 'mail.example.org or smtp.example.org. '
+ 'Just press ENTER if you don\'t.',
+ options=[smtphost], force_prompt=True)
+ if smtphost:
+ stupidmode = False
+ else:
+ smtphost = ''
+
+ if os.path.exists(reportbug.USERFILE):
+ try:
+ os.rename(reportbug.USERFILE, reportbug.USERFILE+'~')
+ except OSError:
+ ewrite('Unable to rename %s as %s~\n', reportbug.USERFILE,
+ reportbug.USERFILE)
+
+ fp = file(reportbug.USERFILE, 'w')
+ print >> fp, '# reportbug preferences file'
+ print >> fp, '# Version of reportbug this preferences file was written by'
+ print >> fp, 'reportbug_version "2.48"'
+ print >> fp, '# default operating mode: one of:',
+ print >> fp, ', '.join(reportbug.MODELIST)
+ print >> fp, 'mode %s' % mode
+ print >> fp, '# default user interface'
+ print >> fp, 'ui %s' % interface
+ print >> fp, '# offline setting - comment out to be online'
+ if not online:
+ print >> fp, 'offline'
+ else:
+ print >> fp, '#offline'
+ print >> fp, '# name and email setting (if non-default)'
+ rn = 'realname "%s"'
+ em = 'email "%s"'
+ email_addy = (from_addr or options.email or def_email)
+ print >> fp, rn % (realname or options.realname or def_realname)
+ print >> fp, em % email_addy
+ uid = os.getuid()
+ if uid < MIN_USER_ID:
+ print >> fp, '# Suppress user ID check for this user'
+ print >> fp, 'no-check-uid'
+
+ if smtphost:
+ print >> fp, '# Send all outgoing mail via the following host'
+ print >> fp, 'smtphost "%s"' % smtphost
+
+ if stupidmode:
+ print >> fp, '# Disable fallback mode by commenting out the following:'
+ print >> fp, 'no-cc'
+ print >> fp, 'header "X-Debbugs-CC: %s"' % email_addy
+ print >> fp, 'smtphost master.debian.org'
+ else:
+ print >> fp, '# If nothing else works, remove the # at the beginning'
+ print >> fp, '# of the following three lines:'
+ print >> fp, '#no-cc'
+ print >> fp, '#header "X-Debbugs-CC: %s"' % email_addy
+ print >> fp, '#smtphost master.debian.org'
+
+ print >> fp, '# You can add other settings after this line. See'
+ print >> fp, '# /etc/reportbug.conf for a full listing of options.'
+ fp.close()
+ ui.long_message('Default preferences file written. To reconfigure, '
+ 're-run reportbug with the "--configure" option.\n')
+
+ascii_range = ''.join([chr(x) for x in range(32,127)])
+notascii = re.compile(r'[^'+re.escape(ascii_range)+']')
+notascii2 = re.compile(r'[^'+re.escape(ascii_range)+r'\s]')
+
+# Wrapper for MIMEText
+class BetterMIMEText(MIMEText):
+ def __init__(self, _text, _subtype='plain', _charset=None):
+ MIMEText.__init__(self, _text, _subtype, 'us-ascii')
+ # Only set the charset paraemeter to non-ASCII if the body
+ # includes unprintable characters
+ if notascii2.search(_text):
+ self.set_param('charset', _charset)
+
+def encode_if_needed(text, charset, encoding='q'):
+ needed = False
+
+ if notascii.search(text):
+ # Fall back on something vaguely sensible if there are high chars
+ # and the encoding is us-ascii
+ if charset == 'us-ascii':
+ charset = 'iso-8859-15'
+ return Header(text, charset)
+ else:
+ return Header(text, 'us-ascii')
+
+def rfc2047_encode_address(addr, charset, mua=None):
+ newlist = []
+ addresses = rfc822.AddrlistClass(addr).getaddrlist()
+ for (realname, address) in addresses:
+ if realname:
+ newlist.append( email.Utils.formataddr(
+ (str(rfc2047_encode_header(realname, charset, mua)), address)))
+ else:
+ newlist.append( address )
+ return ', '.join(newlist)
+
+def rfc2047_encode_header(header, charset, mua=None):
+ if mua: return header
+
+ return encode_if_needed(header, charset)
+
+def verify_option(option, opt, value, parser, *args):
+ heading, valid = args
+ if value == 'help':
+ ewrite('%s:\n %s\n' % (heading, '\n '.join(valid)))
+ sys.exit(1)
+ elif value in valid:
+ setattr(parser.values, option.dest, value)
+ else:
+ ewrite('Ignored bogus setting for %s: %s\n' % (opt, value))
+
+def verify_append_option(option, opt, value, parser, *args):
+ heading, valid = args
+ if value == 'help':
+ ewrite('%s:\n %s\n' % (heading, '\n '.join(valid)))
+ sys.exit(1)
+ elif value in valid:
+ try:
+ getattr(parser.values, option.dest).append(value)
+ except AttributeError:
+ setattr(parser.values, option.dest, [value])
+ else:
+ ewrite('Ignored bogus setting for %s: %s\n' % (opt, value))
+
+def main():
+ global quietly, ui
+
+ try:
+ locale.setlocale(locale.LC_ALL, '')
+ except locale.Error, x:
+ print >> sys.stderr, '*** Warning:', x
+
+ charset = locale.nl_langinfo(locale.CODESET)
+ # It would be nice if there were some canonical character set conversion
+ if charset.lower() == 'ansi_x3.4-1968':
+ charset = 'us-ascii'
+
+ notatty = not ui.ISATTY
+ body = ''
+ filename = None
+
+ defaults = {
+ 'sendto' : 'submit', 'mode' : 'novice', 'mta' : '/usr/sbin/sendmail',
+ 'check_available' : True, 'query_src' : True, 'debconf' : True,
+ 'editor' : '', 'offline' : False, 'verify' : True, 'check_uid' : True,
+ 'testmode' : False, 'attachments' : [], 'keyid' : '', 'body' : None,
+ 'bodyfile' : None }
+
+ if not sys.stdin.isatty():
+ defaults.update({ 'dontquery' : True, 'notatty' : True,
+ 'printonly' : True })
+
+ # Convention: consider `option.foo' names read-only; they always contain
+ # the original value as determined by the cascade of command-line options
+ # and configuration files. When we need to adjust a value, we first say
+ # "foo = options.foo" and then refer to just `foo'.
+ args = reportbug.parse_config_files()
+ for option, arg in args.items():
+ if option in reportbug.CONFIG_ARGS:
+ defaults[option] = arg
+ else:
+ sys.stderr.write('Warning: untranslated token "%s"\n' % option)
+
+ parser = optparse.OptionParser(
+ usage='%prog [options] ', version=VERSION)
+ parser.set_defaults(**defaults)
+ parser.add_option('-c', '--no-config-files', action="store_true",
+ dest='noconf', help='do not include conffiles in report')
+ parser.add_option('-C', '--class', action='callback', type='string',
+ callback=verify_option, dest="klass", metavar='CLASS',
+ callback_args=('Permitted report classes:',
+ debianbts.CLASSLIST),
+ help='specify report class for GNATS BTSes')
+ parser.add_option('-d', '--debug', action='store_const', const=DEBUGGER,
+ dest='sendto', help='send report only to '+DEBUGGER)
+ parser.add_option('--test', action="store_true", default=False,
+ dest="testmode",
+ help="operate in test mode (maintainer use only)")
+ parser.add_option('-e', '--editor', dest='editor',
+ help='specify an editor for your report')
+ parser.add_option('-f', '--filename', dest='searchfor',
+ help='file to search for')
+ parser.add_option('--path', dest='pathonly', action="store_true",
+ default=False, help='only search the path with -f')
+ parser.add_option('-g', '--gnupg', '--gpg', action='store_const',
+ dest='sign', const='gpg',
+ help='sign report with GNU Privacy Guard')
+ parser.add_option('-G', '--gnus', action='store_const', dest='mua',
+ const=reportbug.MUA['gnus'],
+ help='send the report using GNUS')
+ parser.add_option('--pgp', action='store_const', dest='sign',
+ const='pgp', help='sign report with PGP')
+ parser.add_option('-K', '--keyid', type="string", dest="keyid",
+ help="key ID to use for PGP/GnuPG signatures")
+ parser.add_option('-H', '--header', action='append', dest='headers',
+ help='add a custom RFC822 header to your report')
+ parser.add_option('--license', action='store_true', default=False,
+ help='show copyright and license information')
+ parser.add_option('-m', '--maintonly', action='store_const',
+ dest='sendto', const='maintonly',
+ help='send the report to the maintainer only')
+ parser.add_option('-M', '--mutt', action='store_const', dest='mua',
+ const=reportbug.MUA['mutt'],
+ help='send the report using mutt')
+ parser.add_option('--mirror', action='append', help='add a BTS mirror',
+ dest='mirrors')
+ parser.add_option('-a', '--af', action='store_const', dest='mua',
+ const=reportbug.MUA['af'],
+ help='send the report using af')
+ parser.add_option('-n', '--mh', '--nmh', action='store_const', dest='mua',
+ help='send the report using mh/nmh',
+ const=reportbug.MUA['mh'])
+ parser.add_option('--mua', dest='mua',
+ help='send the report using the specified mailer')
+ parser.add_option('--mta', dest='mta', help='send the report using the '
+ 'specified mail transport agent')
+ parser.add_option('--list-cc', action='append', dest='listcc',
+ help='send a copy to the specified address')
+ parser.add_option('-p', '--print', action='store_true', dest='printonly',
+ help='output the report to standard output only')
+ parser.add_option('--report-quiet', action='store_const', dest='sendto',
+ const='quiet', help='file report without any mail to '
+ 'the maintainer or tracking lists')
+ parser.add_option('-q', '--quiet', action='store_true', dest='quietly',
+ help='reduce the verbosity of the output', default=False)
+ parser.add_option('-s', '--subject', help='the subject for your report')
+ parser.add_option('-x', '--no-cc', dest='nocc', action='store_true',
+ help='do not send a copy of the report to yourself')
+ parser.add_option('-z', '--no-compress', dest='nocompress',
+ action='store_true', help='do not strip blank lines '
+ 'and comments from config files')
+ parser.add_option('-o', '--output', dest='outfile', help='output the '
+ 'report to the specified file')
+ parser.add_option('-O', '--offline', help='disable all external queries',
+ action='store_true')
+ parser.add_option('-i', '--include', action='append',
+ help='include the specified file in the report')
+ parser.add_option('-A', '--attach', action='append', dest='attachments',
+ help='attach the specified file to the report')
+ parser.add_option('-b', '--no-query-bts', action='store_true',
+ dest='dontquery',help='do not query the BTS for reports')
+ parser.add_option('--query-bts', action='store_false', dest='dontquery',
+ help='query the BTS for reports')
+ parser.add_option('-T', '--tag', action='callback', dest='tags',
+ callback=verify_append_option, type='string',
+ callback_args=('Permitted tags:',
+ debianbts.TAGLIST+['none']),
+ help='add the specified tag to the report')
+ parser.add_option('--http_proxy', '--proxy', help='use this proxy for '
+ 'HTTP accesses')
+ parser.add_option('--email', help='specify originating email address')
+ parser.add_option('--realname', help='specify real name for your report')
+ parser.add_option('--smtphost', help='specify SMTP server for mailing')
+ parser.add_option('--replyto', '--reply-to', help='specify Reply-To '
+ 'address for your report')
+ parser.add_option('--query-source', action='store_true', dest='query_src',
+ help='query on source packages, not binary packages')
+ parser.add_option('--no-query-source', action='store_false',
+ dest='query_src', help='query on binary packages only')
+ parser.add_option('--debconf', action='store_true',
+ help='include debconf settings in your report')
+ parser.add_option('--no-debconf', action='store_false', dest='debconf',
+ help='exclude debconf settings from your report')
+ parser.add_option('-j', '--justification', help='include justification '
+ 'for the severity of your report')
+ parser.add_option('-V', '--package-version', dest='pkgversion',
+ help='specify the version number for the package')
+ parser.add_option('-u', '--interface', '--ui', action='callback',
+ callback=verify_option, type='string', dest='interface',
+ callback_args=('Valid user interfaces',
+ reportbug.VALID_UIS),
+ help='choose which user interface to use')
+ parser.add_option('-Q', '--query-only', action='store_true',
+ dest='queryonly', help='only query the BTS')
+ parser.add_option('-t', '--type', action='callback', dest='type',
+ callback=verify_option, type='string',
+ callback_args=('Valid types of report:',
+ ('gnats', 'debbugs')),
+ help='choose the type of report to file')
+ parser.add_option('-B', '--bts', action='callback', dest='bts',
+ callback=verify_option, type='string',
+ callback_args=('Valid bug tracking systems',
+ debianbts.SYSTEMS.keys()),
+ help='choose BTS to file the report with')
+ parser.add_option('-S', '--severity', action='callback',
+ callback=verify_option, type='string', dest='severity',
+ callback_args=('Valid severities', debianbts.SEVLIST),
+ help='identify the severity of the report')
+ parser.add_option('--template', action='store_true',
+ help='output a template report only')
+ parser.add_option('--configure', action='store_true',
+ help='reconfigure reportbug for this user')
+ parser.add_option('--check-available', action='store_true',
+ help='check for new releases at packages.debian.org')
+ parser.add_option('--no-check-available', action='store_false',
+ dest='check_available', help='do not check for new '
+ 'releases')
+ parser.add_option('--mode', action='callback', help='choose the operating '
+ 'mode for reportbug', callback=verify_option,
+ type='string', dest='mode',
+ callback_args=('Permitted operating modes',
+ reportbug.MODES.keys()))
+ parser.add_option('-v', '--verify', action='store_true', help='verify '
+ 'integrity of installed package using debsums')
+ parser.add_option('--no-verify', action='store_false', dest='verify',
+ help='do not verify package installation')
+ parser.add_option('-k', '--kudos', action='store_true', default=False,
+ help='send appreciative email to the maintainer, rather '
+ 'than filing a bug report')
+ parser.add_option('--check-installed', action='store_true',
+ dest='querydpkg', help='check whether the specified '
+ 'package is installed when filing a report (default)')
+ parser.add_option('--body', dest="body", type="string",
+ help="specify the body for the report as a string")
+ parser.add_option('--body-file', '--bodyfile', dest="bodyfile",
+ type="string",
+ help="use the specified file as the body of the report")
+ parser.add_option('-I', '--no-check-installed', action='store_false',
+ default=True, dest='querydpkg',
+ help='don\'t check whether the package is installed')
+ (options, args) = parser.parse_args()
+
+ if options.configure:
+ offer_configuration(options)
+ sys.exit(0)
+ elif options.license:
+ print COPYRIGHT
+ print
+ print LICENSE
+ sys.exit(0)
+
+ # These option values may get adjusted below, so give them a variable name.
+ check_available = options.check_available
+ dontquery = options.dontquery
+ headers = options.headers or []
+ mua = options.mua
+ pkgversion = options.pkgversion
+ quietly = options.quietly
+ severity = options.severity
+ smtphost = options.smtphost
+ subject = options.subject
+ sysinfo = debianbts.SYSTEMS[options.bts or 'debian']
+ rtype = options.type or sysinfo['type']
+ attachments = options.attachments
+ pgp_addr = options.keyid
+
+ if options.body:
+ body = textwrap.fill(options.body)
+ elif options.bodyfile:
+ try:
+ body = file(options.bodyfile).read()
+ except:
+ ewrite('Unable to read body from file %s.\n', options.bodyfile)
+ sys.exit(1)
+
+ if body and not body.endswith('\n'):
+ body += '\n'
+
+ if options.queryonly:
+ check_available = False
+
+ if options.offline:
+ check_available = False
+ dontquery = True
+
+ if options.tags:
+ taglist = options.tags
+ if 'none' in taglist:
+ taglist = []
+ else:
+ taglist = []
+
+ if options.testmode:
+ options.sendto = DEBUGGER
+ options.tags = ['none']
+ check_available = False
+ dontquery = True
+ severity = 'normal'
+ subject = 'testing'
+ taglist = []
+
+ if options.template:
+ check_available = False
+ dontquery = quietly = notatty = True
+ mua = smtphost = None
+ severity = severity or 'wishlist'
+ subject = subject or 'none'
+
+ if options.outfile or options.printonly:
+ mua = smtphost = None
+
+ if attachments and mua:
+ ewrite('Attachments are incompatible with using an MUA. They will be ignored.\n')
+ attachments = []
+
+ if reportbug.first_run():
+ if not args:
+ offer_configuration(options)
+ main()
+ sys.exit(0)
+ else:
+ ewrite('Warning: no reportbug configuration found. Proceeding in %s mode.\n' % options.mode)
+
+ mode = reportbug.MODELIST.index(options.mode)
+
+ # Disable signatures when in printonly or mua mode
+ # (since they'll be bogus anyway)
+ sign = options.sign
+ if (options.mua or options.printonly) and sign:
+ sign = ''
+
+ uid = os.getuid()
+ if uid < MIN_USER_ID:
+ if notatty and not uid:
+ ewrite("reportbug will not run as root non-interactively.\n")
+ sys.exit(1)
+
+ if not uid or options.check_uid:
+ if not uid:
+ message = "Running 'reportbug' as root is probably insecure!"
+ else:
+ message = "Running 'reportbug' as an administrative user "\
+ "is probably not a good idea!"
+ message += ' Continue'
+
+ if not ui.yes_no(message, 'Continue with reportbug.', 'Exit.',
+ False):
+ ewrite("reportbug stopped.\n")
+ sys.exit(1)
+
+ # Fix up command line options for GNOME interface
+ sys.argv = sys.argv[:1] + list(args)
+ if options.interface:
+ if options.interface in ('gnome', 'newt'):
+ ui.long_message("The %s interface is not supported. Unless you "
+ "are debugging reportbug, please do not use it. "
+ "If you are debugging reportbug, please DO NOT "
+ "file bugs more serious than 'normal' that "
+ "indicate problems with this interface.\n",
+ options.interface)
+
+ iface = 'reportbug_ui_'+options.interface
+ exec 'import '+iface
+ ui = eval(iface)
+
+ if (reportbug.first_run() and not args):
+ offer_configuration(options)
+ ewrite('To report a bug, please rerun reportbug.\n')
+ sys.exit(0)
+
+ foundfile = None
+ package = None
+ if not len(args) and not options.searchfor and not notatty:
+ package = get_package_name(options.bts or 'debian', mode)
+ elif len(args) > 1:
+ ewrite("Please report one bug at a time.\n")
+ ewrite("[Did you forget to put all switches before the "
+ "package name?]\n")
+ sys.exit(1)
+ elif options.searchfor:
+ (foundfile, package) = find_package_for(options.searchfor, notatty,
+ options.pathonly)
+ elif len(args):
+ package = args[0]
+ if package and package.startswith('/'):
+ (foundfile, package) = find_package_for(package, notatty)
+
+ if not package:
+ ewrite("No package specified; stopping.\n")
+ sys.exit(1)
+
+ if options.interface == 'text':
+ ewrite('*** Welcome to reportbug. Use ? for help at prompts. ***\n')
+
+ fromaddr = reportbug.get_user_id(options.email, options.realname)
+ ewrite("Using '%s' as your from address.\n", fromaddr)
+
+
+ try:
+ blah = u'hello'.encode(charset)
+ except LookupError:
+ ui.long_message(
+ 'Unable to use specified character set "%s"; you probably need '
+ 'either cjkcodecs (for users of Asian locales) or iconvcodec '
+ 'installed.\nFalling back to ASCII encoding.\n', charset)
+ charset = 'ascii'
+ else:
+ ewrite("Detected character set: %s\n"
+ "Please change your locale if this is incorrect.\n\n", charset)
+
+ buginfo = '/usr/share/bug/' + package
+ bugexec = submitas = submitto = presubj = None
+ if os.path.isfile(buginfo) and os.access(buginfo, os.X_OK):
+ bugexec = buginfo
+ elif os.path.isdir(buginfo):
+ if os.path.isfile(buginfo+'/script') and os.access(buginfo+'/script', os.X_OK):
+ bugexec = buginfo+'/script'
+
+ if os.path.isfile(buginfo+'/presubj'):
+ presubj = buginfo+'/presubj'
+
+ if os.path.isfile(buginfo+'/control'):
+ submitas, submitto = reportbug.parse_bug_control_file(buginfo+'/control')
+ elif os.path.isfile('/usr/share/bug/default/'+package) \
+ and os.access('/usr/share/bug/default/'+package, os.X_OK):
+ bugexec = '/usr/share/bug/default/'+package
+ elif os.path.isdir('/usr/share/bug/default/'+package):
+ buginfo = '/usr/share/bug/default/'+package
+ if os.path.isfile(buginfo+'/script') and os.access(buginfo+'/script',
+ os.X_OK):
+ bugexec = buginfo+'/script'
+
+ if os.path.isfile(buginfo+'/presubj'):
+ presubj = buginfo+'/presubj'
+
+ if os.path.isfile(buginfo+'/control'):
+ submitas, submitto = reportbug.parse_bug_control_file(buginfo+
+ '/control')
+
+ incfiles = ""
+ if options.include:
+ for f in options.include:
+ if os.path.exists(f):
+ fp = file(f)
+ incfiles = '%s\n*** %s\n%s' % (incfiles, f, fp.read())
+ fp.close()
+ else:
+ ewrite("Can't find %s to include!\n", f)
+ sys.exit(1)
+ incfiles += '\n'
+
+ pkgavail = maintainer = ''
+ depends = []
+ conffiles = []
+ isvirtual = (package in sysinfo['otherpkgs'].keys() and
+ package not in sysinfo.get('nonvirtual', []))
+ issource = installed = False
+
+ if not pkgversion and options.querydpkg and sysinfo['query-dpkg']:
+ ewrite("Getting status for %s...\n", package)
+ status = reportbug.get_package_status(package)
+
+ pkgavail, installed = status[1], status[5]
+ # Packages that only exist to do weird dependency things
+ deppkgs = sysinfo.get('deppkgs')
+ if pkgavail and deppkgs:
+ if installed and package in deppkgs:
+ depends = status[2]
+ if depends:
+ newdepends = []
+ for x in depends:
+ newdepends.extend(x)
+ depends = newdepends
+ if len(depends) == 1:
+ ewrite('Dependency package "%s" corresponds to '
+ 'actual package "%s".\n', package, depends[0])
+ package = depends[0]
+ else:
+ opts = [(x, reportbug.get_package_status(x)[10])
+ for x in depends]
+ if mode >= MODE_ADVANCED:
+ opts += [(package,
+ status[10]+' (dependency package)')]
+
+ package = ui.menu('%s is a dependency package. '
+ 'Which of the following '
+ 'packages is the bug in?' % package,
+ opts,
+ 'Select one of these packages: ')
+ ewrite("Getting status for %s...\n", package)
+ status = reportbug.get_package_status(package)
+ pkgavail, installed = status[1], status[5]
+
+ if not pkgavail and not isvirtual:
+ # Look for a matching source package
+ packages = reportbug.get_source_package(package)
+ if len(packages) > 0:
+ src = package
+ if len(packages) == 1:
+ ewrite('Source package "%s" corresponds to '
+ 'binary package "%s".\n', package, packages[0][0])
+ package = packages[0][0]
+ elif len(packages) and not notatty:
+ packages.append( (src, 'Source package') )
+ package = ui.menu('Which of the following packages is the '
+ 'bug in?', packages, empty_ok=True,
+ prompt='Select one of these packages: ')
+ if not package:
+ ewrite("No package specified; stopping.\n")
+ sys.exit(1)
+
+ if package != src:
+ ewrite("Getting status for %s...\n", package)
+ status = reportbug.get_package_status(package)
+ else:
+ issource = True
+ else:
+ ewrite('No matching source or binary packages.\n')
+
+ if not installed and not notatty and not isvirtual and not issource:
+ packages = reportbug.packages_providing(package)
+ tmp = pack = None
+ if not packages:
+ if ui.yes_no(
+ 'A package named "%s" does not appear to be installed; do '
+ 'you want to search for a similar-looking filename in '
+ 'an installed package' % package,
+ 'Look for a file with a similar filename.',
+ 'Continue filing with this package name.', True):
+ pkgavail = False
+ else:
+ pack = package
+
+ if not packages and not pkgavail and not pack:
+ (tmp, pack) = find_package_for(package, notatty)
+ if pack:
+ if not ui.yes_no(
+ "A package named '%s' does not appear to be installed "
+ "on your system; however, '%s' contains a file named "
+ "'%s'. Do you want to file your report on the "
+ "package reportbug found" % (package, pack, tmp),
+ 'Yes, use the package specified.',
+ 'No, give up the search.'):
+ ewrite("Package not installed; stopping.\n")
+ sys.exit(1)
+
+ if pack:
+ foundfile, package = tmp, pack
+ ewrite("Getting status for %s...\n", package)
+ status = reportbug.get_package_status(package)
+ elif not packages:
+ if not ui.yes_no(
+ 'This package does not appear to be installed; continue '
+ 'with this report', 'Ignore this problem and continue.',
+ 'Exit without filing a report.', False):
+ ewrite("Package not installed; stopping.\n")
+ sys.exit(1)
+ elif (len(packages) > 1) or (packages[0][0] != package):
+ this_package = [(package, 'Uninstalled/non-existent package')]
+ package = ui.menu('Which of the following installed packages '
+ 'is the bug in?', packages + this_package,
+ 'Select one of these packages: ',
+ empty_ok=True)
+ if not package:
+ ewrite("No package specified; stopping.\n")
+ sys.exit(1)
+ else:
+ ewrite("Getting status for %s...\n", package)
+ status = reportbug.get_package_status(package)
+ elif not pkgavail and not notatty and not isvirtual and not issource:
+ if not ui.yes_no(
+ 'This package does not appear to exist; continue',
+ 'Ignore this problem and continue.',
+ 'Exit without filing a report.', False):
+ ewrite("Package does not exist; stopping.\n")
+ sys.exit(1)
+
+ (pkgversion, pkgavail, depends, conffiles, maintainer, installed,
+ origin, vendor, reportinfo, priority, desc, src_name,
+ fulldesc, state) = status
+
+ if (pkgavail and options.verify and os.path.exists('/usr/bin/debsums')
+ and not (notatty or options.kudos) and state == 'installed'):
+ ewrite('Verifying package integrity...\n')
+ rc, output = commands.getstatusoutput('/usr/bin/debsums -s'+
+ commands.mkarg(package))
+ if rc:
+ if not ui.yes_no(
+ 'There may be a problem with your installation of '+package+
+ ';\nthe following files appear to be missing or changed:\n'+
+ output+'\nDo you still want to file a report',
+ 'Ignore this problem and continue. This may be '
+ 'appropriate if you have fixed the package manually already. '
+ 'This problem may also result from the use of localepurge.',
+ 'Exit without filing a report.', False, nowrap=True):
+ ewrite("Package integrity check failed; stopping.\n")
+ sys.exit(1)
+
+ if not pkgversion:
+ if not (isvirtual or issource or notatty):
+ pkgversion = ui.get_string('Please enter the version of the '
+ 'package this report applies to '
+ '(blank OK)', force_prompt=True)
+ elif check_available and not (options.kudos or notatty or
+ options.offline):
+ ewrite('Checking for newer versions at packages.debian.org...\n')
+ (avail, toonew) = checkversions.check_available(
+ package, pkgversion, check_incoming=(mode > MODE_STANDARD),
+ http_proxy=options.http_proxy)
+ if toonew:
+ if not ui.yes_no(
+ '\nYour version of %s (%s) is newer than that in Debian!\n'
+ 'Do you still want to file a report' % (package, pkgversion),
+ 'Ignore this problem and continue. This may be '
+ 'appropriate if you know this bug is present in older '
+ 'releases of the package, or you\'re running a mixed '
+ 'stable/testing installation.',
+ 'Exit without filing a report.', False):
+ ewrite("Newer released version; stopping.\n")
+ sys.exit(1)
+
+ if avail:
+ availtext = ''
+ availlist = avail.keys()
+ availlist.sort()
+ for rel in availlist:
+ availtext += ' %s: %s\n' % (rel, avail[rel])
+
+ if not ui.yes_no(
+ ('\nYour version (%s) of %s appears to be out of date.\nThe '
+ 'following newer release(s) are available in the Debian '
+ 'archive:\n' % (pkgversion, package))+availtext+
+ 'Do you still want to file a report',
+ 'Ignore this problem and continue. This may be '
+ 'appropriate if you know this bug is still present in more '
+ 'recent releases of the package.',
+ 'Exit without filing a report.', False, nowrap=True):
+ ewrite("Newer released version; stopping.\n")
+ sys.exit(1)
+
+ bts = DEFAULT_BTS
+ if options.bts:
+ bts = options.bts
+ ewrite("Will send report to %s.\n", debianbts.SYSTEMS[bts]['name'])
+ elif origin:
+ if origin == bts:
+ ewrite("Package originates from %s.\n", vendor)
+ reportinfo = None
+ elif origin in debianbts.SYSTEMS.keys():
+ ewrite("Package originates from %s; overriding your system "
+ "selection.\n", vendor)
+ bts = origin
+ reportinfo = None
+ elif reportinfo:
+ ewrite("Unknown origin %s; will send to %s.\n", origin,
+ reportinfo[1])
+ rtype, submitto = reportinfo
+ elif submitto:
+ ewrite("Unknown origin %s; will send to %s.\n", origin, submitto)
+ else:
+ ewrite("Unknown origin %s; will send to %s.\n", origin, bts)
+ elif reportinfo:
+ rtype, submitto = reportinfo
+ ewrite("Will use %s protocol talking to %s.\n", rtype, submitto)
+ dontquery = True
+
+ if rtype == 'mailto':
+ rtype = 'debbugs'
+ dontquery = True
+
+ if options.listcc:
+ headers.append('X-Debbugs-CC: '+', '.join(options.listcc))
+
+ special = False
+ if not body and not subject and not notatty:
+ res = special_prompts(package, bts, ui)
+ if res:
+ (subject, severity, h, body, query) = res
+ headers = headers + h
+ if not query:
+ dontquery = True
+ special = True
+
+ sendto = options.sendto
+ exinfo = None
+ if not (dontquery or notatty or options.kudos):
+ pkg, src = package, issource
+ if options.query_src:
+ src = True
+ try:
+ exinfo = ui.handle_bts_query(pkg, bts, options.mirrors,
+ options.http_proxy, source=src)
+ except NotImplemented:
+ exinfo = None
+ except NoNetwork:
+ ewrite('Unable to contact BTS; continuing anyway.\n')
+ except NoPackage:
+ if not options.queryonly and maintainer and ui.yes_no(
+ 'There is no record of this package in the bug tracking '
+ 'system.\nSend report directly to maintainer',
+ 'Send the report to the maintainer (%s).' % maintainer,
+ 'Send the report to the BTS anyway.'):
+ rtype = 'debbugs'
+ sendto = maintainer
+ except NoBugs:
+ ewrite('No bug reports found.\n')
+ except NoReport:
+ ewrite('Nothing new to report; exiting.\n')
+ return
+
+ if options.queryonly: return
+
+ ccaddr = os.environ.get('MAILCC')
+ if options.nocc:
+ bccaddr = os.environ.get('MAILBCC')
+ else:
+ bccaddr = os.environ.get('MAILBCC', fromaddr)
+
+ if maintainer:
+ ewrite("Maintainer for %s is '%s'.\n", package, maintainer)
+ if 'qa.debian.org' in maintainer:
+ ui.long_message('''\
+This package is currently "orphaned"; if you care a current or prospective
+Debian developer, you might consider adopting it. Please be aware that your
+report may not be resolved for a while, and that packages that have been
+orphaned for a long period of time are often removed from the archive.\n''')
+ ui.ewrite('\nFor more details, please see: http://www.debian.org/devel/wnpp/\n')
+
+ if options.kudos:
+ if maintainer:
+ sendto = maintainer
+ else:
+ ewrite('Unable to determine maintainer for %s; exiting.', package)
+ sys.exit(1)
+
+ depinfo = ""
+ # Grab dependency list, removing version conditions.
+ if depends and not options.kudos:
+ ewrite("Getting dependency information for %s...\n", package)
+ depinfo = reportbug.get_dependency_info(package, depends)
+
+ confinfo = []
+ conftext = ''
+ remonly = False
+ if conffiles and not options.kudos:
+ ewrite("Getting changed configuration files...\n")
+ confinfo, changed = reportbug.get_changed_config_files(conffiles,
+ nocompress)
+
+ if not conffiles:
+ pass
+ elif options.noconf and changed:
+ for f in changed:
+ confinfo[f] = 'changed [not included]'
+ elif changed and not notatty:
+ while 1:
+ x = ui.select_options(
+ "*** WARNING: The following configuration files have been "
+ "modified:\n"+ "\n".join(changed)+
+ "\nSend modified configuration files", 'Ynd',
+ {'y':'Send your modified configuration files.',
+ 'n':"Don't send modified configuration files.",
+ 'd':'Display modified configuration files.'})
+ if x == 'n':
+ for f in changed:
+ confinfo[f] = 'changed [not included]'
+ break
+ elif x == 'd':
+ PAGER = os.environ.get('PAGER', '/usr/bin/sensible-pager')
+ system(PAGER+' '+' '.join(changed))
+ else:
+ break
+
+ if confinfo:
+ conftext = '\n-- Configuration Files:\n'
+ files = confinfo.keys()
+ files.sort()
+ for f in files:
+ conftext = conftext + '%s %s\n' % (f, confinfo[f])
+
+ if (options.debconf and os.path.exists('/usr/bin/debconf-show') and
+ not options.kudos and installed):
+ (status, output) = commands.getstatusoutput(
+ 'DEBCONF_SYSTEMRC=1 DEBCONF_NOWARNINGS=yes '
+ '/usr/bin/debconf-show %s' % package)
+ if status:
+ conftext += '\n-- debconf-show failed\n'
+ elif output:
+ if (notatty or
+ ui.yes_no("*** The following debconf settings were detected:\n"
+ +output+"\nInclude these settings in your report",
+ 'Send your debconf settings.',
+ "Don't send your debconf settings.", nowrap=True)):
+ conftext += '\n-- debconf information:\n%s\n' % output
+ else:
+ conftext += '\n-- debconf information excluded\n'
+ else:
+ conftext += '\n-- no debconf information\n'
+
+ ewrite('\n')
+ prompted = False
+ if options.kudos:
+ subject = subject or ('Thanks for packaging %s!' % package)
+ elif exinfo:
+ if special:
+ body = ''
+ prompted = True
+ subject = ui.get_string('Please provide a subject for your response; '
+ 'no subject will stop reportbug.',
+ force_prompt=True)
+ elif not subject and not notatty:
+ prompted = True
+ if presubj:
+ ewrite(file(presubj).read()+'\n')
+
+ subject = ui.get_string(
+ 'Please briefly describe your problem (you can elaborate in '
+ 'a moment; an empty response will stop reportbug). This '
+ 'should be a pithy summary of what is wrong with the package, '
+ 'for example, "fails to send email" or "does not start with -q '
+ 'option specified."', force_prompt=True)
+
+ if not subject:
+ ewrite("No subject specified; stopping.\n")
+ sys.exit(1)
+
+ if len(subject) > 100 and prompted and mode < MODE_EXPERT:
+ subject = ui.get_string(
+ 'Your description is a bit long; please enter a shorter subject. '
+ '(An empty response will retain the existing subject.)',
+ force_prompt=True) or subject
+ if package != 'wnpp' and prompted and mode < MODE_EXPERT:
+ if foundfile:
+ subject = foundfile + ": " + subject
+ ewrite("Rewriting subject to '%s'\n", subject)
+ elif (not re.match(r"\S+:\s", subject) and package not in subject):
+ subject = package + ": " + subject
+ ewrite("Rewriting subject to '%s'\n", subject)
+
+ if severity and rtype:
+ severity = debianbts.convert_severity(severity, rtype)
+
+ klass = options.klass
+ if not notatty and not (exinfo or options.kudos):
+ if not severity:
+ if rtype == 'gnats':
+ severities = debianbts.SEVERITIES_gnats
+ default = 'non-critical'
+ else:
+ if mode == MODE_NOVICE:
+ severities = {'normal' : debianbts.SEVERITIES['normal'],
+ 'minor': debianbts.SEVERITIES['minor'],
+ 'wishlist': debianbts.SEVERITIES['wishlist'],
+ }
+ else:
+ severities = debianbts.SEVERITIES
+ default = 'normal'
+
+ severity = ui.menu("How would you rate the severity of this "
+ "problem or report?", severities,
+ 'Please select a severity level: ',
+ default=default, order=debianbts.SEVLIST)
+
+ if rtype == 'gnats':
+ # Class of report
+ klass = ui.menu("What sort of problem are you reporting?",
+ debianbts.CLASSES, 'Please select a class: ',
+ default='sw-bug', order=debianbts.CLASSLIST)
+
+ severity = severity or 'normal'
+
+ justification = options.justification
+ if rtype == 'debbugs' and package != 'wnpp' and mode < MODE_EXPERT:
+ if severity in ('critical', 'grave'):
+ justification = ui.menu(
+ 'You are reporting a ' +severity+' bug; which of the '
+ 'following criteria does it meet?',
+ debianbts.JUSTIFICATIONS[severity],
+ 'Please select the impact of the bug: ', default='unknown')
+ elif severity == 'serious':
+ justification = ui.get_string(
+ 'You are reporting a serious bug; which section of the '
+ 'Debian Policy Manual contains the "must" or "required" '
+ 'directive that it violates? (E.g., "1.2.3") Just type '
+ '"unknown" if you are not sure.', force_prompt=True)
+ if re.match('[0-9]+\.[0-9.]+', justification):
+ justification = 'Policy ' + justification
+ elif not justification:
+ justification = 'unknown'
+
+ if justification == 'unknown':
+ justification = ''
+ severity = 'normal'
+ ewrite('Severity downgraded to "normal".\n')
+
+ if severity == 'does-not-build':
+ if pkgversion and not src_name:
+ src_name = package
+ if src_name and check_available and not notatty:
+ ewrite('Checking buildd.debian.org for past builds of %s...\n',
+ src_name)
+ built = checkbuildd.check_built(src_name,
+ http_proxy=options.http_proxy)
+
+ if built:
+ ewrite('Successful past builds... treating as serious.\n')
+ severity = 'serious'
+ justification = 'no longer builds from source'
+ else:
+ ewrite('No successful builds... treating as important.\n')
+ severity = 'important'
+ justification = 'fails to build from source'
+ else:
+ if notatty:
+ severity = 'important'
+ justification = 'fails to build from source'
+ else:
+ if ui.yes_no(
+ 'Has this package successfully been built for this '
+ 'architecture in the past (you can look this up at '
+ 'buildd.debian.org)',
+ 'Yes, this is a recently-introduced problem.',
+ 'No, it has always been this way.'):
+ severity = 'serious'
+ justification = 'no longer builds from source'
+ else:
+ severity = 'important'
+ justification = 'fails to build from source'
+
+ TMPDIR = os.environ.get('TMPDIR', '/tmp')
+ HOMEDIR = os.environ.get('HOME', '/')
+
+ if (rtype == 'debbugs' and not options.tags and
+ not (notatty or options.kudos or exinfo) and package != 'wnpp' and
+ mode > MODE_NOVICE):
+ # Multiple-choice checkbox
+ taglist = ui.select_multiple(
+ 'Do any of the following apply to this report?', debianbts.TAGS,
+ 'Please select tags: ', order=debianbts.TAGLIST,
+ extras=debianbts.EXTRA_TAGS)
+
+ patch = ('patch' in taglist)
+
+ if taglist:
+ tags = ' '.join(taglist)
+ else:
+ tags = ''
+
+ # Execute bug script
+ if bugexec and not options.kudos:
+ if os.path.exists('handle_bugscript'):
+ handler = './handle_bugscript'
+ else:
+ handler = '/usr/share/reportbug/handle_bugscript'
+
+ fh, filename = TempFile()
+ fh.close()
+ system(handler+' '+bugexec+' '+filename)
+
+ addinfo = "\n-- Package-specific info:\n"+file(filename).read()
+ os.unlink(filename)
+ if addinfo and incfiles:
+ incfiles = addinfo + "\n" + incfiles
+ elif addinfo:
+ incfiles = addinfo
+
+ # Prepare bug report
+ if options.kudos:
+ message = '\n\n'
+ if not mua:
+ SIGFILE = os.path.join(HOMEDIR, '.signature')
+ try:
+ message = "\n\n-- \n"+file(SIGFILE).read()
+ except IOError:
+ pass
+ else:
+ message = reportbug.generate_blank_report(
+ submitas or package, pkgversion, severity, justification, depinfo,
+ conftext, foundfile, incfiles, bts, exinfo, rtype, klass, subject,
+ tags, body, mode)
+
+ # Substitute server email address
+ if submitto and '@' not in sendto:
+ if '@' in submitto:
+ sendto = submitto
+ else:
+ if exinfo:
+ if sendto != 'submit':
+ sendto = '%d-%s' % (exinfo, sendto)
+ else:
+ sendto = str(exinfo)
+
+ sendto = sendto+'@'+submitto
+ elif '@' not in sendto:
+ if exinfo:
+ if sendto != 'submit':
+ sendto = '%d-%s' % (exinfo, sendto)
+ else:
+ sendto = str(exinfo)
+
+ try:
+ sendto = sysinfo['email'] % sendto
+ except TypeError:
+ sendto = sysinfo['email']
+
+ sendto = rfc822.dump_address_pair((sysinfo['name']+
+ ' Bug Tracking System', sendto))
+
+ mailing = not (mua or options.printonly or options.template)
+ message = "Subject: %s\n%s" % (subject, message)
+
+ if mailing:
+ fh, filename = TempFile()
+ fh.write(message)
+ fh.close()
+ oldmua = mua or options.mua
+ if not options.body and not options.bodyfile:
+ message = handle_editing(filename, message, options, sendto,
+ attachments, package)
+ if not oldmua and options.mua:
+ mua = options.mua
+ if mua:
+ mailing = False
+ if os.path.exists(filename):
+ os.unlink(filename)
+ elif not sendto:
+ print message,
+ # Remove the temporary file
+ if os.path.exists(filename):
+ os.unlink(filename)
+ return
+
+ if not mua and patch and not attachments and not notatty:
+ while True:
+ patchfile = ui.get_filename(
+ 'What is the filename of the patch (if none, or you have '
+ 'already included it, just press ENTER)?',
+ force_prompt=True)
+ if patchfile:
+ attachfile = os.path.expanduser(patchfile)
+ if os.path.exists(attachfile):
+ attachments.append(attachfile)
+ break
+ else:
+ ewrite('%s not found!', attachfile)
+ else:
+ break
+
+ body, headers, pseudoheaders = reportbug.cleanup_msg(message,headers,rtype)
+
+ if sign:
+ ewrite('Passing message to %s for signature...\n', sign)
+ if not pgp_addr:
+ pgp_addr = reportbug.get_email_addr(fromaddr)[1]
+
+ # Make the unsigned file first
+ (unsigned, file1) = TempFile(
+ prefix=('reportbug-unsigned-%s-%d-' % (package, os.getpid())) )
+ unsigned.write(body)
+ unsigned.close()
+
+ # Now make the signed file
+ (signed, file2) = TempFile(
+ prefix=('reportbug-signed-%s-%d-' % (package, os.getpid())))
+ signed.close()
+
+ if sign == 'gpg':
+ signcmd = "gpg --local-user '%s' --clearsign" % pgp_addr
+ else:
+ signcmd = "pgp -u '%s' -fast" % pgp_addr
+
+ signcmd += '<'+commands.mkarg(file1)+' >'+commands.mkarg(file2)
+ try:
+ os.system(signcmd)
+ x = file(file2, 'r')
+ signedbody = x.read()
+ x.close()
+
+ if os.path.exists(file1):
+ os.unlink(file1)
+ if os.path.exists(file2):
+ os.unlink(file2)
+
+ if not signedbody:
+ raise NoMessage
+ body = signedbody
+ except (NoMessage, IOError, OSError):
+ fh, tmpfile2 = TempFile(prefix="reportbug-")
+ fh.write(body)
+ fh.close()
+ ewrite('gpg/pgp failed; input file in %s\n', tmpfile2)
+ sys.exit(1)
+
+ if pseudoheaders:
+ body = '\n'.join(pseudoheaders)+'\n\n'+body
+
+ if attachments and not mua:
+ import mimetypes
+ mimetypes.init()
+
+ message = MIMEMultipart('mixed')
+ bodypart = BetterMIMEText(body, _charset=charset)
+ bodypart.add_header('Content-Disposition', 'inline')
+ message.preamble = 'This is a multi-part MIME message sent by reportbug.\n\n'
+ message.epilogue = ''
+ message.attach(bodypart)
+ for attachment in attachments:
+ if not os.path.isfile(attachment):
+ ewrite("Warning: can't find attachment '%s'.\n", attachment)
+ continue
+ ctype = None
+ cset = charset
+ if os.path.exists('/usr/bin/file'):
+ info = commands.getoutput('/usr/bin/file --mime --brief' +
+ commands.mkarg(attachment) +
+ ' 2>/dev/null')
+ match = re.match(r'([^;, ]*)(,[^;]+)?(?:; )?(.*)', info)
+ if match:
+ ctype, junk, extras = match.groups()
+ match = re.search(r'charset=([^,]+|"[^,"]+")', extras)
+ if match:
+ cset = match.group(1)
+ # If file doesn't work, try to guess based on the extension
+ if not ctype:
+ ctype, encoding = mimetypes.guess_type(
+ attachment, strict=False)
+ if not ctype:
+ ctype = 'application/octet-stream'
+
+ maintype, subtype = ctype.split('/', 1)
+ if maintype == 'text':
+ fp = file(attachment)
+ part = BetterMIMEText(fp.read(), _subtype=subtype,
+ _charset=cset)
+ fp.close()
+ elif maintype == 'message':
+ fp = file(attachment)
+ part = MIMEMessage(email.message_from_file(fp),
+ _subtype=subtype)
+ fp.close()
+ elif maintype == 'image':
+ fp = file(attachment, 'rb')
+ part = MIMEImage(fp.read(), _subtype=subtype)
+ fp.close()
+ elif maintype == 'audio':
+ fp = file(attachment, 'rb')
+ part = MIMEAudio(fp.read(), _subtype=subtype)
+ fp.close()
+ else:
+ fp = file(attachment, 'rb')
+ part = MIMEBase(maintype, subtype)
+ part.set_payload(fp.read())
+ fp.close()
+ email.Encoders.encode_base64(part)
+ part.add_header('Content-Disposition', 'attachment',
+ filename=os.path.basename(attachment))
+ message.attach(part)
+ else:
+ message = BetterMIMEText(body, _charset=charset)
+
+ # Standard headers
+ message['From'] = rfc2047_encode_address(fromaddr, charset, mua)
+ message['To'] = rfc2047_encode_address(sendto, charset, mua)
+
+ for (header, value) in headers:
+ if header in ['From', 'To', 'Cc', 'Bcc', 'X-Debbugs-CC', 'Reply-To',
+ 'Mail-Followup-To']:
+ message[header] = rfc2047_encode_address(value, charset, mua)
+ else:
+ message[header] = rfc2047_encode_header(value, charset, mua)
+
+ if ccaddr:
+ message['Cc'] = rfc2047_encode_address(ccaddr, charset, mua)
+
+ if bccaddr:
+ message['Bcc'] = rfc2047_encode_address(bccaddr, charset, mua)
+
+ replyto = os.environ.get("REPLYTO", options.replyto)
+ if replyto:
+ message['Reply-To'] = rfc2047_encode_address(replyto, charset, mua)
+
+ if mailing:
+ message['X-Mailer'] = VERSION
+ message['Date'] = email.Utils.formatdate(localtime=True)
+ elif mua and not (options.printonly or options.template):
+ message['X-Reportbug-Version'] = "2.48"
+
+ failed = using_sendmail = False
+ msgname = ''
+ # Disable smtphost if mua is set
+ if mua and smtphost:
+ smtphost = ''
+
+ addrs = [str(x) for x in (message.get_all('To', []) +
+ message.get_all('Cc', []) +
+ message.get_all('Bcc', []))]
+ alist = email.Utils.getaddresses(addrs)
+
+ cclist = [str(x) for x in message.get_all('X-Debbugs-Cc', [])]
+ debbugs_cc = email.Utils.getaddresses(cclist)
+ if cclist:
+ del message['X-Debbugs-Cc']
+ addrlist = ', '.join(cclist)
+ message['X-Debbugs-Cc'] = rfc2047_encode_address(addrlist, charset, mua)
+
+ if options.template or options.printonly:
+ pipe = sys.stdout
+ elif mua:
+ pipe, filename = TempFile()
+ elif options.outfile or not os.path.exists(options.mta):
+ msgname = options.outfile or ('/var/tmp/%s.bug' % package)
+ if os.path.exists(msgname):
+ try:
+ os.rename(msgname, msgname+'~')
+ except OSError:
+ ewrite('Unable to rename existing %s as %s~\n',
+ msgname, msgname)
+ try:
+ pipe = open_write_safe(msgname, 'w')
+ except OSError:
+ fh, newmsgname = TempFile(prefix=('reportbug-%s-%d-' %
+ (package, os.getpid())))
+ fh.write(message.as_string())
+ fh.close()
+ ewrite('Writing to %s failed; '
+ 'wrote bug report to %s\n', msgname, newmsgname)
+ msgname = newmsgname
+ elif not smtphost:
+ try:
+ x = os.getcwd()
+ except OSError:
+ os.chdir('/')
+ pipe = os.popen(options.mta+' -t -oi -oem', 'w')
+ using_sendmail = True
+
+ message = message.as_string()
+ if smtphost:
+ toaddrs = [x[1] for x in alist]
+ smtp_message = re.sub(r'(?m)^[.]', '..', message)
+
+ ewrite("Connecting to %s...\n", smtphost)
+ try:
+ conn = smtplib.SMTP(smtphost)
+ conn.sendmail(fromaddr, toaddrs, smtp_message)
+ conn.quit()
+ except (socket.error, smtplib.SMTPException), x:
+ failed = True
+ ewrite('SMTP send failure: %s\n', x)
+ fh, msgname = TempFile(prefix=('reportbug-%s-%d-' %
+ (package, os.getpid())))
+ fh.write(message)
+ fh.close()
+ ewrite('Wrote bug report to %s\n', msgname)
+ else:
+ pipe.write(message)
+ if msgname:
+ ewrite("Bug report written as %s\n", msgname)
+
+ if pipe.close() and using_sendmail:
+ failed = True
+ fh, msgname = TempFile(prefix=('reportbug-%s-%d-' %
+ (package, os.getpid())))
+ fh.write(message)
+ fh.close()
+ ewrite('Wrote bug report to %s\n', msgname)
+
+ if mua:
+ for bit in mua.split():
+ if '%s' not in bit: break
+ ewrite("Spawning %s...\n", bit or mua)
+ if '%s' not in mua:
+ mua += ' %s'
+ system(mua % commands.mkarg(filename)[1:])
+ elif not failed and (using_sendmail or smtphost):
+ if options.kudos:
+ ewrite('\nMessage sent to: %s\n', sendto)
+ else:
+ ewrite("\nBug report submitted to: %s\n", sendto)
+
+ addresses = []
+ for addr in alist:
+ if addr[1] != rfc822.parseaddr(sendto)[1]:
+ addresses.append(addr)
+
+ if len(addresses):
+ ewrite("Copies sent to:\n")
+ for address in addresses:
+ ewrite(' %s\n', rfc822.dump_address_pair(address))
+
+ if debbugs_cc and rtype == 'debbugs':
+ ewrite("Copies will be sent after processing to:\n")
+ for address in debbugs_cc:
+ ewrite(' %s\n', rfc822.dump_address_pair(address))
+
+ if not (exinfo or options.kudos) and rtype == 'debbugs':
+ ewrite('\n')
+ ui.long_message(
+"""If you want to provide additional information, please wait to
+receive the bug tracking number via email; you may then send any extra
+information to %s (e.g. %s), where n is the bug number.\n""",
+ (sysinfo['email'] % 'n'), (sysinfo['email'] % '999999'))
+
+ # If we've stored more than one copy of the message, delete the
+ # one without the SMTP headers.
+ if os.path.exists(msgname) and os.path.exists(filename):
+ try:
+ os.unlink(filename)
+ except:
+ pass
+
+ if filename and os.path.exists(filename) and not mua:
+ # Message is misleading if an MUA is used.
+ ewrite("A copy of the report is stored as: %s\n" % filename)
+ return
+
+if __name__ == '__main__':
+ sys.path.append('/usr/share/reportbug')
+ try:
+ main()
+ except KeyboardInterrupt:
+ ewrite("\nreportbug: exiting due to user interrupt.\n")
+ except debianbts.Error, x:
+ ewrite('error accessing BTS: %s\n' % x)
+=============================================================================
+
+root writes:
+
+\start
+Date: Thu, 20 May 2004 00:08:12 -0400
+From: root
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: [Axiom-developer] Re: maple clifford package
+
+BF,
+
+I downloaded your documents PDF and the Maple code.
+I did succeed in setting up the libraries.
+I tried to run the Maple code with little success.
+I'll try again soon.
+
+I was hoping that the docs contained a description of the algorithms
+but all I've seen so far is a description of the functions and their
+calling arguments.
+
+\start
+Date: Thu, 20 May 2004 10:21:40 +0200
+From: David MENTRE
+To: Bertfried.Fauser@uni-konstanz.de
+Subject: On formal correctness and readability (was: Re: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA)
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, camm@enhanced.com, Stavros Macrakis , siver@mx.ihep.su
+
+Hello,
+
+Bertfried Fauser writes:
+
+> Hence, for challenging problems, ie new math! and phys!, I would _reject_
+> the lates goodies programmers can provide and favour to have a stable, as
+> simple as possible, if possible provable algorithm.
+
+This is the path followed by the FOC project
+(http://www-calfor.lip6.fr/foc/index-en.html). The objective is to make
+a provable CAS. They are using free software for that (the OCaml
+language and the Coq proof assistant) but unfortunalty, they have chosen
+to make the system closed source and proprietary[1].
+
+On the Axiom side, there is a path that can be followed: using ACL2
+(http://www.cs.utexas.edu/users/moore/acl2/) to make a similar
+system. Both Axiom and ACL2 (and Maxima) run on GCL. But all the hard
+work (i.e. proving things) remain to be done.
+
+> New goodies, may be later added (in a separate pamphlet file ,
+> also by people who do not fully understand the theory and purpose of
+> the program. They can then check against the slow but stable
+> code. This method at least led me to stable and reasonable fast code,
+> which at the and was relatively complex.
+
+Interesting idea: systematizing the idea of reference
+implementation. And formal proofs between the different implementations
+are not necessary. We just need a framework to easily redo a fast
+computation with a slower but safer implementation. Of course, formal
+proof would be a plus, but I doubt that it can be done.
+
+
+[1] I wonder when one french reasearcher will understand the power and
+ necessity of free software for real research!
+
+\start
+Date: Thu, 20 May 2004 10:01:47 -0400
+From: Tim Daly
+To: bkocay@cc.UManitoba.ca
+Subject: [Axiom-developer] Axiom mailing list
+Cc: axiom-developer@nongnu.org, daly@idsi.net
+
+Go to http://savannah.nongnu.org/mail/?group=axiom to sign up.
+The developer list is where most discussion occurs.
+Averages about 1 email a day with gusts up to 15 or so on hot topics.
+
+The archives are at:
+http://mail.gnu.org/archive/html/axiom-developer
+
+Thanks for permission to use your paper. The plan is to rework it
+into a literate programming format which means to modify the TeX
+to include actual source code. Is there any chance of getting the
+original TeX (assuming you used that). I'm working on model examples
+of literate programs in Axiom and selecting interesting papers that
+include features like pseudocode, complexity analysis, algorithm
+theory, termination proofs, etc. Ideally all computational math
+papers would include runnable source code.
+
+You can see the sturm und drang in the archives.
+
+\start
+Date: Thu, 20 May 2004 09:00:27 -0400
+From: Tim Daly
+To: vb@cybertester.com
+Subject: [Axiom-developer] Re: [Axiom] Cyber Tester, LLC: Free automated bug list generation for Axiom
+
+Vladimir,
+
+There is code in Axiom to perform regression tests every time the
+system is changed.
+
+You're welcome to download the package and create a new testing
+scheme if you'd like. The CVS is at:
+
+http://savannah.nongnu.org/projects/axiom
+
+and you can send patches directly to me.
+
+How do you suggest we change the testing scheme?
+
+Tim
+
+===============================================================
+
+Hello Timothy,
+
+You are the leader of the Axiom project; do you think it would
+be interesting to identify bugs in Axiom automatically?
+
+Actually, I am in software testing 10+ years, particularly, I have
+tested MMA, Maple, Derive, MuPAD, and more, details are here
+http://www.cas-testing.org/index.php?list=3
+
+I know your site and visited it a number of times. I have a limited
+live experience with Axiom but I had read the J/S book many times.
+Sure, I also have seen Axiom bug list. I work on automated testing
+of computer algebra systems; now I have shown publicly a couple of
+first steps like http://maple.bug-list.org/ but I have gotten
+essentially farther, and most probably within several next months
+I will update cardinally my servers wrt Maple.
+
+I find Axiom to be a terrific environment and have real interest
+in testing it. Thought I did not test Axiom still, from the previous
+experience with MMA/Maple I can expect that my GEMM environment
+can calculate solid "minimal" bug lists, its records will contain
+the "minimal" (say, in length) samples at which the given bug
+manifests.
+
+What do you make of it?
+
+Best wishes,
+
+Vladimir
+
+\start
+Date: Thu, 20 May 2004 11:31:58 -0400
+From: "Stavros Macrakis"
+To: "'Tim Daly'"
+Subject: [Axiom-developer] RE: maxima and axiom
+
+> Maxima and Axiom can work together usefully. One interesting
+> idea is that since maxima is common lisp and axiom is also
+> common lisp we could run them both in the same image.
+
+That would be great! I don't know anything at all about Axiom, so I
+have no clue about how that would work....
+
+Maxima is not a clean system. A lot of state is held in global
+variables or communicated via global variables. Errors aren't always
+clean. Etc. So it is not easy to make it "play well with others". But
+there are certainly clean parts, and other parts might be encapsulable.
+
+\start
+Date: Thu, 20 May 2004 10:20:41 -0400
+From: Tim Daly
+To: stavros.macrakis@verizon.net
+Subject: [Axiom-developer] maxima and axiom
+
+Maxima and Axiom can work together usefully. One interesting idea
+is that since maxima is common lisp and axiom is also common lisp
+we could run them both in the same image. In axiom you can execute
+lisp commands with
+ )lisp (yourlispfn args)
+
+Suppose we load maxima into an axiom image. We could then type:
+
+ )lisp (maxima)
+
+and be in maxima. Why bother? Well, if we could get the two systems
+to talk it might be useful to use one system to check the results of
+the other system automatically. And since Axiom is really just lisp
+then Maxima could use Axiom code and vice-versa. It would take some
+engineering but that's just the easy part :-)
+
+\start
+Date: 20 May 2004 18:42:13 -0400
+From: Camm Maguire
+To: =?iso-8859-1?q?Fr=E9d=E9ric?= Lehobey
+Subject: Re: [Axiom-developer] Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
+
+Greetings!
+
+OK, trial packages are now at
+
+http://people.debian.org/~camm/
+
+snapshot taken at 20040517. Please check them out all who are
+interested and provide feedback if any. These are most likely the
+versions that will be in the next Debian release ("sarge").
+
+Please keep in mind that while the division is not set in stone
+(especially 'axiom-tex'), most of it is required to satisfy Debian
+policy, which mandates that significant binary-independent data be
+stored in /usr/share in a separate binary independent package.
+
+Another item which I've included, though am not yet fully committed
+to, is a little helper script to rerun the test suite on the users
+fresh install should they desire, together with the concatenated
+.output files generated at build time.
+
+One item not currently in which might be a good idea is to run the
+build twice after the .fn files have been generated.
+
+Fr=E9d=E9ric Lehobey writes:
+
+> Dear Camm,
+>
+> On Thu, Apr 22, 2004 at 02:40:55PM -0400, Camm Maguire wrote:
+> > Greetings!
+> >
+> > Along these lines, I'd just like to note that the 01/30 axiom snapshot
+> > has just entered Debian testing.
+>
+> Congratulations and thanks a lot!
+>
+> > Had to hand compile on alpha to get
+> > around a libc6.1 bug which apparently will not be fixed soon.
+>
+> Which one is it? Have you its number around.
+>
+
+221969, now fixed, thankfully!
+
+> > As earlier stated, I'd like to get another snapshot in before the
+> > Debian 'sarge' release is finalized. Toward this end, I think the
+> > axiom package needs splitting, at the very least due to the Debian
+> > policy requirements that arch-dependent (e.g. .o files) and
+> > arch-independent (e.g. source files and docs) data needs to be
+> > separated.
+> >
+> > As I know there are quite a few Debian axiom users here, I thought I'd
+> > solicit opinions on a binary package structure. Perhaps at least
+> > axiom, axiom-doc and axiom-source.
+>
+> That would be great. Could we even have axiom package suggest
+> axiom-source? (or maybe an intermediate [axiom-spad?] package
+> recommended by axiom that would provide the .spad files extracted from
+> the original sources .spad.pamphlet).
+>
+
+Yes, axiom now recommends axiom-source.
+
+> You mentioned earlier to me having already long ago solved bug
+> #237634 in your personal cvs tree. Is this cvs repository publicly
+> available? If not, would you mind providing some (read) access to it
+
+This fix is in the latest packages.
+
+> as is doing, for example, David Mentr=E9 with his code (by using arch,
+> not cvs, and for development, not packaging) at
+> . I am currently
+> learning how to produce Debian packages, and been able to lurk at the
+> way your are preparing your packaging would be to me a great
+> incitement to help you debugging (and porting) and (hopefully some
+> day) provide relevant patches (I have great interest in Axiom though
+> not yet been able to spend on it as much time as I would like to).
+>
+
+Looking at debian/rules is the best way to get started, IMHO.
+
+
+\start
+Date: Thu, 20 May 2004 21:10:20 -0400
+From: Camm Maguire
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] Debian Axiom package
+Cc: Frederic.Lehobey@free.fr, daly@idsi.net
+
+Greetings!
+
+OK, trial packages are now at
+
+http://people.debian.org/~camm/
+
+snapshot taken at 20040517. Please check them out all who are
+interested and provide feedback if any. These are most likely the
+versions that will be in the next Debian release ("sarge").
+
+Please keep in mind that while the division is not set in stone
+(especially 'axiom-tex'), most of it is required to satisfy Debian
+policy, which mandates that significant binary-independent data be
+stored in /usr/share in a separate binary independent package.
+
+Another item which I've included, though am not yet fully committed
+to, is a little helper script to rerun the test suite on the users
+fresh install should they desire, together with the concatenated
+.output files generated at build time.
+
+One item not currently in which might be a good idea is to run the
+build twice after the .fn files have been generated.
+
+Fr=E9d=E9ric Lehobey writes:
+
+> Dear Camm,
+>
+> On Thu, Apr 22, 2004 at 02:40:55PM -0400, Camm Maguire wrote:
+> > Greetings!
+> >
+> > Along these lines, I'd just like to note that the 01/30 axiom snapshot
+> > has just entered Debian testing.
+>
+> Congratulations and thanks a lot!
+>
+> > Had to hand compile on alpha to get
+> > around a libc6.1 bug which apparently will not be fixed soon.
+>
+> Which one is it? Have you its number around.
+>
+
+221969, now fixed, thankfully!
+
+> > As earlier stated, I'd like to get another snapshot in before the
+> > Debian 'sarge' release is finalized. Toward this end, I think the
+> > axiom package needs splitting, at the very least due to the Debian
+> > policy requirements that arch-dependent (e.g. .o files) and
+> > arch-independent (e.g. source files and docs) data needs to be
+> > separated.
+> >
+> > As I know there are quite a few Debian axiom users here, I thought I'd
+> > solicit opinions on a binary package structure. Perhaps at least
+> > axiom, axiom-doc and axiom-source.
+>
+> That would be great. Could we even have axiom package suggest
+> axiom-source? (or maybe an intermediate [axiom-spad?] package
+> recommended by axiom that would provide the .spad files extracted from
+> the original sources .spad.pamphlet).
+>
+
+Yes, axiom now recommends axiom-source.
+
+> You mentioned earlier to me having already long ago solved bug
+> #237634 in your personal cvs tree. Is this cvs repository publicly
+> available? If not, would you mind providing some (read) access to it
+
+This fix is in the latest packages.
+
+> as is doing, for example, David Mentr=E9 with his code (by using arch,
+> not cvs, and for development, not packaging) at
+> . I am currently
+> learning how to produce Debian packages, and been able to lurk at the
+> way your are preparing your packaging would be to me a great
+> incitement to help you debugging (and porting) and (hopefully some
+> day) provide relevant patches (I have great interest in Axiom though
+> not yet been able to spend on it as much time as I would like to).
+>
+
+Looking at debian/rules is the best way to get started, IMHO.
+
+\start
+Date: Fri, 21 May 2004 01:15:54 -0400
+From: root
+To: camm@enhanced.com
+Subject: Re: [Axiom-developer] Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
+Cc: Frederic.Lehobey@free.fr
+
+Camm,
+
+Axiom "knows" where certain files reside so you may need symbolic
+links to get it to run. I am working hard on putting together the
+ISSAC proceedings on CD and can't look at the debian package now.
+Next week I have to go give two invited lectures and will likely not
+have connectivity (it's still the late 80s in most of the world it
+seems). So I'm not going to be able to look critically at the changes
+you've made to the axiom distribution until after next week.
+
+We should rewrite the Makefiles to build in your new "install"
+scheme. Can you give me a simple outline of what you moved where?
+I'll rewrite the Makefile install so it all works properly and
+you don't have to change anything for debian. But it can't happen
+in the next two weeks. If you can get the move list to me by
+monday I can probably work on the changes offline in the hotel.
+
+\start
+Date: Fri, 21 May 2004 09:09:25 -0400
+From: Tim Daly
+To: vb@cybertester.com
+Subject: [Axiom-developer] Re: Your current Axiom bug list is far far too short to be trusted
+
+> By some technical reasons, right away I'd strongly
+> prefer to work with Windows version.
+>
+> Do you currently have Axiom for Windows?
+> If not, when do you think Axiom for Windows could be available?
+
+Axiom does not yet run on Windows. The port is "in plan" but has
+not happened yet. I won't have access to a Windows machine until
+we get the open source lab up and running which won't be for
+another few weeks.
+
+> I'd say these 52 entries makes a kind of toy Axiom bug list.
+> In my opinion, if you want to make Axiom reliable and mathematically
+> correct, you might be interesting in a more solid bug list.
+>
+> If you do not want to get Axiom tested by my environment, no
+> problem, just tell me this explicitly, so I'd not bother you
+> in the future.
+
+erm...ok. it's open source. find a bug. report it. send a patch
+that fixes it and I'll incorporate it. if not, I'll fix it as
+soon as I can. Most bugs don't get posted because I'm the one
+who knows what the bug is and I fix them as I find them. The
+most active developers usually send me mail directly rather than
+use the bug list.
+
+Are you suggesting that the length of a bug list is in some
+way related to the quality of software? I'd welcome any testing
+you're willing to do on Axiom. It certainly needs more testing
+and there are certainly more bugs. But the code has been around
+for 30 years so it doesn't have the typical "startup" bug profile.
+
+See the archives for this mailing list related to the CATS
+(Computer Algebra Test Suite) effort.
+
+\start
+Date: Sat, 22 May 2004 12:26:39 +0200 (CEST)
+From: "m.rubey"
+To: Petri Salmela
+Subject: [Axiom-developer] Re: Axiom build trouble on Mandrake
+
+Thanks a lot, this worked!!!
+
+Martin
+
+On Fri, 23 Apr 2004, Petri Salmela wrote:
+
+> Hello!
+>
+> I was trying to compile Axiom on Mandrake 9.2 and ran into some
+> problems. With google I found out that you had similar problems about
+> one month ago. I red those emails on Gcl-devel and Axiom-developer
+> -lists, but didn't find solution there. I don't know if you have found
+> any solution, but atleast for me installing package
+> "glibc-static-devel-2.3.2-14mdk" seemed to help.
+>
+> I sent this to you in case that you still need to solve this problem and
+> haven't found the solution.
+>
+> Best wishes,
+>
+> Petri Salmela
+> --
+> ,----------------------.-------------------------------.
+> | Petri Salmela | |
+> | University of Turku | |
+> `----------------------^-------------------------------'
+
+\start
+Date: Fri, 21 May 2004 16:21:40 -0700
+From: Richard Fateman
+To: Bob McElrath
+Subject: Re: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, Bertfried.Fauser@uni-konstanz.de, Camm Maguire , feyncalc@feyncalc.org, siver@mx.ihep.su
+
+I would not discard the possibility the best most concrete descriptions
+of algorithms that you will find will be the programs (e.g.
+Mathematica code), and that the reduction of the papers to
+the code may involve details not present in the papers.
+
+This opinion is, however, based on general experience and not
+a particular examination of FeynCalc.
+
+Good luck in any case..
+RJF
+
+\start
+Date: 21 May 2004 17:58:10 -0400
+From: Camm Maguire
+To: daly@idsi.net
+Subject: Re: [Maxima] Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, stavros.macrakis@verizon.net, siver@mx.ihep.su, Bertfried.Fauser@uni-konstanz.de
+
+Greetings! Just a thought here -- luckily all this is on top of lisp,
+and, in principle, its 'code is data' feature would allow one to write
+a walker which would generate a list of invocations guaranteed to
+trigger every branch, or even specified levels of branch
+combinations. Someone told me once they've seen such a walker for a
+certain application, so the idea is not completely vaporware, but I'd
+imagine the test list would grow exponentially quite quickly.
+
+Just a thought.
+
+Take care,
+
+root writes:
+
+> Bob,
+>
+> > Test cases.
+> >
+> > While this does not *prove* the correctness of the code in a
+> > mathematical sense, it does in a monte-carlo sense. I note that both
+> > maxima and axiom have test suites.
+> >
+> > I do not think new mathematical code or subsystems should be accepted
+> > unless they are accompanied by a thorough test suite.
+>
+> I've been collecting test cases from different computer algebra systems.
+> The effort is called CATS (Computer Algebra Test Suite).
+>
+> One of the problems with current systems, like Axiom, is that people
+> write some algebra then write some test cases. The test cases are not
+> comprehensive, don't test corner cases, and don't test failure modes.
+> And, most egregious is, they are not documented. The tests given
+> an answer but is it the right answer? So current test cases are only
+> really useful as regression tests looking for what's broken.
+>
+> So the idea is to collect the various test suites, document the
+> underlying math and set up pamphlet files which contain code for
+> each of the various systems. You can get the Axiom code pile with
+> the CATS work using the tla from Gnu-arch.
+>
+> The idea is to develop a test suite that would be similar to the
+> NIST (National Institute of Standards and Technology) classification
+> scheme for numerical software but this time for symbolic software.
+> Currently there is no classification scheme and no agreed-upon
+> test suite.
+>
+> There are few enough computational mathematicians. We shouldn't waste
+> their time duplicating tests in areas that others have already done.
+> Besides, tests are best when written by others :-)
+>
+> Thus, CATS.
+
+\start
+Date: 21 May 2004 18:19:28 -0400
+From: Camm Maguire
+To: daly@idsi.net
+Subject: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, Stavros Macrakis , bertfried.fauser@uni-konstanz.de, siver@mx.ihep.su
+
+Greetings! Just my 0.02 here --
+
+I think the concept of literate programming axiom has adopted is
+marvelous. The need for providing a ladder whereby a human brain can
+easily expand the realm of its comprehension into a new area of
+interest without expensive infrastructure and in a reasonable period
+of time exceeds the need for a black box to spit out an answer in
+assembly line fashion, IMHO, though both needs obviously exist and
+will continue to do so. As long as we're talking 30 years, I think
+the real coup would be to provide a framework which smooths the path
+stretching from one end of this continuum to the other, and
+concommitantly, provides utility and access to as wide a group of
+interested volunteers as possible, especially in this frenetic age
+when one's available time is likely to come in erratic and
+unpredicatable short bursts.
+
+Take care,
+
+
+Tim Daly writes:
+
+> I know this is a research problem though hardly one that merits papers
+> on the subject, I guess.
+>
+> My goal isn't to solve physics/math problems. My goal is to build a system
+> that will be used by computational mathematicians 30 years from now. Once
+> this is the stated goal several things become clear.
+>
+> One clear problem that every system suffers from is that the research
+> papers are disconnected from the code. Mathematicians do the research
+> and programmers do the code. Usually it is the same person with two
+> mindsets. So the math mindset writes the theory with theorems and
+> proofs then publishes it, possibly making claims (with no way to
+> verify the claims by others). The programmer mindset writes the code
+> which hopefully correctly implements the theory but never publishes it.
+> Or publishes it as a "contribution" to some system.
+>
+> Consider the issues this raises for computational mathematicians.
+>
+> First, claims are made which cannot be reproduced. Citing results of
+> the program runs without presenting the programs is equivalent to
+> citing theorems without providing proofs. How can a referee properly
+> review such work? Physics and chemistry require reproduced results
+> before claims are accepted.
+>
+> Second, the programs are either not available or published as
+> contributions. In the first case who is to know if the actual reason
+> for an algorithmic speedup turns out to be a compiler switch rather
+> than some theoretical reason like term ordering in a groebner basis
+> computation? Since it is unpublished the code is likely to die thus
+> undermining both the basis for the claim and the possibility that
+> other researchers can build on the work.
+>
+> The second case is even worse in some sense. I have 1100 domains
+> in Axiom (some of which I wrote) and 100+ algorithms in Magnus
+> with no theoretical documentation; indeed most have no documentation
+> at all. In the 30 year view how is the next generation supposed to
+> build upon the work we've done so far? How can they see the evolution
+> of algorithms? How can they maintain the code without the theory?
+>
+> Axiom represents over 30 years and over 300 man-years of research.
+> I don't believe that there will be funding to build systems that are
+> this large and this general. Even if one funded such an effort we
+> end up with a lot of rework that virtually no-one wants to do.
+>
+> So I'm proposing a goal for the 30 year horizon. We need to make an
+> effort to collect the theory and the code and reunite the two. I
+> realize that there are issues.
+>
+> One issue is, as you point out, that code has to deal with grubby
+> details which the theory can skip. But real design choices are made
+> when reducing theory to practice and these design choices greatly
+> affect the results. We need to encourage the practice of explaining
+> these design decisions. For example, how are infinite objects (like
+> groups) represented? We have learned that in simple domains like
+> polynomials there are a wide range of design choices (dense, sparse,
+> recursive, etc) that are appropriate for different problems.
+>
+> Another issue is that current systems don't "reach up" close enough to
+> the theory. The gap between the theory and the implementation (I call
+> it the impedance mismatch) is too large for most systems. For
+> instance, Magnus is implemented in C++ which is WAY too close to the
+> machine and very, very far away from Infinite Group Theory (the Magnus
+> domain). Thus the burden of crossing this gap falls on the
+> programmer. Systems like Axiom are much closer to the mathematics. But
+> not close enough. We need systems that span this gap in carefully
+> structured ways so we can be efficient without being obscure.
+> This is one of the root causes of your comment that "the
+> practical implementation of the algorithm is often connected to the
+> published algorithm in complicated ways". The implemented algorithm
+> should not be much longer than the published one.
+>
+> If we look at the 30 year horizon it is clear that all papers in
+> computational mathematics will be online. We must set standards
+> now, or at least strive for good examples, that make it possible
+> to use the research effectively. In today's terms we should be
+> able to "drag and drop" a computational mathematics paper onto
+> a system like Axiom and have it immediately available. (In 30
+> year terms Axiom should know the "intentional stance" of the
+> researcher and automatically incorporate the algorithms).
+>
+> One of the key problems is that "Computational Mathematics" is
+> like "Computer Science" was 30 years ago. Comp Sci was a branch
+> of the Math dept (numerical analysis), Engineering (circuit
+> minimization), or Business (spreadsheets). It was not recognized
+> as its own subject with yet.
+>
+> Today Computational Mathematics is growing out of Math (research
+> papers with no code), Comp Sci (research papers in polynomial
+> representation), Physics (clifford algebras, hopf algebras), or
+> Engineering (matrix methods), etc. It is not recognized as its
+> own subject yet (at least not everywhere. Risc-Linz, UWO, Waterloo,
+> and a few other places seem to have done so).
+>
+> My current religious zealotism and wild-eyed, irrational planning
+> (I admit it's over-the-top-painful) claim is that we need to start
+> with an old idea "Literate Programming" and evolve it to suit the
+> needs of the next generation Computational Mathematician. Thus
+> all of Axiom (and soon Magnus) has been rewritten into TeX documents.
+> There are no C, Lisp, Spad, Makefile, etc files. Now I'm trying to
+> ensure that new code added to the system includes the theory (or
+> at least permission to use the paper so I can write the literate
+> document).
+>
+> Thus I would really like to see the papers that provide the theory for
+> FeynCalc as well as the code. If I can write one of the algorithms in
+> Axiom in a few dozen lines that would be much clearer than a few
+> thousand lines of C and I'd have the research paper attached.
+>
+> It's a hard problem but we have 30 years to solve it.
+
+\start
+Date: 21 May 2004 18:05:34 -0400
+From: Camm Maguire
+To: Bob McElrath
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, Bertfried.Fauser@uni-konstanz.de, siver@mx.ihep.su
+
+Greetings!
+
+Bob McElrath writes:
+
+> FeynCalc involves a significant amount of "interface" for writing
+> lagrangians, etc that may not be appropriate for literal translation,
+> due to language differences. It may be worth thinking hard about a
+> re-implementation of the functionality rather than a direct port.
+>
+
+Toward this end, it would be helpful to clearly and as concisely as
+possible detail what Feyncalc can do, i.e. what is the functionality
+implemented. I'm assuming this exists in the documentation, but as
+you can tell, I haven't found time to dig in yet.
+
+Take care,
+
+
+> > > The "algorithms" are documented in QFT textbooks such as Peskin &
+> > > Schroeder
+> >
+> > Would you really make this a claim? I still think, that without expert
+> > knowledge one cannot derive even simple results out of these sources...
+>
+> I agree.
+
+\start
+Date: Sun, 23 May 2004 00:00:51 -0700 (PDT)
+From: C Y
+To: Richard Fateman , Bob McElrath
+Subject: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, Camm Maguire , Bertfried.Fauser@uni-konstanz.de, siver@mx.ihep.su
+
+Maybe a good way to say it is thus:
+
+An algorithm implemented in a program allows no implicit assumptions.
+
+In a case where there are issues with translating an algorithm to
+program level, the questions that come to my mind are:
+
+1) Do the implicit assumptions initially made, when made explicit, map
+well to the programming environment?
+
+2) Has the space in which the algorithm is known/intended to operate
+been well defined?
+
+3) Are the assumptions in fact well understood?
+
+In theory at least, computers ought to be capable of verifying that
+human created mathematics is correct. (Somebody correct me if that
+isn't true.) Perhaps part of the problem is that a human being faced
+with a physical/science problem can make "sane" assumptions where a
+computer cannot, or see that a result makes no physical sense and thus
+conclude there is a mistake. Making sure the system has enough
+information to do the job is often a difficult propositon.
+
+Perhaps a trend toward literate programming such as that being used in
+Axiom might be generally better practice for defining algorithms, but I
+suspect the extra work involved will limit the appeal to many.
+Probably if an idea is reduced to working symbolic computational
+algorithms it will be by someone who focuses on that.
+
+CY
+
+--- Richard Fateman wrote:
+> I would not discard the possibility the best most concrete
+> descriptions
+> of algorithms that you will find will be the programs (e.g.
+> Mathematica code), and that the reduction of the papers to
+> the code may involve details not present in the papers.
+>
+> This opinion is, however, based on general experience and not
+> a particular examination of FeynCalc.
+>
+> Good luck in any case..
+> RJF
+
+\start
+Date: 21 May 2004 18:02:29 -0400
+From: Camm Maguire
+To: Bob McElrath
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, Bertfried.Fauser@uni-konstanz.de, siver@mx.ihep.su
+
+Greetings!
+
+Bob McElrath writes:
+
+> Bertfried Fauser [fauser@spock.physik.uni-konstanz.de] wrote:
+> >
+> > Hi,
+> >
+> > as fare as I understand the package (havn't though done much with it, so I
+> > might be wrong), it is designed for very "practical" purpose (ie
+> > phenomenology.) Many problems can be subsummarized in a larger frame of
+> > mathematics. Given the type system of AXIOM, it would be, in my eyes, a
+> > fraud to implement something like "Dirac matrixes" and trace rules, while
+> > this is a closed structure in a *-autonomous category. However, I am still
+> > not able myself to give AXIOM code for such a vast general thing.
+>
+> The *purpose* of FeynCalc is to be a general purpose framework for doing
+> quantum field theory calculations. That is, dirac matrices, trace
+> rules, Feynman rules from Lagrangians, representations for fields and
+> the like.
+>
+> It also contains code for doing one-loop integrals. This same code
+> exists in several places (I know of a fortan library "ff" and a Maple
+> package "xloops" as well), and I can point to the papers if people
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+I think this would be helpful.
+
+Take care,
+
+
+> desire. But the loop code is only half of FeynCalc.
+>
+> The actual algorithms are straightforward, but very tedious to
+> calculate, so thus the results are collected into libraries like
+> FeynCalc. There are yet a handful of obstacles in dealing with
+> divergences that have kept us from writing a fully automatic method of
+> computing these loop integrals. At one loop I think it can be fully
+> automatic, but I do not think this is something a non-expert would want
+> to tackle.
+>
+> The "algorithms" are documented in QFT textbooks such as Peskin &
+> Schroeder "An Introduction to Quantum Field Theory", Weinberg "Quantum
+> Theory of Fields", etc. This is a one-year graduate level physics
+> course. The decomposition of loop integrals into scalar integrals was
+> done by Passarino and Veltman
+> http://dx.doi.org/10.1016/0550-3213(79)90234-7
+> though these days it's not the only way...
+
+\start
+Date: Fri, 21 May 2004 15:54:35 -0700
+From: Bob McElrath
+To: Camm Maguire
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, Bertfried.Fauser@uni-konstanz.de, siver@mx.ihep.su
+
+Camm Maguire [camm@enhanced.com] wrote:
+> Greetings!
+>
+> Bob McElrath writes:
+> > It also contains code for doing one-loop integrals. This same code
+> > exists in several places (I know of a fortan library "ff" and a Maple
+> > package "xloops" as well), and I can point to the papers if people
+> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+>
+> I think this would be helpful.
+
+Let me say that this *must* be implemented by an expert. The physics
+community barely trusts such codes, and the ones that are barely trusted
+(such as ff) have been massively cross checked across many calculations
+and papers. That said:
+ http://dx.doi.org/10.1016/0550-3213(79)90605-9
+Here is a more modern reference with some new ideas, and the references
+will be useful:
+ http://arxiv.org/abs/hep-ph/0307113
+Bertfried Fauser (on CC list) works on these types of things and might
+be an appropriate person to do it.
+
+These calculations are in general plauged by singularities, and the
+procedure to remove them lies in physics, not math (renormalization).
+The singularities are real, but we understand that they do not affect
+physical observables. If it were possible to write general algorithmic
+codes, we would do it.
+
+\start
+Date: 21 May 2004 20:17:16 -0400
+From: Camm Maguire
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
+Cc: Frederic.Lehobey@free.fr, axiom-developer@nongnu.org
+
+Greetings! OK, please tell me if the following is not clear. Debian
+can build packages using 'install' and 'links' files. The former
+consists of lines of two fields each: the file location in the build
+tree and its destination directory when the corresponding package is
+installed. The latter (i.e. 'links files) also consist of lines of
+two fields each: the installed file location and the destination
+location of the link. Lastly, Debian has a 'control' file which
+describes the packages and their interrelationships.
+
+I've included what I have so far below. Please note that it is still
+a work in progress for sure -- comments most appreciated. For
+example, Debian has nowebm already packaged, so I've omitted these
+files and had the package suggest nowebm. I'm assuming that is
+sufficient, but it would also be possible of course to require nowebm
+and install links as appropriate. I'd also appreciate recommendations
+on the wording of the package descriptions, as these were obviously
+just put together quickly. There are other debian specific files,
+such as menu entries, TeX style file installation scripts, etc. These
+can be examined by unpacking the .debs directly, a task with which I
+will be happy to assist should you desire.
+
+Lastly, I'm experimenting a bit with the build procedure. I've tried
+instructing the build to run twice after touching the .lisp and .lsp
+files, as you've earlier mentioned and we've discussed, for a dramatic
+performance improvement. I'm trying now to achieve the same result
+with a single compile pass (debian has some very slow platforms),
+using a 'sys-proclaim.lisp' file automatically generated from the .fn
+files via (for example)
+
+echo ')lisp (compiler::make-all-proclaims "int/interp/*.fn"
+"int/algebra/*.fn")' | obj/linux/bin/interpsys
+
+and adding this to the PROCLAIMS make variable in
+src/interm/Makefile.pamphlet to be loaded into depsys. Depending on
+how you load your .fn files (haven't yet checked), this could be
+faster as well -- all this compiler generated info should be loaded
+into the image before compiling any of the final .o files (i.e. not
+just the .fn file pertaining to the file being compiled.) I think
+axiom likely already does this.
+
+Take care,
+
+=============================================================================
+axiom-databases.install
+=============================================================================
+mnt/linux/algebra/browse.daase usr/share/axiom-0.20040517/algebra
+mnt/linux/algebra/category.daase usr/share/axiom-0.20040517/algebra
+mnt/linux/algebra/compress.daase usr/share/axiom-0.20040517/algebra
+mnt/linux/algebra/interp.daase usr/share/axiom-0.20040517/algebra
+mnt/linux/algebra/operation.daase usr/share/axiom-0.20040517/algebra
+mnt/linux/algebra/gloss.text usr/share/axiom-0.20040517/algebra
+mnt/linux/algebra/topics.data usr/share/axiom-0.20040517/algebra
+=============================================================================
+=============================================================================
+axiom-databases.links
+=============================================================================
+usr/share/axiom-0.20040517/algebra/browse.daase usr/lib/axiom-0.20040517/algebra/browse.daase
+usr/share/axiom-0.20040517/algebra/category.daase usr/lib/axiom-0.20040517/algebra/category.daase
+usr/share/axiom-0.20040517/algebra/compress.daase usr/lib/axiom-0.20040517/algebra/compress.daase
+usr/share/axiom-0.20040517/algebra/interp.daase usr/lib/axiom-0.20040517/algebra/interp.daase
+usr/share/axiom-0.20040517/algebra/operation.daase usr/lib/axiom-0.20040517/algebra/operation.daase
+usr/share/axiom-0.20040517/algebra/gloss.text usr/lib/axiom-0.20040517/algebra/gloss.text
+usr/share/axiom-0.20040517/algebra/topics.data usr/lib/axiom-0.20040517/algebra/topics.data
+=============================================================================
+=============================================================================
+axiom-doc.install
+=============================================================================
+mnt/linux/doc/DeveloperNotes.dvi usr/share/doc/axiom-doc
+mnt/linux/doc/Rosetta.dvi usr/share/doc/axiom-doc
+mnt/linux/doc/book.dvi usr/share/doc/axiom-doc
+mnt/linux/doc/book.pdf usr/share/doc/axiom-doc
+mnt/linux/doc/hypertex usr/share/doc/axiom-doc
+mnt/linux/doc/msgs usr/share/doc/axiom-doc
+mnt/linux/doc/ps usr/share/doc/axiom-doc
+mnt/linux/doc/src usr/share/doc/axiom-doc
+debian/axiom_tutorialu usr/share/doc/axiom-doc
+=============================================================================
+=============================================================================
+axiom-doc.links
+=============================================================================
+usr/share/doc/axiom-doc usr/lib/axiom-0.20040517/doc
+=============================================================================
+=============================================================================
+axiom-source.install
+=============================================================================
+mnt/linux/src usr/share/axiom-0.20040517
+=============================================================================
+=============================================================================
+axiom-source.links
+=============================================================================
+usr/share/axiom-0.20040517/src usr/lib/axiom-0.20040517/src
+=============================================================================
+=============================================================================
+axiom-test.install
+=============================================================================
+mnt/linux/input usr/share/axiom-0.20040517
+debian/test_results usr/share/doc/axiom-test
+debian/bin/axiom-test usr/bin
+debian/axiom-test.1 usr/share/man/man1
+=============================================================================
+=============================================================================
+axiom-test.links
+=============================================================================
+usr/share/axiom-0.20040517/input usr/lib/axiom-0.20040517/input
+=============================================================================
+=============================================================================
+axiom-tex.install
+=============================================================================
+mnt/linux/bin/axiom.sty usr/share/texmf/tex/plain/misc
+=============================================================================
+=============================================================================
+axiom.install
+=============================================================================
+mnt/linux/autoload/apply.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/c-doc.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/c-util.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/profile.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/category.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/compiler.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/define.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/functor.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/info.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/iterator.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/modemap.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nruncomp.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/package.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/htcheck.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/xruncomp.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/parsing.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/bootlex.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/def.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/fnewmeta.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/metalex.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/metameta.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/parse.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/postpar.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/preparse.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/bc-matrix.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/bc-misc.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/bc-solve.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/bc-util.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/ht-util.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/htsetvar.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/ht-root.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/br-con.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/br-data.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/showimp.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/br-op1.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/br-op2.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/br-search.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/br-util.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/topics.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/br-prof.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/br-saturn.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/ax.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-c02.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-c05.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-c06.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-d01.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-d02.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-d03.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-e01.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-e02.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-e04.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-f01.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-f02.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-f04.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-f07.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nag-s.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/nspadaux.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/wi1.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/wi2.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/pspad1.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/pspad2.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/autoload/mark.o usr/lib/axiom-0.20040517/autoload
+mnt/linux/algebra/ABELGRP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ABELGRP-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ABELMON.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/exposed.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ABELMON-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ABELSG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ABELSG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BOOLEAN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CABMON.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CHAR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CLAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CLAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DFLOAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIFRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIFRING-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIVRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIVRING-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ENTIRER.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ES.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ES-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EUCDOM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EUCDOM-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFIELDC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFIELDC-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FPS-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GCDDOM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GCDDOM-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HOAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HOAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ILIST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INS-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTDOM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTDOM-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ISTRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LNAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LNAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LSAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LSAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONOID.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONOID-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MTSCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NNI.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OINTDOM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDRING-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OUTFORM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PI.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRIMARR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLYCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLYCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PSETCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PSETCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QFCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QFCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RCAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RCAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RING-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RNG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RNS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RNS-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SETAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SETAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SETCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SETCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SINT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SYMBOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TSETCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TSETCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UFD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UFD-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ULSCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPOLYC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPOLYC-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/URAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/URAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VECTOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/AHYP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ATTREG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CFCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ELTAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/KOERCE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/KONVERT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MSYSCMD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODEIFTBL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMCONN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMDEV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OUT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRIMCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRINT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PTRANFN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SPFCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TYPE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ANY1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMBOPC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DROPT1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EQ2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FORTCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ITFUN2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ITFUN3.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ITUPLE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MKBCFUNC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MKRECORD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MKUCFUNC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NONE1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PLOT1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PPCURVE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PSCURVE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REAL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RESLATC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RETRACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RETRACT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEGBIND2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEGCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STREAM1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STREAM2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STREAM3.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FMC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FMFUN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FORTFN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FVC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FVFUN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTRET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEGXCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/AGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/AGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BASTYPE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BASTYPE-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GRDEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIST3.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MKFUNC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ANON.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COLOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMPPROP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ELTAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ELTAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ESCONT1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EXIT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FAMONC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FILECAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FINITE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FNCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FORMULA1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IDPC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IEVALAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IEVALAB-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTBIT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LMODULE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LOGIC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LOGIC-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MAPHACK1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MAPHACK2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MAPHACK3.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MAPPKG1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MAPPKG2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MAPPKG3.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONAD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONAD-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NIPROB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NONE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NUMINT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODECAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODEPROB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMENC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ONECOMP2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OPTCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OPTPROB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDSET-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PALETTE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PARPCURV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PARPC2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PARSCURV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PARSC2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PARSURF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PARSU2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATMAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATRES2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATTERN1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PDECAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PDEPROB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REPSQ.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REPDB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RFDIST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RIDIST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RMODULE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEXCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SGROUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SGROUP-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SPACEC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SPLNODE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STEP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUCH.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TEX1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UDVO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/YSTREAM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ATRIG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ATRIG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BMODULE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CACHSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CHARNZ.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CHARZ.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DVARCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DVARCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ELEMFUN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ELEMFUN-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ESTOOLS2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EVALAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EVALAB-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FCOMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FEVALAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FEVALAB-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FPATMAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GROUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GROUP-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IDPAM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IDPO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IXAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INCRMAPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IXAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/KERNEL2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LALG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LINEXP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MODMONOM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONADWU.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONADWU-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MRF2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NARNG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NARNG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NSUP2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OASGP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODVAR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OPQUERY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDFIN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDMON.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATMATCH.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PERMCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PDRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PDRING-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SDVAR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUP2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TRIGCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TRIGCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ULS2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UP2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/AUTOMOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BGAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BGAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BRAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BRAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CARTEN2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CHARPOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMPLEX2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIFEXT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIFEXT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DLAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ELAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ELAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ES1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ES2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GRMOD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GRMOD-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HYPCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HYPCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MKCHSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MODRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MODULE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MODULE-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NASRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NASRING-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OAMON.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SORTPAK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ZMOD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALGEBRA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALGEBRA-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BTCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BTCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FMCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IDPOAM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IFAMON.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GRALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GRALG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OCAMON.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRQAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QUAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SKAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BSTREE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BTOURN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CARD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DRAWHACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DQAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FACTFUNC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FMTC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FR2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRAC2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRUTIL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ITAYLOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MLO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAALG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OAGROUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OAMONS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDCOMP2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PID.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RANDSRC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UNISEG2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/AMR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/AMR-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DEGRED.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DLP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ESTOOLS1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FAGROUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FAMONOID.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FIELD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FIELD-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLINEXP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLINEXP-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRETRCT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRETRCT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSERIES.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IDPAG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IDPOAMS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INFINITY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMLO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORTHPOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRODUCT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PADICCT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMPRED.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMASS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PTFUNC2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RADCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RADCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RATRET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RADUTIL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPXS2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XFALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ZLINDEP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/A1AGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/A1AGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ARR2CAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ARR2CAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP34.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BBTREE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BFUNCT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BPADIC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BTREE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CRAPACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DEQUEUE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DLIST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DRAWCX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01GBFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D02EJFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D03FAFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DRAWPT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FAMR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FAMR-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLASORT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLAGG2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FGROUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FM1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FPC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FPC-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FMONOID.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INDE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IPADIC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IROOT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IR2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LEXP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIECAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIECAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIST2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIST2MAP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LMOPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LZSTAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LZSTAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MAGMA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MESH.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MOEBIUS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MODFIELD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MODOP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MTHING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NCNTFRAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NCODIV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NUMTUBE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OFMONOID.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ONECOMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDCOMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OREPCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OREPCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OWP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PADIC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATTERN2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATLRES.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PARTPERM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PBWLB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PENDTREE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PGE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PGROEB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PINTERP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PLOTTOOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMDOWN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRTITION.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMINS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMLSAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMTOOLS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PSCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PSCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QFORM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QUEUE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SCACHE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEG2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEXOF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STTAYLOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TABLBUMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TABLEAU.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TOPSP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TRANFUN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TRANFUN-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TUBE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UDPO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UNISEG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VIEW.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VSPACE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VSPACE-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XPOLYC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XPR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/APPLYORE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ARRAY1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ARRAY12.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ARRAY2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASTACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BTAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BTAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMBINAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CSTTOOLS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01FCFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/E04MBFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FARRAY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GALUTIL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HEAP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IARRAY1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IARRAY2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IFARRAY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTHEORY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IRREDFFX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LFCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LODOCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LODOCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LWORD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MATCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MATCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MATSTOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORESUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OREPCTO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OREUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PLOT3D.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PREASSOC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRIMARR2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REDORDER.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SRAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SRAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STREAM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SYMPOLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TUPLE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPSCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPSCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VECTCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VECTCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XDPOLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XEXPPKG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XF-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XPBWPOLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XPOLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/XRPOLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BITS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIRPROD2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IMATRIX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IVECTOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LPOLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LSMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LSMP1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MATCAT2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PTCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STRICAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TRIMAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASSOCEQ.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CARTEN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CLIF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CLIP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COORDSYS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DBASE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DHMATRIX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIOSP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIRPCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIRPCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D02BBFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D02BHFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D02CJFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FAXF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FAXF-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFPOLY2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FNLA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GRAY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IRSN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MCALCFN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MHROWRED.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NUMODE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NUMQUAD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODESYS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODETOOLS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ORDFUNS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PERMAN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFECAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFECAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POINT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PSEUDLIN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PTPACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REP2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SETMN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SYMFUNC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VECTOR2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP10.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP24.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP4.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP50.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP6.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP73.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BALFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BEZOUT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BINARY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BINFILE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BOUNDZRO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BPADICRT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BRILL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CDEN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CHVAR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMMUPC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CONTFRAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CVMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CYCLOTOM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CYCLES.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DDFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DECIMAL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIOPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIOPS-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIRPROD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DISPLAY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DPMO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DPOLCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DPOLCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01AJFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01AKFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01ALFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01AMFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01APFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01AQFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EMR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EQ.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ERROR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EVALCYC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/E04DGFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/E04FDFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/E04GCFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/E04JAFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FACUTIL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFCG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFCGX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFHOM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFNB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFNBX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFPOLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFSLPE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FGLMICPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FILE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FINAALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FINAALG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FINRALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FINRALG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLOATRP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FNAME.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FOP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FORMULA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FORT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FTEM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GENEEZ.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GENMFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GENPGCD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GALFACTU.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GALPOLYU.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GBEUCLID.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GBF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GBINTERN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GHENSEL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GMODPOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GOSPER.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GRIMAGE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GROEBSOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HDMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HDP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HEXADEC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HEUGCD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IBPTOOLS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IFF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IBITS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ICARD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ICDEN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IDECOMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IIARRAY2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IMATLIN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IMATQF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INMODGCD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INNMFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INPSIGN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTHERTR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTRAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTRF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTSLPE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTTR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ISUMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LAUPOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LEADCDET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LGROBP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIMITRF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LINDEP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LPEFRAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LSPP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MATLIN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MCDEN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MDDFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MFINFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MFLOAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MINT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MLIFT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MMAP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MODMON.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONOTOOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MPCPF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MPC2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MPC3.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MPOLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MPRFF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MRATFAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MULTSQFR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NORMRETR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NPCOEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NSUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NTPOLFN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODEPRIM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODEPRRIC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMPKG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMSERVER.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PADEPAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PADICRAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PADICRC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PCOMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PDECOMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFBR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFBRU.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFOTOOLS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFRPAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PGCD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PINTERPA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PLEQN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMPLCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMQFCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PNTHEORY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLUTIL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLTOPOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLYCATQ.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLYLIFT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLYROOT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLY2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLY2UP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PSQFR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PUSHVAR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QALGSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QFCAT2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RADIX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RATFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RCFIELD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RCFIELD-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RDETR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RDETRS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REAL0.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REAL0Q.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REALSOLV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RESRING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RETSOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RFFACTOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RMATCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RMATCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RRCC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RRCC-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SCPKG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SHDP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SHP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SIGNRF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SMITH.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SMTS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SOLVEFOR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SPLTREE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STINPROD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STTFNC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUBRESP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUMRF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUPFRACF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TANEXP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TEMUTL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TEX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TEXTFILE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TREE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TWOFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UNIFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPCDEN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPDECOMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPDIVP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPOLYC2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPXSCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPSQFREE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VIEWDEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VIEW2D.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VOID.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/WEIER.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/WP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DIAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DSMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EXPUPXS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRAMALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRAMALG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MDAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODPOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PLOT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RMCAT2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ROIRC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SDPOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SMATCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SMATCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TUBETOOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPXSCCA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPXSCCA-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DPMM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EFUPXS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFINTBAS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRIDEAL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRIDEAL2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRMOD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IBATOOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/KDAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/KDAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MSETAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONOGEN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MONOGEN-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NFINTBAS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SPACE3.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CCLASS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSAGG2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GALFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IALGFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IBACHIN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NORMMA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODERED.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMSAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PERM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PERMGRP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRIMES.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PWFFINTB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RDIST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SAE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SAEFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SAERFFC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SGCF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TBAGG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TBAGG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VIEW3D.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALIST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EQTBL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GSTBL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HASHTBL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTABL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTFTBL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTPACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IPF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/KAFILE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATRES.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STBL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STRTBL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TABLE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TBCMPPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ACF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ACF-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ACPLOT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ANTISYM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ANY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP12.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP27.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP28.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP33.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP49.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP55.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP7.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP78.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP8.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP9.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ATTRBUT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BOP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/BOP1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMMONOP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMPCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMPCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DRAW.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DRAWCFUN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DROPT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DROPT0.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01ANFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01ASFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D03AGNT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/E04AGNT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FCPAK1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FEXPR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFCGP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFNBP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLOAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FPARFRAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRNAALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRNAALG-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FS-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FUNCTION.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GDMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HACKPI.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IDEAL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INFORM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INFORM1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IPRNTPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ISUPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/KERNEL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LMDICT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LODOOPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MATRIX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MKFLCFN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/M3D.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGC02.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGC05.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGC06.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGD03.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGE01.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGE02.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGE04.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGF07.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGSP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NREP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NUMFMT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OC-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODEPACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODERAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMERR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMERRK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OPTPACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OSI.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PATTERN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OVAR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMKERNEL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMSYM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/POLY.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PRIMELT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QALGSET2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QEQUAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RECLOS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REP1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RESULT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QUATCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QUATCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RFFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RMATRIX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ROMAN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ROUTINE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RPOLCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RPOLCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RULECOLD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SAOS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SEGBIND.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SPECOUT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SQMATRIX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SWITCH.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SYMS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SYMTAB.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SYSSOLP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UTSCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UTSCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/VARIABLE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/WFFINTBS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ACFS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ACFS-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/AF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALGFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALGFF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALGMANIP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALGMFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALGPKG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ALGSC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/AN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/APPRULE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP19.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP20.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP30.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP31.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP35.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP41.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP42.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP74.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP77.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP80.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CINTSLPE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMPFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMPLEX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMPLPAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CMPLXRT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CPMATCH.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CRFP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CTRIGMNP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01WGTS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D02AGNT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D03EEFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DBLRESP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DERHAM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DFSFUN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DRAWCURV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/E04NAFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/E04UCFA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EFSTRUC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ELFUTS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ESTOOLS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EXPEXPAN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EXPRODE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EXPRTUBE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EXPR2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FDIVCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FDIVCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FDIV2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FFCAT2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FLOATCP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FORDER.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FORTRAN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSRED.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSUPFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FRNAAF2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSPECF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FS2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FS2UPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GAUSSFAC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GCNAALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GENUFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GENUPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GTSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GPOLSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IAN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INEP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INFPROD0.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INFSP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INPRODFF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INPRODPF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTAF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTALG.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTG0.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTHERAL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTPAF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTPM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTTOOLS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ITRIGMNP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/JORDAN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/KOVACIC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LODOF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LSQM.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OMEXPR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MCMPLX.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/MULTFACT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGD01.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGD02.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGF01.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGF02.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NAGF04.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NCEP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NLINSOL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NSMP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NUMERIC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OCT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/OCTCT2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODEPAL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODERTRIC.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PADE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PAN2EXPR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PDEPACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PFOQ.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PICOERCE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMASSFS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMFS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PMPREDFS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/PSETPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QUAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QUATCT2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RADFF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RDEEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RDEEFS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RDIV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RSETCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RSETCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RULE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RULESET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SIMPAN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SFORT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SOLVESER.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUMFS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUTS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TOOLSIGN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TRIGMNIP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/TRMANIP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ULSCCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ULSCCAT-.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPXSSING.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UTSODE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UTSODETL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UTS2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/WUTSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DEFINTEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DFINTTLS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/DEFINTRF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01TRNS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EFULS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ESCONT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EXPR.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/EXPR2UPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FDIV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSCINT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSINT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FS2EXPXP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/GSERIES.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/HELLFDIV.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INVLAPLA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IR2F.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IRRF2F.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LAPLACE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LIMITPS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LODEEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NODE1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODECONST.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODEINT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REP.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SOLVERAD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SULS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUPXS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ULS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ULSCONS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPXS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UPXSCONS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/UTS.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ASP29.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/COMBF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/D01AGNT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/FSPRMELT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INBFF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LODO.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LODO1.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LODO2.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NTSCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/REGSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RGCHAIN.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RSETGCD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RSDCMPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SFRTCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SIGNEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SNTSCAT.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SOLVETRA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SRDCMPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SREGSET.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/STTF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SUBSPACE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ZDSOLVE.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/CPIMA.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/IRURPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LAZM3PK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/LEXTRIPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/NORMPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/QCMPACK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/RURPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SFRGCD.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/SFQCMPK.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/INTRVL.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/algebra/ODEEF.o usr/lib/axiom-0.20040517/algebra
+mnt/linux/bin/AXIOMsys usr/lib/axiom-0.20040517/bin
+mnt/linux/bin/axiom usr/lib/axiom-0.20040517/bin
+mnt/linux/bin/asq usr/lib/axiom-0.20040517/bin
+mnt/linux/bin/clef usr/lib/axiom-0.20040517/bin
+mnt/linux/lib/summary usr/lib/axiom-0.20040517/lib
+mnt/linux/autoload/postprop.lsp usr/lib/axiom-0.20040517/autoload
+debian/bin/axiom usr/bin
+debian/axiom.1 usr/share/man/man1
+=============================================================================
+=============================================================================
+axiom.links
+=============================================================================
+usr/share/doc/axiom/copyright usr/lib/axiom-0.20040517/lib/copyright
+usr/bin/axiom usr/bin/AXIOMsys
+usr/share/man/man1/axiom.1 usr/share/man/man1/AXIOMsys.1
+=============================================================================
+=============================================================================
+control
+=============================================================================
+Source: axiom
+Section: math
+Priority: optional
+Maintainer: Camm Maguire
+Build-Depends: debhelper (>> 4.0.0), gcl ( >= 2.6.1-39 ), libgmp3-dev, libncurses5-dev, libreadline4-dev, binutils-dev, xlibs-dev, xfree86-common, tetex-bin, gawk, sharutils
+Standards-Version: 3.6.1
+
+Package: axiom
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, axiom-databases (= ${Source-Version})
+Recommends: axiom-source, axiom-doc
+Suggests: texmacs, axiom-tex, axiom-test, nowebm
+Description: A general purpose computer algebra system: main binary and modules
+ Axiom is useful for
+ research and development of mathematical algorithms. It defines a
+ strongly typed, mathematically correct type hierarchy. It has a
+ programming language and a built-in compiler.
+ .
+ Axiom has been in development since 1973 and was sold as a
+ commercial product. It has been released as free software.
+ .
+ Efforts are underway to extend this software to (a) develop a
+ better user interface (b) make it useful as a teaching tool
+ (c) develop an algebra server protocol (d) integrate additional
+ mathematics (e) rebuild the algebra in a literate programming style
+ (f) integrate logic programming (g) develop an Axiom Journal with
+ refereed submissions.
+ .
+ This package contains the main program binary and all precompiled
+ algebra and autoloadable modules.
+
+Package: axiom-source
+Architecture: all
+Description: A general purpose computer algebra system: source files
+ Axiom is useful for
+ research and development of mathematical algorithms. It defines a
+ strongly typed, mathematically correct type hierarchy. It has a
+ programming language and a built-in compiler.
+ .
+ Axiom has been in development since 1973 and was sold as a
+ commercial product. It has been released as free software.
+ .
+ Efforts are underway to extend this software to (a) develop a
+ better user interface (b) make it useful as a teaching tool
+ (c) develop an algebra server protocol (d) integrate additional
+ mathematics (e) rebuild the algebra in a literate programming style
+ (f) integrate logic programming (g) develop an Axiom Journal with
+ refereed submissions.
+ .
+ This package contains source files in Axiom's native spad language
+ for the compiled algebra modules supplied in the axiom package.
+ .
+
+Package: axiom-test
+Architecture: all
+Depends: axiom (= ${Source-Version})
+Description: A general purpose computer algebra system: regression test inputs
+ Axiom is useful for
+ research and development of mathematical algorithms. It defines a
+ strongly typed, mathematically correct type hierarchy. It has a
+ programming language and a built-in compiler.
+ .
+ Axiom has been in development since 1973 and was sold as a
+ commercial product. It has been released as free software.
+ .
+ Efforts are underway to extend this software to (a) develop a
+ better user interface (b) make it useful as a teaching tool
+ (c) develop an algebra server protocol (d) integrate additional
+ mathematics (e) rebuild the algebra in a literate programming style
+ (f) integrate logic programming (g) develop an Axiom Journal with
+ refereed submissions.
+ .
+ This package contains input files for Axiom's regression test suite.
+
+Package: axiom-doc
+Architecture: all
+Description: A general purpose computer algebra system: documentation
+ Axiom is useful for
+ research and development of mathematical algorithms. It defines a
+ strongly typed, mathematically correct type hierarchy. It has a
+ programming language and a built-in compiler.
+ .
+ Axiom has been in development since 1973 and was sold as a
+ commercial product. It has been released as free software.
+ .
+ Efforts are underway to extend this software to (a) develop a
+ better user interface (b) make it useful as a teaching tool
+ (c) develop an algebra server protocol (d) integrate additional
+ mathematics (e) rebuild the algebra in a literate programming style
+ (f) integrate logic programming (g) develop an Axiom Journal with
+ refereed submissions.
+ .
+ This package contains all documentation, including the Axiom book in
+ dvi format with all postscript images.
+
+Package: axiom-databases
+Architecture: all
+Description: A general purpose computer algebra system: generated text databases
+ Axiom is useful for
+ research and development of mathematical algorithms. It defines a
+ strongly typed, mathematically correct type hierarchy. It has a
+ programming language and a built-in compiler.
+ .
+ Axiom has been in development since 1973 and was sold as a
+ commercial product. It has been released as free software.
+ .
+ Efforts are underway to extend this software to (a) develop a
+ better user interface (b) make it useful as a teaching tool
+ (c) develop an algebra server protocol (d) integrate additional
+ mathematics (e) rebuild the algebra in a literate programming style
+ (f) integrate logic programming (g) develop an Axiom Journal with
+ refereed submissions.
+ .
+ This package contains the text databases generated during the build
+ process used in computing the hierarchical domain structure, among
+ other uses.
+
+Package: axiom-tex
+Architecture: all
+Depends: tetex-extra
+Description: A general purpose computer algebra system: style file for TeX
+ Axiom is useful for
+ research and development of mathematical algorithms. It defines a
+ strongly typed, mathematically correct type hierarchy. It has a
+ programming language and a built-in compiler.
+ .
+ Axiom has been in development since 1973 and was sold as a
+ commercial product. It has been released as free software.
+ .
+ Efforts are underway to extend this software to (a) develop a
+ better user interface (b) make it useful as a teaching tool
+ (c) develop an algebra server protocol (d) integrate additional
+ mathematics (e) rebuild the algebra in a literate programming style
+ (f) integrate logic programming (g) develop an Axiom Journal with
+ refereed submissions.
+ .
+ This package contains a TeX style file useful in publishing results
+ obtained with Axiom.
+
+=============================================================================
+
+
+root writes:
+
+> Camm,
+>
+> Axiom "knows" where certain files reside so you may need symbolic
+> links to get it to run. I am working hard on putting together the
+> ISSAC proceedings on CD and can't look at the debian package now.
+> Next week I have to go give two invited lectures and will likely not
+> have connectivity (it's still the late 80s in most of the world it
+> seems). So I'm not going to be able to look critically at the changes
+> you've made to the axiom distribution until after next week.
+>
+> We should rewrite the Makefiles to build in your new "install"
+> scheme. Can you give me a simple outline of what you moved where?
+> I'll rewrite the Makefile install so it all works properly and
+> you don't have to change anything for debian. But it can't happen
+> in the next two weeks. If you can get the move list to me by
+> monday I can probably work on the changes offline in the hotel.
+
+\start
+Date: 21 May 2004 19:42:28 -0400
+From: Camm Maguire
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] requested change
+
+Greetings, and sorry for the delay.
+
+This (no longer?) appears to be an issue.
+
+Take care,
+
+root writes:
+
+> > > 2) Hardlinks notangle.1 nountangle.1 must be symlinks according to
+> > > Debian policy.
+> >
+> > ok. i'll change this.
+>
+> I looked at the lastest build.
+> Why do you think notangle.1 and nountangle.1 are hardlinks?
+> They don't appear to be in my build.
+
+\start
+Date: 21 May 2004 19:23:34 -0400
+From: Camm Maguire
+To: Bob McElrath
+Subject: Re: [Axiom-developer] Re: FeynCalc -> MAXIMA
+Cc: maxima@www.ma.utexas.edu, feyncalc@feyncalc.org, Bertfried.Fauser@uni-konstanz.de, siver@mx.ihep.su
+
+Greetings!
+
+Bob McElrath writes:
+
+> Camm Maguire [camm@enhanced.com] wrote:
+> > Greetings!
+> >
+> > Bob McElrath writes:
+> > > It also contains code for doing one-loop integrals. This same code
+> > > exists in several places (I know of a fortan library "ff" and a Maple
+> > > package "xloops" as well), and I can point to the papers if people
+> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+> >
+> > I think this would be helpful.
+>
+> Let me say that this *must* be implemented by an expert. The physics
+> community barely trusts such codes, and the ones that are barely trusted
+> (such as ff) have been massively cross checked across many calculations
+> and papers. That said:
+> http://dx.doi.org/10.1016/0550-3213(79)90605-9
+
+Is there an nline version of this one available to a general audience?
+
+Take care,
+
+
+> Here is a more modern reference with some new ideas, and the references
+> will be useful:
+> http://arxiv.org/abs/hep-ph/0307113
+> Bertfried Fauser (on CC list) works on these types of things and might
+> be an appropriate person to do it.
+>
+> These calculations are in general plauged by singularities, and the
+> procedure to remove them lies in physics, not math (renormalization).
+> The singularities are real, but we understand that they do not affect
+> physical observables. If it were possible to write general algorithmic
+> codes, we would do it.
+
+\start
+Date: Mon, 24 May 2004 19:47:57 -0400
+From: root
+To: axiom-developer@nongnu.org
+Subject: [Axiom-developer] axiom update
+Cc: alenka_zajka@mail.ru
+
+The latest changes have been pushed into the savannah CVS today.
+
+There are two major changes related to ongoing efforts.
+
+First, the pamphlet files are starting to show up as dvi
+files under the mnt/sys/doc subdirectory. These are in
+preparation for developing a viewer of some sort.
+
+Second, a new, nonfunctional )set command exists:
+
+ )set output openmath on
+
+which does nothing at the moment but is related to ongoing
+joint work with the ORRCA group at Univ. Western Ontario.
+The eventual plan is to enable I/O using OpenMath.
+
+One side-effect is that src/interp/setvars.boot and setvart.boot
+have better organization and documentation.
+
+\start
+Date: Tue, 25 May 2004 08:45:50 +0200
+From: David MENTRE
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] axiom update
+
+root writes:
+
+> The latest changes have been pushed into the savannah CVS today.
+
+Is this work also in your Arch repository?
+
+\start
+Date: Tue, 25 May 2004 07:13:03 -0400
+From: root
+To: david.mentre@wanadoo.fr
+Subject: Re: [Axiom-developer] axiom update
+
+re: arch repository. not yet. I'm trying to move the arch repository
+from tenkan.org to axiom-developer.org and it isn't working.
+
+there is no such thing as a simple job.
+
+back on sunday.
+
+\start
+Date: Tue, 25 May 2004 08:55:53 -0400
+From: root
+To: david.mentre@wanadoo.fr
+Subject: Re: [Axiom-developer] axiom update
+
+re: arch repository.
+
+If I set you up with a userid/passwd on axiom-developer.org
+would you be interested in setting up/maintaining the arch
+repository?
+
+besides setting it up we need to figure out how to make it
+writeable directly from the net so people can push changes
+back directly without going thru me. i'm too much of a
+bottleneck in the development.
+
+\start
+Date: Tue, 25 May 2004 14:20:08 +0200
+From: David MENTRE
+To: daly@idsi.net
+Subject: Re: [Axiom-developer] axiom update
+
+root