\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Thu, 1 Apr 2004 11:37:09 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: tenkan server

Hi Tim,

	yesterday I spoke long with a person with potential interest in
AXIOM. I advised him to download the book, but if one goes to tenkan,
there is not the slightest hint that there is an AXIOM, even the link to
the newer source [20040321 sources] is broken. Would it be possible to set
a link there on the pdf-file of the book? (ps, dvi, what soever)

\start
Date: Thu, 1 Apr 2004 12:15:01 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: Clifford algebras in AXIOM

Dear Tim,

	I have had a look at the clifford package in AXIOM by now. Indeed,
it looks to me, as if this package was only included for the sake of
showing how to program, and not for really doing research in clifford
algebra. In effect, only product, sum, ...  are defined nothing special.
Furthermore is the restriction to a quadratic form not quite necessary.
	I made good progress with some math to remedy this, but I have
problems to start to write a category and/or a domain (I tried it for an
afternoon or so, but nothing compiled, ....). As you announced to provide
a template with explanations, I would benefit very much from this.  At the
moment I do experiment with the Hopf algebra of symmetric functions, but
if that works, its easy to implement a super Hopf algebra of super
symmetric functions which includes symmetric and grassmann as weyl and
clifford algebras. My main problem is to define data structures in an most
general way, but such that it makes still sense mathematically (and is
not totally inefficient either, computations will be _tremendously_
involved).

I would need somethinng like:

Super [L]
	* L is an "alphabet of letters, which may be signed letters,
          there are positive, neutral, and negative letters, and later on
          their 'duals'
        * Letters may form words by concatenation  "letter monomials"
        * words may be added to form general elements
          sentences or "polynomials"
	* Note that this is the tensor algebra over [L] factoered by
          the symmetry constrained induced by teh letters

Tens Super [L]
	* Now we itterate! Consider _any_ monomial in Super [L] as a
          generator of Supper [L], denote it somehow eg (w)
	* Create (as for super) the tensor algebra over the (w)'s
	* Introduce some fancy maps and scalar products, build a factor
          wrt to those, then one gets
Pleth Super [L] and its graded dual Brace Super [L]
	* Pleth Super [L] has as special cases the symmetric functions,
          the Grassmann algebra, Weyl and Clifford algebras, but also
          Heisenberg algebras etc, exactly my beloved pets.

__Pleth Super [L] __ is a Hopf algebra!

Example: let L={a} be the alphabet in one neutral letter (ordinary
variable), then Super [L] becomes the polynomial algebra Z[a] respectivley
the algebra of formal power series Z[[A]] (all tensor products are taken
over the intergers Z). A monoidal basis of Super [L] in this case is given
by the powers of a, {1,a,a^2,a^3,a^4,...}, note that AXIOM has to type
these as "monom Letter neutral" (one should be able to distinguish between
monoms and polynoms for sake of algorithmical simplicity), then Tens Super[L]
is giben by the structure V = {1,a^2,a^3,a^4,...} and V^2, V^3 etc are
formed as linear combinations of products of these terms, eg
	W \in Tens Super [L] with
	W = (w1)(w2)...(wn)
        (wi) = (a^r)^{s}(a^p)^(q)

hence something like:

x0 (1)+ x1 (1)^(4) + x2 (a)^(1)(a^2)^(3) + ....

there are still more complicated data structures to come, namely a letter
place algebra, where elements are formed from pairs of monomials of the
Tens Super [L] and Tens Super [P].

Of course one can discard letter place techniques, and call everything a
"module", The above described mechanism is in a certain sense basis free,
in the module language this become apparent.

Now, I searched for some time to see how AXIOM handles polynomials, and
variouse series, but wasn't really happy about the code, I simply don't
undertsand whats going on there. I suspect, that much of the code could be
reused for my problem, but the grading and letter type has to be added
carefully. I do by now know the algorithms how to compute for many
coercions etc, and would like to start with some baby category to see if I
am right.
	An (simple) example how to define a category/domain and how to
define types (data structures) (and pretyprint output, otherwise these
data cannot be recognized by a human, I am thinking for a better notation
though, hopefully streamlined for applications in physice) would be of
extraordinary help.

\start
Date: Thu, 1 Apr 2004 07:22:10 -0500
From: Tim Daly
To: Bertfried Fauser
Subject: Re: tenkan server

>	yesterday I spoke long with a person with potential interest in
>AXIOM. I advised him to download the book, but if one goes to tenkan,
>there is not the slightest hint that there is an AXIOM, even the link to
>the newer source [20040321 sources] is broken. Would it be possible to set
>a link there on the pdf-file of the book? (ps, dvi, what soever)

The reason the link disappeared is that I'm under pressure from my
hosting site to reduce the disk usage so I nuked the images. I also merged
the book into the axiom--release--1 image and am working on a test build
now. If all goes well I'll be putting the book in its current form into
the savannah site image shortly. There is still work to do on it but it
is no longer in the "development" stage and is useful as is, mistakes
and all.

\start
Date: Thu, 1 Apr 2004 07:33:30 -0500
From: Tim Daly
To: Bertfried Fauser
Subject: Re: Clifford algebras in AXIOM

Bertfried,

I'm on vacation next week and aside from a weekend trip to visit my
mom I'll have some free time to think about this. I'll look at
providing some documentation about how to write a new domain in Axiom.

I'm also trying to come up to speed on your physics work. I have a 
textbook by Kaku (Kaku, Michio, "Quantum Field Theory" Oxford Univ. Press
(1993)). Chapter 2 deals with symmetries, SU(3) and SO(2), etc. My
efforts to understand that have led me off to more general Lie groups
(Lipkin, Harry, "Lie Groups for Pedestrians" Dover (1966)). Am I on 
the right track? If not, can you send me a reference or two?

Tim

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

>	I have had a look at the clifford package in AXIOM by now. Indeed,
>it looks to me, as if this package was only included for the sake of
>showing how to program, and not for really doing research in clifford
>algebra. In effect, only product, sum, ...  are defined nothing special.
>Furthermore is the restriction to a quadratic form not quite necessary.
>	I made good progress with some math to remedy this, but I have
>problems to start to write a category and/or a domain (I tried it for an
>afternoon or so, but nothing compiled, ....). As you announced to provide
>a template with explanations, I would benefit very much from this.  At the
>moment I do experiment with the Hopf algebra of symmetric functions, but
>if that works, its easy to implement a super Hopf algebra of super
>symmetric functions which includes symmetric and grassmann as weyl and
>clifford algebras. My main problem is to define data structures in an most
>general way, but such that it makes still sense mathematically (and is
>not totally inefficient either, computations will be _tremendously_
>involved).
>
>I would need somethinng like:
>
>Super [L]
>	* L is an "alphabet of letters, which may be signed letters,
>          there are positive, neutral, and negative letters, and later on
>          their 'duals'
>        * Letters may form words by concatenation  "letter monomials"
>        * words may be added to form general elements
>          sentences or "polynomials"
>	* Note that this is the tensor algebra over [L] factoered by
>          the symmetry constrained induced by teh letters
>
>Tens Super [L]
>	* Now we itterate! Consider _any_ monomial in Super [L] as a
>          generator of Supper [L], denote it somehow eg (w)
>	* Create (as for super) the tensor algebra over the (w)'s
>	* Introduce some fancy maps and scalar products, build a factor
>          wrt to those, then one gets
>Pleth Super [L] and its graded dual Brace Super [L]
>	* Pleth Super [L] has as special cases the symmetric functions,
>          the Grassmann algebra, Weyl and Clifford algebras, but also
>          Heisenberg algebras etc, exactly my beloved pets.
>
>__Pleth Super [L] __ is a Hopf algebra!
>
>Example: let L={a} be the alphabet in one neutral letter (ordinary
>variable), then Super [L] becomes the polynomial algebra Z[a] respectivley
>the algebra of formal power series Z[[A]] (all tensor products are taken
>over the intergers Z). A monoidal basis of Super [L] in this case is given
>by the powers of a, {1,a,a^2,a^3,a^4,...}, note that AXIOM has to type
>these as "monom Letter neutral" (one should be able to distinguish between
>monoms and polynoms for sake of algorithmical simplicity), then Tens Super[L]
>is giben by the structure V = {1,a^2,a^3,a^4,...} and V^2, V^3 etc are
>formed as linear combinations of products of these terms, eg
>	W \in Tens Super [L] with
>	W = (w1)(w2)...(wn)
>        (wi) = (a^r)^{s}(a^p)^(q)
>
>hence something like:
>
>x0 (1)+ x1 (1)^(4) + x2 (a)^(1)(a^2)^(3) + ....
>
>there are still more complicated data structures to come, namely a letter
>place algebra, where elements are formed from pairs of monomials of the
>Tens Super [L] and Tens Super [P].
>
>Of course one can discard letter place techniques, and call everything a
>"module", The above described mechanism is in a certain sense basis free,
>in the module language this become apparent.
>
>Now, I searched for some time to see how AXIOM handles polynomials, and
>variouse series, but wasn't really happy about the code, I simply don't
>undertsand whats going on there. I suspect, that much of the code could be
>reused for my problem, but the grading and letter type has to be added
>carefully. I do by now know the algorithms how to compute for many
>coercions etc, and would like to start with some baby category to see if I
>am right.
>	An (simple) example how to define a category/domain and how to
>define types (data structures) (and pretyprint output, otherwise these
>data cannot be recognized by a human, I am thinking for a better notation
>though, hopefully streamlined for applications in physice) would be of
>extraordinary help.

\start
Date: 01 Apr 2004 16:43:26 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Clifford algebras in AXIOM
Cc: Bertfried Fauser

Greetings!  For what its worth, I have some background in this area.
My Ph.D. is in theoretical physics, specifically the quantum theory of
solids.  I'm also currently involved in a project making some
significant use of group theory.  Unfortunately, I don't know anything
about axiom (yet) above the lisp level!

Take care,

Tim Daly writes:

> Bertfried,
> 
> I'm on vacation next week and aside from a weekend trip to visit my
> mom I'll have some free time to think about this. I'll look at
> providing some documentation about how to write a new domain in Axiom.
> 
> I'm also trying to come up to speed on your physics work. I have a 
> textbook by Kaku (Kaku, Michio, "Quantum Field Theory" Oxford Univ. Press
> (1993)). Chapter 2 deals with symmetries, SU(3) and SO(2), etc. My
> efforts to understand that have led me off to more general Lie groups
> (Lipkin, Harry, "Lie Groups for Pedestrians" Dover (1966)). Am I on 
> the right track? If not, can you send me a reference or two?
> 
> Tim
> 
> ========================================================================
> 
> >	I have had a look at the clifford package in AXIOM by now. Indeed,
> >it looks to me, as if this package was only included for the sake of
> >showing how to program, and not for really doing research in clifford
> >algebra. In effect, only product, sum, ...  are defined nothing special.
> >Furthermore is the restriction to a quadratic form not quite necessary.
> >	I made good progress with some math to remedy this, but I have
> >problems to start to write a category and/or a domain (I tried it for an
> >afternoon or so, but nothing compiled, ....). As you announced to provide
> >a template with explanations, I would benefit very much from this.  At the
> >moment I do experiment with the Hopf algebra of symmetric functions, but
> >if that works, its easy to implement a super Hopf algebra of super
> >symmetric functions which includes symmetric and grassmann as weyl and
> >clifford algebras. My main problem is to define data structures in an most
> >general way, but such that it makes still sense mathematically (and is
> >not totally inefficient either, computations will be _tremendously_
> >involved).
> >
> >I would need somethinng like:
> >
> >Super [L]
> >	* L is an "alphabet of letters, which may be signed letters,
> >          there are positive, neutral, and negative letters, and later on
> >          their 'duals'
> >        * Letters may form words by concatenation  "letter monomials"
> >        * words may be added to form general elements
> >          sentences or "polynomials"
> >	* Note that this is the tensor algebra over [L] factoered by
> >          the symmetry constrained induced by teh letters
> >
> >Tens Super [L]
> >	* Now we itterate! Consider _any_ monomial in Super [L] as a
> >          generator of Supper [L], denote it somehow eg (w)
> >	* Create (as for super) the tensor algebra over the (w)'s
> >	* Introduce some fancy maps and scalar products, build a factor
> >          wrt to those, then one gets
> >Pleth Super [L] and its graded dual Brace Super [L]
> >	* Pleth Super [L] has as special cases the symmetric functions,
> >          the Grassmann algebra, Weyl and Clifford algebras, but also
> >          Heisenberg algebras etc, exactly my beloved pets.
> >
> >__Pleth Super [L] __ is a Hopf algebra!
> >
> >Example: let L={a} be the alphabet in one neutral letter (ordinary
> >variable), then Super [L] becomes the polynomial algebra Z[a] respectivley
> >the algebra of formal power series Z[[A]] (all tensor products are taken
> >over the intergers Z). A monoidal basis of Super [L] in this case is given
> >by the powers of a, {1,a,a^2,a^3,a^4,...}, note that AXIOM has to type
> >these as "monom Letter neutral" (one should be able to distinguish between
> >monoms and polynoms for sake of algorithmical simplicity), then Tens Super[L]
> >is giben by the structure V = {1,a^2,a^3,a^4,...} and V^2, V^3 etc are
> >formed as linear combinations of products of these terms, eg
> >	W \in Tens Super [L] with
> >	W = (w1)(w2)...(wn)
> >        (wi) = (a^r)^{s}(a^p)^(q)
> >
> >hence something like:
> >
> >x0 (1)+ x1 (1)^(4) + x2 (a)^(1)(a^2)^(3) + ....
> >
> >there are still more complicated data structures to come, namely a letter
> >place algebra, where elements are formed from pairs of monomials of the
> >Tens Super [L] and Tens Super [P].
> >
> >Of course one can discard letter place techniques, and call everything a
> >"module", The above described mechanism is in a certain sense basis free,
> >in the module language this become apparent.
> >
> >Now, I searched for some time to see how AXIOM handles polynomials, and
> >variouse series, but wasn't really happy about the code, I simply don't
> >undertsand whats going on there. I suspect, that much of the code could be
> >reused for my problem, but the grading and letter type has to be added
> >carefully. I do by now know the algorithms how to compute for many
> >coercions etc, and would like to start with some baby category to see if I
> >am right.
> >	An (simple) example how to define a category/domain and how to
> >define types (data structures) (and pretyprint output, otherwise these
> >data cannot be recognized by a human, I am thinking for a better notation
> >though, hopefully streamlined for applications in physice) would be of
> >extraordinary help.

\start
Date: Thu, 1 Apr 2004 18:06:49 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: Clifford algebras in AXIOM
Cc: Bertfried Fauser

Camm,

re: quantum theory and groups. Bertfried is working on Clifford and
Hopf algebras. One of the concerns seems to be the choice of an
efficient data structure. Since I (as yet) know nothing about the
subject I can't give good advice. However, I'm looking around at
some books to help me learn.

Axiom has some group theory (LyndonWords, LieAlgebra, Clifford Algebra, 
etc) already. They are not in the paper version of the book but are
in the electronic version.

I'm hoping to extend Axiom with domains which are useful in physics.
>From my reading it appears that SU(3), SO(2), etc are of interest.

\start
Date: Thu, 1 Apr 2004 18:05:01 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Compiling error

Has anyone else seen this error?

