\start
Date: Sat, 01 May 2004 09:09:24 +0200
From: David Mentre
To: Tim Daly
Subject: Machine clusters & Axiom (was: re: [Gcl-devel] gcl sockets)

Hello Tim,

Tim Daly 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: list
Subject: 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: Richard Fateman
Subject: franz socket interface
Cc: Camm Maguire, Helmut Eller

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: Tim Daly
Subject: Re: franz socket interface
Cc: Camm Maguire, Richard Fateman

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:
<http://www.franz.com/support/documentation/6.2/doc/socket.htm>

and OpenMCL's here:
<http://openmcl.clozure.com/Doc/sockets.html>

\start
Date: Mon, 3 May 2004 19:48:21 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: 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 = <filename>

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: <bibtex_database>.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 <final_filename>.pdf
	cp <final_filename>.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: Tim Daly
To: Bertfried Fauser
Subject: Re: 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: Bill Page
To: list
Subject: Collaborative mathematics on the Axiom Portal latex wiki
Cc: Bertfried Fauser

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: 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
Subject: Re: 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
Subject: Re: 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: 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: Re: [Gcl-devel] Re: Server sockets with GCL?
Cc: Tom Johnson, 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: Tom Johnson
To: Camm Maguire
Subject: Re: Server sockets with GCL?
Cc: Chris Hall, Tom Johnson, Jeff Dalton

This is a multipart message in MIME format.
--=_alternative 00750D6D86256E8C_=

>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. &nbsp;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). &nbsp;

However, in the particular situation I face at the moment, my &quot;server&quot; need
not be able to (and in fact, cannot currently) serve multiple concurrent 
clients. &nbsp;Thus, I would be using the server socket only with one client at<br>
a time. &nbsp;

My main need for now is a function to listen &quot;passively&quot; and produce 
the same sort of thing produced by SI::SOCKET. &nbsp;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: Tom Johnson
Subject: Re: [Gcl-devel] Re: Server sockets with GCL?
Cc: Chris Hall

Greetings!

Tom Johnson 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 <sys/socket.h>
+#include <sys/types.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#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: list
Subject: 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: Tom Johnson
To: Camm Maguire
Subject: Re: Server sockets with GCL?
Cc: Chris Hall

>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!!! &nbsp;I haven't yet tried it out, but now that I
see the patch, I understand the foreign function interface 
machanics a lot better. &nbsp;I was most confused by that tkconnect 
specific stuff.

\start
Date: Sun, 9 May 2004 13:58:24 -0700
From: Bob McElrath
To: list
Subject: building axiom

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: Tim Daly
To: David Mentre
Subject: Re: creating high quality pdf files
Cc: Bertfried Fauser

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: Tim Daly
To: Bill Page
Subject: 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: Tim Daly
Subject: Re: creating high quality pdf files
Cc: Bertfried Fauser

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: Wolfgang Zocher
To: Tim Daly
Subject: Re: creating high quality pdf files

Tim Daly 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: 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: Tim Daly
Subject: 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 Maguire
Subject: FeynCalc

Where do I find FeynCalc?

\start
Date: Wed, 12 May 2004 11:04:05 -0400
From: Tim Daly
To: Camm Maguire
Subject: 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: Tim Daly
Subject: 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 Maguire
Subject: 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: Andrei Sokolov
Subject: OpenMath
Cc: Elena Smirnova

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: 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: Xin Li
Subject: 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: 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: 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 Maguire
Subject: 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: Cliff Yapp
Subject: Re: FeynCalc
Cc: Camm Maguire

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: Cliff Yapp
To: Tim Daly, Camm Maguire
Subject: 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
Subject: 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: Cliff Yapp
Subject: re: FeynCalc
Cc: Camm Maguire

Cliff Yapp 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 Maguire
Subject: 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: Cliff Yapp
To: Bob McElrath
Subject: re: FeynCalc
Cc: Camm Maguire

--- Bob McElrath wrote:
> C Y [Cliff Yapp] 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
From: David Mentre
To: Bill Page
Subject: 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: FeynCalc
Cc: Camm Maguire

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: OpenMath
Cc: Elena Smirnova, Andrei Sokolov

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: Tim Daly
To: Mike Dewar
Subject: Re: OpenMath
Cc: Andrei Sokolov, Mike Dewar, Elena Smirnova

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: Tim Daly
Subject: Re: OpenMath
Cc: Mike Dewar, Andrei Sokolov, Elena Smirnova

Hello Tim,

Tim Daly 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: Tim Daly
To: David Mentre
Subject: Re: OpenMath
Cc: Andrei Sokolov, Elena Smirnova, Mike Dewar

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: Tim Daly
Subject: Re: OpenMath
Cc: Mike Dewar, Andrei Sokolov, Elena Smirnova

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: Tim Daly
Subject: Re: OpenMath
Cc: Mike Dewar, Andrei Sokolov, Elena Smirnova

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: Tim Daly
Subject: TeXmacs & notbook (was: Re: OpenMath)

