diff --git a/book/2004-04.txt b/book/2004-04.txt new file mode 100644 index 0000000..e57314b --- /dev/null +++ b/book/2004-04.txt @@ -0,0 +1,5272 @@ +\start +Date: Thu, 1 Apr 2004 11:37:09 +0200 (CEST) +From: Bertfried Fauser +To: root +Subject: [Axiom-developer] 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: root +Subject: [Axiom-developer] 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: root +To: Bertfried.Fauser@uni-konstanz.de +Subject: [Axiom-developer] 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: root +To: Bertfried.Fauser@uni-konstanz.de +Subject: [Axiom-developer] 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: daly@idsi.net +Subject: Re: [Axiom-developer] Re: Clifford algebras in AXIOM +Cc: Bertfried.Fauser@uni-konstanz.de + +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, + +root 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: root +To: camm@enhanced.com +Subject: Re: [Axiom-developer] Re: Clifford algebras in AXIOM +Cc: Bertfried.Fauser@uni-konstanz.de + +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: C Y +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: smustudent1@yahoo.com +Subject: Re: [Axiom-developer] 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: root +To: smustudent1@yahoo.com +Subject: Re: [Axiom-developer] Compiling error + +CY, + +Are you running Fedora? + +\start +Date: Thu, 1 Apr 2004 23:48:29 -0500 +From: root +To: smustudent1@yahoo.com +Subject: Re: [Axiom-developer] 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: root +To: smustudent1@yahoo.com +Subject: Re: [Axiom-developer] 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: , "root" +Subject: RE: [Axiom-developer] 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: [Axiom-developer] 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: root +To: camm@enhanced.com, C Y +Subject: [smustudent1@yahoo.com: Re: [Axiom-developer] 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: C Y +Subject: Re: [Axiom-developer] Compiling error +To: daly@idsi.net + +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: C Y +To: daly@idsi.net, camm@enhanced.com +Subject: Re: [smustudent1@yahoo.com: Re: [Axiom-developer] Compiling error] + +--- root 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: +Subject: [Axiom-developer] 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. + +-----Original Message----- +From: zwiki-wiki@zwiki.org [mailto:zwiki-wiki@zwiki.org] +Sent: Saturday, April 03, 2004 10:51 AM +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: C Y +Subject: Re: [Axiom-developer] Compiling error] +Cc: camm@enhanced.com + +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: root +To: cyapp@UDel.Edu +Subject: Re: [Axiom-developer] Compiling error] +Cc: camm@enhanced.com + +CY, + +I'm back. Where can I get a copy of Gentoo? + +\start +Date: Sun, 4 Apr 2004 23:08:29 -0700 (PDT) +From: C Y +To: daly@idsi.net +Subject: Re: [Axiom-developer] 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 + +--- root 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: C Y +Subject: Re: [Axiom-developer] 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, + +C Y 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: root +To: Camm Maguire , C Y +Subject: [Axiom-developer] Compiling error +Cc: axiom-developer@nongnu.org, daly@idsi.net + +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: daly@idsi.net +Subject: Re: [Axiom-developer] Re: Clifford algebras in AXIOM +Cc: Bertfried.Fauser@uni-konstanz.de + +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, + +root 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: root +To: camm@enhanced.com, Bertfried.Fauser@uni-konstanz.de +Subject: [Axiom-developer] (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, +> +>root 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: [Axiom-developer] Re: [TeXmacs] Axiom plugin +Cc: 'chu-ching huang' , "Bill. Page1 \(E-mail\)" + +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: C Y +To: Camm Maguire +Subject: Re: [Axiom-developer] 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: axiom-mail@nongnu.org +Subject: [Axiom-developer] 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: root +To: Bertfried.Fauser@uni-konstanz.de +Subject: [Axiom-developer] 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: root +To: smustudent1@yahoo.com +Subject: Re: [Axiom-developer] 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: [Axiom-developer] 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@uni-konstanz.de +Subject: Re: [Axiom-developer] Math Types inclusion + +This is a multi-part message in MIME format. +--------------876C806F6CCD71DFE8C46B46 +Content-Type: text/plain; charset=gb2312 +Content-Transfer-Encoding: 7bit + +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 +-- +William Sit +Department of Mathematics..............Email: wyscc@cunyvm.cuny.edu +City College of New York..........................Tel: 212-650-5179 +Convent Ave at West 138th Street..................Fax: 212-862-0004 +New York, NY 10031............Axiom, A Scientific Computation Sytem +USA..........................http://www.nongnu.org/axiom/index.html +--------------876C806F6CCD71DFE8C46B46 +Content-Type: text/plain; charset=gb2312; + name="monoid.input" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline; + 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 +Content-Type: text/plain; charset=gb2312; + name="monoid.spad" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline; + 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: root +Subject: [Axiom-developer] 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: [Axiom-developer] Re: [TeXmacs] Axiom plugin +Cc: 'chu-ching huang' , "Bill. Page1 \(E-mail\)" + +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: wyscc@cunyvm.cuny.edu +Subject: Re: [Axiom-developer] Math Types inclusion +Cc: Bertfried.Fauser@uni-konstanz.de + +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: root +To: camm@enhanced.com +Subject: [Axiom-developer] lisp + +Camm, + +I'm (finally) going to apply those axiom patches you sent. + +\start +Date: Tue, 6 Apr 2004 14:42:43 -0400 +From: root +To: camm@enhanced.com +Subject: [Axiom-developer] 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: daly@idsi.net +Subject: [Axiom-developer] 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, + +root 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: [Axiom-developer] 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----- +> From: zwiki-wiki@zwiki.org [mailto:zwiki-wiki@zwiki.org] +> Sent: Saturday, April 03, 2004 10:51 AM +> 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: daly@idsi.net +Subject: [Axiom-developer] Re: lisp + +Greetings! + +root 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: [Axiom-developer] 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: root +To: bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] Re: lisp +Cc: camm@enhanced.com + +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: +Subject: RE: [Axiom-developer] Re: lisp +Cc: camm@enhanced.com + +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----- +> From: root [mailto:daly@idsi.net] +> Sent: Tuesday, April 06, 2004 4:56 PM +> To: bill.page1@sympatico.ca +> Cc: camm@enhanced.com; daly@idsi.net; axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] 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: root +To: bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] Re: lisp +Cc: camm@enhanced.com + +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: [Axiom-developer] 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 ... 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: root +To: bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] A possiible "navigation" approach for Axiom "crystal" +Cc: camm@enhanced.com + +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: daly@idsi.net +Subject: Re: [Axiom-developer] Re: lisp +Cc: bill.page1@sympatico.ca + +Greetings! + +root 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: root +To: camm@enhanced.com +Subject: Re: [Axiom-developer] Re: lisp +Cc: bill.page1@sympatico.ca + +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: root +To: nicolas.ratier@lpmo.edu +Subject: [Axiom-developer] 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: daly@idsi.net +Subject: Re: [Axiom-developer] Re: lisp +Cc: bill.page1@sympatico.ca + +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, + +root 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: [Axiom-developer] Re: [Gcl-devel] 2.6.2..... +Cc: Mike Thomas , "Page, Bill" , "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: root +To: mike.thomas@brisbane.paradigmgeo.com +Subject: [Axiom-developer] gcl 2.6.2 +Cc: camm@enhanced.com, Bill.Page@drdc-rddc.gc.ca, vvzhy@netorn.ru + +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: root +To: mike.thomas@brisbane.paradigmgeo.com +Subject: [Axiom-developer] gcl 2.6.2 +Cc: camm@enhanced.com, Bill.Page@drdc-rddc.gc.ca, vvzhy@netorn.ru + +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: +Subject: [Axiom-developer] RE: [Gcl-devel] gcl 2.6.2 +Cc: camm@enhanced.com, Bill.Page@drdc-rddc.gc.ca, vvzhy@netorn.ru + +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: root +To: mike.thomas@brisbane.paradigmgeo.com +Subject: [Axiom-developer] Re: [Gcl-devel] gcl 2.6.2 +Cc: vvzhy@netorn.ru, gcl-devel@gnu.org, camm@enhanced.com, Bill.Page@drdc-rddc.gc.ca + +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: +Subject: [Axiom-developer] RE: [Gcl-devel] gcl 2.6.2 +Cc: camm@enhanced.com, Bill.Page@drdc-rddc.gc.ca, vvzhy@netorn.ru + +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: root +To: Bill.Page@drdc-rddc.gc.ca +Subject: [Axiom-developer] Re: [Gcl-devel] gcl 2.6.2 +Cc: vvzhy@netorn.ru, mike.thomas@brisbane.paradigmgeo.com, camm@enhanced.com, Bill.Page@drdc-rddc.gc.ca + +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: "Page, Bill" +To: 'Mike Thomas' +Subject: [Axiom-developer] RE: [Gcl-devel] gcl 2.6.2 +Cc: camm@enhanced.com, "Page, Bill" , vvzhy@netorn.ru + +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----- +> From: Mike Thomas [mailto:mike.thomas@brisbane.paradigmgeo.com] +> Sent: Wednesday, April 14, 2004 12:37 AM +> To: daly@idsi.net +> Cc: vvzhy@netorn.ru; gcl-devel@gnu.org; camm@enhanced.com; +> Bill.Page@drdc-rddc.gc.ca; axiom-developer@nongnu.org +> 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: "Page, Bill" , +Subject: [Axiom-developer] RE: [Gcl-devel] gcl 2.6.2 +Cc: camm@enhanced.com, vvzhy@netorn.ru + +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: "Page, Bill" +To: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] 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: root +To: Bill.Page@drdc-rddc.gc.ca +Subject: Re: [Axiom-developer] 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: + <>= +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: daly@idsi.net +Subject: [Axiom-developer] Re: [Gcl-devel] gcl 2.6.2 +Cc: mike.thomas@brisbane.paradigmgeo.com, Bill.Page@drdc-rddc.gc.ca, vvzhy@netorn.ru + +Greetings! + +root 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: daly@idsi.net +Subject: [Axiom-developer] Re: [Gcl-devel] gcl 2.6.2 +Cc: mike.thomas@brisbane.paradigmgeo.com, Bill.Page@drdc-rddc.gc.ca, vvzhy@netorn.ru + +Greetings! + +root 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@enhanced.com +Subject: [Axiom-developer] 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: [Axiom-developer] 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: root +To: camm@enhanced.com +Subject: [Axiom-developer] 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@enhanced.com +Subject: [Axiom-developer] 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: [Axiom-developer] 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: daly@idsi.net +Subject: [Axiom-developer] '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@enhanced.com +Subject: [Axiom-developer] 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: [Axiom-developer] 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.com +Subject: [Axiom-developer] 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.com +Subject: [Axiom-developer] 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: root +Subject: Re: [Axiom-developer] A possible "navigation" approach for Axiom "crystal" +Cc: Bill.Page@drdc-rddc.gc.ca + +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: +> <>= +> 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: +Subject: RE: [Axiom-developer] 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@uni-konstanz.de +Subject: Re: [Axiom-developer] A possible "navigation" approach for Axiom "crystal" +Cc: Bill.Page@drdc-rddc.gc.ca + +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: root +To: Michael Koehne , fujimori@ns.fujimori.cache.waseda.ac.jp, camm@enhanced.com +Subject: [Axiom-developer] 404 http://axiom.tenkan.org/axiom.20040321.tgz +Cc: axiom-developer@nongnu.org, daly@idsi.net + +> Moin Tim, +> +> i wanted to download actual axiom, but got a 404 on the above URL ;( +> would be nice to inform me, fujimori@ns.fujimori.cache.waseda.ac.jp +> and camm@enhanced.com, when the new verions is available again ;) +> +> Bye Michael +> -- +> mailto:kraehe@copyleft.de UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1' +> http://www.xml-edifact.org/ CETERUM CENSEO WINDOWS ESSE DELENDAM + +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: daly@idsi.net, Tim Daly +Subject: Re: [Axiom-developer] 404 http://axiom.tenkan.org/axiom.20040321.tgz +Cc: camm@enhanced.com, Michael Koehne , fujimori@ns.fujimori.cache.waseda.ac.jp + +root 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: [Axiom-developer] 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: root +To: Michael Koehne , fujimori@ns.fujimori.cache.waseda.ac.jp, camm@enhanced.com +Subject: [Axiom-developer] 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, fujimori@ns.fujimori.cache.waseda.ac.jp +> > and camm@enhanced.com, 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: root +To: Michael Koehne , fujimori@ns.fujimori.cache.waseda.ac.jp, camm@enhanced.com +Subject: [Axiom-developer] 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: root +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] fyi + +Date: Mon, 19 Apr 2004 18:30:30 +0200 +From: ISSAC 04 +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: daly@idsi.net +Subject: [Axiom-developer] Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz] +Cc: Michael Koehne , fujimori@ns.fujimori.cache.waseda.ac.jp + +Greetings! + +root 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: root +To: camm@enhanced.com +Subject: [Axiom-developer] Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz] +Cc: fujimori@ns.fujimori.cache.waseda.ac.jp, kraehe@copyleft.de + +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@univ-orleans.fr +To: Camm Maguire +Subject: Re: [Axiom-developer] 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: root +To: camm@enhanced.com +Subject: [Axiom-developer] 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: root +To: camm@enhanced.com, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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: [Axiom-developer] Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz] +Cc: fujimori@ns.fujimori.cache.waseda.ac.jp, 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: [Axiom-developer] 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: ; +> fontadj="_.int(REQUEST.get('latexwiki_fontadjust',0))" +> fontsize="latex_font_size"> +> font-size: px; +> +> } +> .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: 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: [Axiom-developer] Re: 404 http://axiom.tenkan.org/axiom.20040321.tgz] +Cc: Michael Koehne , fujimori@ns.fujimori.cache.waseda.ac.jp + +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: [Axiom-developer] Re: LatexWiki for free open source AXIOM computer algebra system + +--Fba/0zbH8Xs+Fj9o +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +Bill Page [bill.page1@sympatico.ca] 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: root +To: bob@mcelrath.org +Subject: [Axiom-developer] Axiom +Cc: bill.page1@sympatico.ca + +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: root +To: bill.page1@sympatico.ca +Subject: [Axiom-developer] 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: root +To: bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] Axiom wiki +Cc: camm@enhanced.com + +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: root +To: dpt@math.harvard.edu +Subject: Re: [Axiom-developer] Axiom wiki +Cc: camm@enhanced.com, bill.page1@sympatico.ca + +> > 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: root +To: camm@enhanced.com +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: gcl sockets + +root 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: root +To: hall.cj@verizon.net +Subject: Re: [Axiom-developer] 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: root +To: camm@enhanced.com +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: puzzled.... + +root 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: CY +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: daly@idsi.net +Subject: [Axiom-developer] 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, + +root 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: daly@idsi.net +Subject: [Axiom-developer] Re: [Gcl-devel] puzzled.... + +Greetings! + +root 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: "Page, Bill" +To: daly@idsi.net +Subject: [Axiom-developer] 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----- +> From: Camm Maguire [mailto:camm@enhanced.com] +> Sent: Wednesday, April 28, 2004 6:57 PM +> To: daly@idsi.net +> Cc: axiom-developer@nongnu.org; gcl-devel@gnu.org +> 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: [Axiom-developer] 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 " 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)) +> # +> +> >(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))) +> # +> +> ------------ /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. +> +> Aloha, +> +Chris +> +> -- +> Good judgment comes from experience. Experience comes from bad +> judgment. +> - Jim Horning +> +> +> +> _______________________________________________ +> Gcl-devel mailing list +> Gcl-devel@gnu.org +> http://mail.gnu.org/mailman/listinfo/gcl-devel + +\start +Date: Thu, 29 Apr 2004 07:41:54 -0400 +From: root +To: camm@enhanced.com +Subject: Re: [Axiom-developer] 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: root +To: Bill.Page@drdc-rddc.gc.ca +Subject: Re: [Axiom-developer] 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: root +To: Bill.Page@drdc-rddc.gc.ca +Subject: [Axiom-developer] 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: root +Subject: Re: [Axiom-developer] 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: root +To: Bertfried.Fauser@uni-konstanz.de +Subject: Re: [Axiom-developer] 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: +Subject: RE: [Axiom-developer] Re: [Gcl-devel] gcl sockets +Cc: Bertfried.Fauser@uni-konstanz.de + +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 ... + diff --git a/changelog b/changelog index 9e9c9fc..26d85f4 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,5 @@ +20140422 tpd src/axiom-website/patches.html 20140422.03.tpd.patch +20140422 tpd book/2004-04.txt regularize 20140422 tpd src/axiom-website/patches.html 20140422.02.tpd.patch 20140422 tpd book/2004-03.txt regularize 20140422 tpd src/axiom-website/patches.html 20140422.01.tpd.patch diff --git a/src/axiom-website/patches.html b/src/axiom-website/patches.html index 2728375..998fdb2 100644 --- a/src/axiom-website/patches.html +++ b/src/axiom-website/patches.html @@ -4292,6 +4292,8 @@ book/2004-01.txt regularize book/2004-02.txt regularize 20140422.02.tpd.patch book/2004-03.txt regularize +20140422.03.tpd.patch +book/2004-04.txt regularize