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 writes: + +> If I set you up with a userid/passwd on axiom-developer.org +> would you be interested in setting up/maintaining the arch +> repository? + +Yes, I can help, but not before the middle of June. + +> 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. + +I'm a bit reluctant to offer write access to anybody (including +myself). I think peer review of patches is of first importance for +software quality. I personnaly think that having a core team of +developers integrating patch from others is better. + +\start +Date: Tue, 25 May 2004 14:21:38 +0200 (CEST) +From: "m.rubey" +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] Patches (?) for sum/product and sqrt + +last weekend I tracked down two of the bugs I reported. However, the way to fix +one of them is not completely clear to me. (The other one I submitted as a +patch) Therefore, I'd like to discuss it here first... + +[bugs #9057] product over product or sum fail + +The problem is that + +(2) -> product(summation(i,i=1..j),j=1..1) + + >> Error detected within library code: + not a kernel + +protected-symbol-warn called with (NIL) + +or, even shorter, + +(2) -> eval(summation(i,i=1..%A),%A,1) + + >> Error detected within library code: + not a kernel + +protected-symbol-warn called with (NIL) + +in fact, anything but %A works in the line above. Obviously, this is a problem +of variable capture. Internally, summation(f(i),i=1..j) is represented as the +operator %defsum with arguments [f(%A),%A,i,1,j]. For some reason, the +author of the package introduces a dummy variable %A, which represents the +summation index. Since the same dammy variable is used for all sums and +products, there is a problem when we nest them or when the summation bound is +"bad". The offending line product(summation(i,i=1..j),j=1..1) is represented as + +%defprod with arguments [%defsum with arguments [%A,%A,i,1,%A],%A,j,1,1] + +and, when evaluating it, axiom substitutes 1 for %A in the inner list. Then it +tries to evaluate %defum with arguments [1,1,i,1,1] which leads to an error, +because AXIOM expects the second element of the list to be a symbol... + +A possible fix is to introduce a new dummy variable for each sum and +product. However, I did not *quite* manage to do so, since AXIOM does not seem +to care about which symbols are already around: + +(1) -> %A::SYMBOL + + (1) %A + Type: Symbol +(2) -> new()$SYMBOL + + (2) %A + Type: Symbol +(3) -> G1419::SYMBOL + + (3) G1419 + Type: Symbol +(4) -> symbol(GENSYM()$Lisp) + + (4) G1419 + Type: Symbol + +Anyway, in the submitted patchfile, I did this. + +In fact, I do not really understand why this dummy variable is needed... + +While reading the package COMBF I stumbled over annother bug. The following is +used as rule for differentiating sums: + + dvdsum(l, x) == + x = retract(y := third l)@SE => 0 + k := retract(d := second l)@K + differentiate(h := third rest rest l,x) * eval(f := first l, k, h) + - differentiate(g := third rest l, x) * eval(f, k, g) + + opdsum [differentiate(f, x), d, y, g, h] + +Although this -- d/dx sum_i^x f(i) = f(x) -- is a nice try, it is wrong. It +seems that the order of magnitude is roughly correct, but that's about it. + +\start +Date: Mon, 31 May 2004 16:02:26 -0400 +From: root +To: bill.page1@sympatico.ca +Subject: [Axiom-developer] learning in public + +Bill, + +I'm starting to use your wiki. It's an experiment in "learning in public" +about Clifford algebras. I have no idea how it will turn out but it is +at least an attempt to leverage the wiki for documentation purposes. +The new page is at: + +http://page.axiom-developer.org/zope/Plone/wiki/Clifford + +and is linked from the Axiom Wiki page. + +\start +Date: 31 May 2004 16:42:07 -0400 +From: Camm Maguire +To: daly@idsi.net +Subject: [Axiom-developer] Re: Debian Axiom package feedback + +Greetings! Just a reminder of the request for feedback on the Debian +axiom packages, trial versions of which are at + +http://people.debian.org/~camm + +No immediate rush, but I'd like to upload within a week or two so that +these can get into the next Debian release. + +\start +Date: Mon, 31 May 2004 20:35:02 -0400 +From: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] RE: learning in public +Cc: bill.page1@sympatico.ca, 'Bertfried Fauser' + +Hi Tim, + +I am just back from another trip, hence my silence in recent weeks. + +Thank you for pointing out your new Clifford algebra page on the +axiom-developer wiki. I have added a comment to the page with what +I think are some useful references, a small criticism concerning +Lie algebra versus Clifford algebra and a few other opinions. +I think your goal of a more advanced implementation of Clifford +algebra in Axiom is a very good one. And I hope other people will +also contribute when they have time. + +BTW, when I set up Plone at axiom-developer.org a few weeks ago, +I remember configuring the system to enable email subscriptions. +I.e. the system should allow people to subscribe to topics and +to pages that interest them and then automatically send email +updates when new material is added to the web site. I am sure +that this used to work when I first tested it but it does not +seem to be working now. Has something changed in the configuration +of the axiom-developer system? Specifically, is the sendmail +process still running and does it enable email to be forwarded? + +Cheers, +Bill Page. + + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Monday, May 31, 2004 4:02 PM +> To: bill.page1@sympatico.ca +> Cc: daly@idsi.net; axiom-developer@nongnu.org +> Subject: learning in public +> +> +> Bill, +> +> I'm starting to use your wiki. It's an experiment in "learning in +> public" about Clifford algebras. I have no idea how it will turn +> out but it is at least an attempt to leverage the wiki for +> documentation purposes. The new page is at: +> +> http://page.axiom-developer.org/zope/Plone/wiki/Clifford +> +> and is linked from the Axiom Wiki page. + +\start +Date: Mon, 31 May 2004 22:15:49 -0400 +From: root +To: Bill.Page@drdc-rddc.gc.ca +Subject: [Axiom-developer] Re: learning in public +Cc: fauser@spock.physik.uni-konstanz.de, bill.page1@sympatico.ca + +Bill, + +sendmail was turned off. I just fixed that. Let me know if that was +the problem. + +\start +Date: Mon, 31 May 2004 23:42:14 -0400 +From: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] RE: learning in public +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca + +Hi Tim, + +Email from the Axiom portal (and wiki) at +axiom-developer.org still does not seem to be working. +I have made several tests and even restarted the Zope +server program but so far I have not received any email +from the system. But I do not get any error message either. + +I am not sure what might be wrong. + +When you are logged in remoted to the +axiom-developer.org system can you send outgoing +email? I suppose I can also try this from here +via ssh. Perhaps it will show some kind of error. + +Later, +Bill Page. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Monday, May 31, 2004 10:16 PM +> To: Bill.Page@drdc-rddc.gc.ca +> Cc: daly@idsi.net; axiom-developer@nongnu.org; +> bill.page1@sympatico.ca; +> fauser@spock.physik.uni-konstanz.de +> Subject: Re: learning in public +> +> +> Bill, +> +> sendmail was turned off. I just fixed that. Let me know if that was +> the problem. + +\start +Date: Mon, 31 May 2004 23:44:55 -0400 +From: "Page, Bill" +To: "'daly@idsi.net'" +Subject: [Axiom-developer] RE: learning in public +Cc: bill.page1@sympatico.ca + +Tim, + +Oops, I did not look closely enough. When I try to +send an email message containg a link to some page +on the portal (using the little email icon at the +top right corner of the page), I get the following +error message: + + (111, 'Connection refused') + +Perhaps that indicates that sendmail is still not +configured the way that it was originally, about +4 weeks ago. + +Bill. + +> -----Original Message----- +> From: Page, Bill [mailto:Bill.Page@drdc-rddc.gc.ca] +> Sent: Monday, May 31, 2004 11:42 PM +> To: 'daly@idsi.net' +> Cc: axiom-developer@nongnu.org; bill.page1@sympatico.ca +> Subject: RE: learning in public +> +> +> Hi Tim, +> +> Email from the Axiom portal (and wiki) at +> axiom-developer.org still does not seem to be working. +> I have made several tests and even restarted the Zope +> server program but so far I have not received any email +> from the system. But I do not get any error message either. +> +> I am not sure what might be wrong. +> +> When you are logged in remoted to the +> axiom-developer.org system can you send outgoing +> email? I suppose I can also try this from here +> via ssh. Perhaps it will show some kind of error. +> + + + diff --git a/changelog b/changelog index 26d85f4..2d2ea58 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,5 @@ +20140422 tpd src/axiom-website/patches.html 20140422.04.tpd.patch +20140422 tpd book/2004-05.txt regularize 20140422 tpd src/axiom-website/patches.html 20140422.03.tpd.patch 20140422 tpd book/2004-04.txt regularize 20140422 tpd src/axiom-website/patches.html 20140422.02.tpd.patch diff --git a/src/axiom-website/patches.html b/src/axiom-website/patches.html index 998fdb2..f6633bb 100644 --- a/src/axiom-website/patches.html +++ b/src/axiom-website/patches.html @@ -4294,6 +4294,8 @@ book/2004-02.txt regularize book/2004-03.txt regularize 20140422.03.tpd.patch book/2004-04.txt regularize +20140422.04.tpd.patch +book/2004-05.txt regularize