Finished compiling
/home/user/axiomtoplevel/axiom/lsp/gcl-2.6.2/cmpnew/collectfn.
Loading /home/user/axiomtoplevel/axiom/lsp/gcl-2.6.2/cmpnew/collectfn.o
start address -T 0x8488f40 Finished loading
/home/user/axiomtoplevel/axiom/lsp/gcl-2.6.2/cmpnew/collectfn.o
Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/proclaims.lisp
Finished loading
/home/user/axiomtoplevel/axiom/obj/linux/interp/proclaims.lisp
Compiling /home/user/axiomtoplevel/axiom/obj/linux/interp/postpar.lsp.
; (DEFUN |postError| ...) is being compiled.
;; The variable |$defOp| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |postCategory| ...) is being compiled.
;; The variable |$insidePostCategoryIfTrue| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |postDef| ...) is being compiled.
;; The variable |$maxSignatureLineNumber| is undefined.
;; The compiler will assume this variable is a global.
;; The variable |$docList| is undefined.
;; The compiler will assume this variable is a global.
;; The variable |$headerDocumentation| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |postIf| ...) is being compiled.
;; Warning: The variable |x| is not used.
End of Pass 1.  
End of Pass 2.  

Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by COND.
Broken at APPLY.  Type :H for Help.
COMPILER>>make[3]: ***
[/home/user/axiomtoplevel/axiom/obj/linux/bin/depsys] Error 255
make[3]: Leaving directory `/home/user/axiomtoplevel/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/home/user/axiomtoplevel/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/user/axiomtoplevel/axiom'
make: *** [all] Error 2

\start
Date: Thu, 1 Apr 2004 22:01:04 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Compiling error

CY,

Try typing 'make' again. It appears there is a random error that
occurs under some as-yet-unknown conditions that causes the build
to fail. It appears to be related to a GCL error. If this failure
is caused by the random error then the 'make' command should
recover properly and continue the build.

\start
Date: Thu, 1 Apr 2004 23:19:35 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Compiling error

CY,

Are you running Fedora?

\start
Date: Thu, 1 Apr 2004 23:48:29 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Compiling error

CY,

It appears that you can compile the file (pass 1 and pass 2 complete)
but the failure has something to do with writing the binary.

\start
Date: Fri, 2 Apr 2004 01:03:58 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Compiling error

CY,

My system builds cleanly. (Which is like saying: The light in my room
is working so it should be working in your room :-) ).

\start
Date: Fri, 2 Apr 2004 16:21:35 +1000
From: Mike Thomas
To: Bertfried Fauser
Subject: RE: Clifford algebras in AXIOM

Hi Bertfried.

Your post caught my eye because I'm interested in the so called Geometric
Algebra (GA) as promoted by David Hestenes eg:

  http://modelingnts.la.asu.edu/

At one stage I considered implementing a GA library in Haskell, a non-strict
functional programming language.  My idea was that you would implement a
general GA data type as a recursive lazy datastructure which would unfold
during computations only to the extent needed, hopefully saving work -
something I quite like to do!

Given that:

  1. you were asking about data structures,

  2. you seem to be constructing strings from symbols and constructing
algebra on top of algebra, on top of algebra..., and

  3. GA seems to be a small subset of your algebraic structures,

I thought the same approach might be workable for you.

I have never used Axiom, but, a quick look through the PDF Axiom book
recently put on line shows that lazy lists are supported in Axiom, for
example, via the "generate()" function on page 62:

  "Another method of creating streams is to use the generate(f,a) function.
This applies its first argument repeatedly onto its second to produce the
stream [a, f(a), f(f(a)), f(f(f(a))) . . .]. Given that the function
nextPrime returns the lowest prime number greater than its argument we can
generate a stream of primes as follows:
  generate(nextPrime,2)$Stream Integer
    [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, . . .]
   Type: Stream Integer"

Whether laziness will help you in the long run I don't know, but it might be
worthwhile finding out.  It might also be worthwhile contacting Hestenes
himself who is, I believe, looking into higher level computational methods
for GA.

\start
Date: Fri, 2 Apr 2004 14:04:20 +0200 (CEST)
From: Bertfried Fauser
To: Mike Thomas
Subject: RE: Clifford algebras in AXIOM

On Fri, 2 Apr 2004, Mike Thomas wrote:

Dear Mike,

perhaps this topic should move to teh AXIOM math mailing list? But I
provide an short answer, to others I beg your pardon.

> Your post caught my eye because I'm interested in the so called Geometric
> Algebra (GA) as promoted by David Hestenes eg:
>
>   http://modelingnts.la.asu.edu/
I know this flavour of Clifford algebra very well. Unfortunately it does
only serve en engineer, not a scientist. Clifford algebras were (almost)
classified by Clifford himself, virtually _anything_ is know and from a
mathematical point of view this field is dead. However, quaternions etc,
are used in computer graphics, image perception, robotics, etc.

What bothers me is the structure of quantum field theory, but under an
categorial angle. There one needs quite elaborated algebraic structures,
among them those which I described in my mail.

> At one stage I considered implementing a GA library in Haskell, a non-strict
> functional programming language.  My idea was that you would implement a
> general GA data type as a recursive lazy datastructure which would unfold
> during computations only to the extent needed, hopefully saving work -
> something I quite like to do!

I had a look at haskel, but decided that a full grown computer algebra
system provides such a larg amount of pre-done things, that I wont miss
it.

>   1. you were asking about data structures,

Indeed, I know the mathematical needs, but had to lear that representing
math in a computer sets further sever constraints, if perfomance is an
issue.

>   2. you seem to be constructing strings from symbols and constructing
> algebra on top of algebra, on top of algebra..., and

No, not strings, better to think of lists of lists of typed (lists,
elements, grades, signs,...)

>   3. GA seems to be a small subset of your algebraic structures,
Rather small yes.

	ndeed streams would be perfectly good for creating bases, etc, but
I need also to implement combinatorially very involved "products".
Consider the composition of functions. F a polynom, g a polynom, compute
(f\circ g)(x)=f(g(x)), this is already involved, now consider the
composition of f with u in Tens Tens V, (releted to products of group
representations)

> stream [a, f(a), f(f(a)), f(f(f(a))) . . .]. Given that the function
Usually to slow, itteration is computational inefficient (at least if I
handle it)

> worthwhile finding out.  It might also be worthwhile contacting Hestenes
> himself who is, I believe, looking into higher level computational methods
> for GA.

I know him personally, and especially Hongbo Li a post doc of him who did
some work in theorem proving. But my problem is much more complicated by
magnitutes. You might have a look at the Maple packages Clifford and
Bigebra (math.tntech.edu/rafal/) which Rafal Ablamowicz and myself
maintain. This can do almost all with tensor products of clifford
algebras. If I am looking for a new implementation in (either maple or
axiom) I will not make the errore you find documented there once more.

I stop since this is a developer mailing list ;-))

\start
Date: Fri, 2 Apr 2004 12:22:42 -0500
From: Tim Daly
To: Camm Maguire, Cliff Yapp
Subject: [Cliff Yapp: Re: Compiling error]

Camm,

CY is building Axiom on a Gentoo system and it fails during the lisp
compile of the first lisp file.

We tried running the newly built lisp image directly and the compile
succeeds so the image seems to be able to run ok.


CY,

A couple of notes:

1) The build process for axiom at this stage is intending to build
   an image called "depsys". To do this it creates a lisp file which 
   contains all of the instructions about how to make depsys:

(load "/home/user/axiomtoplevel/axiom/obj/linux/interp/makedep.lisp")

Perhaps you can try to start the lisp image and hand-load this file:
  /home/user/axiomtoplevel/axiom/obj/linux/bin/lisp
  > (load "/home/user/axiomtoplevel/axiom/obj/linux/interp/makedep.lisp")

2) You could try to build a down-level version of lisp and see if that
   succeeds. To do this you need to change the version requested in
   the Makefile.pamphlet:

   a) edit Makefile.pamphlet
      look for the lines (around line 519):
          #GCLVERSION=gcl-2.6.1
          GCLVERSION=gcl-2.6.2
      change it to read:
          GCLVERSION=gcl-2.6.1
          #GCLVERSION=gcl-2.6.2
      save the file

   rebuild the Makefile from Makefile.pamphlet

   b) make clean                    <== remove the old build effort
      make start                    <== make the noweb commands
      document Makefile             <== extract Makefile from Makefile.pamphlet

   rebuild the system with gcl-2.6.1

   c) make

   this will now build a system based on gcl-2.6.1. 
   Camm has made changes to GCL and they may have affected the build
   (although this is just superstition at this point but worth trying).

Tim

------- Start of forwarded message -------
Date: Thu, 1 Apr 2004 23:49:14 -0800 (PST)
From: Cliff Yapp
Subject: Re: Compiling error
To: Tim Daly

Well, the failure is reproducable as below.  What's even more
interesting is the whole lisp system seems to be unstable.  Not sure
how to debug something like this.

bash-2.05b$ /home/user/axiomtoplevel/axiom/obj/linux/bin/lisp

>(load "/home/user/axiomtoplevel/axiom/obj/linux/interp/makedep.lisp")

Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/makedep.lisp
Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/sys-pkg.lsp
Finished loading
/home/user/axiomtoplevel/axiom/obj/linux/interp/sys-pkg.lsp
Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/nocompil.lsp
Finished loading
/home/user/axiomtoplevel/axiom/obj/linux/interp/nocompil.lsp
Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/util.lsp
Finished loading
/home/user/axiomtoplevel/axiom/obj/linux/interp/util.lsp
Loading /home/user/axiomtoplevel/axiom/int/interp/vmlisp.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/vmlisp.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/ggreater.lisp
Finished loading
/home/user/axiomtoplevel/axiom/int/interp/ggreater.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/hash.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/hash.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/bootfuns.lisp
Finished loading
/home/user/axiomtoplevel/axiom/int/interp/bootfuns.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/union.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/union.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/nlib.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/nlib.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/macros.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/macros.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/comp.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/comp.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/spaderror.lisp
Finished loading
/home/user/axiomtoplevel/axiom/int/interp/spaderror.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/debug.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/debug.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/spad.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/spad.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/bits.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/bits.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/setq.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/setq.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/property.lisp
Finished loading
/home/user/axiomtoplevel/axiom/int/interp/property.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/unlisp.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/unlisp.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/foam_l.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/foam_l.lisp
Loading /home/user/axiomtoplevel/axiom/int/interp/axext_l.lisp
Finished loading /home/user/axiomtoplevel/axiom/int/interp/axext_l.lisp
Loading /home/user/axiomtoplevel/axiom/lsp/gcl-2.6.2/cmpnew/collectfn.o
start address -T 0x848ef20 Finished loading
/home/user/axiomtoplevel/axiom/lsp/gc
l-2.6.2/cmpnew/collectfn.o
Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/parse.fn
Finished loading
/home/user/axiomtoplevel/axiom/obj/linux/interp/parse.fn
Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/postpar.fn
Finished loading
/home/user/axiomtoplevel/axiom/obj/linux/interp/postpar.fn
Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/proclaims.lisp
Finished loading
/home/user/axiomtoplevel/axiom/obj/linux/interp/proclaims.lisp
Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/postpar.o
start address -T 0x87a2000 Finished loading
/home/user/axiomtoplevel/axiom/obj/li
nux/interp/postpar.o
Compiling /home/user/axiomtoplevel/axiom/obj/linux/interp/parse.lsp.
; (DEFUN |parseType| ...) is being compiled.
;; The variable |$oldParserExpandAbbrs| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |parseTypeError| ...) is being compiled.
;; The variable |$op| is undefined.
;; The compiler will assume this variable is a global.
;; Warning: The variable |x| is not used.
; (DEFUN |specialModeTran| ...) is being compiled.
;; The variable |$QuotientField| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |parseTranCheckForRecord| ...) is being compiled.
;; Warning: The variable |op| is not used.
; (DEFUN |transCategoryItem| ...) is being compiled.
;; The variable |$transCategoryAssoc| is undefined.
;; The compiler will assume this variable is a global.
End of Pass 1.  
End of Pass 2.  

Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by COND.
Broken at APPLY.  Type :H for Help.
COMPILER>>:q

Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by COND.
Broken at APPLY.  Type :H for Help.
>>:q

Error: The variable COMPILER::*COMPILER-INPUT* is unbound.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by IF.

Error: 30 is an illegal ihs index.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by SYSTEM:UNIVERSAL-ERROR-HANDLER.
Backtrace: system:universal-error-handler > system:sch-frs-base >
lambda > lambda
- -closure > block > apply > APPLY

Error: The tag (NIL) is undefined.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by APPLY.
Backtrace: system:universal-error-handler > lambda > lambda-closure >
block > app
ly > APPLY
Error handler called recursively (:ERROR NIL APPLY "" "The tag ~s is
undefined." 
(NIL))

Unrecoverable error: Segmentation violation..
Aborted
bash-2.05b$ 

\start
Date: Fri, 2 Apr 2004 10:50:48 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Camm Maguire
Subject: Re: [Cliff Yapp: Re: Compiling error]

--- Tim Daly wrote:
> Camm,
> 
> CY is building Axiom on a Gentoo system and it fails during the lisp
> compile of the first lisp file.

It's kinda weird Camm - I think at one point I even swapped in a
current cvs tree and tried building that, with the same results.

> We tried running the newly built lisp image directly and the compile
> succeeds so the image seems to be able to run ok.

The failure seems to come after the makedep.lsp is executed - something
being loaded there must cause some kind of instability on my specific
system :-(.

> A couple of notes:
> 
> 1) The build process for axiom at this stage is intending to build
>    an image called "depsys". To do this it creates a lisp file which 
>    contains all of the instructions about how to make depsys:
> 
> (load "/home/user/axiomtoplevel/axiom/obj/linux/interp/makedep.lisp")
> 
> Perhaps you can try to start the lisp image and hand-load this file:
>   /home/user/axiomtoplevel/axiom/obj/linux/bin/lisp
>   > (load
> "/home/user/axiomtoplevel/axiom/obj/linux/interp/makedep.lisp")

That's what I did in my previous example.  Same failure :-(.
 
> 2) You could try to build a down-level version of lisp and see if
> that succeeds.

 [snip]
 
>    this will now build a system based on gcl-2.6.1. 
>    Camm has made changes to GCL and they may have affected the build
>    (although this is just superstition at this point but worth
>    trying).
> 
> Tim

OK, I'll give that a shot.  

\start
Date: Sat, 3 Apr 2004 12:00:36 -0500
From: Bill Page
To: list
Subject: A possiible "navigation" approach for Axiom "crystal"

Tim,

When you have a moment take a look at the example

  http://zeck.floop.org.uk/mathis/WikiLiver/withNavigator

I am very impressed with the ability of this user interface

  http://www.touchgraph.com

  http://touchgraph.sourceforge.net/

to present very complex subjects.

For the last several months I have been very interested in
the Zope application development environment

  http://www.zope.org

I have implemented (under contract) a collaborative portal
based on Plone (http://www.plone.org) which includes a Wiki
(interactive web page) component

  http://www.zwiki.org

So I am beginning to understand this environment quite well.
Zope is written in Python

  http://www.python.org

If you haven't yet looked at Python, then I very strongly
recommend that you do. From the point of view of Axiom,
Python looks (almost exactly!) like the Boot sub-language
in which most of Axiom is written. I would even go so far
as to suggest that it might be possible (even quite easy?)
to port most of Axiom to Python. Doing so would have some
very important advantages because of the extensive support
that Python has for current computing environments.

Recently I also became aware of "LaTeXwiki"

  http://zwiki.org/LatexWiki

  http://mcelrath.org/Notes/LatexWiki

see also example at

  http://www.latexwiki.com

Taken together, I have the strong feeling that all of these
"technologies" provide exactly the kind of long term (30 years?)
development environment that is needed for Axiom and for large
scale computer algebra systems in general.

Originally I had been very interested in mathematical document
software with a computer algebra interface such as TeXmacs
(http://www.texmacs.org). This might be a fairly good alternative
to the old Axiom hypertex interface but this does not really
address at all the larger issues that you raised in your email
last December

 http://mail.gnu.org/archive/html/axiom-developer/2003-12/msg00056.html


I would be very interested to get reactions to this (what must
seem rather radical) suggestion.

Regards,
Bill Page.

Subject: [GeneralDiscussion] TouchGraph ZWiki Navigator

I'm currently trying to figure out a good way to package an applet I've
cobbled together from the "TouchGraph":http://www.touchgraph.com/ app =
and
some ZWiki, oython and HTML hacks.  If anybody's interested, I've =
published
a working example on
WikiLiver":http://zeck.floop.org.uk/mathis/WikiLiver/withNavigator and =
I'd
really appreciate any ideas on how I could package it so that others can =
try
it out on their ZWiki installations.
--
forwarded from
http://zwiki.org/GeneralDiscussion#msg20040403075120-0800@zwiki.org

\start
Date: Mon, 5 Apr 2004 01:42:04 -0400
From: Cliff Yapp
To: list
Subject: Re: Compiling error]
Cc: Camm Maguire

I tried building an axiom tarball I had from sometime in 2003 (which I
think did work) and the failure is exactly the same.  So the odds are
its something on my system.  Auuuugh.

So disregard the gentoo issue for a while - it looks like some update
on my system has upset the gcl build, and I'm not sure if that's due
to some weirdness in the build order of something or a fundamental
incompatibility.  Guess I'll try a full system rebuild and see if that
fixes it :-).

\start
Date: Mon, 5 Apr 2004 02:34:56 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Compiling error]
Cc: Camm Maguire

CY,

I'm back. Where can I get a copy of Gentoo?

\start
Date: Sun, 4 Apr 2004 23:08:29 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Compiling error]

Main website is at http://www.gentoo.org  It's a beast to install, so
be warned.  You might want to wait - I might have something that's
wrong on my system, and gentoo is not for the faint of heart :-).  I'm
running some system checks now, and I might go ahead and reinstall in a
couple weeks to get the full benefit of the 2.6 linux kernel.

If you do decide to install it, things to remember:

1)  You need detailed knowledge of your hardware configuration - 
    remember you compile your own kernel.
2)  The install docs are great, and necessary as well :-).
3)  The most grueling system stress test on earth for PC hardware
    is a gentoo install.  Memory in particular often shows failures
    here where it wouldn't otherwise.

CY

--- Tim Daly wrote:
> CY,
> 
> I'm back. Where can I get a copy of Gentoo?
> 
> Tim

\start
Date: 05 Apr 2004 11:34:59 -0400
From: Camm Maguire
To: Cliff Yapp
Subject: Re: Compiling error

Greetings, and thanks for your feedback!

I've read your recent messages indicating your suspicion that a recent
update has renderred your system unstable in some way.  I concur that
this is likely.  Please check just in case that your new kernel is not
doing some Fedora-type exec-shield protection.  I think this is not
the case, as your failure should have been much earlier.  The most
recent stable 2.6.2 release candidate has an automatic workaround for
this situation, but I'm not sure if it is in the axiom tree yet.

In any case, should you wish to pursue, please build gcl with
debugging (add --enable-debug to the configure command line), then run
the lisp image in gdb (gdb obj/linux/bin/lisp, most likely), 'r' to
start, and then (compile-file "....").  When you get the segfault,
start by reporting a backtrace with 'bt'.

Take care,

Cliff Yapp writes:

> Has anyone else seen this error?
> 
> Finished compiling
> /home/user/axiomtoplevel/axiom/lsp/gcl-2.6.2/cmpnew/collectfn.
> Loading /home/user/axiomtoplevel/axiom/lsp/gcl-2.6.2/cmpnew/collectfn.o
> start address -T 0x8488f40 Finished loading
> /home/user/axiomtoplevel/axiom/lsp/gcl-2.6.2/cmpnew/collectfn.o
> Loading /home/user/axiomtoplevel/axiom/obj/linux/interp/proclaims.lisp
> Finished loading
> /home/user/axiomtoplevel/axiom/obj/linux/interp/proclaims.lisp
> Compiling /home/user/axiomtoplevel/axiom/obj/linux/interp/postpar.lsp.
> ; (DEFUN |postError| ...) is being compiled.
> ;; The variable |$defOp| is undefined.
> ;; The compiler will assume this variable is a global.
> ; (DEFUN |postCategory| ...) is being compiled.
> ;; The variable |$insidePostCategoryIfTrue| is undefined.
> ;; The compiler will assume this variable is a global.
> ; (DEFUN |postDef| ...) is being compiled.
> ;; The variable |$maxSignatureLineNumber| is undefined.
> ;; The compiler will assume this variable is a global.
> ;; The variable |$docList| is undefined.
> ;; The compiler will assume this variable is a global.
> ;; The variable |$headerDocumentation| is undefined.
> ;; The compiler will assume this variable is a global.
> ; (DEFUN |postIf| ...) is being compiled.
> ;; Warning: The variable |x| is not used.
> End of Pass 1.  
> End of Pass 2.  
> 
> Error: Caught fatal error [memory may be damaged]
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by COND.
> Broken at APPLY.  Type :H for Help.
> COMPILER>>make[3]: ***
> [/home/user/axiomtoplevel/axiom/obj/linux/bin/depsys] Error 255
> make[3]: Leaving directory `/home/user/axiomtoplevel/axiom/src/interp'
> make[2]: *** [interpdir] Error 2
> make[2]: Leaving directory `/home/user/axiomtoplevel/axiom/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/home/user/axiomtoplevel/axiom'
> make: *** [all] Error 2

\start
Date: Mon, 5 Apr 2004 12:50:38 -0400
From: Tim Daly
To: Camm Maguire, Cliff Yapp
Subject: Compiling error

Camm,

>I've read your recent messages indicating your suspicion that a recent
>update has renderred your system unstable in some way.  I concur that
>this is likely.  Please check just in case that your new kernel is not
>doing some Fedora-type exec-shield protection.  I think this is not
>the case, as your failure should have been much earlier.  The most
>recent stable 2.6.2 release candidate has an automatic workaround for
>this situation, but I'm not sure if it is in the axiom tree yet.

nope. it's not in the axiom tree yet. i'm in the process of trying
to move the axiom gnu-arch to a new domain due to space problems so
even the book is lagged.

i don't believe it is an exec-shield problem because CY is able to
save an image and use it to compile the gcl code. the system dies
once it tries to compile axiom's lisp code. most curious of all
is that it compiles cleanly by hand.

>
>In any case, should you wish to pursue, please build gcl with
>debugging (add --enable-debug to the configure command line), then run
>the lisp image in gdb (gdb obj/linux/bin/lisp, most likely), 'r' to
>start, and then (compile-file "....").  When you get the segfault,
>start by reporting a backtrace with 'bt'.

\start
Date: 05 Apr 2004 12:44:33 -0400
From: Camm Maguire
To: Tim Daly
Subject: re: Clifford algebras in AXIOM
Cc: Bertfried Fauser

Greetings!  If/when I can clear the deck with pending GCL issues, I'd
really like to dive in to the guts of axiom regarding issues like
this.  Please accept my apologies for being so non-helpful at the
present time.

I think Bertfried brings up an interesting distinction between the
needs of cutting edge theoretical mathematicians, and more
'practical' sorts like certain types of physicists and most engineers
who really need an effective compendium of what is known about a
subject and a tool to help verify its application.  While the former
is interesting to me, I'm really mostly in the latter camp, which I
think is also a much larger group in general.  There is no reason why
the needs of both cannot be met as far as I can see.

>From this latter perspective, the key groups in physics are not that
many.  SO(2) which most would refer to as U(1), while extremely
simple, has profound implications for electricity and magnetism as well
as quantum mechanics, arguably setting the stage for the general
gauge-invariant pattern of the interaction of force with matter.
SO(3) and its quantum-mechanically allowed double cover SU(2), governs
the rotational symmetry of our three dimensional space, as well as
providing a separation of fundamental particles into Bose and Fermi
statistical camps.  SO(3,1) and its double cover SL(2,C) governs
relativity and the division of antimatter from matter.  These, IMHO,
are the truly well understood groups with nevertheless far reaching
implications.  SU(3) describing the symmetry of the strong
force/quantum chromodynamics is basically understood, but I think the
implications of asymptotic confinement are still being digested
somewhat.  Higher up in the Lie Group chain, SU(5) governs one of the
simpler schemes for a Grand Unified (field) Theory (GUT), while the
exceptional groups (e.g. E8) pertain to strings.  All of these are
still quite speculative, IMHO, in their applications to the real
world.  

Tacking on the group of translations onto SL(2,C) gives the poincare
group, the classifications of the irreducible representations of which
was one of Wigner's most famous achievements.  Another interesting
item is the connection between the generators of SU(2) and the
Heisenberg group containing the essential modifications of kinematics
from the classical to the quantum worlds.

To these I'd also add the 'point' groups chemists use to classify the
spectra of molecules based on their symmetry.  Quite powerful
conclusions can be drawn from symmetry alone.

Take care,

Tim Daly writes:

> Camm,
> 
> re: quantum theory and groups. Bertfried is working on Clifford and
> Hopf algebras. One of the concerns seems to be the choice of an
> efficient data structure. Since I (as yet) know nothing about the
> subject I can't give good advice. However, I'm looking around at
> some books to help me learn.
> 
> Axiom has some group theory (LyndonWords, LieAlgebra, Clifford Algebra, 
> etc) already. They are not in the paper version of the book but are
> in the electronic version.
> 
> I'm hoping to extend Axiom with domains which are useful in physics.
> >From my reading it appears that SU(3), SO(2), etc are of interest.

\start
Date: Mon, 5 Apr 2004 13:51:58 -0400
From: Tim Daly
To: Camm Maguire, Bertfried Fauser
Subject: (no subject)

Camm Maguire writes:

>Greetings!  If/when I can clear the deck with pending GCL issues, I'd
>really like to dive in to the guts of axiom regarding issues like
>this.  Please accept my apologies for being so non-helpful at the
>present time.
>
>I think Bertfried brings up an interesting distinction between the
>needs of cutting edge theoretical mathematicians, and more
>'practical' sorts like certain types of physicists and most engineers
>who really need an effective compendium of what is known about a
>subject and a tool to help verify its application.  While the former
>is interesting to me, I'm really mostly in the latter camp, which I
>think is also a much larger group in general.  There is no reason why
>the needs of both cannot be met as far as I can see.
>
>>From this latter perspective, the key groups in physics are not that
>many.  SO(2) which most would refer to as U(1), while extremely
>simple, has profound implications for electricity and magnetism as well
>as quantum mechanics, arguably setting the stage for the general
>gauge-invariant pattern of the interaction of force with matter.
>SO(3) and its quantum-mechanically allowed double cover SU(2), governs
>the rotational symmetry of our three dimensional space, as well as
>providing a separation of fundamental particles into Bose and Fermi
>statistical camps.  SO(3,1) and its double cover SL(2,C) governs
>relativity and the division of antimatter from matter.  These, IMHO,
>are the truly well understood groups with nevertheless far reaching
>implications.  SU(3) describing the symmetry of the strong
>force/quantum chromodynamics is basically understood, but I think the
>implications of asymptotic confinement are still being digested
>somewhat.  Higher up in the Lie Group chain, SU(5) governs one of the
>simpler schemes for a Grand Unified (field) Theory (GUT), while the
>exceptional groups (e.g. E8) pertain to strings.  All of these are
>still quite speculative, IMHO, in their applications to the real
>world.  
>
>Tacking on the group of translations onto SL(2,C) gives the poincare
>group, the classifications of the irreducible representations of which
>was one of Wigner's most famous achievements.  Another interesting
>item is the connection between the generators of SU(2) and the
>Heisenberg group containing the essential modifications of kinematics
>from the classical to the quantum worlds.
>
>To these I'd also add the 'point' groups chemists use to classify the
>spectra of molecules based on their symmetry.  Quite powerful
>conclusions can be drawn from symmetry alone.
>
>Take care,
>
>Tim Daly writes:
>
>> Camm,
>> 
>> re: quantum theory and groups. Bertfried is working on Clifford and
>> Hopf algebras. One of the concerns seems to be the choice of an
>> efficient data structure. Since I (as yet) know nothing about the
>> subject I can't give good advice. However, I'm looking around at
>> some books to help me learn.
>> 
>> Axiom has some group theory (LyndonWords, LieAlgebra, Clifford Algebra, 
>> etc) already. They are not in the paper version of the book but are
>> in the electronic version.
>> 
>> I'm hoping to extend Axiom with domains which are useful in physics.
>> >From my reading it appears that SU(3), SO(2), etc are of interest.
>

The correct attack on these kinds of problems in Axiom is to first
figure out the category hierarchy. Within algebra you can find a
nice structure of:

 fields
   rings
     groups
       monoids

etc. In one textbook I saw this hierarchy diagrammed but have never
been able to find it again.  Does there exist a book which shows the
Venn diagram or containment hierarchy for the kind of groups you
mention?  Implicit in the discussion above is that such a thing exists
but I haven't ever found it written down. If we could write down how
these groups are contained within each other (and what specialized
names they go by, such as Poincare groups) we'd be well on our way to
having a good, general purpose way of constructing and representing
them. I'm sure this is all well understood but I've never seen it
written down. Does anyone know of diagrams of this kind?

Ideally you'd be able to declare variables of type SU(3).

\start
Date: Mon, 05 Apr 2004 18:55:39 +0200
From: David Mentre
To: Camm Maguire
Subject: Re: [TeXmacs] Axiom plugin
Cc: Chu-Ching Huang, Bill Page

Hello Camm,

Camm Maguire writes:

> diff -urNad /home/rt/debian/own/texmacs/texmacs-1.0.3/plugins/axiom/progs/init-axiom.scm texmacs-1.0.3/plugins/axiom/progs/init-axiom.scm
> --- /home/rt/debian/own/texmacs/texmacs-1.0.3/plugins/axiom/progs/init-axiom.scm	2004-01-13 21:00:39.000000000 +0100
> +++ texmacs-1.0.3/plugins/axiom/progs/init-axiom.scm	2004-01-23 21:12:22.000000000 +0100
> @@ -17,7 +17,7 @@
>    (lazy-input-converter (axiom-input) axiom))
>  
>  (plugin-configure axiom
> -  (:require (url-exists-in-path? "AXIOMsys"))
> +  (:require (url-exists-in-path? "/usr/bin/axiom"))
>    (:initialize (axiom-initialize))
>    (:launch "tm_axiom")
>    (:session "Axiom"))
> diff -urNad /home/rt/debian/own/texmacs/texmacs-1.0.3/plugins/axiom/src/tm_axiom.c texmacs-1.0.3/plugins/axiom/src/tm_axiom.c
> --- /home/rt/debian/own/texmacs/texmacs-1.0.3/plugins/axiom/src/tm_axiom.c	2004-01-13 21:00:39.000000000 +0100
> +++ texmacs-1.0.3/plugins/axiom/src/tm_axiom.c	2004-01-23 21:12:20.000000000 +0100
> @@ -299,8 +299,8 @@
>      case 0: /* Axiom */
>        dup2(p1[1],1); close(p1[1]); close(p1[0]);
>        dup2(p2[0],0); close(p2[0]); close(p2[1]);
> -      execlp("AXIOMsys","AXIOMsys","-noclef",0);
> -      fatal("exec AXIOMsys");
> +      execlp("/usr/bin/axiom","/usr/bin/axiom","-noclef",0);
> +      fatal("exec /usr/bin/axiom");

Just poping some old mails, I discovered the above patch. Like Bill put
it at that time, I think AXIOMsys and not axiom should be called. If the
path to AXIOMsys in not in the PATH, then, of course, an absolute path
can be used.

\start
Date: Mon, 5 Apr 2004 12:04:58 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire
Subject: Re: Compiling error

--- Camm Maguire wrote:
> Greetings, and thanks for your feedback!
> 
> I've read your recent messages indicating your suspicion that a
> recent update has renderred your system unstable in some way.  I 
> concur that this is likely.

I'm currently doing a more or less complete sysem rebuild (I think) in
order to be sure there aren't any hidden quirks that might have
survived.  I've encountered weird behavior like this before with the
evolution email client - it eventually went away, but I was never sure
what did it.  I'm not so patient where gcl/axiom/maxima are concerned
;-).

> Please check just in case that your new kernel is
> not doing some Fedora-type exec-shield protection.  I think this is 
> not the case, as your failure should have been much earlier. 

I'm 99% sure it's not the kernel - I've been using the same 2.4 kernel
ever since I finally got lmsensors working.

> The most
> recent stable 2.6.2 release candidate has an automatic workaround for
> this situation, but I'm not sure if it is in the axiom tree yet.

I doubt I'll run into that, but if I finally do a full system reinstall
I'll keep it in mind.
 
> In any case, should you wish to pursue, please build gcl with
> debugging (add --enable-debug to the configure command line), then
> run the lisp image in gdb (gdb obj/linux/bin/lisp, most likely), 'r' 
> to start, and then (compile-file "....").  When you get the segfault,
> start by reporting a backtrace with 'bt'.

Ah - now that's a good idea :-).  I did try gdb, but forgot to do
enable debug.  No wonder there was so little information available :-).

\start
Date: Tue, 6 Apr 2004 00:12:49 +0200 (CEST)
From: Bertfried Fauser
To: list
Subject: Math Types inclusion

On Mon, 5 Apr 2004, root wrote:

> The correct attack on these kinds of problems in Axiom is to first
> figure out the category hierarchy. Within algebra you can find a
> nice structure of:
>
>  fields
>    rings
>      groups
>        monoids
>
> Ideally you'd be able to declare variables of type SU(3).

Dear Camm and Tim,

	both of you write very interesting perspectives on the possible
applications of group theory. However, life is somehow more complicated.

While I think I would be able to come up with some inclusion ship like
above, that is _not_ what a physicist _really_ wants. Having a group, say
SU(2) for simplicity, does not solve actual (and hence not computational)
problems. What physicists want to deal with are group _representations_!

All of quantum entanglement, quantum information processing, quantum
computing etc deals with tensor product representations of SU(2) currently
(and only a few such factors are currently experimental available, quantum
computers have up to say 15 q-bits max, that is one has to deal with a 15
fold tensor product of basic SU(2) spin 1/2 representations)

	There is a special purpose program called Schur (proprietary non
free software alas), which can handle such questions is a virtuose manner.
My attempts go into the direction to implement such possibilities.
Actually Clifford/Bigebra can do this in part, but Schur can do much more.
It was used to perform calculations in nuclear phys, high energy phys,
quantum chemistry, etc. I have tried to come up with a maple package
SchurFkt and implement there cutting edge algorithms (using Hopf
algebra methods) for dealing with Schur functions (group representations)
[Actually to test own calculations and preconceptions in a research
paper]

Hence while eg.
	 monoid < group,
you need representations of these groups (monoids), which increases the
computational complexity by magnitudes. To have an SU(2) variable would not
be entirely satisfying. An SU(2) variable would not even allow you to say
what spin it has, since the spin value is given to a representation, an
SU(2) element would however _act_ on such representations. [A group
representation could be projective, over complex numbers, over a finite
field etc...]

The point is, that eg. in Schur there is an algorithmical knowledge grown
up in several master and PhD thesis over a period of over 2 decades.
Unfortunately died Brian Wybourne, who initiated the project and was the
main power user of Schur last year, Peter and I were extraordinarily sad
to hear that bad news, since Brian was interested in or Hopf algebra
approach to the topic. (And due to the personal loss of such a friend and
mathematician.)
	Unfortunately, Schur's algorithms are not well documented, but
only its usage. Since its written in C, its pretty hard (for me at least)
to extract the time relevant parts of the algorithms. Hence my attempt to
implement them newly using new mathematics.

Most helpful, and I think mathematical modest, would be the development of
a category in AXIOM which could handle polynomial algebra, where the
"variables can be as complex as possible data structures (to be able to
iterate, at least one should have

A polynomial algebra in several variables, where the variables are signed
(commutative, anticommutative (two types) and neutral) every "variable"
should be replaceable by an element from (another instance of) the
polynomial algebra itself.

I think I can do this, but I will take my time (more likely years than
month). To be able to get started, a simple test domain for polynomial
algebra would be a great learning filed. I have to face the fact, that I
am a bad programmer, so my problem really is more like "what is the syntax
of this and that" and questions like "how to program this and that awkward
index set" etc. And -- efficiency is a major topic since all actual
computations are rather pretty longwinded, even beyond present day
compuert power, see the quantum simulator at the FIRST Fraunhofer
institute in Berlin (soory no url, but easily found via goole)

Regarding the discussion about Haskell, I am not sure how "functional" one
can be. My personal experience is, that to abstract mathematics often
fails the computer algebra texst. I found rather a couple of "theorems"
which didn't hold true on being tested via Clifford/Bigebra. AXIOM is the
only tool, which really seems to allow to program nearly functional by
specifying only types and not actual "elements", but...

Look at commutativity, given a multiplication m which is commutative
m(a,b)=m(b,a). A CAS needs _further_ information on term ordering to make
sense from this. Eg assume a>b then a "simplify" would not affect m(a,b),
but would change the arguments of m(b,a) into m(a,b). Such issues come up
in Groebner basis methods, and they really become a point in
noncommutative algebra. Actually such things as the Euclidean algorithm
breaks down in such domains and computability is very weak. There math is
an issue, not only the implementation.

Hence, (see Singular), even if you have a commutative ring, (monoid, with
action of an Abelian group [beware, there are rings having no monoid
structure, ie are not build over a "vector space"]) you need to specify a
term order to be able to compute. There lays the main difference between
categorial mathematics and computer algebra needs.

(AXIOM can already deal rudimentarily with symmetric functions, and hence
with group representations, see that chapter in the book, alas, the
current AXIOM does not allow to load this package as described there, so I
was not able to test what can be done actually)

Since the present discussion very fast could come into an idle discussion,
the main point recently has to be to bring AXIOM into life as complete as
possible, and to provide documentation which allows silly people as I am
to create a category and a domain, and to understand what actual types are
already there (I wont try to hack in bad code for things in AXIOM done
already much neater)

\start
Date: Tue, 6 Apr 2004 03:02:59 -0400
From: Tim Daly
To: Bertfried Fauser
Subject: Re: [Axiom-mail] Math Types inclusion

Actually, it seems that you are treading on an area we are currently
discussing internally. Essentially it amounts to the following
observation: Computer algebra systems are not "symbolic" at the level
we want to work. 

Essentially you'd like to work with the domains themselves rather
than elements of the domains, if I understand you correctly. Or at
least with a "canonical element" of a domain. 

We've had much discussion about this issue. It is the driving force
behind my attempt to unify the ACL2 work and Axiom. Somewhere between
the two approaches lies a useful kind of computational reasoning.

Categorically, Axiom seems capable of handling these domains.
However, the issue of representation and computation is different
than what we traditionally do. We want a representation that captures
the whole domain structure rather than a single element. We want a
computation that captures the axioms and theorems rather than
computation of individual results.

ACL2 is too far toward the proof end of the reasoning and Axiom
is too far toward the computational end of the reasoning. We need
to be able to represent and compute the lower central series, for
example, not as individual elements but as entire objects.

Does this seem to capture the essence of your struggle?

\start
Date: Tue, 6 Apr 2004 03:10:33 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: PDF version

CY,

At the moment the big struggle is to embed the pictures in the book
I downloaded the PDF version of the axiom book David generated
but the pictures seem to be missing. Of course, it could be that
my version of acroread and xpdf can't display the pictures. Once
I finish the current correction pass I'll work with David to figure
out how to get pictures.

\start
Date: Tue, 6 Apr 2004 09:34:37 +0200 (CEST)
From: Bertfried Fauser
To: William Sit
Subject: Re: Math Types inclusion

Dear William,

thankx for these pointers I will look into this code and just will try to
make a start. Better to go anywhere today ;-)) than nowhere anytime.

\start
Date: Tue, 06 Apr 2004 03:03:21 -0400
From: William Sit
To: Bertfried Fauser
Subject: Re: Math Types inclusion

This is a multi-part message in MIME format.
--------------876C806F6CCD71DFE8C46B46

Dear Bertfried:

Date: Tue, 6 Apr 2004 00:12:49 +0200 (CEST)
From: Bertfried Fauser

> Most helpful, and I think mathematical modest, would be the development of
> a category in AXIOM which could handle polynomial algebra, where the
> "variables can be as complex as possible data structures (to be able to
> iterate, at least one should have
> 
> A polynomial algebra in several variables, where the variables are signed
> (commutative, anticommutative (two types) and neutral) every "variable"
> should be replaceable by an element from (another instance of) the
> polynomial algebra itself.

Axiom already has these categories, domains, and packages. Check out
MonoidRing(R,M) category constructor (R a commutative ring, M a monoid), which
can be used to construct for example polynomial rings in which the variables
need not be commuting (but the coefficient ring is). On the other hand,
Polynomial(R) can construct polynomial rings where R is not commutative, but the
variables commute. MonoidRing can probably be generalized to take a
non-commutative ring without too much trouble. I think what you mean ny
"replaceable" is a tower construction (combining or iterating constructors, such
as Polynomial (R) where R is a ring and "replacing" can change such a polynomial
into some domain of the category Algebra(R)) and this can also be done on the
fly from the categorical constructors. 
> 
> I think I can do this, but I will take my time (more likely years than
> month). To be able to get started, a simple test domain for polynomial
> algebra would be a great learning filed. I have to face the fact, that I
> am a bad programmer, so my problem really is more like "what is the syntax
> of this and that" and questions like "how to program this and that awkward
> index set" etc. 

Too bad that the open source Axiom has not revived the hyperdoc, which would
help you with this. For the moment you will have to use 
)show       [e.g. )show MonoidRing], or
)display op [e.g. )display op leadingMonomial] to find the syntax.

> And -- efficiency is a major topic since all actual
> computations are rather pretty longwinded, even beyond present day
> compuert power, see the quantum simulator at the FIRST Fraunhofer
> institute in Berlin (soory no url, but easily found via goole)

Axiom is better for testing conceptual algorithms and is not known for its
efficiency. Efficiency can only be gained with better algorithms and fine tuning
in implementation. It is not uncommon that an axiom programmer uses recursion
(carelessly) when a non-recursive version is far more efficient and not that
much harder to code. The justification is that recursion is easier to be proved
correct, and compiler technology and computer hardware will catch up to save the
day.

> Regarding the discussion about Haskell, I am not sure how "functional" one
> can be. My personal experience is, that to abstract mathematics often
> fails the computer algebra texst. I found rather a couple of "theorems"
> which didn't hold true on being tested via Clifford/Bigebra. AXIOM is the
> only tool, which really seems to allow to program nearly functional by
> specifying only types and not actual "elements", but...

Beware that sometimes Axiom is correct in subtle ways even if the result
surprises. It is very strongly typed, and in the interpreter, the type and hence
the operation chosen (guessed?) by the interpreter need not be the one the user
intends. Such "wrong" theorems should be reported as possible bugs though.

> Look at commutativity, given a multiplication m which is commutative
> m(a,b)=m(b,a). A CAS needs _further_ information on term ordering to make
> sense from this. Eg assume a>b then a "simplify" would not affect m(a,b),
> but would change the arguments of m(b,a) into m(a,b). Such issues come up
> in Groebner basis methods, and they really become a point in
> noncommutative algebra. Actually such things as the Euclidean algorithm
> breaks down in such domains and computability is very weak. There math is
> an issue, not only the implementation.

> Hence, (see Singular), even if you have a commutative ring, (monoid, with
> action of an Abelian group [beware, there are rings having no monoid
> structure, ie are not build over a "vector space"]) you need to specify a
> term order to be able to compute. There lays the main difference between
> categorial mathematics and computer algebra needs.

Axiom has also included all sorts of ordering required for computation. Indeed,
different term-orderings in a polynomial ring are implemented for different
polynomial domains (DMP, HDMP, GDMP). Axiom distinguishes an ordered ring from a
ring so there are categories for OrderedRing, OrderedMonoid, etc.

> Hence while eg.
>          monoid < group,
> you need representations of these groups (monoids), which increases the
> computational complexity by magnitudes. To have an SU(2) variable would not
> be entirely satisfying. An SU(2) variable would not even allow you to say
> what spin it has, since the spin value is given to a representation, an
> SU(2) element would however _act_ on such representations. [A group
> representation could be projective, over complex numbers, over a finite
> field etc...]

You can construct as many (parametrized or not) representations of SU(2) as you
like. You can first construct the domain SU(2) as a group of matrices (data
representation) over whatever ground field (that is, the ground field R would be
a parameter of the domain constructor) together with generators and relations.
The group representations can then be constructed using the built-in domain
constructor MonoidRing(R,SU(2)) -- which mathematically speaking, is the algebra
of all maps from SU(2) to R with finite support. You can substitute R with R^n
or other direct product of rings if the representation is more involved (so for
the spin property, you can use as one factor FiniteField(2,1) -- 0 or 1). In
MonoidRing(R, SU(2)), the action need only be defined for the generators and
extended to all of SU(2). Now, may be this is not exactly what you want (and I
am not a physicist, nor have I tested this!), but I think this would be a good
start.

> (AXIOM can already deal rudimentarily with symmetric functions, and hence
> with group representations, see that chapter in the book, alas, the
> current AXIOM does not allow to load this package as described there, so I
> was not able to test what can be done actually)

Axiom has two packages on representation of finite groups:
RepresentationPackage1(R),
RepresentationPackage2(R), the first is for permutation groups, and the second
for modular representtion of finite groups and algebra (using the meat-Axe
algorithm). While these may not fit your application, the source (rep1.spad and
rep2.spad) may be useful as reference.

> Since the present discussion very fast could come into an idle discussion,
> the main point recently has to be to bring AXIOM into life as complete as
> possible, and to provide documentation which allows silly people as I am
> to create a category and a domain, and to understand what actual types are
> already there (I wont try to hack in bad code for things in AXIOM done
> already much neater)

You can take a look at the source code catdef.spad. I am also attaching two old
files monoid.spad and monoid.input as simple examples of constructing your own
monoid categories and domains (with some brief comments comparing with C++). It
also illustrates on-the-fly construction of new domains (direct product of two
monoid domains -- this would be similar to repeated tensor products of SU(2)
constructed on the fly). As long as you put these in your own private directory,
they will not interfere with the system libraries.

William
 filename="monoid.input"

)load INTPAIR MCAT MCAT- MONOID1 MONOID2 DPM
x:IntegerPair:=makePair(2,3)
x1:Monoid1:=x
x1:MonoidOne:=x
x2:MonoidTwo:=x
x1 * x1
x2 * x2
power(x1,4)
power(x2,4)
M12:=DirectProductOfMonoids(MonoidOne, MonoidTwo)
x12 := makeProduct(x1,x2)
x12 * x12
power(x12,4)
-- you can even form new direct product of the direct product!
-- with just a single line of code
M1212:=DirectProductOfMonoids(M12,M12)
x1212:=makeProduct(x12,x12)
x1212 * x1212
power(x1212,4)

--------------876C806F6CCD71DFE8C46B46
 name="monoid.spad"
 filename="monoid.spad"

)abb category MCAT MonoidCategory
)abb domain   MONOID1 MonoidOne
)abb domain   INTPAIR IntegerPair
)abb domain   MONOID2 MonoidTwo
)abb domain   DPM DirectProductOfMonoids

--% IntegerPair
IntegerPair(): Header == Code where
   Header ==> SetCategory with -- derived Class
     makePair: (Integer, Integer) -> $ -- C++ constructor, public
     FirstCoordinate:$->Integer -- C++ member function, public
     SecondCoordinate:$->Integer
   Code ==> add
     Rep := Record(x:Integer, y:Integer)  -- encapsulated data, private
     p,q:$
     (p = q):Boolean == (p.x = q.x) and (p.y = q.y)
     coerce(p):OutputForm == bracket([p.x::OutputForm, p.y::OutputForm])
     makePair(a, b) == [a,b]$Rep  
     FirstCoordinate(p) == p.x
     SecondCoordinate(p) == p.y

--% MonoidCategory
-- example of abstract base class
MonoidCategory():Category == SetCategory with
-- specify class member functions (similar to header files)
    "*": ($,$) -> $  -- pure virtual C++ functions
    1: constant -> $
    power: ($, Integer) -> $  -- virtual C++ function
  add
    power(x, n) ==   -- with default implementation
      n < 0 => error("Only positive powers in monoids")
      n = 0 => 1
      n = 1 => x
      x * power(x, n-1)

--% MonoidOne
MonoidOne(): Header == Code where
  Header ==> MonoidCategory with  -- derived from abstract base class
    coerce:IntegerPair -> $ -- new member function, a constructor
  Code ==> IntegerPair add -- derived from real base class
    import IntegerPair
    Rep:=IntegerPair -- layered inheritance
    coerce x == x
    (p:$ * q:$):$ ==
       x := FirstCoordinate(p) * FirstCoordinate(q)
       y := SecondCoordinate(p) * SecondCoordinate(q)
       makePair(x,y)
    1 == makePair(1$Integer, 1$Integer)

--% MonoidTwo
MonoidTwo(): Header == Code where
  Header ==> MonoidCategory with
    coerce:IntegerPair -> $
  Code ==> IntegerPair add
    import IntegerPair
    Rep:=IntegerPair
    coerce x == x  -- equivalent to C++ constructor
    (p:$ * q:$):$ ==
       x := FirstCoordinate(p) * SecondCoordinate(q)
       y := FirstCoordinate(p) * SecondCoordinate(q)
       makePair(x,y)
    1 == makePair(1$Integer, 1$Integer)

--% DirectProductOfMonoids
DirectProductOfMonoids(A:MonoidCategory,B:MonoidCategory):Header == Code where
    Header ==> MonoidCategory with -- derived from abstract base class
      makeProduct:(A, B) -> $
      FirstProjection:$ -> A
      SecondProjection:$-> B
    Code ==> add
      Rep:= Record(first:A, second:B)  -- layered inheritance
      makeProduct(a,b) == [a,b]$Rep
      x, y:$
      x * y == makeProduct(x.first *  y.first, x.second * y.second)
      FirstProjection(x) == x.first
      SecondProjection(x) == x.second
      coerce(x:$):OutputForm ==  -- ostream equivalent
        bracket([x.first::OutputForm, x.second::OutputForm])
      1 == makeProduct(1$A, 1$B)

-- note that we can now form many direct products of monoids
-- and do so "on the fly", all without any notion of pointers.
-- To do so in C++ would require so many levels of pointers
-- only the diehard would love it (every abstraction level
-- generally require at least one level of pointers).
--------------876C806F6CCD71DFE8C46B46--

\start
Date: Tue, 6 Apr 2004 09:25:27 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: Re: [Axiom-mail] Math Types inclusion

On Tue, 6 Apr 2004, root wrote:

Dear Tim,

> Actually, it seems that you are treading on an area we are currently
> discussing internally. Essentially it amounts to the following
> observation: Computer algebra systems are not "symbolic" at the level
> we want to work.

Interesting, I haven't known that such a discussion is on the track.

> Essentially you'd like to work with the domains themselves rather
> than elements of the domains, if I understand you correctly. Or at
> least with a "canonical element" of a domain.

Yes, in category theory (math), there is the concept of the "name" of an
operator. One can compute with the names of operators _without_ even
having defined elements. The same holds true for arrow only categories,
where objects are given via identity arrows, no elements at all. [This can
nicely be done in a Hopf algebra setting, one point why I like this
structure so much]

> We've had much discussion about this issue. It is the driving force
> behind my attempt to unify the ACL2 work and Axiom. Somewhere between
> the two approaches lies a useful kind of computational reasoning.

I do not know ACL2, but I fear not to have the resources to learn another
system. I think AXIOM has already the key features which are needed to
come up with computational and categorial issues.

> Categorically, Axiom seems capable of handling these domains.
> However, the issue of representation and computation is different
> than what we traditionally do. We want a representation that captures
> the whole domain structure rather than a single element.

In symmetric function theory, there are hints what to do. One can compute
with symmetric functions _without_ havings seen variables! (AXIOM does
this the same way, you specify the type of symmetric function (say power
sum) and the partition which characterizes it, that's sufficient to
compute with them, you need not even specify a name for the "variables",
they need not even to be actually _there_. However, one needs to make
assumptions about their domain (commutative, associative, etc..) which
enters the actual algorithms.

> We want a computation that captures the axioms and theorems rather than
> computation of individual results.

Once more, there is a big math problem in the back. In Maple, Rafal and I
do computations on a general element and _after_ the computation is
performed, this elements is cut out and eliminated. It works more like a
substrate or catalyst. However, regarding Clifford algebras, Zbigniew
Oziewicz and I (and probably others too) tried to get a entirely
categorial axiomatization but failed. If you try to do this, you get a
wast generalization of the structure. A categorial description does eg
know nothing about the base ring of the modules. So one has to deal with
characteristic free models which are much more complicated than those over
ordinary fields with characteristic zero.

> ACL2 is too far toward the proof end of the reasoning and Axiom
> is too far toward the computational end of the reasoning. We need
> to be able to represent and compute the lower central series, for
> example, not as individual elements but as entire objects.

I have studied linear categorial logic quite recently. It looks very
promising to solve quantum field and quantum mechanical problems. There
are quite a few but extraordinarily interesting papers around, showing how
categorial logic and proof theory __directly__ applies to quantum optics!
However, physics seem to need linear logic, and intuitionistic logic,
boolean logic will not do. During a lose discussion I told colleagues,
that my long term dream is to "Reformulate quantum field theory in terms
of categorial logic, so that (elementary particle) processes become a
proof in that logic, every process in nature would then be a step in a
quantum programming language called QFT" Of course, that's fare from being
actually realized, but a goal to struggle for.

> Does this seem to capture the essence of your struggle?
Yes, but I had also expressed very practical needs, due to my
unskillfulness in programming.

\start
Date: 06 Apr 2004 12:32:46 -0400
From: Camm Maguire
To: David Mentre
Subject: re: [TeXmacs] Axiom plugin
Cc: Chu-Ching Huang, Bill Page

Greetings!  I take it this is a reference to the debian texmacs
package.  I don't maintain this package, and so cannot address this.
The next version of the axiom debian package will have an AXIOMsys
symlink in /usr/bin.  Please know that if one calls this directly, one
still needs to putenv the AXIOM and possibly PATH variables, which is
done by the shell script wrapper.  Another problem with using an
absolute path is that the AXIOMsys binary is kept, at least currently,
in a directory with the version number in the path, which I think is a
good idea.  So I'd recommend staying with /usr/bin/AXIOMsys with
putenv'ed AXIOM and PATH environment variables if one doesn't like the
shell script, and when I get the next cut released into unstable,
which I hope to have built atop gcl 2.6.2.

Take care,

David Mentre writes:

> Hello Camm,
> 
> Camm Maguire writes:
> 
> > diff -urNad /home/rt/debian/own/texmacs/texmacs-1.0.3/plugins/axiom/progs/init-axiom.scm texmacs-1.0.3/plugins/axiom/progs/init-axiom.scm
> > --- /home/rt/debian/own/texmacs/texmacs-1.0.3/plugins/axiom/progs/init-axiom.scm	2004-01-13 21:00:39.000000000 +0100
> > +++ texmacs-1.0.3/plugins/axiom/progs/init-axiom.scm	2004-01-23 21:12:22.000000000 +0100
> > @@ -17,7 +17,7 @@
> >    (lazy-input-converter (axiom-input) axiom))
> >  
> >  (plugin-configure axiom
> > -  (:require (url-exists-in-path? "AXIOMsys"))
> > +  (:require (url-exists-in-path? "/usr/bin/axiom"))
> >    (:initialize (axiom-initialize))
> >    (:launch "tm_axiom")
> >    (:session "Axiom"))
> > diff -urNad /home/rt/debian/own/texmacs/texmacs-1.0.3/plugins/axiom/src/tm_axiom.c texmacs-1.0.3/plugins/axiom/src/tm_axiom.c
> > --- /home/rt/debian/own/texmacs/texmacs-1.0.3/plugins/axiom/src/tm_axiom.c	2004-01-13 21:00:39.000000000 +0100
> > +++ texmacs-1.0.3/plugins/axiom/src/tm_axiom.c	2004-01-23 21:12:20.000000000 +0100
> > @@ -299,8 +299,8 @@
> >      case 0: /* Axiom */
> >        dup2(p1[1],1); close(p1[1]); close(p1[0]);
> >        dup2(p2[0],0); close(p2[0]); close(p2[1]);
> > -      execlp("AXIOMsys","AXIOMsys","-noclef",0);
> > -      fatal("exec AXIOMsys");
> > +      execlp("/usr/bin/axiom","/usr/bin/axiom","-noclef",0);
> > +      fatal("exec /usr/bin/axiom");
> 
> Just poping some old mails, I discovered the above patch. Like Bill put
> it at that time, I think AXIOMsys and not axiom should be called. If the
> path to AXIOMsys in not in the PATH, then, of course, an absolute path
> can be used.

\start
Date: 06 Apr 2004 13:07:21 -0400
From: Camm Maguire
To: William Sit
Subject: Re: Math Types inclusion
Cc: Bertfried Fauser

Just a brief note of thanks for this marvelous outline of AXIOM's
abilities in this regard.  Hope I get some time soon....

\start
Date: Tue, 6 Apr 2004 14:04:36 -0400
From: Tim Daly
To: Camm Maguire
Subject: lisp

Camm,

I'm (finally) going to apply those axiom patches you sent.

\start
Date: Tue, 6 Apr 2004 14:42:43 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: lisp

is the autotune in the lastest distrib? should I do a cvs co?

re: significance. it's important. every performance gain gets multiplied
by the number of copies and adds up. but you knew that.

\start
Date: 06 Apr 2004 13:53:04 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: lisp

Great!  With the new autotune of the maximum pages by type (which is
not in your tree yet but will be in gcl 2.6.2) plus those AXIOM
patches, the compile time for EXPEXPAN.spad is down by about a factor
of ten on my box.  Full build took just over an hour (2.4Ghz).

I know such questions are of quite lesser significance, but someone
did state on the list that they wanted a faster compile, which kicked
me off in this direction.

Take care,

Tim Daly writes:

> Camm,
> 
> I'm (finally) going to apply those axiom patches you sent.

\start
Date: 06 Apr 2004 13:39:48 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: A possiible "navigation" approach for Axiom "crystal"

Greetings, and thanks for your very interesting suggestions!

Bill Page writes:

> Tim,
> 
> If you haven't yet looked at Python, then I very strongly
> recommend that you do. From the point of view of Axiom,
> Python looks (almost exactly!) like the Boot sub-language
> in which most of Axiom is written. I would even go so far
> as to suggest that it might be possible (even quite easy?)
> to port most of Axiom to Python. Doing so would have some
> very important advantages because of the extensive support
> that Python has for current computing environments.
> 

Just a few comments here -- disclaimer -- I've never used python
myself. 

To my understanding python is a great language, but I don't think it
would be a good idea to re-implement AXIOM in python.  The main
advantage of python is that it arguably has a larger pool of
knowledgeable users and developers than lisp does at this point.  This
is offset in my mind at least by the observations that 1) the language
is still a moving target 2) it is much slower/less efficient than lisp
in general, 3) a good deal of its popularity stems from the fact that
it has evolved the furthest towards lisp of the various popular
scripting languages -- it even has a 'lambda', 4) we have way too much
work to do as it is :-), 5) while quite portable, I am unaware of any
environment to which python could carry axiom to which gcl does not
already carry axiom, 6) lisp has a far longer history of real world
use, 7) it is unclear who will still be using python when the next hot
thing comes along or the development of the language ends, whereas
lisp appears to endure forever :-).

Just my $0.02.

Take care,


> Recently I also became aware of "LaTeXwiki"
> 
>   http://zwiki.org/LatexWiki
> 
>   http://mcelrath.org/Notes/LatexWiki
> 
> see also example at
> 
>   http://www.latexwiki.com
> 
> Taken together, I have the strong feeling that all of these
> "technologies" provide exactly the kind of long term (30 years?)
> development environment that is needed for Axiom and for large
> scale computer algebra systems in general.
> 
> Originally I had been very interested in mathematical document
> software with a computer algebra interface such as TeXmacs
> (http://www.texmacs.org). This might be a fairly good alternative
> to the old Axiom hypertex interface but this does not really
> address at all the larger issues that you raised in your email
> last December
> 
>  http://mail.gnu.org/archive/html/axiom-developer/2003-12/msg00056.html
> 
> 
> I would be very interested to get reactions to this (what must
> seem rather radical) suggestion.
> 
> Regards,
> Bill Page.
> 
> -----Original Message-----
> Subject: [GeneralDiscussion] TouchGraph ZWiki Navigator
> 
> 
> I'm currently trying to figure out a good way to package an applet I've
> cobbled together from the "TouchGraph":http://www.touchgraph.com/ app and
> some ZWiki, oython and HTML hacks.  If anybody's interested, I've published
> a working example on
> WikiLiver":http://zeck.floop.org.uk/mathis/WikiLiver/withNavigator and I'd
> really appreciate any ideas on how I could package it so that others can try
> it out on their ZWiki installations.
> --
> forwarded from
> http://zwiki.org/GeneralDiscussion#msg20040403075120-0800@zwiki.org

\start
Date: 06 Apr 2004 14:45:57 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: lisp

Greetings!

Tim Daly writes:

> is the autotune in the lastest distrib? should I do a cvs co?
> 

Yes.  It would be nice if you can check it out.  There is a variable
si::*optimize-maximum-pages* which defaults to t which eliminates an
old problem of spinning the gc for temporary allocations of eg. strings
in a 32 page space on a heap growing to quite large size.  You might
want to investigate (time ..) and (room) on computationally intensive
jobs with and without this variable set.

Our Windows guy just closed what appears to be the final bug.  I'm
waiting on one email from someone trying to get openbsd up and
running, after which I intend to make a read-only 2.6.2pre tag, have
everyone repeat their tests on the same version, then make the 2.6.2
tarball. 

> re: significance. it's important. every performance gain gets multiplied
> by the number of copies and adds up. but you knew that.
> 

\start
Date: Tue, 6 Apr 2004 16:04:42 -0400
From: Bill Page
To: Camm Maguire
Subject: Re: lisp

Camm,

On Tuesday, April 06, 2004 1:53 PM you wrote:
> 
> ...  With the new autotune of the maximum pages by type 
> (which is not in your tree yet but will be in gcl 2.6.2) plus 
> those AXIOM patches, the compile time for EXPEXPAN.spad is 
> down by about a factor of ten on my box.  Full build took 
> just over an hour (2.4Ghz).
>

Excellent!
 
> I know such questions are of quite lesser significance, but 
> someone did state on the list that they wanted a faster 
> compile, which kicked me off in this direction.
> 

I think it is VERY important. It is my understanding that because of the
dependency loops in Axiom's algebra definition (which necessitates the
current "bootstrap from LISP" method) it is, at least in prinicple =
necessary
to iterate the compilation of the algebra at least twice - once to
re-generate the bootstrap LISP code from the SPAD sources, replacing the
bootstrap code with the new LSIP. And then a second time  to make sure =
that
the generated bootstrap LISP code does not change (i.e. is a fixed =
point).

This is true, isn't it Tim?

On the other hand, I used the words "in principle" above because I think
(but haven't checked fully yet) that due to the currently rather simple
nature of the dependecy loops in Axiom's algebra code, one iteration is
sufficient. I think there is a need for some automatic means to check =
for
the fixed point. I have seen that the internally generated LISP names do =
not
stay the same from the original bootstrap to the first iteration LISP
output. So a comparison is not so trivial as a simple diff.

\start
Date: Tue, 6 Apr 2004 16:56:10 -0400
From: Tim Daly
To: Bill Page
Subject: Re: lisp
Cc: Camm Maguire

re: fixed point. Close but not quite the issue. The reason for the
second compile is performance. The first compile will generate .fn
files. If they exist the GCL compiler can use the type information
from the .fn files to generate better code.

\start
Date: Tue, 6 Apr 2004 17:06:34 -0400
From: Bill Page
To: Tim Daly
Subject: Re: lisp
Cc: Camm Maguire

Tim,

It seems to me that you are talking about something else. A different
issue.  Fast link is just a GCL thing isn't it? It just means that GCL
produces more efficient C code that gets compiled into a faster
binary. This is not an algebra "fixed point" in the sense that I meant
it.

What I am talking about is the situation where the lisp generated by
AXIOM for a bootstrapped module might not be the same as the original
lisp code that was used for the bootstrap. This could be the case if
changes are made in any of the algebra modules in the loop in which
the bootstrap module occurs - a kind of feedback - because the
dependencies are not really a lattice, they form a directed graph with
cycles. The bootstrap method is a way to break the cycles so that what
we end up compiling is a lattice of dependent code. As I understand
it, the lisp code for the current bootstrap was obtained by you from a
previous version of AXIOM or maybe even some of it was
hand-compiled. The code that gets generated in the end might depend on
the initial choice of bootstrap LISP code. This is not desirable
because REALLY the AXIOM algebra is supposed to be completely
specified by the SPAD code and all LISP should be derived from that.

To get correct LISP code for all modules in the loop you have to take
the generated lisp and feed it back into a recompile and check again
whether the generated lisp is the same as the bootstrap. As far as I
know we (at least I) have never checked that all the generated lisp
for the bootstrapped modules is equivalent to the original bootstrap
code.

Am I clearly describing what I mean?

Regards,
Bill Page.

> -----Original Message-----
> Subject: re: lisp
> 
> re: fixed point. Close but not quite the issue. The reason 
> for the second compile is performance. The first compile will 
> generate .fn files. If they exist the GCL compiler can use 
> the type information from the .fn files to generate better code.

\start
Date: Tue, 6 Apr 2004 18:15:46 -0400
From: Tim Daly
To: Bill Page
Subject: Re: lisp
Cc: Camm Maguire

You're clearly describing the situation with the algebra and
you're quite correct. At the moment it isn't an issue. The
base of the algebra lattice contains cycles. If you change
one of the domains in the cycle then that file as well as
the other files in the cycle have the "fixed point" issue.
Currently the Axiom build does not deal with this.

The second issue, which I raised, is that Axiom is faster after
the second system build due to the .fn files. The build cycle
can (and used to) deal with this issue. It will again in the
future when time permits.

The reason I raised the second issue is that Camm has made some
performance improvements.

\start
Date: Tue, 6 Apr 2004 19:05:10 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: A possiible "navigation" approach for Axiom "crystal"

Camm,

On Tuesday, April 06, 2004 1:40 PM you wrote:
> 
> Bill Page writes:
> ... 
> > If you haven't yet looked at Python, then I very strongly
> > recommend that you do. From the point of view of Axiom, Python
> > looks (almost exactly!) like the Boot sub-language in which
> > most of Axiom is written. I would even go so far as to suggest
> > that it might be possible (even quite easy?) to port most of
> > Axiom to Python. Doing so would have some very important
> > advantages because of the extensive support that Python has
> > for current computing environments.
> > 
> 
> Just a few comments here -- disclaimer -- I've never used 
> python myself. 
> 
> To my understanding python is a great language, but I don't 
> think it would be a good idea to re-implement AXIOM in 
> python.

Well, I didn't go so far as to actually say that it would be
a good idea ... <grin> In that sense I am not really serious.
GCL is a wonderful basis for AXIOM as it stands right now.
And you are making it even better very quickly!

But of course the situation is quite a bit more complicated.

In a sense AXIOM is not really implemented in lisp. It uses
lisp to implement a "higher level" (or maybe better stated:
"syntactically sweeter") language called BOOT. And it uses
BOOT to implement a still higher level language SPAD (and
from Tim's description maybe some other intermediate language
variants). The AXIOM interpreter is also written in BOOT.
The SPAD compiler compiles to lisp (or perhaps BOOT as an
intermediate?) Most of the non-algebraic parts of AXIOM are
written in BOOT, while the algebraic parts are in SPAD. etc.

Then GCL in turn generates C code which is compiled by GCC
etc.

Python is a byte code interpreter. There are some quite
efficient byte code interpreter implementations of lisp such
as CCL. One version of AXIOM was implemented in CCL.

Finally there is this popular introduction to Python

  http://www.norvig.com/python-lisp.html

which starts like this:

Python for Lisp Programmers

This is a brief introduction to Python for Lisp programmers.
(Although it wasn't my intent, Python programmers have told
me this page has helped them learn Lisp.) Basically, Python
can be seen as a dialect of Lisp with "traditional" syntax
(what Lisp people call "infix" or "m-lisp" syntax). One
message on comp.lang.python said "I never understood why LISP
was a good idea until I started playing with python." Python
supports all of Lisp's essential features except macros, and
you don't miss macros all that much because it does have eval,
and operator overloading, and regular expression parsing, so
you can create custom languages that way. 

-----------

> The main advantage of python is that it arguably has 
> a larger pool of knowledgeable users and developers than
> lisp does at this point.  This is offset in my mind at least
> by the observations that 1) the language is still a moving 
> target 2) it is much slower/less efficient than lisp in 
> general, 3) a good deal of its popularity stems from the fact 
> that it has evolved the furthest towards lisp of the various 
> popular scripting languages -- it even has a 'lambda',

I think what you say is true, although some people have
argued that it is not that much less efficient than compiled
C or lisp code. It is strange (and certainly widely discussed)
that lisp is much older (ca. 1960's) and more capable but
Python is new (1995?) yet has a large pool of users. I think
this really tells us something about the nature of programming
since I don't think one can blame the lack of adoption of
lisp on politics or other even less substantive influences.

> 4) we have way too much work to do as it is :-),

A have to agree there!

> 5) while quite portable, I am unaware of any environment to
> which python could carry axiom to which gcl does not already
> carry axiom, 

True.

> 6) lisp has a far longer history of real world use,

True.

> 7) it is unclear who will still be using python when the next
> hot thing comes along or the development of the language ends, 
> whereas lisp appears to endure forever :-).
>

Yes, odd isn't it? But we could say something rather similar
at the hardware level. We are still all using the same basic
design of computer - so called von Neumann architecture - that
was developed nearly 50 years ago. There is something quite
literally universal about it.

Theoretical linguists (e.g. Chomsky) have argued that all human
languages also have some kind of underlying universal grammar.
But no known living language actually uses this grammar although
there are hints of it in the way people - particularly children
actually learn language. Each one has its own variant that somehow
maps to the universal.

I think AXIOM is an excellent environment in which to observe
high level computer programming languages, particularly so
because it attempts to mimic many aspects of the only other
kind of universal language that I know of - mathematics. Almost
nothing we do with computers these days is sufficiently "high
level" to deal with the kind of abstractions that mathematicians
use daily.

I have been reading a paper "Categorical Analysis" by Zbigniew
Oziewicz and Guillermo Coutino

  http://www.arxiv.org/abs/math.CT/0101115

The authors present an abstract graphic language (tangles) for
reasoning about categories. Under the section heading "Why?"
They quote Dieudonne:

"Half the success (in mathematics) depends on a proper choice
of notation"

and then write: "Unfortunate notation might kill fortunate
ideas."

It seems to me that this epitaph also largely applies to lisp
and indeed to AXIOM and other computer algebra languages as
well.

> Just my $0.02.
> 

We all owe you considerable more than that for all your
invaluable work on GCL!

\start
Date: Tue, 6 Apr 2004 22:38:23 -0400
From: Tim Daly
To: Bill Page
Subject: Re: A possiible "navigation" approach for Axiom "crystal"
Cc: Camm Maguire

Bill,

This flame is not directed at you, Bill. You just managed to step on
my religious convictions at a time when I'm in a flaming mood.


/me mounts religious soapbox.....

I've looked at Python and, while it implements ideas that closely
resemble Lisp, it misses the essential point. The essential point
is that in Lisp the programs and the data are syntactically equivalent.
It is fundamental, yet often overlooked, that this equivalence exists.
In Lisp it is trivial to parse programs, just use (read). To do that
in Python you need much more machinery. Treating programs as data and
data as programs makes lisp unique. (In fact, there have been misguided
moves afoot to distinguish code from data in hardware.)

Axiom's power is premised on this ability. Boot was an attempt to
construct Python long before Python existed. Dick Jenks and I had
almost monthly debates about this. At one point I rewrote Axiom's
Boot layer in Lisp, which simplified the whole build process, and
got endless grief over it so I "unwrote" it. However, I do expect
the boot language to disappear if I ever get the free time.

Boot and Python are "Lisp without parens" as the advocates
like to paint it. Usually they make some "minor" distinctions like
there are no macros, or full closures don't work, or some such.
There have been dozens of these "Lisp without parens" languages.
They feel they've only added "syntactic sugar" to lisp.

The reason that Lisp syntax is important has to do with the notion
of "impedence matching" (e.g. hooking a soda straw to a fire hose).
The reason computer languages exist is to try to match your ideas
and thoughts to machine instructions. Obviously there is a big
impedence mismatch. 

Some languages, like assembler and C, are very close to the machine
and you need to bridge the gap. The upside is that you get very
efficient code. The downside is that there are many ways to mismatch.

Others languages are very close to what you want to write and you
don't have to work hard to make the match. The upside is that your
ideas are easy to express. The downsides are that (a) the language
limits what you can express and (b) the results may not be efficient.
Languages like Smalltalk are great if your idea can easily be expressed
as objects but fail badly if you want an efficient linked list.

Lisp is the only language I know that (a) is very close to the machine
(car and cdr are pointers) and (b) is very close to your thoughts.
Not only is there very little syntax to learn but you can mix high
level, idea-specific statements with low level pointer operations:
(devolve-semantic-network (car my-big-thing) (cdr my-other-thing))

So, given Lisp's self-describing, self-modifying, broad-impedence-matching
abilities you'll find that languages that try to be "lisp without parens"
like Boot and Python, miss the central characteristics.

There are yet more characteristics that get overlooked but you get the
idea. All of the good ideas in programming were first implemented in Lisp. 

/me crawls back under soapbox

\start
Date: 06 Apr 2004 22:36:17 -0400
From: Camm Maguire
To: Tim Daly
Subject: re: lisp
Cc: Bill Page

Greetings!

Tim Daly writes:

> The second issue, which I raised, is that Axiom is faster after
> the second system build due to the .fn files. The build cycle
> can (and used to) deal with this issue. It will again in the
> future when time permits.
> 

Thanks for bringing this to my attention. So I take it the build so
far does not take advantage of any proclamation information?  The
addition of this information can make a big difference to
performance.  I'm interested in the mechanism AXIOM used in the past
to make use of the .fn files.  What we do in GCL proper (on occasion,
not with every build, yet), is to emit all fn files in a given
directory, then make-all-proclaims, producing one big
sys-proclaims.lisp, which is then loaded automatically if it exists by
a direction in a gcl_cmpinit.lsp file in the same directory.  I can't
really think of a better way of doing it given that functions calling
each other can be in different files.  Indeed more, they can easily be
in different directories or even 'layers'.  We've recently added an
improvement in loading the sys-proclaims.lisp file for every compiled
module directory right before the save-system, so that this
information is preserved in the lisp image when moving on to the next
layer.  Still, if anyone can think of a more transparent way to do
this I'd be most interested.  I'd also be interested in looking at
what needs to be done to restore AXIOM's older ability to inhale the
.fn files.

Take care,

> The reason I raised the second issue is that Camm has made some
> performance improvements.

\start
Date: Tue, 6 Apr 2004 23:55:04 -0400
From: Tim Daly
To: Camm Maguire
Subject: re: lisp
Cc: Bill Page

Camm,

The .fn processing machinery is there. All you need to do to speed
up axiom is to do a build, touch the int/*.{lsp|lisp} files, and
then 'make'. This will trigger a second round of compiles. Since
the first round of compiles wrote the .fn files they will be available
for the second round of compiles and the type optimizations occur.

I need to add these steps to the build but there are other high
priority items to fix first.

\start
Date: Wed, 7 Apr 2004 13:35:10 -0400
From: Tim Daly
To: Nicolas Ratier
Subject: Re: [AXIOM]

Nicolas,

The book sources are in the standard cvs on savannah. use:

export CVS_RSH=ssh
cvs -z3 -d:ext:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom

and look at

src/doc/book.pamphlet 

file. Axiom's document command or noweb's noweave command will
extract the tex sources. If memory serves I believe the book.pamphlet
file is standard latex as I don't remember including any code in it.

\start
Date: 08 Apr 2004 12:36:04 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: lisp
Cc: Bill Page

Greetings!  Yes, thanks!  Just confirmed that doing so shaved 1/3 off
the regression suite time.

It appears that AXIOM is making use of the .fn files in a slightly
different way than GCL itself -- namely automatically loading the .fn
file of the same base name when compiling a file the second time.
(I'm still looking for the spot in the compiler source where this
happens, can't seem to find it yet.)  If this is the case, and if a
new lisp process is started for every compile-file, then the benefits
of the .fn files will only accrue to calls within the file itself.
I.e. GCL will compile a function taking real C arguments, and if
another function calls it in the same file, the call will be done via
a C function pointer set to the first compiled function address and
loading arguments directly onto the C stack.  Calls from other files
will load values onto the lisp value stack and pass through a section
of GCL code which will make the call via a jump table.  This will
still be faster than having the function break apart the values from
the lisp value stack itself, but might be further improved.

In general, the optimal situation would be to load sys-proclaim.lisp
files made from the .fn files in all layers and subdirectories, dump
the image, and then this to compile the second pass.  All
proclamation information is now permanently in the image.

In the future, I would like to make this easier to use, but this will
surely wait for a long time.  The best idea I have at present is to
store the lisp source for each function in the function symbol's
plist, recompile the function whenever new info is acquired on one of
its calls, and then perhaps put in some algorithm to dump the lisp
source to save space when all calls have been proclaimed, though one
could always redefine the functions later and miss thereby the info
required to make the updates.  

Anyway, this whole concept of the compiler getting smarter as it
builds the image is quite special to lisp, it appears, as in C, for
example, all of this information must be explicitly provided by the
user in the form of included static header files.

Take care,

Tim Daly writes:

> Camm,
> 
> The .fn processing machinery is there. All you need to do to speed
> up axiom is to do a build, touch the int/*.{lsp|lisp} files, and
> then 'make'. This will trigger a second round of compiles. Since
> the first round of compiles wrote the .fn files they will be available
> for the second round of compiles and the type optimizations occur.
> 
> I need to add these steps to the build but there are other high
> priority items to fix first.

\start
Date: 13 Apr 2004 11:06:16 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: [Gcl-devel] 2.6.2.....
Cc: Mike Thomas, Bill Page, Vadim V. Zhytnikov

Greetings!

Mike Thomas writes:

> Hi Camm/Vadim.
> 
> | Thanks, Vadim!  OK I'll push 0 for the second value
> 
> Please do so for the following reasons:
> 

OK, done.

> | unless Mike knows
> | how to get child runtimes on mingw.
> 
> 1. I don't know.
> 
> 2. I believe from a quick search of the MSDN Win32 docs that OS accumulated
> execution time for spawned sub-processes isn't available directly from the
> Win32 API.  It is definitely not available through MSVCRT (the C runtime
> library).
> 
> 
> Moving forward:
> 
> I built CLtL1 GCL/gcc 3.3.3/binutils 2.15.90 and did a complete ACL2 2.8
> build and "make regression" with the optional books without error.
> 

Great!

> Tried Axiom on the off-chance that it would work without divine intervention
> but immediately ran into swathes of problems unrelated to GCL so left it for
> the Axiom team to worry about.
> 

Thank God for Bill Page!

\start
Date: Tue, 13 Apr 2004 18:13:52 -0400
From: Tim Daly
To: Mike Thomas
Subject: gcl 2.6.2
Cc: Camm Maguire, Bill Page, Vadim V. Zhytnikov

Camm Maguire writes:
> Mike Thomas writes:
> 
> > Moving forward:
> > 
> > I built CLtL1 GCL/gcc 3.3.3/binutils 2.15.90 and did a complete ACL2 2.8
> > build and "make regression" with the optional books without error.
> > 
> 
> Great!
> 
> Tried Axiom on the off-chance that it would work without divine intervention
> but immediately ran into swathes of problems unrelated to GCL so left it for
> the Axiom team to worry about.

Is there any chance of getting a console trace from the Axiom run?

\start
Date: Tue, 13 Apr 2004 18:17:59 -0400
From: Tim Daly
To: Mike Thomas
Subject: gcl 2.6.2
Cc: Camm Maguire, Bill Page, Vadim V. Zhytnikov

Camm,

FYI, Axiom's latest CVS does a build on the latest 2.6.2 (actually listed
as gcl-2.6.2a due to incompatible changes with the previous 2.6.2). This
has your memory balancing code as well as the patches you submitted for
util.lisp.

I've been working on getting the collectfn performance changes built
into the makefiles. Axiom will now, by default, generate the .fn files
(the gcl_collectfn and sys-proclaims.lisp files are loaded by default)
when compiles are done in the image. There are still some issues due
to package-naming that I need to resolve before I can upload these
changes.

\start
Date: Wed, 14 Apr 2004 14:06:35 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: [Gcl-devel] gcl 2.6.2
Cc: Camm Maguire, Bill Page, Vadim V. Zhytnikov

Hi Tim.

Good to hear from you again.  Please note that I'm not in a position to
chase this up beyond the point of triviality, but for what it's worth,
please read on:

| > Tried Axiom on the off-chance that it would work without divine
| intervention
| > but immediately ran into swathes of problems unrelated to GCL
| so left it for
| > the Axiom team to worry about.
|
| Is there any chance of getting a console trace from the Axiom run?


=====================================================================
$ ./configure --help

You must set your AXIOM and PATH variables. Type:

export AXIOM=/c/cvs/head/axiom/mnt/linux
export PATH=$AXIOM/bin:$PATH

To build the rest of the system type:

make

configure finished.

$ export AXIOM=/c/cvs/head/axiom/mnt/linux


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

Tim, note that here I diverge and use "win" instead of "linux".  In fact, I
used the latter yesterday and got the same result.


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

$ export AXIOM=/c/cvs/head/axiom/mnt/win; export PATH=${AXIOM}/bin:${PATH}

$ make
13 making noweb
tar: contrib/kostas/Makefile: Cannot create symlink to `Makefile.make': No
such
file or directory
tar: Error exit delayed from previous errors
patching file `modules.c'
make[1]: [install-shell] Error 1 (ignored)
make[1]: [install-code] Error 1 (ignored)
c:\lang\mingw32\bin\strip.exe: c/nt: No such file or directory
c:\lang\mingw32\bin\strip.exe: c/markup: No such file or directory
c:\lang\mingw32\bin\strip.exe: c/mnt: No such file or directory
c:\lang\mingw32\bin\strip.exe: c/finduses: No such file or directory
make[1]: *** [install-code] Error 1
make: *** [noweb] Error 2

$ ls mnt
win

$ ls mnt/win
bin

$ ls mnt/win/bin
lib

$ ls mnt/win/bin/lib
cpif     nodefs  noroots   nountangle  noweb        tmac.w
htmltoc  noroff  notangle  noweave     nuweb2noweb  toroff

$ ls -l ./obj/noweb/contrib/kostas
total 28
-rw-r--r--    1 miketh   Administ     2441 Mar 28  2000
C++_translation_table
-rw-r--r--    1 miketh   Administ     1960 Mar 28  2000 C_translation_table
-rw-r--r--    1 miketh   Administ     1703 Mar 28  2000 Makefile.gnu
-rw-r--r--    1 miketh   Administ     1703 Mar 28  2000 Makefile.make
-rw-r--r--    1 miketh   Administ      779 Mar 28  2000 README
-rw-r--r--    1 miketh   Administ     1368 Mar 28  2000 WHATS_NEW
-rw-r--r--    1 miketh   Administ      690 Mar 28  2000 defns.nw
-rw-r--r--    1 miketh   Administ       20 Mar 28  2000 email
-rw-r--r--    1 miketh   Administ     5452 Mar 28  2000
icon_translation_table
-rw-r--r--    1 miketh   Administ     2484 Mar 28  2000
math_translation_table
-rw-r--r--    1 miketh   Administ      571 Mar 28  2000 mathdefs.nw
-rw-r--r--    1 miketh   Administ     5255 Mar 28  2000
oot_translation_table
-rw-r--r--    1 miketh   Administ     6036 Mar 28  2000 ootdefs.nw
-rw-r--r--    1 miketh   Administ    19567 Mar 28  2000 pp.nw

$ find . -iname finduses

$
---------------------------------------------------------------

\start
Date: Wed, 14 Apr 2004 01:00:52 -0400
From: Tim Daly
To: Mike Thomas
Subject: Re: [Gcl-devel] gcl 2.6.2
Cc: Vadim V. Zhytnikov, Camm Maguire, Bill Page

Thomas,

The failure occurs building noweb which is a literate programming tool.
Apparently it tries to make a symbolic link but failed. Axiom itself
is almost all common lisp.

If you have some notes about how to set up the win environment I'd
find it most useful. We're setting up an open source lab at work
and I plan to set up one Windows machine to try to get GCL running.

\start
Date: Wed, 14 Apr 2004 14:36:58 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: [Gcl-devel] gcl 2.6.2
Cc: Camm Maguire, Bill Page, Vadim V. Zhytnikov

Hi Tim.

| If you have some notes about how to set up the win environment I'd
| find it most useful. We're setting up an open source lab at work
| and I plan to set up one Windows machine to try to get GCL running.

Good to see.  Please find below the contents of the file "readme.mingw",
available from the GNU Common Lisp CVS repository (stable branch).

I suggest you obtain gcc version 3.3.1 and binutils 2.14.90 as these seem to
work best with Windows GCL in it's current state.

Cheers

Mike Thomas.


===============================================
BUILDING NATIVE WIN32 GNU COMMON LISP FROM CVS
===============================================

The preferred build host system for the Mingw32 compiler is MSYS.

I use gcc version 3.3.1 and binutils 2.14.90, but earlier versions
back to gcc 2.95 are OK provided that you remove the
"-fno-zero-initialized-in-bss" flag in "h/mingw.defs" before running
"configure".

Also note that gcc 3.3.3 does NOT work; likewise binutils 2.13.*


===============================================
BUILDING GCL USING MSYS AS THE HOST
===============================================

BUILD TOOLS

- Mingw32 Version 2 Windows native gcc:
    http://www.mingw.org/

- MSYS Mingw build environment, including the MSYS DTK
    http://www.mingw.org/

- Source code for GCL.
    http://savannah.gnu.org/projects/gcl/

It is a good idea to keep up to date with Mingw32 and MSYS.  There
are usually updates for various parts of these packages to be found
on the web site.   Pleas note the version issues with gcc and binutils
mentioned above.

Avoid using MSYS 1.10 RC3 as it has some annoying bugs. RC2 is fine
as I write in January 2004.


SHORT SETUP NOTES

- Install Mingw32 and MSYS using the instructions at those sites.


DETAILED SETUP NOTES

- Start by installing the latest version of MinGW2.exe.

- By looking at the dates and version numbers appended to the other
  packages on the download page, get any versions of gcc 3.2, binutils,
  mingw-runtime, and w32api that are later than the Mingw2 package.

- Go to the top level Mingw32 installation directory - the one in which you
  can see "bin", "lib" etc

- Extract those other packages in that directory eg:

  tar xzf rumpty-dumpty.tar.gz

- Remove the Mingw version of "make" from the bin directory - it has serious
  bugs and will not work properly for most tasks including building GCL and
  Maxima.  We will be using the MSYS version.

- Get MSYS and install it - follow the instructions - subscribe to the
  mailing list and read the archives.

- In the MSYS directory install the "msysDTK-1.0.0-alpha-1.tar.gz" package
  which gives you cvs, ssh, rlogin, etc.



BUILDING

- Change to your GCL source directory eg:

  cd /c/cvs/gcl

- You are now ready to configure GCL:

  ./configure --prefix="c:/gcl" > configure.log 2>&1

  Change the prefix directory as required for your final installation path.
  I find it helpful to redirect output from "configure" and "make" into log
  files for debugging and checking.

- Check the log.

- Type:

  	make >& make.log

- The "saved_gcl.exe" should turn up eventually in the unixport directory.
You
  can try it out directly by typing:

	./unixport/saved_gcl.exe

  at the command prompt.

- To install:

	make install >& install.log

  It is necessary to install GCL before building Maxima.

- The batch file "gclm.bat" can be used to make a Windows desktop
  shortcut.

- BFD fasloading, Stratified Garbage Collection (SGC) readline and GCL-TK
  don't work under Windows.  The configuration options above provide a
  "traditional" GCL executable which will build the current CVS version of
  Maxima.  The BFD option will depend on someone with knowledge of BFD and
  PE-COFF linking fixing some problems with the BFD library - I am slowly
  absorbing the info needed, but we really need input from an expert.  My
  inclination is to stick with custom relocation as BFD is less efficient.

\start
Date: Wed, 14 Apr 2004 01:30:31 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [Gcl-devel] gcl 2.6.2
Cc: Vadim V. Zhytnikov, Mike Thomas, Camm Maguire, Bill Page

Excellent. The lab should be powered on in the next few weeks (hopefully
by the end of april). Of course, I'll be at the east coast computer 
algebra day at the beginning of may it's all gonna take time.

Michele Lavaud has a Windows version of the Rosetta CD which contains
a bunch of computer algebra systems. You might want to let him know
that GCL and ACL2 are running on Windows.

\start
Date: Wed, 14 Apr 2004 00:35:34 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: [Gcl-devel] gcl 2.6.2
Cc: Camm Maguire, Vadim V. Zhytnikov

Tim, Mike,

Take a loot at

  http://mail.gnu.org/archive/html/axiom-developer/2003-10/msg00227.html

wherein I gave Tim my notes on the state of my attempt at building Axiom
under Windows as of last October. I think most of this still applies with
the exception perhaps of the versions of MSYS/MinGW tools listed below.

Regards,
Bill Page.

> -----Original Message-----
> Subject: RE: [Gcl-devel] gcl 2.6.2
> 
> 
> Hi Tim.
> 
> | If you have some notes about how to set up the win environment I'd
> | find it most useful. We're setting up an open source lab at work
> | and I plan to set up one Windows machine to try to get GCL running.
> 
> Good to see.  Please find below the contents of the file 
> "readme.mingw",
> available from the GNU Common Lisp CVS repository (stable branch).
> 
> I suggest you obtain gcc version 3.3.1 and binutils 2.14.90 
> as these seem to
> work best with Windows GCL in it's current state.
> 
> Cheers
> 
> Mike Thomas.
> 
> 
> ===============================================
> BUILDING NATIVE WIN32 GNU COMMON LISP FROM CVS
> ===============================================
> 
> The preferred build host system for the Mingw32 compiler is MSYS.
> 
> I use gcc version 3.3.1 and binutils 2.14.90, but earlier versions
> back to gcc 2.95 are OK provided that you remove the
> "-fno-zero-initialized-in-bss" flag in "h/mingw.defs" before running
> "configure".
> 
> Also note that gcc 3.3.3 does NOT work; likewise binutils 2.13.*
> 
> 
> ===============================================
> BUILDING GCL USING MSYS AS THE HOST
> ===============================================
> 
> BUILD TOOLS
> 
> - Mingw32 Version 2 Windows native gcc:
>     http://www.mingw.org/
> 
> - MSYS Mingw build environment, including the MSYS DTK
>     http://www.mingw.org/
> 
> - Source code for GCL.
>     http://savannah.gnu.org/projects/gcl/
> 
> It is a good idea to keep up to date with Mingw32 and MSYS.  There
> are usually updates for various parts of these packages to be found
> on the web site.   Pleas note the version issues with gcc and binutils
> mentioned above.
> 
> Avoid using MSYS 1.10 RC3 as it has some annoying bugs. RC2 is fine
> as I write in January 2004.
> 
> 
> SHORT SETUP NOTES
> 
> - Install Mingw32 and MSYS using the instructions at those sites.
> 
> 
> DETAILED SETUP NOTES
> 
> - Start by installing the latest version of MinGW2.exe.
> 
> - By looking at the dates and version numbers appended to the other
>   packages on the download page, get any versions of gcc 3.2, 
> binutils,
>   mingw-runtime, and w32api that are later than the Mingw2 package.
> 
> - Go to the top level Mingw32 installation directory - the 
> one in which you
>   can see "bin", "lib" etc
> 
> - Extract those other packages in that directory eg:
> 
>   tar xzf rumpty-dumpty.tar.gz
> 
> - Remove the Mingw version of "make" from the bin directory - 
> it has serious
>   bugs and will not work properly for most tasks including 
> building GCL and
>   Maxima.  We will be using the MSYS version.
> 
> - Get MSYS and install it - follow the instructions - subscribe to the
>   mailing list and read the archives.
> 
> - In the MSYS directory install the 
> "msysDTK-1.0.0-alpha-1.tar.gz" package
>   which gives you cvs, ssh, rlogin, etc.
> 
> 
> 
> BUILDING
> 
> - Change to your GCL source directory eg:
> 
>   cd /c/cvs/gcl
> 
> - You are now ready to configure GCL:
> 
>   ./configure --prefix="c:/gcl" > configure.log 2>&1
> 
>   Change the prefix directory as required for your final 
> installation path.
>   I find it helpful to redirect output from "configure" and 
> "make" into log
>   files for debugging and checking.
> 
> - Check the log.
> 
> - Type:
> 
>   	make >& make.log
> 
> - The "saved_gcl.exe" should turn up eventually in the 
> unixport directory.
> You
>   can try it out directly by typing:
> 
> 	./unixport/saved_gcl.exe
> 
>   at the command prompt.
> 
> - To install:
> 
> 	make install >& install.log
> 
>   It is necessary to install GCL before building Maxima.
> 
> - The batch file "gclm.bat" can be used to make a Windows desktop
>   shortcut.
> 
> - BFD fasloading, Stratified Garbage Collection (SGC) 
> readline and GCL-TK
>   don't work under Windows.  The configuration options above provide a
>   "traditional" GCL executable which will build the current 
> CVS version of
>   Maxima.  The BFD option will depend on someone with 
> knowledge of BFD and
>   PE-COFF linking fixing some problems with the BFD library - 
> I am slowly
>   absorbing the info needed, but we really need input from an 
> expert.  My
>   inclination is to stick with custom relocation as BFD is 
> less efficient.

\start
Date: Wed, 14 Apr 2004 15:07:22 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: [Gcl-devel] gcl 2.6.2
Cc: Camm Maguire, Vadim V. Zhytnikov

Thanks Bill.

I'll try this when I find my way out of the current round of bugs.

\start
Date: Wed, 14 Apr 2004 05:51:25 -0400
From: Bill Page
To: list
Subject: RE: A possible "navigation" approach for Axiom  "crystal"

In

  http://mail.gnu.org/archive/html/axiom-developer/2004-04/msg00015.html

I wrote about the possibility of using math-enabled interactive web page
server (wiki) such as

  http://mcelrath.org/Notes/LatexWiki

as a means to host Axiom documentation, code and mathematical articles. Here
are some examples of two other existing systems which already contain a lot
of useful mathematical documentation

  http://planetmath.org/

"PlanetMath is a virtual community which aims to help make mathematical
knowledge more accessible. PlanetMath's content is created collaboratively:
the main feature is the mathematics encyclopaedia with entries written and
reviewed by members. The entries are contributed under the terms of the GNU
Free Documentation License (FDL) in order to preserve the rights of both the
authors and readers in a sensible way.

..."

For example

  http://planetmath.org/encyclopedia/CategoryTheory.html

planetmath has direct support for LaTeX.

------

  http://en.wikipedia.org/wiki/Mathematics

"Main Page
>From Wikipedia, the free encyclopaedia. 

Welcome to Wikipedia! We are building an open-content encyclopaedia in many
languages. We started in January 2001 and are now working on 246334 articles
in the English version. Join us! Visit the Community Portal or try out the
sandbox to find out how you can edit any article right now.  

... "

Although wikipedia is more general than just mathematics, it seems to have
rather good coverage of some advanced subjects in mathematics. For example

  http://en.wikipedia.org/wiki/Enriched_category

-------

What I envisage is a large set of fully cross-referenced web pages such as
these with one or more pages for each of the algebra modules (packages,
domains and categories) within Axiom. But in addition the SPAD code itself
would be accessible and editable in this same manner. The code would be
accessible to a 'make' process that could build an operational Axiom system.
Additional documentation pages would include both description text as well
as executable Axiom code illustrating the concepts. Finally, it should also
be possible to prepare complete mathematical articles online which include
Axiom to calculations. All of these pages would be accessible by external
URLs for reference purposes.

This sort of environment scales very well from a single user system running
a simple wiki web server plus Axiom to a large shared installation with high
performance web server and multiple high speed processors running Axiom.

\start
Date: Wed, 14 Apr 2004 07:36:32 -0400
From: Tim Daly
To: Bill Page
Subject: Re: A possible "navigation" approach for Axiom "crystal"

An excellent idea. How would you propose we approach such a problem?
Would we set up a wiki? Is the software they are using available?
Can we arrange to maintain our wiki portions as subportions of these
other wikis? If we do the syntax change of chunks from:
   <<a chunk defn>>=  
to a latex form:
   \chunkdefn{a chunk defn}
can we parse this into MathML using some standard tools? 

\start
Date: 14 Apr 2004 09:35:36 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] gcl 2.6.2
Cc: Mike Thomas, Bill Page, Vadim V. Zhytnikov

Greetings!

Tim Daly writes:

> Camm,
> 
> FYI, Axiom's latest CVS does a build on the latest 2.6.2 (actually listed
> as gcl-2.6.2a due to incompatible changes with the previous 2.6.2). This
> has your memory balancing code as well as the patches you submitted for
> util.lisp.
> 

Great!  Please accept my apologies for the version numbering confusion
-- we haven't released 2.6.2 yet, so what you have is a release
candidate which should be numbered 2.6.1 in the splash.

> I've been working on getting the collectfn performance changes built
> into the makefiles. Axiom will now, by default, generate the .fn files
> (the gcl_collectfn and sys-proclaims.lisp files are loaded by default)
> when compiles are done in the image. There are still some issues due
> to package-naming that I need to resolve before I can upload these
> changes.

So you are making sys-proclaims.lisp from the .fn in a separate step?
Probably a good idea.  The .fn files appear to be directly loaded in
some manner on recompile in any case, although I still haven't found
out where in the compiler source.  There is also a lot more
information being collected than would appear necessary for the
sys-proclaims.  I'll look into this some more.  From my current
understanding, my recommendation would be to load all the
sys-proclaims.lisp files from each layer into the interpsys, dump a
new interpsys, and recompile.

\start
Date: 14 Apr 2004 09:48:47 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] gcl 2.6.2
Cc: Mike Thomas, Bill Page, Vadim V. Zhytnikov

Greetings!

Tim Daly writes:

> Excellent. The lab should be powered on in the next few weeks (hopefully
> by the end of april). Of course, I'll be at the east coast computer 
> algebra day at the beginning of may it's all gonna take time.
> 

Just wondered when/where this computer algebra day was being held...

Just as a quick summary here of the state (as I know it) of GCL on
Windows, thanks to Mike's wonderful efforts, things have improved
quite a bit since Bill last tried in October.  We've closed a long
standing bug that prevented faslinking in the ansi image, and another
that interfered with compiled object code initialization with
different optimization settings.  Both of these issues were in the
linker file sfasl.c, which to my knowledge is only used by the Windows
port at present, making it harder to debug of course.  We still have
outstanding three issues -- 1) The build breaks unless compiler
optimization settings are carefully set and coordinated 2) we have a
randomly occurring pathname corruption bug when ansi (ignore-errors
...) is in place, and 3) we can't compile maxima with gcc 3.3.3.

I'm mentioning this in case you might have any person resources in
your open source lab to assist in chasing these down.  Windows is a
much harder development platform, and I'd like to spare as many Mike
Thomas cycles as possible for his many other responsibilities.

Take care,

> Michele Lavaud has a Windows version of the Rosetta CD which contains
> a bunch of computer algebra systems. You might want to let him know
> that GCL and ACL2 are running on Windows.

\start
Date: Wed, 14 Apr 2004 09:15:38 -0400
From: Tim Daly
To: Camm Maguire
Subject: misc

East Coast Computer Algebra Day 2004 (Saturday, May 8th)
in Waterloo, Ontario, Canada. Maybe I can score a new Maple t-shirt :-)

http://www.cargo.wlu.ca/eccad2004

=========================
re: GCL on Windows and open source lab

I teach an open source course and I've gotten funded to set up a lab.
(I'm trying to get funds to invite speakers but no luck so far).

One of the boxen in the lab is targetted toward being a computer 
algebra pile. I'm lead developer on Axiom and Magnus (infinite
group theory). I'd like to get a student or two to do computer
algebra work. Also, this box is going to be used to work with 
Dirk to build a new Quantian Scientific Computing CD (similar
to Knoppix) (see http://dirk.eddelbuettel.com/quantian.html)
I want to put GCL, Axiom and ACL2 on it. It already has Maxima.

A second box is a 64 bit machine so we can look at pushing Axiom
(and therefore GCL) up to 64 bits.

The other boxes are planned to run other distros, including Windows,
for porting and compile-farming.

The goal is to get a couple students who want to learn to be
computational mathematicians. We can't find them so we have to
grow them. I just got my hands on the new Computational 
Commutative Algebra book (built around CoCoA) and have been
considering teaching a course around it. I also have a good
book on Category Theory and it would make an interesting course
(but very Axiom specific). 

Anyway the lab equipment has been ordered but has not yet arrived.
And, as we all know, getting a new computer up and running is a
time consuming job. sigh.

========================================
re: GCL 2.6.1 vs 2.6.2 vs 2.6.2a

umm, I'm confused. According to your note the latest cvs checkout
will only get 2.6.1? I thought it was 2.6.2. 

\start
Date: 14 Apr 2004 10:57:50 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] misc

Greetings!

Tim Daly writes:

> East Coast Computer Algebra Day 2004 (Saturday, May 8th)
> in Waterloo, Ontario, Canada. Maybe I can score a new Maple t-shirt :-)
> 
> http://www.cargo.wlu.ca/eccad2004
> 

... was hoping for next door nyc :-)

> =========================
> re: GCL on Windows and open source lab
> 
> I teach an open source course and I've gotten funded to set up a lab.
> (I'm trying to get funds to invite speakers but no luck so far).
> 
> One of the boxen in the lab is targetted toward being a computer 
> algebra pile. I'm lead developer on Axiom and Magnus (infinite
> group theory). I'd like to get a student or two to do computer
> algebra work. Also, this box is going to be used to work with 
> Dirk to build a new Quantian Scientific Computing CD (similar
> to Knoppix) (see http://dirk.eddelbuettel.com/quantian.html)
> I want to put GCL, Axiom and ACL2 on it. It already has Maxima.
> 
> A second box is a 64 bit machine so we can look at pushing Axiom
> (and therefore GCL) up to 64 bits.
> 

Just to let you know, gcl/axiom works at present on itanium and
alpha.  I expect it also to work on amd64, though haven't tested
explicitly.  amd64 should be the strongest 64bit GCL offering, as it
can natively relocate object code.

> The other boxes are planned to run other distros, including Windows,
> for porting and compile-farming.
> 
> The goal is to get a couple students who want to learn to be
> computational mathematicians. We can't find them so we have to
> grow them. I just got my hands on the new Computational 
> Commutative Algebra book (built around CoCoA) and have been
> considering teaching a course around it. I also have a good
> book on Category Theory and it would make an interesting course
> (but very Axiom specific). 
> 
> Anyway the lab equipment has been ordered but has not yet arrived.
> And, as we all know, getting a new computer up and running is a
> time consuming job. sigh.

Sounds exciting.  Good luck!

> 
> ========================================
> re: GCL 2.6.1 vs 2.6.2 vs 2.6.2a
> 
> umm, I'm confused. According to your note the latest cvs checkout
> will only get 2.6.1? I thought it was 2.6.2. 
> 

You are not the only one who is confused!  After the gnu.org
compromise, we've hosted gcl on Debian.  We still have not changed
this, but hope to with 2.6.2.  Right now, we have an 'upstream'
version, 2.6.1, and a Debian package version (now at -37), which can
be found in the first line of the debian/changelog file.  So current
stable is at 2.6.1-37.  When we finally squash at least the Windows
gcc 3.3.3 bug, we'll release 2.6.2, push to gnu.org and change the
numbering system.  CVS snapshots after that point will have the date
in the version number, I'm guessing.

Suggestions of course most welcome.

\start
Date: Wed, 14 Apr 2004 16:09:49 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel] misc

> > East Coast Computer Algebra Day 2004 (Saturday, May 8th)
> > in Waterloo, Ontario, Canada. Maybe I can score a new Maple t-shirt :-)
> > 
> > http://www.cargo.wlu.ca/eccad2004
> > 
> 
> ... was hoping for next door nyc :-)


Actually, we are hosting a conference in NYC on April 30th:
(no admission, registration at the door)
http://www.grouptheory.org

The Future of Scientific Computation

Michael P. Barnett

"Helping scientific research and teaching benefit from symbolic computation"

Professor Michael P. Barnett is a visiting researcher at Princeton
University and Professor Emeritus at Brooklyn College. His recent
research in symbolic integration results in tabulations of overlap
integrals, molecular integrals, and Coulomb integrals and he has
compiled extensive surveys of use of computer algebra in chemistry and
the life sciences.

Bruno Buchberger

"How I managed to automate myself"

Bruno Buchberger is Professor of Computer Mathematics, at The Research
Institute for Symbolic Computation in Linz.  He is the Group Leader
Symbolic Computation Professor for Computer Mathematics at the
Research Group for Symbolic Computation at RISC. He has made
fundamental contributions to Computer algebra, symbolic computation,
Automated theorem proving and Mathematical knowledge management. His
work on Groebner bases is one of the most important tools in computer
algebra.
 

Charles Peskin

"Muscle and Blood: Computer Simulation of the Heart by the Immersed
 Boundary Method"

Charles S. Peskin is Professor of Computer Science at the Courant
Institute of Mathematical Sciences of New York University. He was
elected to the National Academy of Sciences in 1995. According to the
membership listing, "Peskin has made fundamental contributions to the
mathematical and numerical analysis of physiological problems,
particularly in cardiac fluid dynamics and the study of the heart's
architecture; the deep insights his work has produced contribute to
the design of prosthetic heart valves, and his methods advance the art
of scientific computation".


Stephen Watt

"Interfaces for Mathematical Components"

Stephen Watt, the former chair of Computer Science at The University
of Western Ontario, is now a full professor in the department. He has
made fundamental contributions to Maple and Axiom, two leading
computer algebra systems. Stephen was the designer and technical lead
on the development of Aldor, a strongly-typed categorical programming
language. He has also had important contributions in MathML, a
standard for math on the internet.

Date: Thu, 15 Apr 2004 09:39:52 -0400
From: Tim Daly
To: Camm Maguire
Subject: stable/unstable

I've almost certainly grabbed 2.7 as I added no version information
to the cvs command line. Axiom appears to work there anyway. Is the
version number available in the image?

\start
Date: 15 Apr 2004 11:04:55 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: stable/unstable

Greetings!

Tim Daly writes:

> I've almost certainly grabbed 2.7 as I added no version information
> to the cvs command line. Axiom appears to work there anyway. Is the
> version number available in the image?
> 

Yes, when gcl is started there is a splash screen with the version
number.  Also in files majvers and minvers in the top of the source.

\start
Date: 15 Apr 2004 10:28:31 -0400
From: Camm Maguire
To: Tim Daly
Subject: 'gcl 2.6.2a'

Greetings!  Tim, is it possible you've grabbed the cvs HEAD/aka
unstable development branch for axiom?  If so, I'd suggest using the
stable branch, which has all the recent improvements backported into
it.  2.7.x is unstable, 2.6.x is stable.  In general for the future,
x.y.z is (stable,unstable) when y is (even,odd) just like the linux
kernel. 

export CVS_RSH=ssh
export CVSROOT=:ext:anoncvs@subversions.gnu.org:/cvsroot/gcl
cvs -z9 -q co -d gcl-2.6.1 -r Version_2_6_1 gcl

Without the -r Version.... arg, the head/unstable branch is taken by
default. 

\start
Date: Thu, 15 Apr 2004 09:36:55 -0400
From: Tim Daly
To: Camm Maguire
Subject: parGCL

Are you connected with parGCL?
We've been muttering about parallel extensions to Axiom.
Magnus is already parallel.

\start
Date: 15 Apr 2004 11:04:11 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: parGCL

Greetings!

Tim Daly writes:

> Are you connected with parGCL?
> We've been muttering about parallel extensions to Axiom.
> Magnus is already parallel.
> 

Yes -- in fact its author has volunteered as a GCL developer, and has
refreshed the code to recent GCL.  We had discussed bundling it at
some point, but I am unsure whether it properly belongs in a lisp
system distribution per se - i.e. where does one draw the line at
interfaces to external libraries?  

It definitely should work, though I don't know how efficient it is.
I've tested it briefly myself.

\start
Date: Thu, 15 Apr 2004 13:29:18 -0400
From: Tim Daly
To: Dirk Eddelbuettel
Subject: quantian

Dirk,

I finally got hold of a machine where I can set up Quantian.
I'm going to try to add Axiom and re-image the CD.

\start
Date: Thu, 15 Apr 2004 13:29:18 -0400
From: Tim Daly
To: Dirk Eddelbuettel
Subject: quantian

Dirk,

I finally got hold of a machine where I can set up Quantian.
I'm going to try to add Axiom and re-image the CD.


\start
Date: Sat, 17 Apr 2004 23:11:53 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: Re: A possible "navigation" approach for Axiom "crystal"
Cc: Bill Page

On Wed, 14 Apr 2004, root wrote:

> An excellent idea. How would you propose we approach such a problem?
> Would we set up a wiki? Is the software they are using available?
> Can we arrange to maintain our wiki portions as subportions of these
> other wikis? If we do the syntax change of chunks from:
>    <<a chunk defn>>=
> to a latex form:
>    \chunkdefn{a chunk defn}
> can we parse this into MathML using some standard tools?

Dear Bill, and Tim,

to set up a wiki is quite easy, you might find one on my web-page
concerned with the documentation of Clifford and Bigebra.- My experience
is however, that is take reasonable time to reformat documents (eg the
500p documentation of Clifford and Bigebra) into the format used by wikis.
Wikis are optimized to serve a human to format text easily, so that
virtually everyone can edit a page, without knowing any html (not to speak
about LaTeX, or MathML) I do not see an easy automatical conversion. This
is also not the idea of a wiki, being automatically generated from
unaccesiible (via the wiki interface) source, say directly from teh axiom
code. If I understand literate programming correctly, it should however
approch the wiki idea somehow, to allow to document and change the
pamphlet files over the web, this might be restricted to documentation,
not to spoil the code of the official release.

\start
Date: Sat, 17 Apr 2004 23:10:27 -0400
From: Bill Page
To: Bertfried Fauser
Subject: RE: A possible "navigation" approach for Axiom "crystal"

Bertfried

Thank you for the reference to your Clifford wiki at

  http://clifford.physik.uni-konstanz.de/~fauser/

I think that it is an interesting tool to link to other
resources, but you do not seem to have very much content
in the wiki itself. Is this that your intention? Do you
find that many other people besides yourself make use of
the ability to edit your wiki pages?

On Saturday, April 17, 2004 5:12 PM you wrote:
> 
> Dear Bill, and Tim,
> 
> to set up a wiki is quite easy, you might find one on my 
> web-page concerned with the documentation of Clifford and 
> Bigebra.- My experience is however, that is take reasonable 
> time to reformat documents (eg the 500p documentation of 
> Clifford and Bigebra) into the format used by wikis.

I think automatic conversion is possible if you use wiki
tools such as latexwiki which is based on zwiki, and which
in turn is based on Zope. Simple Python scripts could do
most of the necessary reformatting from the original LaTeX.

> Wikis are optimized to serve a human to format text easily,
> so that virtually everyone can edit a page, without knowing
> any html (not to speak about LaTeX, or MathML) I do not see
> an easy automatical conversion.

Some people might claim that LaTeX is optimized to serve a
human to format mathematics easily. latexwiki trys to provide
both in one package. But I think MathML serves an entirely
different purpose. It is not optimized for use by humans,
rather it's purpose in communication between machines.

> This is also not the idea of a wiki, being automatically
> generated from unaccesiible (via the wiki interface) source,
> say directly from the axiom code. If I understand literate
> programming correctly, it should however approch the wiki
> idea somehow, to allow to document and change the pamphlet
> files over the web,

Yes, this is exactly what I would hope to achieve. I think
that initially the Axiom wiki could be loaded from the
existing pamphlet files and LaTeX documentation. But there
after it should be possible to maintain it all entirely
"through the web" including building a new binary Axiom
distribution. Perhaps for some purposes it would also be
desirable to extract everything from the wiki into the
conventional linear text format pamphlet files and
documentation.

> this might be restricted to documentation, not to spoil the
> code of the official release.

No, I would not want to limit the use of the wiki to only
documentation. There are other ways to control access and
to incorporate changes into an official release.

But loading the 1000+ pages of the existing Axiom documentation
into a latexwiki would be a sufficient challenge for me to
start with! I am not quite ready yet to take on that challenge
but maybe soon.

\start
Date: Sun, 18 Apr 2004 10:11:24 +0200
From: David Mentre
To: Bertfried Fauser
Subject: Re: A possible "navigation" approach for Axiom "crystal"
Cc: Bill Page

Hello,

Bertfried Fauser writes:

> approch the wiki idea somehow, to allow to document and change the
> pamphlet files over the web, this might be restricted to documentation,
> not to spoil the code of the official release.

Regarding that point, this functionnality already exists. The PHP
documentation is made such that users can add comments online. For
example, see: http://www.php.net/manual/en/installation.php

\start
Date: Sun, 18 Apr 2004 14:05:02 -0400
From: Tim Daly
To: Michael Koehne, Yoriaki Fujimori, Camm Maguire
Subject: 404 http://axiom.tenkan.org/axiom.20040321.tgz

> Moin Tim,
> 
>   i wanted to download actual axiom, but got a 404 on the above URL ;(
>   would be nice to inform me, Yoriaki Fujimori
>   and Camm Maguire, when the new verions is available again ;)
> 
Michael,

Those files got removed while cleaning up the file system due to lack
of space on the server. I've replaced the source tgz with the latest
set of sources. I'm currently rebuilding the executable from the
latest set of sources (this will take about a day on this machine).
I'll upload the newly compiled files once this completes and let
you know when they are back on line.


\start
Date: Sun, 18 Apr 2004 20:09:17 +0200
From: David Mentre
To: Tim Daly
Subject: Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz
Cc: Camm Maguire, Michael Koehne, Yoriaki Fujimori

Tim Daly writes:

> I'll upload the newly compiled files once this completes and let
> you know when they are back on line.

In the meantime, I have uploaded latest developer sources at:
http://www.linux-france.org/~dmentre/axiom/axiom--release--1--patch-8.tar.gz
(about 40 MB)

\start
Date: Sun, 18 Apr 2004 23:09:31 +0200 (CEST)
From: Bertfried Fauser
To: Bill Page
Subject: RE: A possible "navigation" approach for Axiom "crystal"

Dear Bill,

my Clifford Wiki is essentially inactive, precicely due to the fact, that
I was not able to find out a way to convert the (proprietary!!) maple help
pages _automatically_ into a suitable wiki format (LaTeX wikis were not
easili available on that time when this wiki was installed). With AXIOM
the situation is somehow better, since the files are ASCII and can easiliy
be parsed. In any case, its not suitable to look for different essetially
identical (regarding the content) documentations.


\start
Date: Mon, 19 Apr 2004 08:41:42 -0400
From: Tim Daly
To: Michael Koehne, Yoriaki Fujimori, Camm Maguire
Subject: 404 http://axiom.tenkan.org/axiom.20040321.tgz]

Michael,

These files are back. The binary is 16MB as you expect.
It has been rebuilt from the latest sources.

Note that they actually refer to a new domain called axiom-developer.org.
I'm in the process of setting up a new axiom-only server. 
We ran into space problems on tenkan.org. 

Tim

> > Moin Tim,
> > 
> >   i wanted to download actual axiom, but got a 404 on the above URL ;(
> >   would be nice to inform me, Yoriaki Fujimori
> >   and Camm Maguire, when the new verions is available again ;)
> > 
> > Bye Michael
> > -- 
> 
> Michael,
> 
> Those files got removed while cleaning up the file system due to lack
> of space on the server. I've replaced the source tgz with the latest
> set of sources. I'm currently rebuilding the executable from the
> latest set of sources (this will take about a day on this machine).
> I'll upload the newly compiled files once this completes and let
> you know when they are back on line.

\start
Date: Mon, 19 Apr 2004 16:15:01 -0400
From: Tim Daly
To: Michael Koehne, Yoriaki Fujimori, Camm Maguire
Subject: 404 http://axiom.tenkan.org/axiom.20040321.tgz]

Michael,

Also new in this version you'll find the current book.dvi in
mnt/linux/doc/book.dvi

\start
Date: Mon, 19 Apr 2004 21:22:27 -0400
From: Tim Daly
To: list
Subject: fyi

Date: Mon, 19 Apr 2004 18:30:30 +0200
From: ISSAC 04 <issac2004@RISC.UNI-LINZ.AC.AT>
Subject: ISSAC2004-Call for software exhibitions

*********************************************************************

                  CALL FOR SOFTWARE EXHIBITIONS

                            ISSAC-2004
    International Symposium on Symbolic and Algebraic Computation
             University of Cantabria, Santander, Spain
              http://www.risc.uni-linz.ac.at/issac2004

*********************************************************************

This year ISSAC organizes sessions to exhibit software packages produced by
academic developers. These sessions are intended to promote software
development activities in the areas of symbolic mathematical computation.

Important Dates
---------------

*Deadline for Abstract Submission: May 10, 2004

*Notification of Acceptance: May 28, 2004

Submission Guidelines
---------------------

Authors are invited to submit electronically software packages &
documentation (or links for downloading them) and an abstract of their
presentation to

Thomas Bayer (bayert@in.tum.de)

Topics
------

Topics of the meeting include, but are not limited to:

- Algorithmic mathematics

Algebraic, symbolic and symbolic-numeric algorithms. Simplification,
function manipulation, equations, summation, integration, ODE/PDE, linear
algebra, number theory, group and eometric computing.

- Computer Science

Theoretical and practical problems in symbolic computation. Systems, problem
solving invironments, user interfaces, software, libraries,
parallel/distributed computing and ogramming languages for symbolic
computation, concrete analysis, benchmarking, heoretical and practical
complexity of computer algebra algorithms, automatic differentiation, code
generation, mathematical data structures and exchange protocols.

- Applications

Problem treatments using algebraic, symbolic or symbolic-numeric computation
in an essential or a novel way. Engineering, conomics and finance, physical
and biological sciences, computer science, logic, mathematics, statistics,
education.

Software Exhibitions Chair
--------------------------

Thomas Bayer  (Technical University Munich, Germany)



We apologize for muliple copies.
=====================================================================
Please send all the comments to the appropriate contact:
issac2004@risc.uni-linz.ac.at

\start
Date: 20 Apr 2004 16:57:16 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
Cc: Michael Koehne, Yoriaki Fujimori

Greetings!  

Tim Daly writes:

> Michael,
> 
> Also new in this version you'll find the current book.dvi in
> mnt/linux/doc/book.dvi
> 

This is great!!  Congratulations!  At some point we might even be able
to get color postscript :-).

I'm getting ready to put out another Debian package.  There are a few
very minor outstanding issues:

1) All non-elf/non-script files in mnt/linux must not be executable
   according to Debian policy.  I have an ever-shrinking list which I
   chmod -x explicitly at present.

2) Hardlinks notangle.1 nountangle.1 must be symlinks according to
   Debian policy. 

3) I'm adding the Rosetta .tex file and its corresponding .dvi per a
   user request.

4) I'm adding the axiom tutorial found elsewhere on the web to satisfy
   a user request. 

5) There are a variety of files which have standard places on a Debian
   system which have yet to be moved there and linked to their
   location in the axiom tree under /usr/lib.  E.g. docs go under
   /usr/share/doc, manpages under /usr/share/man

6) I'd like to include the output of dvipdfm on the book.dvi.  I'm
   also wondering if the documentation can be readily converted into
   info and/or html format by existing tools.

7) As earlier stated, this next package will have an AXIOMsys symlink
   in /usr/bin.

\start
Date: Tue, 20 Apr 2004 18:29:57 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
Cc: Yoriaki Fujimori, Mickael Koehne

Camm,

> This is great!!  Congratulations!  At some point we might even be able
> to get color postscript :-).
> 
> I'm getting ready to put out another Debian package.  There are a few
> very minor outstanding issues:
> 
> 1) All non-elf/non-script files in mnt/linux must not be executable
>    according to Debian policy.  I have an ever-shrinking list which I
>    chmod -x explicitly at present.

which files?

> 
> 2) Hardlinks notangle.1 nountangle.1 must be symlinks according to
>    Debian policy. 

ok. i'll change this.

> 
> 3) I'm adding the Rosetta .tex file and its corresponding .dvi per a
>    user request.

i'll add it to the makefile.

> 
> 4) I'm adding the axiom tutorial found elsewhere on the web to satisfy
>    a user request. 

which one? i'll add it to the distrib.

> 
> 5) There are a variety of files which have standard places on a Debian
>    system which have yet to be moved there and linked to their
>    location in the axiom tree under /usr/lib.  E.g. docs go under
>    /usr/share/doc, manpages under /usr/share/man

if you can be precise about these perhaps i can write a 
configure --prefix, etc. i failed writing the configure 
files a couple weeks ago but i'll have another go at it.

> 
> 6) I'd like to include the output of dvipdfm on the book.dvi.  I'm
>    also wondering if the documentation can be readily converted into
>    info and/or html format by existing tools.

that's fine. i haven't figured out a reliable, portable way to get
the pdf, ps, etc. i suppose if i learned to write a configure file
i could look for dvi2ps, etc. 

> 
> 7) As earlier stated, this next package will have an AXIOMsys symlink
>    in /usr/bin.
> 

that's also fine.

\start
Date: Wed, 21 Apr 2004 01:53:44 +0200
From: Michel Lavaud
To: Camm Maguire
Subject: re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]

Hello,

> > Also new in this version you'll find the current book.dvi in
> > mnt/linux/doc/book.dvi
> 
> This is great!!  Congratulations!  At some point we might even be able to
> get color postscript :-).

I suppose you mean just "get color" ? Why "get color postscript" ?
 
> 6) I'd like to include the output of dvipdfm on the book.dvi.  I'm
>    also wondering if the documentation can be readily converted into
>    info and/or html format by existing tools.

into info, probably no, because the latex to texinfo converter is table 
driven, so as soon as you use a personal command or a command defined in 
a latex package, it is ignored (unless you add a translation in the 
table)

into html, probably yes, provided one uses TeX4ht, because it is  not 
table driven (contrary to all other tex to html converters) but uses TeX 
itself as preprocessor, so that, in theory, personal definitions and 
definitions of LaTeX packages are automatically understood (in practice 
some tuning may be necessary)

Best wishes,
Michel

\start
Date: Tue, 20 Apr 2004 22:58:40 -0400
From: Tim Daly
To: Camm Maguire
Subject: requested change

> > 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: Tue, 20 Apr 2004 23:58:22 -0400
From: Tim Daly
To: Camm Maguire
Subject: Rosetta.tex

Camm,

> > 3) I'm adding the Rosetta .tex file and its corresponding .dvi per a
> >    user request.
> 
> i'll add it to the makefile.

I've moved src/booklets/Rosetta.tex to src/doc/Rosetta.pamphlet
I've modified the src/doc/Makefile.pamphlet to include a new stanza
Rosetta.dvi will be built in mnt/linux/doc

As an aside, this would be an excellent file to use as a prototype
on the axiom wiki site once it comes online. It is small but presents
a few challenges (like arrays). It allows people with knowledge of
two systems or unfamiliar systems to contribute. It will make a 
low impact file for building and testing machinery to feed wiki
changes back into the distribution.


\start
Date: Thu, 22 Apr 2004 08:52:17 +0200
From: David Mentre
To: Camm Maguire
Subject: re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
Cc: Yoriaki Fujimori, Michael Koehne

Hello Camm,

Camm Maguire writes:

> 6) I'd like to include the output of dvipdfm on the book.dvi.  I'm
>    also wondering if the documentation can be readily converted into
>    info and/or html format by existing tools.

noweb is capable of producing html output, using -html switch. However,
I don't know how to handle graphics. Probably more simple to convert the
raw .tex file into html using Hevea or latex2html.

\start
Date: Thu, 22 Apr 2004 14:01:13 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: LatexWiki for free open source AXIOM computer algebra system

Bob,

Here is a slightly more convenient link

  http://page.axiom-developer.org

> > 
> > (LatexWiki works inside Plone too. Great!)
> 
> Neat!  I had not tested with plone for the 0.29 release, I 
> had planned to do some more extensive Plone testing for 0.30 
> or 0.31, but I'd appreciate any plone contributions you may 
> have.  It looks like fonts in plone need some work to make 
> math the same size.  Are you using Plone 2?

Yes, I am using Plone 2 and the latest Zwiki-0.30 from darc.

> 
> When I was playing with it, I created a file ploneCustom.css 
> in the plone root directory containing the following::
> 
>     img.equation { vertical-align: middle }
>     .latexwiki { font-family: "serif"; font-size: 16px; 
> background-color: white }
> 
> Comparing to the stylesheet.css currently distributed with 
> latexwiki, I think it should be::
> 
>     img.equation { vertical-align: middle; border: 0px }
>     .latexwiki { 
>       font-family: <dtml-var latexwiki_font missing="'Times 
> New Roman', 'Adobe Serif MM', 
>         'Nimbus Roman No9 L', 'Luxi Serif', 'Bitstream 
> Serif', serif">;
>       <dtml-let 
> fontadj="_.int(REQUEST.get('latexwiki_fontadjust',0))" 
>                 fontsize="latex_font_size">
>       font-size: <dtml-var expr="fontsize+fontadj">px;
>       </dtml-let>
>     }
>     .latexwiki input, .latexwiki select {
>       font-family: 'Nimbus Sans L', sans-serif;
>       font-size: 12px;
>     }
>     .latexwiki code,
>     .latexwiki pre {
>       font-family: 'Nimbus Mono L', monospace;
>       font-size: <dtml-var expr="latex_font_size" missing="17">px;
>     }
> 
> if you get this working, please send me your ploneCustom.css.

I added your suggested ploneCustom.css to the Plone root.
Looks quite ok to me. Does it look better to you?

I still get a grey/blue background for the LaTeX generated
graphics. (I am using MS Explorer 6.0 -- perhaps a cause of
some differences?)

> ...
> > I have a temporary patch that makes it work, and I will be
> > looking at a better long term solution. The problem appears
> > to be the way that Zope Monster handles the url rewrite for
> > the proxy ...
> 
> Yes, I use fastcgi and apache.  The relevant parts of my 
> httpd.conf are::
> ... 
> this took some time to get working...  Note that zope handles 
> the authentication and the files /etc/apache/passwd and 
> /usr/lib/cgi-bin/Zope don't seem to exist...
>

Ah. I used to run Plone like that when I first installed it.
That would explain why you may not have noticed any problems
with the way LatexWiki generates urls for the images.

I found "fastcgi" it a bit inefficient. In the quest for more
speed and flexibility I switched to the newer proxy method.
There are now some good docs for this on the Zope site - but
there are also too many out-of-date alternatives lying around.

> 
> LatexWiki creates PNG's with a proper alpha-channel, so all 
> you need do is modify the background of the HTML.

In the LatexWiki code I see that you use the Ghostscript
pnggray device. I am running Ghostscript 7.x on RedHat 9.
As far as I know pnggray does not generate "alpha-channel"
transparent graphics. To do that you need the GS pngalpha
device, no?

> i.e. in your stylesheet.css change::
> 
>     img.equation { vertical-align: middle; border: 0px; 
> background-color: #ffcccc; }
>

I will try this.
 
> My goal thus far has been to make the math as seamless as 
> possible, not make it stand out.  ;)
> 
> ... 
> I am also very interested in Axiom, so I'm excited to see you 
> using LatexWiki!  I use Maple heavily and have decided that 
> for my next project I was going to use Maxima, and in general 
> start using and contributing to it (and texmacs).  I wasn't 
> familiar with Axiom until I noticed what you were doing.  Any 
> words on the strengths/weaknesses of Axiom vs.  Maxima?  Any 
> references on this?
> 

I also use Maple heavily and am active in Maple beta testing
for the new release. I have'nt used Maxima much myself. The
best place to ask about Axiom vs. Maxima would be on the axiom
user's list.

  Axiom-mail@nongnu.org

Perhaps Tim Daly will be able to add something when he gets
a few spare moments.

\start
Date: 22 Apr 2004 14:40:55 -0400
From: Camm Maguire
To: David Mentre
Subject: re: 404 http://axiom.tenkan.org/axiom.20040321.tgz]
Cc: Michael Koehne, Yoriaki Fujimori

Greetings!

Along these lines, I'd just like to note that the 01/30 axiom snapshot
has just entered Debian testing.  Had to hand compile on alpha to get
around a libc6.1 bug which apparently will not be fixed soon.

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.

Take care,

David Mentre writes:

> Hello Camm,
> 
> Camm Maguire writes:
> 
> > 6) I'd like to include the output of dvipdfm on the book.dvi.  I'm
> >    also wondering if the documentation can be readily converted into
> >    info and/or html format by existing tools.
> 
> noweb is capable of producing html output, using -html switch. However,
> I don't know how to handle graphics. Probably more simple to convert the
> raw .tex file into html using Hevea or latex2html.

\start
Date: Thu, 22 Apr 2004 19:40:03 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: LatexWiki for free open source AXIOM computer algebra system

Bill Page [Bill Page] wrote:
> I still get a grey/blue background for the LaTeX generated
> graphics. (I am using MS Explorer 6.0 -- perhaps a cause of
> some differences?)

MS IE does not properly implement alpha-channel PNG's except on mac.
This is a well-known IE bug (google for 'IE alpha channel PNG' --
there's a petition out there somewhere).  I don't use any MS software so
I cannot verify or fix this mis-feature in their browser.  If you can
provide a fix I'd accept it...

Mozilla works great, is free, and supports MathML.  LatexWiki will get
MathML in the near future...  I've been thinking about using some XSLT
to let the browser transform the page to either images or MathML
depending on its capabilities.  Something similar might be possible to
select PNG/GIF for IE.  XSLT is a complicated, difficult beast though.

> In the LatexWiki code I see that you use the Ghostscript
> pnggray device. I am running Ghostscript 7.x on RedHat 9.
> As far as I know pnggray does not generate "alpha-channel"
> transparent graphics. To do that you need the GS pngalpha
> device, no?

The GS pnggray is not alpha-channeled but PIL then generates an alpha
channel.  (look for 'alpha' in latexWrapper.py)

> > i.e. in your stylesheet.css change::
> > 
> >     img.equation { vertical-align: middle; border: 0px; 
> > background-color: #ffcccc; }
> >
> 
> I will try this.

This will not fix the IE bug.  (But if you can make it white this way
let me know, it would be an easy fix for IE!)

> I also use Maple heavily and am active in Maple beta testing
> for the new release. I have'nt used Maxima much myself. The
> best place to ask about Axiom vs. Maxima would be on the axiom
> user's list.
>
>   Axiom-mail@nongnu.org
> 
> Perhaps Tim Daly will be able to add something when he gets
> a few spare moments.

I will do that, thanks!  This week I'm at a conference looking for new
projects, so I'll think about how I can explore a new symbolic algebra
package at the same time.  :)

I like the idea of texmacs, the maple interface just plain sucks.  I
hope they're working on that...I don't even use the new java one because
it's terrible.  I use the old Motif one...

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

\start
Date: Thu, 22 Apr 2004 23:54:26 -0400
From: Tim Daly
To: Bob McElrath
Subject: Axiom
Cc: Bill Page

Bob,

I'm Tim Daly from Axiom. We appreciate the help you gave Bill on the wiki.
I just played with it a bit and I'm quite excited at the potential.

If you're used to Maple or MMA you'll find Axiom somewhat different.
The easiest way to get a flavor for Axiom is to look at the first
few pre-chapters in the Axiom book. The book can be found online at

http://www.linux-france.org/~dmentre/tmp/book.pdf

It isn't complete but for your purposes it should be all you need.
Let me know if you have specific questions and I'll try to help.

\start
Date: Thu, 22 Apr 2004 23:56:22 -0400
From: Tim Daly
To: Bill Page
Subject: Axiom wiki

Bill,

I just tried the wiki page with the E=mc^2 equation. This is great.
If you can give me some direction about how I can contribute and
how you'd like to structure the wiki pages I'll do what I can to help.

Great job.

\start
Date: Sat, 24 Apr 2004 12:45:41 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Axiom wiki
Cc: Camm Maguire

Bill,

I'm reading the source to mod_lisp which is the apache module that handles
an external lisp. It seems to me that we should be able to bolt Axiom
indirectly to Apache. That way the wiki could pass expression requests
to Axiom and get the results which would be a live link.

If we get lucky or particularly clever there might be a way to associate
Axiom's workspace identifier with different users. That way multiple
people could use the same Axiom without side-effects.

Anyway, it should be possible to bolt GCL to mod_lisp and I'm trying to
do that now. If I get that to go I'll try the same thing with Axiom.
If and when that works we can try to make a live page.

I'll let you know of any successes.

\start
Date: Sat, 24 Apr 2004 16:13:59 -0400
From: Tim Daly
To: Dylan Thurston
Subject: Re: Axiom wiki
Cc: Camm Maguire, Bill Page

> > Anyway, it should be possible to bolt GCL to mod_lisp and I'm trying to
> > do that now. If I get that to go I'll try the same thing with Axiom.
> > If and when that works we can try to make a live page.
> 
> Please be careful of security when you do such a thing.  It would be
> very easy to allow a web user to execute an arbitrary command.

great idea. let the world do the sysadmin tasks :-)
'tis a good point though, which I wasn't considering. 
thanks.

\start
Date: Sun, 25 Apr 2004 00:46:28 -0400
From: Tim Daly
To: Camm Maguire
Subject: gcl sockets

Camm,

I'm having a bit of trouble with sockets in GCL.
I can do:

(in-package "SYSTEM")
(setq sock (open-named-socket 0))
(setq conn (accept-socket-connection sock))
(setq a 
 (make-array 400 :element-type 'standard-char :fill-pointer 0 :static t))

but when I do:

(setq num (our-read-with-offset (caar conn) a 0 5 3000))

lisp waits for the read to complete and then exits.
The function OUR-READ-WITH-OFFSET is given to lisp in o/new_init.c
It references fSour_read_with_offset which seems to be undefined.

What am I doing wrong?

\start
Date: 25 Apr 2004 01:42:05 -1000
From: Chris Hall
To: list
Subject: Re: gcl sockets

Tim Daly writes:
> The function OUR-READ-WITH-OFFSET is given to lisp in o/new_init.c
> It references fSour_read_with_offset which seems to be undefined.

According to my copy of 2.6.1, line 326 in o/sockets.c.

\start
Date: Sun, 25 Apr 2004 11:11:19 -0400
From: Tim Daly
To: Chris Hall
Subject: re: gcl sockets

indeed, you're correct. i don't know how i missed it. thanks. -- t

\start
Date: Sun, 25 Apr 2004 12:03:13 -0400
From: Tim Daly
To: Camm Maguire
Subject: puzzled....

in o/object.h (line 350) there is the struct:

struct ustring{ 
  ....
  unsigned char *ust_self;
  ....

this appears to be the definition of ust_self, a pointer to a char *array



in gcl-tk/sheader.h (line 109) OBJ_TO_CONNECTION_STATE(x) is defined as
  
#define OBJ_TO_CONNECTION_STATE(x) \
  ((struct connection_state *)(void *)((x)->ust.ust_self))

so it appears that OBJ_TO_CONNECTION_STATE accepts a thing of type
ustring and casts the (char *)array to a (connection_state *)array


yet in sockets.c (line 330) the macro is used with an argument:
 .... (OBJ_TO_CONNECTION_STATE(fd) .....
where "fd" has been used to indicate the "file descriptor" which
is a fixnum.

Further the buffer it tries to write into needs to be of type ustring.

I have 2 questions:
  (a) should sockets.c line 330 read:
       ... (OBJ_TO_CONNECTION_STATE(sfd) ...
       (which means that the argument to the function must change)
  
  (b) how does one allocate a ustring?

\start
Date: 26 Apr 2004 01:41:38 -1000
From: Chris Hall
To: list
Subject: Re: puzzled....

Tim Daly writes:

> in o/object.h (line 350) there is the struct:
> 
> struct ustring{ 
>   ....
>   unsigned char *ust_self;
>   ....
> 

Just above it (line 336) is 'struct string' - the only difference I
can see between the two structs' members type-wise is the definition
of the char pointer.

My C is pretty rusty, but I guess it is pretty safe to bet that the
pointer size for these types *ought* to be the same on all
compilers/platforms, so that sizeof(struct ustring/string) *ought* to
be the same - though one can never be absolutely 100% sure of this,
IIRC. ;-)

> this appears to be the definition of ust_self, a pointer to a char *array
> 
> 
> 
> in gcl-tk/sheader.h (line 109) OBJ_TO_CONNECTION_STATE(x) is defined as
>   
> #define OBJ_TO_CONNECTION_STATE(x) \
>   ((struct connection_state *)(void *)((x)->ust.ust_self))
> 
> so it appears that OBJ_TO_CONNECTION_STATE accepts a thing of type
> ustring and casts the (char *)array to a (connection_state *)array
> 
> 
> yet in sockets.c (line 330) the macro is used with an argument:
>  .... (OBJ_TO_CONNECTION_STATE(fd) .....
> where "fd" has been used to indicate the "file descriptor" which
> is a fixnum.

DEFUN_NEW("OUR-READ-WITH-OFFSET",object,fSour_read_with_offset,SI,5,5,NONE,
OO,OI,II,OO,(object fd,object buffer,fixnum offset,fixnum
             ^^^^^^^^^

As a guess, since it isn't a fixnum, given the context it might very
well be meant as an 'sfd'/connection_state (see below)?

> 
> Further the buffer it tries to write into needs to be of type ustring.
> 
> I have 2 questions:
>   (a) should sockets.c line 330 read:
>        ... (OBJ_TO_CONNECTION_STATE(sfd) ...
>        (which means that the argument to the function must change)
>   
>   (b) how does one allocate a ustring?

Based on my guesses above, I would guess further that
'alloc_simple_string(int l)' found in o/string.d at line 37 - and
which seems to alloc a struct, actually ;-) - is what is being used:
the st_dim member is set to l, and st_self set to the address of the
actual string, storage for which seems to have been allocated
elsewhere.

As for 'sfd', from what I can see it would seem that it is used to
refer to the connection_state struct itself, here and elsewhere - one
of the reasons I looked into this is because I, too, was curious about
this usage.

(I suspect that t_string is part of an enum somewhere, but I haven't
yet located where t_string is defined.  If someone knows, please
share?)


(DISCLAIMER: the following is more general and usage-related.)

In ACCEPT-SOCKET-CONNECTION (in o/sockets.c line 210) a string struct
for sizeof(connection_state) is allocated and set to (a pointer to)
the contents of setup_connection_state(fd) (in gcl-tk/comm.c line 69).

connection_state is a struct (in gcl-tk/sheader.h line 86) that
contains the fd for the socket, a pointer to a char buffer or two,
transmission byte counts, etc.

Oh ho!  So that bizarre looking the string in the car of the result
from ACCEPT-SOCKET-CONNECTION is the *connection_state/sfd*.

Here is a transcript of using some of this:

--------------- snip --------------------
>(setf skt (si::open-named-socket 0))
(3 . 5000)

>(setf skt-conn (si::accept-socket-connection skt))
(("

3 . 5000)

>(si:connection-state-fd (car (car skt-conn)))
4
--------------- /snip -------------------
Ummm, could anybody explain to me why the fd's are different in the
previous example?

It seems that I can only open a socket on the localhost (I know that
SI::SOCKET eems to work with another host)?

Can anyone tell me if the following sequence is the correct procedure
to follow when I am done with a socket connection?
--------------- snip --------------------
>(si:close-sd (car (car skt-conn)))
NIL

>(si::close-fd (car (cdr skt-conn)))
T
--------------- /snip -------------------

If I do this, it *does* seem to solve the 'CLOS_WAIT/FINL_WAIT'
problem I described in an earlier post.



\start
Date: Mon, 26 Apr 2004 09:39:11 -0400
From: Cliff Yapp
To: list
Subject: gentoo problem apparently gone

Just did an upgrade of gcc and glibc (among other things) and the
compile problem has vanished.  So odds are it was system weirdness
after all.


\start
Date: 28 Apr 2004 18:34:23 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] gcl sockets

Greetings!

Let me state first that I have yet to acquire much experience with
GCL's socket code, but I am interested in doing so and in ensuring
that the interface is robust and easy to use.  I do have experience in
this area in C.

In any case, a quick look through your example indicates that these
functions expect magic header bytes at the beginning of each exchange,
i.e. as when our-write is feeding data to our-read-with-offset.  The
relevant functions triggering your abort are in gcl-tk/comm.c

Needless to say, this should not be required.  There may be more
general interface functions elsewhere in the code -- I'll try to give
a more thorough look soon.  Suggestions/other experience most welcome.

Take care,

Tim Daly writes:

> Camm,
> 
> I'm having a bit of trouble with sockets in GCL.
> I can do:
> 
> (in-package "SYSTEM")
> (setq sock (open-named-socket 0))
> (setq conn (accept-socket-connection sock))
> (setq a 
>  (make-array 400 :element-type 'standard-char :fill-pointer 0 :static t))
> 
> but when I do:
> 
> (setq num (our-read-with-offset (caar conn) a 0 5 3000))
> 
> lisp waits for the read to complete and then exits.
> The function OUR-READ-WITH-OFFSET is given to lisp in o/new_init.c
> It references fSour_read_with_offset which seems to be undefined.
> 
> What am I doing wrong?

\start
Date: 28 Apr 2004 18:56:50 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] puzzled....

Greetings!

Tim Daly writes:

> in o/object.h (line 350) there is the struct:
> 
> struct ustring{ 
>   ....
>   unsigned char *ust_self;
>   ....
> 
> this appears to be the definition of ust_self, a pointer to a char *array
> 
> 
> 
> in gcl-tk/sheader.h (line 109) OBJ_TO_CONNECTION_STATE(x) is defined as
>   
> #define OBJ_TO_CONNECTION_STATE(x) \
>   ((struct connection_state *)(void *)((x)->ust.ust_self))
> 
> so it appears that OBJ_TO_CONNECTION_STATE accepts a thing of type
> ustring and casts the (char *)array to a (connection_state *)array
> 
> 
> yet in sockets.c (line 330) the macro is used with an argument:
>  .... (OBJ_TO_CONNECTION_STATE(fd) .....
> where "fd" has been used to indicate the "file descriptor" which
> is a fixnum.
> 
> Further the buffer it tries to write into needs to be of type ustring.
> 
> I have 2 questions:
>   (a) should sockets.c line 330 read:
>        ... (OBJ_TO_CONNECTION_STATE(sfd) ...
>        (which means that the argument to the function must change)
>   

I don't think so.  If you look at the arguments to
OUR-READ-WITH-OFFSET, fd is a lisp object, as poor as variable name
choice as that is.  A 'file descriptor' would be of type fixnum.

>   (b) how does one allocate a ustring?

Your original make-array will do.  If you notice GCL's object layout,
compatible _self pointer elements are aligned in the same position in
the various structs, so that in indirecting the lisp union, one can
use st_self, ust_self, v_self, etc.

Also forgot to answer your question put in the other email --
fSour_read_with_offset is created by the expansion of the DEFUN_NEW C
macro.  If one runs cpp -I../h -I../gcl-tk on sockets.c, you'll see
the definition.  Basically one gets a generic lisp interface, and a
raw C interface which can be used directly in 'fast-linking'.

BTW, your first example call to our-read-with-offset appeared to be
correct at least regarding the caar, as the 'connection state' is 48
bytes long and is passed around in lisp as a string of the same
length, which is correctly passed into fSour_read_with_offset in your
example.

We have to figure out what the 'magic' is all about.

I'll try to drum up a simple socket example if I can find a moment.
I'm wondering right now if what we have was designed purely for
gcl-tk. 

\start
Date: Wed, 28 Apr 2004 19:05:05 -0400
From: Bill Page
To: Tim Daly
Subject: RE: [Gcl-devel] puzzled....
Cc: Camm Maguire

Tim,

Doesn't Axiom include it's own socket code linked
into GCL? Perhaps you can get what you need via
Axiom?

Cheers,
Bill Page.

> -----Original Message-----
> Subject: Re: [Gcl-devel] puzzled....
> 
> Greetings!
> 
> ...
> 
> We have to figure out what the 'magic' is all about.
> 
> I'll try to drum up a simple socket example if I can find a moment.
> I'm wondering right now if what we have was designed purely for
> gcl-tk. 

\start
Date: 28 Apr 2004 21:58:03 -0400
From: Camm Maguire
To: Chris Hall
Subject: Re: [Gcl-devel] GCL Socket questions

Greetings!

OK here is a start:

1) Install netcat
2) in a shell, do nc -l -p 1920
3) In gcl osmehwere else, (setq s (si::socket 1920 :host "localhost"))
4) (format s "hello%") ; should appear in netcat window
5)  Type "there <cr>" in netcat window
6) In gcl (read-line s) ; (should get "there")
7) In gcl (close s) ; should terminate netcat.

Take care,

Chris Hall writes:

> I'm using GCL 2.6.1 and Emacs 21.2.1 on Debian Woody w/2.2.25 kernel.
> 
> I'd really, really like to be able to use sockets in GCL, so I have
> been trying things and 'using the source'.
> 
> First of all, it appears that there are two (at least) existing
> approaches to sockets in GCL:
> 
>   * SI::OPEN-NAMED-SOCKET, then SI::ACCEPT-SOCKET-CONNECTION using
>     the cons returned by OPEN-NAMED-SOCKET
> 
>   * SI::SOCKET, which returns a two-way stream (woot!), and may also
>     be passed a 'server function' (woot-woot!) or may be used as a
>     client to connect another process/host.
> 
> SI::SOCKET looks perfect for most of what I'd like to do in the short
> term, while SI::OPEN-NAMED-SOCKET looks good for lower-level stuff.  I
> was busy figuring out what to do with the cons it returned - looking
> 'fd-level' functions that might work - when I saw the earlier post
> about "OUR-WRITE", thats when I started seriously looking into
> SI::SOCKET.
> 
> FTR, I have problems getting the fd (the car of the cons returned by
> OPEN-NAMED-SOCKET) to close properly when running in an inferior lisp
> in Emacs.  SI::CLOSE-FD works at least in part, but netstat then shows
> the port in a FINL-WAIT or CLOS-WAIT or some such - have to exit GCL
> for the port to completely go away.
> 
> 
> >From an xterm, or from an inferior lisp in Emacs,
> ------------ snip -------------
> 
> >(setf skt (si::socket 4100 :host "localhost"))
> couldn't open socket:
> 
> ------------ /snip ------------
> 
> and the process goes away.  In the xterm, we're back at the prompt.
> 
> The error message seems to originate from CreateSocket, defined in
> o/nsocket.c and invoked from o/file.d 'socket' function, if anybody is
> interested.
> 
> A not-so-minor-in-my-book nit: if I am reading CreateSocket right, the
> "couldn't open socket:" message is returned both for a bind error
> _and_ an address error, and tells us nothing about either.
> 
> 
> However,
> ------------ snip -------------
> 
>  >(setf skt (si::socket 4100 :host "localhost" :async t))
> #<two-way stream 08830ee8>
> 
> >(read-line skt)
> ""
> T
> 
> ------------ /snip -------------
> 
> _seems_ to work OK.
> 
> Anyway, once one *does* get a nice two-way, string-char element stream
> wrapped around a socket, what can one do?
> 
> STREAMP returns T on the stream, and STREAM-ELEMENT-TYPE indicates
> STRING-CHAR.
> 
> I can connect to the port from telnet, and type, then try to do a
> READ-LINE - in an inferior lisp, READ-LINE immediately returns an
> empty string and NIL, whether or not telnet has sent anything; from
> the xterm, it hangs until Ctrl-C'd.
> 
> 
> If I try to FORMAT, WRITE-LINE etc.:
> 
> ------------ snip -------------
> 
> >(format skt "Heloo, Chris!~%")
> Error in FORMAT [or a callee]: error writing to socket: errno= 32
> 
> ------------ /snip -------------
> 
> A little research seems to indicate errno 32 = EPIPE = broken pipe.
> 
> 
> The inferior lisp process is still usable, but trying to CLOSE the
> stream after a write gives us:
> 
> ------------ snip -------------
> 
> >(close skt)
> tried Clsing -1 ! as scoket 
> 
> T
> ------------ /snip -------------
> 
> This happens from the xterm as well.
> 
> 
> I can't seem to get my own little server function working either:
> (I am assuming here that the server function passed in is meant to
> accept one argument - the stream?)
> 
> ------------ snip -------------
> 
> >(symbol-function 'soksrv)
> (LAMBDA-BLOCK SOKSRV (STRM) (FORMAT STRM (READ-LINE STRM)))
> 
> >(setf skt (si::socket 4100 :server (symbol-function 'soksrv)))
> #<two-way stream 08832000>
> 
> ------------ /snip -------------
> 
> and then telnetting in and typing, or using WRITE-LINE followed by
> FINISH-OUTPUT doesn't seem to do anything either.
> 
> Any thoughts, suggestions, ideas will be welcome.

\start
Date: Thu, 29 Apr 2004 07:41:54 -0400
From: Tim Daly
To: Camm Maguire
Subject: re: [Gcl-devel] gcl sockets

Camm,

I'm sure the GCL socket code works for tcl/tk but I'm unable to get
it working. The hard part about it is that when it fails it takes
down the whole image (a C code problem rather than a Lisp problem).
Since I link Axiom's socket code into the first GCL image I build
I'm going to use that image instead and try our socket code. 
If that works I'll write it up in some more general fashion.

I'm trying to get GCL to work with Apache mod_lisp. There are other
issues to solve also (e.g. do you run one lisp image that everyone
uses (what about side-effects)) or do you start a new image for
every request (how to maintain session continuity?). Axiom supports
namespaces so each user can have their own workspace without affecting
others.

\start
Date: Thu, 29 Apr 2004 07:34:47 -0400
From: Tim Daly
To: Bill Page
Subject: re: [Gcl-devel] puzzled....

Bill,

Yes, Axiom does include socket code. I was going to use the GCL
version but I'm unable to keep it from crashing. I'll switch
over to using the Axiom version this weekend. (We are hosting
a conference tomorrow and I'm kinda lagged).

\start
Date: Thu, 29 Apr 2004 07:32:28 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [Axiom-mail] Axiom portal and mathematical wiki comments

Bill, 

Good job. I'll look at it this evening. 

I'm working to connect Axiom to Apache so we can execute commands
directly in a webpage and get the output (especially good since
Axiom generates TeX). Once I get that to work we can figure out
how to connect it to your wiki pages.

Once we get pages that can be edited and a way to execute Axiom
expressions with results that can be embedded, the next step seems
to be connecting the pages back to the Axiom distribution.

I'd like make possible a two-way exchange. Literate programs that
exist in the Axiom distribution can be displayed and updated in 
your wiki. Wiki pages can be folded back into the Axiom distribution.

If we get the two-way exchange to work then we can put the whole Axiom
book online and people can expand it at will.

Tim

=====================================================================
Bill page wrote:

> Axiom Users;
> 
> I am looking for people willing to experiment with the experimental Axiom
> portal and Wiki (interactive web page) at:
> 
>  http://page.axiom-developer.org
> 
> Please feel free to drop by, take a look, try things out, and register to
> get online access. One thing that is neat about this the wiki at this site
> is that it allows you to enter mathematics on a web page simply by keying
> ordinary LaTeX commands directly over the web.
> 
> What we do in the future with this will depend on feedback and comments from
> you. Possibilities even include providing a simple online web interface to
> Axiom.
> 
>   (:Think Big :)
> 
> Regards,
> Bill Page.

\start
Date: Thu, 29 Apr 2004 21:16:06 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: re: [Gcl-devel] gcl sockets

On Thu, 29 Apr 2004, root wrote:

Dear Tim,

your plan pluging AXIOM into apache is very ambitious, however, wouldn't a
small perl skrip be a sufficient first step? Indeed a CGI something cannot
handle multiple command in several HTML pages, but one can submit (using a
form) a rather complex multiline command to AXIOM. Including possibly
system commands however. Do you think that a normal web server has the
potential to handle a possibly computational intence AXIOM task too?

\start
Date: Thu, 29 Apr 2004 18:45:21 -0400
From: Tim Daly
To: Bertfried Fauser
Subject: re: [Gcl-devel] gcl sockets

B,

You raise several issues in the same paragraph. Lets see if I can
answer them separately.

(1) your planned AXIOM plugin into apache is very ambitious, however, 
    wouldn't a small perl script be a sufficient first step? 

I've read the mod_lisp.c code. It isn't very complex as these things go.
It simply talks to a lisp process running elsewhere thru sockets. 
So I have to:

(a) get a lisp running that talks to sockets
(b) write an Axiom domain to talk to the server

Sockets are how Axiom talks to it's graphics process and I'm in the process
of recovering the graphics so it's pretty much the same problem. The first
step is to execute an S-expression over a socket which is what I'm working
on at the moment.


(2) ..........  Indeed a CGI something cannot
 handle multiple command in several HTML pages, but one can submit (using a
 form) a rather complex multiline command to AXIOM. 

Initially it is planned to handle single commands. However I don't see
any big problems to handle multiple commands. I can use the session
identifier as the name of an Axiom namespace so that multiple users
don't affect each other's results.


(3) ............ Including possibly  system commands however. 

Dylan mentioned this. The Axiom domain will filter commands to disallow
things that use system commands. 


(4) ....... Do you think that a normal web server has the
 potential to handle a possibly computational intense AXIOM task too?

In general I expect the web server to be barely registering in terms
of process time. I can't imagine tens of thousands of people trying
to do anything on the server at the same time. Since Axiom is running
in a different process (or possibly on a different machine) the web
server should be unaffected.

As for long computational tasks:

(a) initially I expect Axiom will only be running on one processor and
    used to develop documentation thru Page's wiki server.

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

(c) If Axiom reaches THAT level of interest perhaps somebody might be
    interested in funding it :-)

\start
Date: Thu, 29 Apr 2004 21:48:28 -0400
From: Bill Page
To: Tim Daly
Subject: re: [Gcl-devel] gcl sockets
Cc: Bertfried Fauser

Tim,

On Thursday, April 29, 2004 6:45 PM you wrote:
> ...
> Bertfried Fauser wrote:
> > (1) your planned AXIOM plugin into apache is very ambitious,
> > however, wouldn't a small perl script be a sufficient first
> > step? 
> 
> I've read the mod_lisp.c code. It isn't very complex as
> these things go. It simply talks to a lisp process running 
> elsewhere thru sockets.

In the Zope application environment in which the portal and
Wiki runs everything (nearly everything) is a Python script
including the integrated web server itself. Modifying the
existing LatexWiki code to include calls to Axiom will
involve modifying and extending existing Python code which
already calls external processes like LaTeX and Ghostscript.
If we were to follow Bertfried's suggestion of simple
"first step", then Axiom could be called as just one more
external process in this chain. However I like Tim's approach
before for several reasons explain (I hope) below.
 
> ... 
> (2) Indeed a CGI something cannot handle multiple command
> in several HTML pages, but one can submit (using a form)
> a rather complex multiline command to AXIOM. 

>From the point of view of the browser interface, this is
exactly how Zope work, via form actions and urls that
trigger actions on the server. Zope also maintains the
session information for a user and keeps track of persistent
properties associated with "objects". An object can be
something as simple as a static web page, a downloadable
file, a folder containing other objects or even something
more dynamic like a wiki page.

> 
> Initially it is planned to handle single commands. However
> I don't see any big problems to handle multiple commands.
> I can use the session identifier as the name of an Axiom
> namespace so that multiple users don't affect each other's
> results.

Yes, this is possible but in the wiki environment I think
it is more natural to associate an Axiom session with a
wiki page rather than with each user. A wiki is not really
a multi-user environment in the conventional sense. Instead
it is a shared workspace collaboration environment.

Of course people could have private wiki pages containing
their initial draft calculations and later share that
perhaps selectively with their co-workers allowing them
also to make changes and then eventual make it "public"
but read-only for the majority of users.

> ...
> 
> (4) Do you think that a normal web server has the potential
> to handle a possibly computational intense AXIOM task too?
> 
> In general I expect the web server to be barely registering 
> in terms of process time. I can't imagine tens of thousands 
> of people trying to do anything on the server at the same 
> time. Since Axiom is running in a different process (or 
> possibly on a different machine) the web server should be
> unaffected.

I agree that numbers of active Axiom Wiki pages (remember that
pages can be quite large - perhaps whole "chapters") in the
100's I think this approach is quite feasible.

> 
> As for long computational tasks:
> 
> (a) initially I expect Axiom will only be running on one
> processor and used to develop documentation thru Page's
> wiki server.

Yes!

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

That should be fun ...

\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