Hello Tim,

Tim Daly 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: Tim Daly
To: David Mentre
Subject: Re: OpenMath
Cc: Andrei Sokolov, Elena Smirnova, Mike Dewar

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
Subject: Re: OpenMath
Cc: Mike Dewar, Andrei Sokolov, Elena Smirnova

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: Tim Daly
To: Bertfried Fauser
Subject: Re: OpenMath
Cc: Andrei Sokolov, Mike Dewar, Elena Smirnova

> > 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: Tim Daly
To: David Mentre
Subject: Re: TeXmacs & notbook (was: Re: 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: Tim Daly
Subject: Re: OpenMath
Cc: Elena Smirnova, Andrei Sokolov

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: Tim Daly
To: Bertfried Fauser
Subject: Re: OpenMath
Cc: Mike Dewar, Andrei Sokolov, Elena Smirnova

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
Subject: Re: OpenMath
Cc: Mike Dewar, Andrei Sokolov, Elena Smirnova

--VywGB/WGlW4DM4P8

Bertfried Fauser 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: Cliff Yapp
To: Tim Daly, Mike Dewar
Subject: Re: OpenMath
Cc: Andrei Sokolov, Elena Smirnova, Mike Dewar

--- Tim Daly 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: Tim Daly
To: Cliff Yapp
Subject: Re: 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: Cliff Yapp
To: Tim Daly
Subject: Re: OpenMath

--- Tim Daly 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: Cliff Yapp
Subject: Re: 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: Tim Daly
To: Bertfried Fauser
Subject: Re: OpenMath
Cc: Bill Page

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: Tim Daly
To: Bill Page
Subject: wiki

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: Wolfgang Zocher
To: list
Subject: Re: OpenMath

Cliff Yapp 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: Wolfgang Zocher
To: list
Subject: 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: 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: Tim Daly
To: Wolfgang Zocher
Subject: 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: Tim Daly
To: Bertfried Fauser
Subject: Re: OpenMath
Cc: Bill Page

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: Cliff Yapp
To: Bertfried Fauser
Subject: Re: OpenMath
Cc: Bill Page

--- Tim Daly 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: Tim Daly
To: Mike Dewar
Subject: Re: 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: Martin Rubey
To: list
Subject: 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: list
Subject: 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: [Gcl-devel] gcl sockets)

Greetings!

David Mentre writes:

> Hello Tim,
> 
> Tim Daly 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: Re: FeynCalc -> MAXIMA

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: Tim Daly
To: Camm Maguire
Subject: re: FeynCalc -> MAXIMA
Cc: Siver Andrey

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: Tim Daly
To: David Escott
Subject: Re: 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: Cliff Yapp
To: Camm Maguire
Subject: Re: OpenMath
Cc: Bill Page, Bertfried Fauser

--- 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: Cliff Yapp
Subject: Re: OpenMath
Cc: Bill Page, Bertfried Fauser

Greetings!

Cliff Yapp writes:

> --- Tim Daly 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: Tim Daly
Subject: re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Siver Andrey

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: Tim Daly
To: Camm Maguire
Subject: Re: OpenMath
Cc: Bertfried Fauser, Bill Page

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: Tim Daly
To: Bertfried Fauser
Subject: re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Siver Andrey

> 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
Subject: re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Siver Andrey

Bertfried Fauser 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
Subject: Re: [Maxima] re: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Camm Maguire, Siver Andrey

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 nave 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 McElrath
Subject: linear time algorithm
Cc: Bertfried Fauser, Camm Maguire, Richard Fateman, Siver Andrey

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: William Kocay
Subject: 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 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: FeynCalc -> MAXIMA
Cc: Camm Maguire, Siver Andrey

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 project status

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: Re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Stavros Macrakis, Siver Andrey

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: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Camm Maguire, Siver Andrey

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 McElrath
Subject: fyi... Planarity algorithm
Cc: Bertfried Fauser, Camm Maguire, Richard Fateman, Siver Andrey

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
Subject: re: FeynCalc -> MAXIMA

Bertfried Fauser 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: FeynCalc -> MAXIMA
Cc: Camm Maguire, Siver Andrey

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 <grin>, 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: Bertfried Fauser
Subject: RE: [Maxima] re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Siver Andrey

> 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: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Camm Maguire, Siver Andrey

Stavros Macrakis [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.

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: Cliff Yapp
To: Tim Daly, Camm Maguire
Subject: Re: OpenMath
Cc: Bertfried Fauser, Bill Page

--- Tim Daly 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: Cliff Yapp
To: Tim Daly, Stavros Macrakis
Subject: Re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Bertfried Fauser, Siver Andrey

--- 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: Cliff Yapp
To: Bob McElrath, Bertfried Fauser
Subject:  Re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Siver Andrey

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: Cliff Yapp
To: Bob McElrath, Stavros Macrakis
Subject: FeynCalc -> MAXIMA
Cc: Camm Maguire, Bertfried Fauser, Siver Andrey

--- Bob McElrath wrote:
> Stavros Macrakis [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.
> 
> 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: Cliff Yapp
To: Tim Daly
Subject: Re: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Camm Maguire, Stavros Macrakis, Siver Andrey

--- Tim Daly 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: Tim Daly
To: Bob McElrath
Subject: Re: [Maxima] re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Stavros Macrakis, Bertfried Fauser, Siver Andrey

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: Tim Daly
To: Cliff Yapp
Subject: Re: OpenMath
Cc: Camm Maguire, Bill Page, Bertfried Fauser

> 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: Tim Daly
To: Cliff Yapp
Subject: Re: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Camm Maguire, Stavros Macrakis, Siver Andrey

> 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: Tim Daly
To: Cliff Yapp
Subject: Re: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Camm Maguire, Stavros Macrakis, Siver Andrey

> > 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: Tim Daly
Subject: Re: 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 <lawrencc@debian.org>
#   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 <lawrencc@debian.org>'
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] <package | filename>', 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)
=============================================================================

Tim Daly writes:

\start
Date: Thu, 20 May 2004 00:08:12 -0400
From: Tim Daly
To: Bertfried Fauser
Subject: 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
Subject: On formal correctness and readability (was: Re: [Maxima] re: FeynCalc -> MAXIMA)
Cc: Camm Maguire, Stavros Macrakis, Siver Andrey

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 <grin>,
> 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: William Kocay
Subject: Axiom mailing list

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: Vladimir Bondarenko
Subject: 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: 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
Subject: 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: Frederic Lehobey
Subject: 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.

Frederic 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
> <http://www.linux-france.org/~dmentre/arch-ive/>.  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: list
Subject: Debian Axiom package
Cc: Frederic Lehobey, Tim Daly

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.

Frederic 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
> <http://www.linux-france.org/~dmentre/arch-ive/>.  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: Tim Daly
To: Camm Maguire
Subject: re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
Cc: Frederic Lehobey

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: Vladimir Bondarenko
Subject: 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: Martin Rubey
To: Petri Salmela
Subject: 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.

\start
Date: Fri, 21 May 2004 16:21:40 -0700
From: Richard Fateman
To: Bob McElrath
Subject: Re: [Maxima] re: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Camm Maguire, Siver Andrey

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: Tim Daly
Subject: Re: [Maxima] re: FeynCalc -> MAXIMA
Cc: Stavros Macrakis, Siver Andrey, Bertfried Fauser

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,

Tim Daly 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: Tim Daly
Subject: Re: FeynCalc -> MAXIMA
Cc: Stavros Macrakis, Bertfried Fauser, Siver Andrey

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: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Siver Andrey

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: Cliff Yapp
To: Richard Fateman, Bob McElrath
Subject: Re: FeynCalc -> MAXIMA
Cc: Camm Maguire, Bertfried Fauser, Siver Andrey

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: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Siver Andrey

Greetings!

Bob McElrath writes:

> Bertfried Fauser 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: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Siver Andrey

Camm Maguire 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: Tim Daly
Subject: Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
Cc: Frederic Lehobey

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.

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


Tim Daly 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: Tim Daly
Subject: Re: requested change

Greetings, and sorry for the delay.

This (no longer?) appears to be an issue.

Take care,

Tim Daly 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: FeynCalc -> MAXIMA
Cc: Bertfried Fauser, Siver Andrey

Greetings!

Bob McElrath writes:

> Camm Maguire 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: Tim Daly
To: list
Subject: axiom update
Cc: Andrei Sokolov

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: Tim Daly
Subject: Re: axiom update

Tim Daly 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: Tim Daly
To: David Mentre
Subject: Re: 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: Tim Daly
To: David Mentre
Subject: Re: 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: Tim Daly
Subject: Re: axiom update

Tim Daly 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: Martin Rubey
To: list
Subject: 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: Tim Daly
To: Bill Page
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: 31 May 2004 16:42:07 -0400
From: Camm Maguire
To: Tim Daly
Subject: 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: Bill Page
To: Tim Daly
Subject: RE: learning in public
Cc: Bill Page, 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.


> 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: Tim Daly
To: Bill Page
Subject: Re: learning in public
Cc: Bertfried Fauser

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: Bill Page
To: Tim Daly
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.

Later,
Bill Page.

> 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: Bill Page
To: Tim Daly
Subject: RE: learning in public

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-----
> 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.
> 



