\start
Date: Sat, 1 Apr 2006 00:50:50 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: #196 ')set functions compile on'

patch applied. 
available at next release. 
clear and well documented fix.

excellent work.

\start
Date: 01 Apr 2006 08:45:23 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: choose the better expand

Dear Francois,

 
> 5/ Do you prefer :
> a-expand (sin (2*x+y)) gives an Expression in sin x, sin y, cos x... of corse.
> b-expand (sin (3)) remains sin (3) [or do you prefer with sin 1 and cos 1]
> c-expand (sin (3*expressions without variables)) remains the same. 

To be honest, I find it very difficult to answer your question. I guess that in
general there is no such thing as a "normal form" for trigonometric
expressions. However, for special cases there may well be.

I vaguely remember that maxima was very good at simplifying that stuff, they
have trigsimp, trigrat, trigreduce,...

See

http://www.ma.utexas.edu/maxima/maxima_14.html

I think it would be very useful if you would browse the web a little and see
what has been done on the subject.

For example, for the case of no variables, MathSciNet gave me

-------------------------------------------------------------------------------

MR0981072 (90c:68040) 
 Schorn, Peter(1-NC-C) 
 A canonical simplifier for trigonometric expressions in the kinematic
 equation. 
 Inform. Process. Lett. 29 (1988), no. 5, 241--246.
 68Q40

Summary: "We present a new canonical simplification algorithm for trigonometric
expressions in the kinematic equation. The expressions consist of rational
numbers and the function symbols $+, -, *, /, \sin$ and $\cos$. Variables are
not allowed and the arguments of $\sin$ and $\cos$ are limited to rational
multiples of $\pi$. We present an algorithm which computes a simple normal form
in the real domain, in contrast to the known methods which either produce
unnecessarily complicated normal forms or are inefficient due to large integer
arithmetic. The simplifier has successfully been applied in the field of robot
kinematics."

-------------------------------------------------------------------------------


ScienceDirect told me that within ScienceDirect this article was cited once,
namely by:

Trigonometric polynomials with simple roots 

Achim Schweikard* 
 
Technische Universitt Berlin, Berlin, Germany 
 

Abstract


Trigonometric polynomials frequently occur applications in physics, numerical
analysis and engineering, since each periodic function can be approximated by a
trigonometric polynomial. Additionally, there are many analogies between
trigonometric and standard algebraic polynomials. Algorithms in computer
algebra depend on methods for the square-free decomposition of
polynomials. These methods use polynomial division and cannot be applied
directly to trigonometric polynomials. Let P denote the set of odd multiples of
?. A trigonometric polynomial T* is a reduced representation of a trigonometric
polynomial T if the set of zeros of T in P is the same as the set of zeros of
T* in P, and if all zero s of T* are simple zeros. It is shown that a reduced
representation of a trigonometric polynomial with rational or algebraic
coefficients can be found in polynomial time. 


Author Keywords: Analysis of algorithms; computer algebra; trigonometric and
exponential polynomial; root multiplicity; greatest square-free divisor 

-------------------------------------------------------------------------------

it might also be helpful to send a message to Richard Fateman, or to
math.sci.symbolic.

I truly appreciate your work. I find it's a great pity that you cannot come to
the workshop.

\start
Date: 01 Apr 2006 08:48:00 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: choose the better expand

I forgot to add:

on sci.math.symbolic there was a related challenge. Look for

Peter L. Montgomery Re: Semi-tough simplify test

If you teach axiom the trick - in a sensible manner - this would be great.

I guess this all boils down to introduce an Expression Domain without
variables.

\start
Date: Sat, 01 Apr 2006 12:26:23 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Map

On 04/01/2006 04:50 AM, Bill Page wrote:
> On March 31, 2006 9:12 PM Antoine Hersen wrote:
>> I am having some trouble with the function map applied to List.
>>
>> When using it in input files axiom complains but oblige but in
>> a spad files I am always running to disaster.
>>
>> I end up using a [my_function i for i in my_list ]
>>
>> I guess I am not using $ and @ correctly, can anybody give me 
>> some advices ?

> To get some useful advice please be specific and give some
> examples. Even better: Create a page in the Axiom Wiki SandBox
> that shows what you are trying to do. Then someone can help you.

I actually wanted to give the same comment like Bill. I cannot do 
anything to help you, Antoine, if you don't clearly show what your 
problem is. Try to reduce the amount of other people to help you if you 
want to get a quick advice.

A SandBox is a very good place.

\start
Date: Sat, 01 Apr 2006 10:02:24 -0500
From: Raymond Rogers
To: list
Subject: FC5: rsync, lsp, 2412, etc

Hi,
	I have moved to FC5 and am trying to build axiom.  I get the error
mentioned in:
http://cvs.savannah.nongnu.org/viewcvs/axiom/axiom/lsp/Makefile.pamphlet?rev=1.17
configure: line 2412: syntax error near unexpected token `('

I have tried rsynch
rsync -av cvs.savannah.gnu.org::sources/axiom/axiom

but it didn't clear it up.  Is the fix on a separate tree?
Since I have doubts about present day software, I don't do automatic
updates and am not familiar with using cvs and rsynch.  Nice ideas but
probably capable of causing some grief.

\start
Date: Sat, 1 Apr 2006 11:17:06 -0500
From: Tim Daly
To: Raymond Rogers
Subject: Re: FC5: rsync, lsp, 2412, etc

Ray,

I just got the FC5 image this week so I have not yet tried to
build an image there.

\start
Date: 01 Apr 2006 18:46:45 +0200
From: Francois Maltey
To: Martin Rubey
Subject: Re: choose the better expand

Dear Martin, 

Thanks for your friendly mails.

The aim of my first steps in axiom is to have the three minimal functions
expand, rewrite and combine for elementary functions. 
Simplifications come after !

/////////////////////////////////////////////////////////////////////

So expand : expand ! 
I ask for me if I do only one expand (Expr) 
or expand (Expr, "sincos") with one parameter and
   expand (Expr, ["sincos", ...) with many parameters. Do you have an idea ?

rewrite has an aim : 
  rewrite (sin (4*x), "tan") computes (tan (2*x)/(1+tan (2*x)^2)

combine (2*(cos x)^2, "sincos") finds cos (2*x)+1

Axiom has some of theses functions but there are a lot of name to retain.
So I try to give a single access to theses transformations.

/////////////////////////////////////////////////////////////////////

Now where I'm locked : 

How can I produce sin a cosh b + %i cos a sinh b
after expand (sin (a+%i*b)) in the interpreter ?

So sin (a+%i*b) is of type Expression ... Complex ... 

My manip.spad have now this main function kerexpand, 
I add functions expandsin and so, 
add auxilary functions expandsinp for product, and sinnx for sin (n*x)
The function fctCtoN transforms c in R in n in Integer

    kerexpand k ==
      nullary?(op := operator k) => k::F
      is?(op, POWER) => expandpow k
      arg := first argument k
      is?(op, "sec"::Symbol) => inv expand cos arg
      is?(op, "csc"::Symbol) => inv expand sin arg
      is?(op, "log"::Symbol) =>
         exlog(numer(x := expand arg)) - exlog denom x
      is?(op, "exp"::Symbol) => expandexp arg 
      is?(op, "sin"::Symbol) => expandsin arg 
      is?(op, "cos"::Symbol) => expandcos arg
      is?(op, "tan"::Symbol) => expandtan arg
      is?(op, "cot"::Symbol) => expandcot arg
      is?(op, "sinh"::Symbol) => expandsinh arg 
      is?(op, "cosh"::Symbol) => expandcosh arg
      is?(op, "tanh"::Symbol) => expandtanh arg
      is?(op, "coth"::Symbol) => expandcoth arg
      op [expand x for x in argument k]$List(F)

    expandsin arg ==                                   -- for ...plus...
--    If arg is complex AND imag arg ~=0 I want to expand trig with sin, sinh
--      and so
      null variables arg => sin arg 
      num := numer arg 
      den := denom arg
      a := leadingMonomial num
      c := leadingCoefficient a 
      b := reductum num / den
      b ^= 0 => 
          expandsinp (c,a,den) * expandcos b _
        + expandcosp (c,a,den) * expand sin b
      expandsinp (c,a,den)

    fctCtoN c ==       -- it's not so easy to obtain n in Integer from c in R
      n : Integer := 1 
      if R has retractIfCan : R -> Union(Integer,"failed")
        then 
          n1 := (retractIfCan c)@Union(Integer,"failed")
          if n1 case Integer then n := n1::Integer
      n

    expandsinp (c, a, den) ==                 -- for product with an unknow c 
      n := fctCtoN c
      if n = 1 
        then sin (a/den)
        else
          sinnx (n, (a::F) / (n::R::F * den::F))

    sinnx (n,x) ==                                   -- the well-know formula 
      n<0  => -sinnx (-n, x)
      imag(complex(sin(x),cos(x))$CF**n)

\start
Date: Sat, 01 Apr 2006 19:14:41 +0200
From: Gregory Vanuxem
To: list
Subject: #109 and #153 in pending status

Hi,

Is it possible to close issues #109 and #153 (old pending status) ?

I can't check these issues since i have uncompress and i don't use the
makefile install target.

\start
Date: 01 Apr 2006 20:42:11 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: choose the better expand

Francois Maltey writes:

> So expand : expand ! 
> I ask for me if I do only one expand (Expr) 
> or expand (Expr, "sincos") with one parameter and
>    expand (Expr, ["sincos", ...) with many parameters. Do you have an idea ?

You probably should provide the three of them.

Could you define (exactly!) what expand is supposed to do. I guess that it's
similar to

Function: TRIGEXPAND (exp) 

expands trigonometric and hyperbolic functions of sums of angles and of
multiple angles occurring in exp. For best results, exp should be expanded. To
enhance user control of simplification, this function expands only one level at
a time, expanding sums of angles or multiple angles. To obtain full expansion
into sines and cosines immediately, set the switch TRIGEXPAND:TRUE. TRIGEXPAND
default: [FALSE] - if TRUE causes expansion of all expressions containing SINs
and COSs occurring subsequently. HALFANGLES[FALSE] - if TRUE causes half-angles
to be simplified away. TRIGEXPANDPLUS[TRUE] - controls the "sum" rule for
TRIGEXPAND, expansion of sums (e.g. SIN(X+Y)) will take place only if
TRIGEXPANDPLUS is TRUE. TRIGEXPANDTIMES[TRUE] - controls the "product" rule for
TRIGEXPAND, expansion of products (e.g. SIN(2*X)) will take place only if
TRIGEXPANDTIMES is TRUE.

(C1) X+SIN(3*X)/SIN(X),TRIGEXPAND=TRUE,EXPAND;
                              2           2
(D1)                     - SIN (X) + 3 COS (X) + X
(C2) TRIGEXPAND(SIN(10*X+Y));
(D2)               COS(10 X) SIN(Y) + SIN(10 X) COS(Y)


Variable: TRIGEXPANDPLUS 

default: [TRUE] - controls the "sum" rule for TRIGEXPAND. Thus, when the
TRIGEXPAND command is used or the TRIGEXPAND switch set to TRUE, expansion of
sums (e.g. SIN(X+Y)) will take place only if TRIGEXPANDPLUS is TRUE.

Variable: TRIGEXPANDTIMES 

default: [TRUE] - controls the "product" rule for TRIGEXPAND. Thus, when the
TRIGEXPAND command is used or the TRIGEXPAND switch set to TRUE, expansion of
products (e.g. SIN(2*X)) will take place only if TRIGEXPANDTIMES is TRUE.

\start
Date: Sat, 1 Apr 2006 11:15:28 -0800
From: Antoine Hersen
To: list
Subject: Re: Map

Sorry,

Here it is http://wiki.axiom-developer.org/SandBoxSpad

If I try to use the map the compilation fail

I am used to Ocaml who do a terrific job at inferring type( which are
more simple) and I have trouble figuring out where to add type
information.

Thanks,
Antoine Hersen

On 4/1/06, Ralf Hemmecke wrote:
> On 04/01/2006 04:50 AM, Bill Page wrote:
> > On March 31, 2006 9:12 PM Antoine Hersen wrote:
> >> I am having some trouble with the function map applied to List.
> >>
> >> When using it in input files axiom complains but oblige but in
> >> a spad files I am always running to disaster.
> >>
> >> I end up using a [my_function i for i in my_list ]
> >>
> >> I guess I am not using $ and @ correctly, can anybody give me
> >> some advices ?
>
> > To get some useful advice please be specific and give some
> > examples. Even better: Create a page in the Axiom Wiki SandBox
> > that shows what you are trying to do. Then someone can help you.
>
> I actually wanted to give the same comment like Bill. I cannot do
> anything to help you, Antoine, if you don't clearly show what your
> problem is. Try to reduce the amount of other people to help you if you
> want to get a quick advice.
>
> A SandBox is a very good place.

\start
Date: 01 Apr 2006 21:50:57 +0200
From: Francois Maltey
To: Martin Rubey
Subject: Re: choose the better expand

Dear Martin,

> You probably should provide the three syntaxs.

OK.

> Could you define (exactly!) what expand is supposed to do. 
> I guess that it's similar to ... maxima...

I don't forget mupad, results are (almost) the same.
I'm looking for a syntax which is easy for easy computation 
but which allows various interessing abilities.

But might you help me for extracting real part and imag part for 
Expression ... Complex ... ? in manip.spad.
Perhaps do you want I send you my working manip.spad.

I'm going to test an expand which 
     1/ separates real part and imag part, if it's a Complex domain
then 2/ always applies sum formula,
 and 3/ applies Integer * formula_without_denominator
for sin, cos, tan, cot, sinh, cosh, tanh, coth, exp...

A list of String describes the parameters and precises the expand use : 

noComplex bypass the first step, noSum the second, noTimes the third.
allDenom  expands also sin (2*x/3) in 2 sin (x/3) cos (x/3)
evenConst expands sin (sqrt 2 + sqrt 3) in sin... cos... + cos... sin...
recursif  does the silly expand (sin (sin (a+b)))
?????     expands sin (x/3+y/2) * cos (x/2-y/7) in sin... cos... x/6 and y/14 !
          (but I'm not sure I can do it !)

\start
Date: 01 Apr 2006 21:53:36 +0200
From: Francois Maltey
To: Antoine Hersen
Subject: Re: Map

Salut Antoine !

I believe it's map (degree #1, a) we must type in .spad files.
Last days I make the same error. I find this tips by grep .spad file.

Je pense que tu as oubli=C3=A9 le #1, mais je n'ai pas test=C3=A9.

La syntaxe de caml est si pure que l'on oublie facilement
les petits arrangements comme ceux-la.

\start
Date: Sat, 1 Apr 2006 15:18:14 -0800
From: Antoine Hersen
To: Francois Maltey
Subject: Re: Map

Hello,

Does not seem to work,

I try creating an anonymous function to i +-> degree i but same pb ...



On 01 Apr 2006 21:53:36 +0200, Francois Maltey wrote:
> Salut Antoine !
>
> I believe it's map (degree #1, a) we must type in .spad files.
> Last days I make the same error. I find this tips by grep .spad file.
>
> Je pense que tu as oubli=E9 le #1, mais je n'ai pas test=E9.
>
> La syntaxe de caml est si pure que l'on oublie facilement
> les petits arrangements comme ceux-la.

C'est vrais que le moteur d'inference de type est vraiment efficace.
Quand j'utilise Aldor le compilateur donne beaucoup plus
d'information, je me demande si avec un satisfacteur de contrainte il
ne serais pas possible d'avoir un peu plus de souplesse.

\start
Date: Sun, 02 Apr 2006 02:34:33 +0200
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Map

On 04/01/2006 09:15 PM, Antoine Hersen wrote:
> Sorry,
> 
> Here it is http://wiki.axiom-developer.org/SandBoxSpad
> 
> If I try to use the map the compilation fail
> 
> I am used to Ocaml who do a terrific job at inferring type( which are
> more simple) and I have trouble figuring out where to add type
> information.

Actually, I don't understand you Antoine.
[degree i for i in a]
does the same job as your map stuff. And it works.

Second, please start using Aldor. I don't understand why you insist on 
using SPAD. Take for example

(i) +-> degree i

You put this (anonymous) function without giving types. So you rely on 
what the compiler thinks is appropriate in your case.

What can the compiler do if it sees

map(f, a)

where f is the (untyped) function from above.
It figures out the type of a, that is clearly "List P".
OK, it also sees that List(P) provides a function
map: (P -> P, %) -> %
Now the compiler must somehow try to fit your anonymous untyped function 
to the type P->P. Which is actually impossible, since there is no
degree: P->P. The compiler must complain!!!
The bad thing is only that the error message does not say much about the 
reason if you are (like me) unfamiliar with that output.

Well, anyway, use Aldor and enjoy better error messages.

\start
Date: Sun, 2 Apr 2006 03:40:03 -0700
From: Antoine Hersen
To: Ralf Hemmecke
Subject: Re: Map

Hello,

I am using Aldor since Friday and indeed the error message are way more hel=
pful.
And the documentation a blessing.

I think most of my confusion come from the fact that all my functional
programing experience come from Ocaml.

If you are not familiar with Ocaml. It is also strongly typed but with
a much simpler abstract data type system. And so it is capable of
making sound inference on type with a constraint solver.

So yes I kinda expected it to get all the type right for me...
Especially since I did all my previous works in inputs files.

What confused me to is that there is some limited inferring.

But I have learned my lesson no type inference. And ")show SomeType"
is my best friend.

All my map trouble come from the fact that I tried to use map to change typ=
e

map( A -> B , List A ) -> List B
but the definition is always

map( R -> R, % ) -> %

Has an exercise I could create a new domain :

Map(A:Type, B:Type): with {
        map: (A->B , List A) -> List B ;
} == add {
        map( f:(A->B), la :List A):List B == {
                [ f i for i in la ] }
}

map( A->B, List A )$Map(A,B)

or maybe create a function

map(A:Type, B:Type, f:A->B, la: List A) : List B ==
     [f i for i in la] ;

Anyway sorry for the vague question.

And thanks you for orienting me to Aldor

Regards,
Antoine Hersen


On 4/1/06, Ralf Hemmecke wrote:
> On 04/01/2006 09:15 PM, Antoine Hersen wrote:
> > Sorry,
> >
> > Here it is http://wiki.axiom-developer.org/SandBoxSpad
> >
> > If I try to use the map the compilation fail
> >
> > I am used to Ocaml who do a terrific job at inferring type( which are
> > more simple) and I have trouble figuring out where to add type
> > information.
>
> Actually, I don't understand you Antoine.
> [degree i for i in a]
> does the same job as your map stuff. And it works.
>
> Second, please start using Aldor. I don't understand why you insist on
> using SPAD. Take for example
>
> (i) +-> degree i
>
> You put this (anonymous) function without giving types. So you rely on
> what the compiler thinks is appropriate in your case.
>
> What can the compiler do if it sees
>
> map(f, a)
>
> where f is the (untyped) function from above.
> It figures out the type of a, that is clearly "List P".
> OK, it also sees that List(P) provides a function
> map: (P -> P, %) -> %
> Now the compiler must somehow try to fit your anonymous untyped function
> to the type P->P. Which is actually impossible, since there is no
> degree: P->P. The compiler must complain!!!
> The bad thing is only that the error message does not say much about the
> reason if you are (like me) unfamiliar with that output.
>
> Well, anyway, use Aldor and enjoy better error messages.

\start
Date: 03 Apr 2006 04:41:56 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: typo in src/boot/Makefile.pamphlet


Tim --

  BOOT's documentation has typo that prevents proper formatting. 

-- Gaby

* looking for arch@axiom-developer.org--axiom/axiom--main--1--patch-47 to compare with
* comparing to arch@axiom-developer.org--axiom/axiom--main--1--patch-47
M  src/boot/Makefile.pamphlet

* modified files

--- orig/src/boot/Makefile.pamphlet
+++ mod/src/boot/Makefile.pamphlet
@@ -794,7 +794,7 @@
  
 are both translated to
         name1 name2 DEF (pattern:=name2;where)
-\ennd{verbatim}  
+\end{verbatim}  
 
 similarly for patterns that occur as components of a list of
 variables. order

\start
Date: Sun, 2 Apr 2006 23:53:53 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: typo in src/boot/Makefile.pamphlet

patch applied.
fixed in the next release.

\start
Date: Fri, 31 Mar 2006 13:04:54 -0500
From: Tim Daly
To: list
Subject: temp mail address....

My axiom-developer.org mail address is down until we get the
server restored. I can be reached at 'maxima@tenkan.org' for
the duration.

Since list is hosted by savannah the
mailing list distribution is not affected.

\start
Date: 03 Apr 2006 10:03:03 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: choose the better expand

Francois Maltey writes:

> Dear Martin,
> 
> > You probably should provide the three syntaxs.
> 
> OK.
> 
> > Could you define (exactly!) what expand is supposed to do. 
> > I guess that it's similar to ... maxima...
> 
> I don't forget mupad, results are (almost) the same.
> I'm looking for a syntax which is easy for easy computation 
> but which allows various interessing abilities.
> 
> But might you help me for extracting real part and imag part for 
> Expression ... Complex ... ? in manip.spad.
> Perhaps do you want I send you my working manip.spad.

Yes, please. But I'm a little out of time currently. In the worst case, I can
only help after the workshop, but I'll do my best.

> I'm going to test an expand which 
>      1/ separates real part and imag part, if it's a Complex domain
> then 2/ always applies sum formula,
>  and 3/ applies Integer * formula_without_denominator
> for sin, cos, tan, cot, sinh, cosh, tanh, coth, exp...
> 
> A list of String describes the parameters and precises the expand use : 
> 
> noComplex bypass the first step, noSum the second, noTimes the third.
> allDenom  expands also sin (2*x/3) in 2 sin (x/3) cos (x/3)
> evenConst expands sin (sqrt 2 + sqrt 3) in sin... cos... + cos... sin...
> recursif  does the silly expand (sin (sin (a+b)))
> ?????     expands sin (x/3+y/2) * cos (x/2-y/7) in sin... cos... x/6 and y/14 !
>           (but I'm not sure I can do it !)

Since I'm very bad at trigonometrics, I find the description above a little
terse. Precise definitions would be very helpful.

\start
Date: 04 Apr 2006 10:11:57 +0200
From: Martin Rubey
To: list
Subject: operations working in general,	but not in special cases -- help needed

Dear all,

I will first describe my problem with two examples occurring in practice, and
finally try to give a more abstract description. The question is, how to
structure categories in these cases.

Example 1, Matroids

A "matroid" is a mathematical structure with one very, very important
operation, namely "dualizing" which transforms a given matroid into
another. Thus, one is tempted to have a category "MatroidCat", which exports an
operation "dual: % -> %".

However, a very important class of matroids, called "graphic matroids", do have
this operation only if the matroid is "planar". (In fact, "graphic matroids"
are simply undirected, unweighted graphs)

Since "graphic matroids" are so important, I would like to have a category
"GraphicMatroidCat", and since they are matroids I'd like to have it inherit
from "MatroidCat". But this is impossible, since the class is not closed under
duality.

Example 2, Differential Equations

A Holonomic function is a function f -- say in one variable x -- that satisfies
a differential equation with polynomial coefficients:

  p_k(x) f^(k) (x) + ... + p_2(x) f''(x) + p_1(x) f'(x) + p_0(x) f(x) = q(x)

where f^(k) is the k_th derivative of f and p_i and q are polynomials.

It is quite easy to see that the class of holonomic functions is closed under
integration, i.e., integrating a holonomic function yields again a holonomic
function. This is quite an important property, of course, so a priori, I'd like
to export it in "HolonomicCat".

If we take k=0 in the equation above we obtain the class of rational
functions. Since rational functions are so important, I'd like to have a
category "RatCat". However, we all know that the class of rational functions is
*not* closed under integration, the simplest example being 1/x.

The general case

We have a category A with an operation op: % -> %. However, there are natural
subdomains of domains of A, which are no longer closed under op.

Can you propose a "natural" hierarchy of categories for this situation?  Since
this occurs so often, I hope that there is a nice solution...

\start
Date: 04 Apr 2006 10:36:41 +0200
From: Martin Rubey
To: Antoine Hersen
Subject: Re: Map

Dear Antoine,

see SandBoxSpad.


"Antoine Hersen" Antoine Hersen writes:

> All my map trouble come from the fact that I tried to use map to change type
> 
> map( A -> B , List A ) -> List B

Using hyperdoc, you find that this kind of map is provided by ListFunctions2:

click Browse

enter map

click operations

click parameters

click map(f, x)

click signatures

(still a lot of work, since there are so many, but better than )show)


\start
Date: Tue, 4 Apr 2006 09:43:48 +0200 (CEST)
From: Bertfried Fauser
To: Martin Rubey
Subject: Re: operations working in general, but not in special cases -- help needed

On 4 Apr 2006, Martin Rubey wrote:

Hi Martin,

a quite interesting question...

> The general case
>
> We have a category A with an operation op: % -> %. However, there are natural
> subdomains of domains of A, which are no longer closed under op.
>
> Can you propose a "natural" hierarchy of categories for this situation?  Since
> this occurs so often, I hope that there is a nice solution...

In general, a mathematical substructure inherites properties of its
ancestor if and only if the process of producing the substructure is
functorial (a natural mapping). There is the general construction of free
objects, eg free algebra, free group, free monoid etc and the theorem that
every such substructure is an image of teh free structure.
	However, if a free object comes with additional features these
features might not be transported in a meaningfull manner into a
subcategory. To add a further example, take a graded algebra and divide
out a ungraded ideal, then the result is an ungraded alegbra (Tensor
algebra -> Lie algebra), while eg the even od grading might survife in
this setting (-> super Lie alegbra).

Possible solution:
	If I understand the inhertitance correctly, it might be seen as a
(not necessarily) natural map from a (free) category to a subcategory
specified by having additional features (obtained by the mapping). Hence
it might be necessary to enlarge the structure of the definition of a
category/domain:

Currently we have a descriptiv part and an implementation part, there
could be a third part in the definition with prevents certain functions
from the parent category to be inherited or (if possible) alter them to
check if they are applicable.


Category Matroid

  expoerts dual

then

Category GraphMatroid

  inherits Matroid
=>modifies dual -> dual= if has planar then dual else error
  exports  new functionality

the second line is new and would need an alteration of spad and aldor
compilers. However, such an copntrolled overloading should not be to
difficult to be implemented and could help to manage the cases you brought
up, as other ones, eg the change of gradings etc.

In general I doubt that mathematics has a plain tree structure so that
there is a root category. Even is Set (Bourbaki tradition, but see
Lawvere!) is used to do so, nobody would start with Set to do say
differential topology. Also a computer algebra system which would tried to
do this would be doomed to fail.

\start
Date: 04 Apr 2006 12:01:14 +0200
From: Martin Rubey
To: Christian Aistleitner
Subject: Re: [Aldor-l] operations working in general, but not in special cases -- help needed

Christian Aistleitner writes:

> Dear Martin,
> 
> > We have a category A with an operation op: % -> %. However, there are  natural
> > subdomains of domains of A, which are no longer closed under op.
> 
> if I understood you correctly, you did not mean "closed under op" but "op  is a
> partial function" -- which is a completely different thing.

Could you please elaborate. Ideally, the function "dual" would not be available
for graphical matroids and I'd have yet another class
"PlanarGraphicalMatroids".

Or, maybe even better, the dual of a graphical non-planar matroid would simply
yield a general matroid.

Same thing with differential equations: integrating a rational function should
either be unavailable or yield a holonomic function.

In case the function is unavailable, the axiom interpreter would automatically
try to coerce it into a domain where the operation is indeed valid. So there is
no problem for users.

> > Example 1, Matroids
> 
> > A "matroid" is a mathematical structure with one very, very important
> > operation, namely "dualizing" ...
> 
> If a matroid is required to have a "dualizing function", then a graphical
> matroid cannot be a matroid. Simply because it does not provide the total
> function "dualize"
> 
> However, a graphical matroid can "contain" a matroid.
> 
> So the abstract setting is "graphical matroid" and the specialized one is
> "matroid". Not the other way round.

In a way you are right, of course - I followed the same reasoning
originally. However, I do feel a little uneasy saying that a graphical matroid
is not a matroid...

Furthermore, there is another complication:

For a certain class of graphical matroids, namely those which are 3-connected,
we can recover the vertices. I.e.,

general Matroids have duals but no vertices

graphic non-planar three-connected Matroids do not have duals but do have
vertices

So, what to do?

\start
Date: Tue, 04 Apr 2006 14:30:20 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: [Aldor-l] operations working in general, but not in special cases -- help needed

On 04/04/2006 10:11 AM, Martin Rubey wrote:
> Example 1, Matroids

> A "matroid" is a mathematical structure with one very, very important
> operation, namely "dualizing" which transforms a given matroid into
> another. Thus, one is tempted to have a category "MatroidCat", which exports an
> operation "dual: % -> %".

> However, a very important class of matroids, called "graphic matroids", do have
> this operation only if the matroid is "planar". (In fact, "graphic matroids"
> are simply undirected, unweighted graphs)

 From your description it is totally obvious: "graphic matroids" are not 
"matroids".

Since I cannot believe this, I would simply say, your "dual" function is 
not as inherent to a matroid as you think. You probably would like to create

define MatroidCategory: Category == with {
   -- don't know yet
}

define DualizableMatroidCategory: Category == with {
   MatroidCategory;
   dual: % ->%;
}

define GraphicalMatroidCategory: Category == with {
   MatroidCategory;
   if ... --express "planar" here
   then DualizableMatroidCategory;
}


> The general case

> We have a category A with an operation op: % -> %. However, there are natural
> subdomains of domains of A, which are no longer closed under op.

So think of Z (integers) and N (natural numbers) and the operation
   -: % -> %
You would probably never say that N is an additive Group where the 
negation fails. Well, you could do this, but that is not mathematically 
natural. You simply say N is not an additive group.

Well, of course, you don't declare N to be of AbelianGroup.

I see your point, but at the moment I cannot think of a good advice for 
the general case. For the "holonomic" example, it sounds a bit strange 
to say that rational functions do not inherit from holonomic functions.
But what is true is that rational function don't inherit the closure 
properties. So maybe as above that are two categories and one of them is 
the "ClosurePropertyCategory".

I don't yet know whether this is the best thing, but I cannot think of 
anything better at the moment.

\start
Date: Tue, 04 Apr 2006 12:00:11 -0400
From: William Sit
To: Martin Rubey
Subject: Re: operations working in general, but not in special cases -- help needed

Dear Martin:

Martin Rubey wrote:

> The general case
> 
> We have a category A with an operation op: % -> %. However, there are natural
> subdomains of domains of A, which are no longer closed under op.
> 
> Can you propose a "natural" hierarchy of categories for this situation?  Since
> this occurs so often, I hope that there is a nice solution...
> 

There are many such cases already in very simple domains. For example, in
Integer, we have - (minus), but not / (divide). Also minus is not close under
PositiveInteger or NonNegativeInteger. In Axiom, NNI has
CancellationAbelianMonoid under +, 
PI has Monoid under *. Integer has Ring.  So if the analogy is the category A is
Ring, the op is minus or divide, the domain of A is Integer, the subdomains are
NNI and PI. To answer your questions, we have simply to analyse how Axiom set up
such hierarchy.

What Axiom does is to let the subdomains belong to a more general category B for
which the category A belongs. In the above, B is either the
CancellationAbelianMonoid category or the Monoid category. In the category B,
Axiom exports op or opIfCan. For example,  Monoid exports recip:%->(%,"failed"),
and CancellationAbelianMonoid exports subtractIfCan. Also, IntegralDomain
exports exquo (which could have been named divideIfCan). 



> Example 1, Matroids
> 
> A "matroid" is a mathematical structure with one very, very important
> operation, namely "dualizing" which transforms a given matroid into
> another. Thus, one is tempted to have a category "MatroidCat", which exports an
> operation "dual: % -> %".

I assume you want MatroidCat to be the category of all matroids, in which case,
the dual operation is actually a domain constructor.  That is, the above
signature cannot do what you are aiming for:

    MatroidCat():Category == ... with
      dual: % -> %

because the % refers to a particular implementation of a domain which is a
matroid, not the category itself. The argument to dual is an element of a
matroid. A plausible signature is:

      dual:() -> MatroidCat()

which associates a matroid to the current matroid.

Let's review one definition of a matroid. According to Lawler (Combinatorial
Optimization, Networks and Matroids), p. 268, a matroid is a pair (E, I), where
E is a finite set, and I is a family of subsets of E satisfying two axioms:
(1) the empty set is in I, and every proper subset of a set in I is in I.
(2) If A and B are sets in I with p and p+1 elements respectively, then there is
a b in B, not in A such that A union {b} is in I.

Then given a matroid (E, I), there is always a dual matroid M^D = (E, I^D)
(Theorem 8.1, p. 280).

A matroid M therefore is really given by I, a set of subsets of E. We may
therefore think of "elements" of M as subsets of E. In order to construct the
dual of an arbitrary matroid, you need to be able to capture the defining sets E
and I. So, ideally (reading % to mean Set E)

    MatroidCat(): Category == Finite with
      underlyingSet: () -> Finite
      underlyingFamily: () -> Set %
      span: Set % -> Set %
      defining?: % -> Boolean  -- true if set is in underlyingFamily()
      independent?:  Set % -> Boolean
      circuit?: Set % -> Boolean
      ...
      dualSet: () -> Set %  -- constructs I^D
      dual: () -> MatroidCat() 
      dual()==Matroid(underlyingSet(), dualSet())
      ...
 

You can construct domains in MatroidCat, for example:
    
    Matroid(E:Finite, I:Set Set E):MatroidCat == ... with
      ...
      Rep:= Record(elist: Set E)

Alternatively, instead of using functions dual(), you can have a domain
constructor:

    DualSet(M:MatroidCat): Set Set underlyingSet M == ...
      
    Dual(M:MatroidCat):MatroidCat == 
      E:= underlyingSet(M)
      I:=underlyingFamily(M)
      J:=DualSet(M)
      Matroid(E, J)

A more practical implementation may have this outline:

   MatroidCat(E:Finite, I:Set Set E): Category == Finite with
     span: Set % -> Set %
     independent?:  Set % -> Boolean
     circuit?: Set % -> Boolean
     ...


   Matroid(E: SetCategory, I:Set Set E):MatroidCat(E,I) == ... with

   DualSet(E:SetCategory, I:Set Set E):List List E == 

   Dual(E:SetCategory, I:Set Set E):MatroidCat(E, DualSet(E,I)) == ...

   
If you do NOT want to implement dual as a domain constructor, then you may try
implementing Matroid as the DOMAIN of all matroids. However, Axiom does not
allow dependent types at the code level (only at the declaration level for
constructors).

   Matroid(): SetCategory == ...

     Rep:= Record(E:SetCategory, I:Set Set E)

probably won't work in Axiom, but Aldor may. The advantage is that this will
allow domain constructors implemented as functions, and operations on matroids
(not matroid elements) are also possible. So for example, one may test whether
two matroids are equal or isomorphic.
 
> However, a very important class of matroids, called "graphic matroids", do have
> this operation only if the matroid is "planar". (In fact, "graphic matroids"
> are simply undirected, unweighted graphs)
> 
> Since "graphic matroids" are so important, I would like to have a category
> "GraphicMatroidCat", and since they are matroids I'd like to have it inherit
> from "MatroidCat". But this is impossible, since the class is not closed under
> duality.

This needs some clarification.
Given any (not necessarily planar) graph G = (N, A), where N is the node set and
A the arc set, there is always a corresponding matroid M = (E, I) called a
graphic matroid. (Theorem 4.1, p. 271). Hence a graphic matroid always has a
dual matroid called the cographic matroid. So there are TWO matroids for every
graph G.

This means two domain constructors:

    GraphicMatroid(G: GraphCat):MatroidCat == ...

    CographicMatroid(G: GraphCat):MatroidCat == ...
    
Note: graphic matroids are matroids.

> Or, maybe even better, the dual of a graphical non-planar matroid would simply
> yield a general matroid.

This is what I understand from Lawler: Given a planar graph G, there corresponds
non-uniquely a plane graph (not a graph, but a drawing) from which one can
construct a geometric dual G*, which may be a graph or a multigraph. If G* is
planar, it is called a dual graph of G and denoted by G^D. (p. 33). If G has a
dual graph G^D, then the graphic matroid of G is the cographic matroid of G^D
and vice versa. A graph G is planar if and only if its graphic matroid is
cographic, which is if and only if its cographic matroid is graphic. (p. 281).

This means more domain constructors:

   Planar?(G:GraphCat):Boolean == ...  (in other words, G has Planar)

   Draw(G:GraphCat): ??? == ... (this is not practical!)

   GeometricDual(G:GraphCat):GraphCat == ... 

   Dual(G:GraphCat):GraphCat == ...

   Equal(G1:GraphCat, G2:GraphCat): Boolean == ...

Again, ideally, we can do this:

   GraphCat(...):Category == ...
     nodeSet: () -> Finite
     arcSet: () -> List DirectProduct(2, nodeSet())
     graphicMatroid:() ->MatroidCat
     cographicMatroid:() ->MatroidCat
     planar?: () -> Boolean
     geometricDual:() -> Union(GraphCat, "failed")
     dual: () -> Union(GraphCat, "failed")
     equal: DirectProduct(2, GraphCat) -> Boolean

One last comment: this has little to do with the closure problem.    
 
> Example 2, Differential Equations
> 
> A Holonomic function is a function f -- say in one variable x -- that satisfies
> a differential equation with polynomial coefficients:
> 
>   p_k(x) f^(k) (x) + ... + p_2(x) f''(x) + p_1(x) f'(x) + p_0(x) f(x) = q(x)
> 
> where f^(k) is the k_th derivative of f and p_i and q are polynomials.
> 
> It is quite easy to see that the class of holonomic functions is closed under
> integration, i.e., integrating a holonomic function yields again a holonomic
> function. This is quite an important property, of course, so a priori, I'd like
> to export it in "HolonomicCat".
> 
> If we take k=0 in the equation above we obtain the class of rational
> functions. Since rational functions are so important, I'd like to have a
> category "RatCat". However, we all know that the class of rational functions is
> *not* closed under integration, the simplest example being 1/x.

The integrate operation is more like the minus or divide operation. Since they
operate on elements (not domains), you can simply export integrateIfCan in
RatCat.

The two examples you gave present two different problems.

\start
Date: 05 Apr 2006 04:26:14 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: typo in src/boot/Makefile.pamphlet

Tim Daly writes:

| patch applied.
| fixed in the next release.

Thanks!

Is there a way to have the revision number (version number?) at which
the trunk is on a daily basis?  I find that to be a very useful
functionality for tracking the various branches and revisions (and
checking user/developer error).

For example, in GCC we have cron job that updates the version string
daily -- and that version string is built into the compiler, reported
by 'gcc -v'.

My current copy of Axiom trunk reports today it is at "patch-47",
which is exactly what it reported about a week ago -- "yes, I did a 
'tla update'".  

\start
Date: Tue, 4 Apr 2006 23:24:58 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: typo in src/boot/Makefile.pamphlet

it's still at patch-47. 
updates are done on a best-effort, two-month interval.
i've been heavily buried in work, working hard on the 
maple integration-bug study, and dealing with an 
evolving personal issue which has caused a lag.
i'm in the process of creating a new patch now. 
testing is going on and i'm hand-checking all of the
input files since we made a deep change to the system
(macroexpandall).

since we use arch which uses changesets the version number
changes very slowly. patches are collected and grouped into
a single changeset (yes, i know that's counter to the philosophy
of changesets) so patch-47 is correct.

we had a mailing list discussion over a year ago on this question
of frequency of updates and settled on a best-effort, two-month interval.

\start
Date: 05 Apr 2006 04:55:44 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: typo in src/boot/Makefile.pamphlet

Tim Daly writes:

| it's still at patch-47. 
| updates are done on a best-effort, two-month interval.
| i've been heavily buried in work, working hard on the 
| maple integration-bug study, and dealing with an 
| evolving personal issue which has caused a lag.
| i'm in the process of creating a new patch now. 
| testing is going on and i'm hand-checking all of the
| input files since we made a deep change to the system
| (macroexpandall).

many thanks; I wish you good luck.

| since we use arch which uses changesets the version number
| changes very slowly. patches are collected and grouped into
| a single changeset (yes, i know that's counter to the philosophy
| of changesets) so patch-47 is correct.

OK.

| we had a mailing list discussion over a year ago on this question
| of frequency of updates and settled on a best-effort, two-month interval.

Aha, I see.  Somehow I understood that the "wider" public will see
only the two-month interval, while the developers could see immediate
patches (I'm mostly initerested in the other changes that were
suggested and applied, not in the "ennd" thingy).  Since the
developers have write access, I believe it would relieve the burden on
you if they could check-in patches, after public review and we have
procedure for that (we already have procedure for producing and
testing patches).

\start
Date: Tue, 4 Apr 2006 23:19:08 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: typo in src/boot/Makefile.pamphlet

On Tuesday, April 04, 2006 10:56 PM Gabriel Dos Reis wrote:
> ...
> Somehow I understood that the "wider" public will see only
> the two-month interval, while the developers could see
> immediate patches (I'm mostly initerested in the other
> changes that were suggested and applied, not in the "end"
> thingy). Since the developers have write access, I believe
> it would relieve the burden on you if they could check-in
> patches, after public review and we have procedure for that
> (we already have procedure for producing and testing patches).
>

Ah, now wouldn't it be wonderful if we actually had a group
of Axiom developers who were willing and able to do what you
suggest! As far as I know, in two years I am the only one
besides Tim who has ever committed anything to the main
branch and I haven't done that in over a year... :(

I think we need a theory to explain why what you suggest has
not happened yet. Here are some possible explanations (in no
particular order):

1) the literate programming (pamphlet) format is more effort
   that most people are willing to commit to the project.

2) Tim's manual, re-check-everything-twice is intimidating
   to other developers -- nobody wants to commit their
   "mistakes" to the archive.

3) Setting up and using arch with sftp write access is too
   complex. It's easier to just let Tim do it.

4) There are not enough people who have sufficiently deep
   experience with the Axiom source code and those that do
   are already too busy doing other things.

5) The centralized source code repository model sucks. The
   current multiple-branch approach in the Axiom archive is
   not being used effectively. People are still unwilling to
   take responsibility for maintain a particular centrally
   accessible branch.

I think we need cures for some (or all) of these potential
problems before Axiom development can approach anything like
the development model for gcc.

\start
Date: 05 Apr 2006 06:30:37 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: re: typo in src/boot/Makefile.pamphlet

Bill Page writes:

| On Tuesday, April 04, 2006 10:56 PM Gabriel Dos Reis wrote:
| > ...
| > Somehow I understood that the "wider" public will see only
| > the two-month interval, while the developers could see
| > immediate patches (I'm mostly initerested in the other
| > changes that were suggested and applied, not in the "end"
| > thingy). Since the developers have write access, I believe
| > it would relieve the burden on you if they could check-in
| > patches, after public review and we have procedure for that
| > (we already have procedure for producing and testing patches).
| > 
| 
| Ah, now wouldn't it be wonderful if we actually had a group
| of Axiom developers who were willing and able to do what you
| suggest!

I've seen the group of people interested in "hacking" Axiom growing,
so I believe the group of "core" people can grow too, if the entry
barrier is not too high.

| As far as I know, in two years I am the only one
| besides Tim who has ever committed anything to the main
| branch and I haven't done that in over a year... :(
| 
| I think we need a theory to explain why what you suggest has
| not happened yet. Here are some possible explanations (in no
| particular order):
| 
| 1) the literate programming (pamphlet) format is more effort
|    that most people are willing to commit to the project.

Though pmaphlet format might not be the best on the planet, I do buy
the "literate programming" idea.  My experience with other projets is
that divergence between documentation and codes is one of the most
fertile and worst source of bugs and maintaince nightmarre.

| 2) Tim's manual, re-check-everything-twice is intimidating
|    to other developers -- nobody wants to commit their
|    "mistakes" to the archive.

I think the current centralization indeed has some weaknesses we can
improve on.  

If I can share my exprience with GCC, we have basically various level
of maintainers

   * maintainers with global write privilege:  these people have been
     hacking on the compiler for sufficient time that they have
     demonstrated a good understanding of the main structure.  They
     can modify any area of the compiler, though they will try hard
     not to overrule specialized maintainers.  

  * component maintainers:  these are people would have contributed
    components of the compiler (say front-end, middle-end, back-end,
    build machinery, targets) and know those areas very well.  They
    can commit patches to those areas without asking "permission".
    They "own" that area. A component maintainer when contributing to
    an area outside its "blessed kingdom" needs review and approval
    from the specialized component maintainers.

  * write after approval: these people are typically "new" or
    occasional contributors and have no special expertise or no
    immediate interest in endorsing component maintainership.


Interestingly, we may not that the old gcc project "died" precisely
because there was only one person who could commit and make the
release.  The EGCS experience (which later was renamed GCC) was
successful precisely because the maintainership was distributed and
vitality was prominent in the sense that applied patches were
instantly available -- many people work incrementally, so they want to
submit something first and improve on it in successive passes; that
work only when there it no too long delay between reviews and actual
availability of patches.

| 3) Setting up and using arch with sftp write access is too
|    complex. It's easier to just let Tim do it.

Somewhere, we need someone who keeps track of the permission,
copyright and all that stuff.  I believe Tim is doing an excellent job
there.  However, I also believe we need a less intimidating set up
proceudre and version control system (yes, that is a taboo subject,
but we do need to do something about it).

| 4) There are not enough people who have sufficiently deep
|    experience with the Axiom source code and those that do
|    are already too busy doing other things.

this usually comes with time, provided that the entry barrier is not
too high.  At least, that is what I have observed for GCC over a
decade.  GCC is really complex and intimidating. 
It is amazing to see how people come in, first intimidated by
the very complex structure of GCC, and gradually builds understanding
and expertise.  Key factors for that, I believe, are:

   * instant availability of patches applied to mainline

   * public informative review that helps gain understanding of why
     things are the way they are, possible improvements, and things
     that should not be tried.  That is very essential to attain
     critical mass of people understanding the system.

     I've learnt a lot about Axiom through discussions between you,
     Tim and others. I think that should happen more often, on patches
     -- not just in abstract ;-)

| 5) The centralized source code repository model sucks. The
|    current multiple-branch approach in the Axiom archive is
|    not being used effectively. People are still unwilling to
|    take responsibility for maintain a particular centrally
|    accessible branch.

I'm not sure.  The current centralized source code repository is
good.  What we need is more vitality in the source code.  Two months
without seeing any changes in the trunk source sounds like a death.
We need to show that the trunk is alive.  The more you show activity,
the more likely you'll attract people.  The easier you make it for
people to change codes, submit patches and get them 
review, the more you attract people.

| I think we need cures for some (or all) of these potential
| problems before Axiom development can approach anything like
| the development model for gcc.

I do not expect perfect match with GCC model (there are many aspects
of it I do not like but that is a different debate), but I think we
can address those problems today without too much of pain, provided
we're willing to lower the entry barrier.  For example, I hope to
succeed in attracting students to Axiom, but that would succeed only
if they are not intimidated. 

\start
Date: 05 Apr 2006 10:08:31 +0200
From: Martin Rubey
To: William Sit
Subject: Re: operations working in general, but not in special cases -- help needed

Dear William, *

thanks a lot for your answer. I think that you clarified the issue quite a bit,
but I still have to think about it.

A short reply...

William Sit writes:

> > Example 1, Matroids
> > 
> > A "matroid" is a mathematical structure with one very, very important
> > operation, namely "dualizing" which transforms a given matroid into
> > another. Thus, one is tempted to have a category "MatroidCat", which exports an
> > operation "dual: % -> %".
> 
> I assume you want MatroidCat to be the category of all matroids, 

No, at least not originally. I wanted MatroidCat be the "category" (in the
sense of axiom/aldor) of those domains, which represent matroids. I.e., an
element of a domain which in turn belongs to MatroidCat would be a matroid.

> in which case, the dual operation is actually a domain constructor.  That is,
> the above signature cannot do what you are aiming for:
> 
>     MatroidCat():Category == ... with
>       dual: % -> %
> 
> because the % refers to a particular implementation of a domain which is a
> matroid, not the category itself. The argument to dual is an element of a
> matroid. A plausible signature is:
> 
>       dual:() -> MatroidCat()
> 
> which associates a matroid to the current matroid.

So, in your view, MatroidCat would contain all matroids, and a domain belonging
to MatroidCat would be a specific matroid?
 
> If you do NOT want to implement dual as a domain constructor, then you may
> try implementing Matroid as the DOMAIN of all matroids. However, Axiom does
> not allow dependent types at the code level (only at the declaration level
> for constructors).
> 
>    Matroid(): SetCategory == ...
> 
>      Rep:= Record(E:SetCategory, I:Set Set E)
> 
> probably won't work in Axiom, but Aldor may. The advantage is that this will
> allow domain constructors implemented as functions, and operations on
> matroids (not matroid elements) are also possible. So for example, one may
> test whether two matroids are equal or isomorphic.

That's what I had in mind.

> Given any (not necessarily planar) graph G = (N, A), where N is the node set and
> A the arc set, there is always a corresponding matroid M = (E, I) called a
> graphic matroid. (Theorem 4.1, p. 271). Hence a graphic matroid always has a
> dual matroid called the cographic matroid. So there are TWO matroids for every
> graph G.

Well, yes. Usually one says that the graphic matroid corresponds to the graph,
though.
 
> This means two domain constructors:
> 
>     GraphicMatroid(G: GraphCat):MatroidCat == ...
> 
>     CographicMatroid(G: GraphCat):MatroidCat == ...

If I follow this route I should put all matroidal properties of graphs into
MatroidCat, and only those properties which are not matroidal into GraphCat I
think I like this idea.

> > Example 2, Differential Equations
> > 
> > It is quite easy to see that the class of holonomic functions is closed
> > under integration
> > 
> > However, we all know that the class of rational functions is *not* closed
> > under integration
> 
> The integrate operation is more like the minus or divide operation. Since
> they operate on elements (not domains), you can simply export integrateIfCan
> in RatCat.

yes. 

> The two examples you gave present two different problems.

It very much depends on how you view the problem(s). Of course, taking your
approach, these are different problems, but I do think that one can see them as
a single problem, too.

However, I do like your approach, so I will give it a try.

\start
Date: 05 Apr 2006 11:05:25 +0200
From: Martin Rubey
To: Christian Aistleitner
Subject: Re: [Aldor-l] operations working in general, but not in special cases -- help needed

Christian Aistleitner writes:
> I am not familiar with matroids, so let me get this straightened out.
> 
> 1. Graphic non-planar matroids do not provide a way to compute a dual
>    element.

Well, no. The dual of a graphic non-planar matroids is not a graphic matroid
again. It is perfectly well defined on the level of matroids. 

Consider the rationals versus the integers. Then only units are invertible in
the integers, but all non-zero elements are invertible in the rationals.

> 2. Graphic planar matroids are able to compute duals for all elements.

yes.

> 3. Graphic non-planar three-connected Matroids do not have duals at all.

no. See 1.

> 4. Graphic three-connected Matroids allow recovering of vertices.

yes.

> 5. Planar graphic matroids are called "matroids".

yes.

I think that William Sit got it right -- and his solution is simple, too -- but
I don't have time right now to check the details. He sent his mail also to
Aldor-l, so you should have gotten it...

\start
Date: Tue, 04 Apr 2006 11:39:29 +0200
From: Christian Aistleitner
To: Martin Rubey,
Subject: Re: [Aldor-l] operations working in general, but not in special cases -- help needed

Dear Martin,

> We have a category A with an operation op: % -> %. However, there are  
> natural
> subdomains of domains of A, which are no longer closed under op.

if I understood you correctly, you did not mean "closed under op" but "op  
is a partial function" -- which is a completely different thing.

> Example 1, Matroids

> A "matroid" is a mathematical structure with one very, very important
> operation, namely "dualizing" ...

If a matroid is required to have a "dualizing function", then a graphical  
matroid cannot be a matroid. Simply because it does not provide the total  
function "dualize"

However, a graphical matroid can "contain" a matroid.

So the abstract setting is "graphical matroid" and the specialized one is  
"matroid". Not the other way round.

> Example 2, Differential Equations

Again the same problem as above.

Of course you can introduce a category

OpSubstructureType: Category == with {
   opable?: % -> Boolean;
   +++if   opable? a, then op( a ) dualizes.
   +++if ~ opable? a, then the behaviour of op is undefined
   op: % -> %; -- op( a ) with ~ opable?( a ) crashes the program
   opIfCan: % -> Partial %
}

and use it in all places, but think about what is the more abstract  
setting and what the specialized one.
For me, a property of a generalization has to hold in its spezialization.
And a property of a specialization does not have to a generalization.

So I'd suggest

+++\begin{addescription}{provides a category for graphical matroids}
+++Some element of a \adthistype may be dualizable.
+++\end{addescription}
GraphicalMatroidType: Category == with {

   dualizeable?: % -> Boolean;

   +++\begin{addescription}{computes the dual element}
   +++if   dualizeable? a, then op( a ) dualizes.
   +++if ~ dualizeable? a, then the behaviour of op is undefined
   +++\end{addescription}
   dualize: % -> %;

   dualizeIfCan: % -> Partial %
}

and

+++\begin{addescription}{provides a category for matroids}
+++Every element of a \adthistype has to be dualizable.
+++\end{addescription}
MatroidType: Category == with {
   GraphicalMatroidType;
   default {
     dualizeable?( a: % ): Boolean == {
       true
     };
     dualizeIfCan( a: % ): Partial % == {
       [ (dualize@%) ]
     };
   }
}

\start
Date: Wed, 05 Apr 2006 10:48:06 +0200
From: Christian Aistleitner
To: Martin Rubey
Subject: Re: [Aldor-l] operations working in general, but not in special cases -- help needed

Hello Martin,

>> > We have a category A with an operation op: % -> %. However, there  
>> are  natural
>> > subdomains of domains of A, which are no longer closed under op.
>>
>> if I understood you correctly, you did not mean "closed under op" but  
>> "op  is a
>> partial function" -- which is a completely different thing.
>
> Could you please elaborate.

Take Q\{0} and multiplicative inverse of an element.

{ 1 }    is closed under inversion and inversion is a total function on  
{1}.

{ 1, 2 } is not closed under inversion ( 1/2 is not in {1,2} ).
Hence inversion is a partial function on { 1, 2 }.
But 1/2 can be computed in Q\{0}.

Consider { 0, 1 }. Inversion is not defined for 0. Therefore inversion is  
a partial function on { 0, 1 }.
In contrast to the situation before, you cannot say "{ 0, 1 }" is closed  
under inversion. Neither the opposite. Since inversion is not defined for  
0.

>> > Example 1, Matroids
>>
>> > A "matroid" is a mathematical structure with one very, very important
>> > operation, namely "dualizing" ...
>>
>> If a matroid is required to have a "dualizing function", then a  
>> graphical
>> matroid cannot be a matroid. Simply because it does not provide the  
>> total
>> function "dualize"
>>
>> However, a graphical matroid can "contain" a matroid.
>>
>> So the abstract setting is "graphical matroid" and the specialized one  
>> is
>> "matroid". Not the other way round.
>
> In a way you are right, of course - I followed the same reasoning
> originally. However, I do feel a little uneasy saying that a graphical  
> matroid
> is not a matroid...

A name is just a name ...

The important part is the structure of the things. That's what you want to  
model.
And the structure tells you that a "graphical matroid" is not a "matroid".
The name does not affect the inner structre of an object.

There are a lot of similar situation in mathematics.
Consider for example polynomials.
In computer algebra a polynomial ring is typically commutative. If it is  
not commutative (in whatever way), we say "non-commutative polynomial  
ring".
However, "non-commutative polynomial ring" is the generalization and  
"polynomial ring" is the specialization.
Replace "non-commutative" by "graphical" and "polynomial ring" by  
"matroid" and you will see, the correspondance.

Or maybe the example Ralf gave convinces you ;)

> Furthermore, there is another complication:
>
> For a certain class of graphical matroids, namely those which are  
> 3-connected,
> we can recover the vertices. I.e.,
>
> general Matroids have duals but no vertices
>
> graphic non-planar three-connected Matroids do not have duals but do have
> vertices
>
> So, what to do?

I am not familiar with matroids, so let me get this straightened out.

1. Graphic non-planar matroids do not provide a way to compute a dual  
element.
2. Graphic planar matroids are able to compute duals for all elements.
3. Graphic non-planar three-connected Matroids do not have duals at all.
4. Graphic three-connected Matroids allow recovering of vertices.
5. Planar graphic matroids are called "matroids".

I got number 1 wrong in my previous post. I thought, a graphical matroid  
can dualize _some_ of its elements. This laid way to the "partial  
function" thing.

So the base category is
GraphicalMatroid

You have several qualities for GraphicalMatroids:
-"planarness"
-"three-connected-ness"

I assume, that the properties coming from "planarness" and  
"three-connected-ness" are bound to graphical matroids and not a general  
mathematic construct (e.g.: the connection between a planar near-ring and  
a near-ring is not connected in any way with the connection between planar  
graphic matroids and graphic matroids -- At least I cannot see an obvious  
connection). If this assumtion is wrong, than I'd introduce general  
categories "PlanarType" and "ThreeConnectedType". However, let's assume  
the assumption is valid.

GraphicalMatroidType: Category == with {
}

PlanarGraphicalMatroidType: Category == with {
   GraphicalMatroidType;

   dualize: % -> %;
}

ThreeConnectedGraphicalMatroidType: Category == with {
   GraphicalMatroidType;

   recover: ( %, % ) -> %;
}

This models 1., 2., and 4..
I would not model 5., since this is just a renaming. However, I in the  
documentation of PlanarMatroidType, I would mention that "planar graphical  
matroids" are called "matroids".
3. is awkward, since only planar graphical matroids have duals. So non  
planar, already means that they have no duals. Three-connected is  
superfluous. Therefore, 3. is redundant and already contained.


Obviously, I misunderstood the problem, as my solution seems too easy :((

\start
Date: Wed, 05 Apr 2006 09:49:58 +0200
From: Christian Aistleitner
To: Bertfried Fauser, Martin Rubey
Subject: Re: [Aldor-l] Re: operations working in general, but not in special cases -- help needed

Hi Bertfried,

> Category Matroid
>
>   expoerts dual
>
> then
>
> Category GraphMatroid
>
>   inherits Matroid
> =>modifies dual -> dual= if has planar then dual else error
>   exports  new functionality

thereby, you would demolish the semantics of the dual of Matroid.

I would strongly discourage from using such a solution. (Compare  
covariance and contravariance for parameters)
If I understood you correctly, right now such a solution is not possible  
in Axiom anyways. And this is actually good!

According to Martin's description of matroids and "graphical matroids", a  
"graphical matroid" is _not_ a matroid.
So a "graphical matroid" should _not_ be modelled as a specialisation of  
matroid.

\start
Date: Wed, 05 Apr 2006 12:23:36 +0200
From: Ralf Hemmecke
To: William Sit
Subject: Re: operations working in general, but not in special cases -- help needed

Dear William,

I like most of what you have written, but I must oppose against a few 
things.

>> Example 1, Matroids
>>
>> A "matroid" is a mathematical structure with one very, very important
>> operation, namely "dualizing" which transforms a given matroid into
>> another. Thus, one is tempted to have a category "MatroidCat", which exports an
>> operation "dual: % -> %".
> 
> I assume you want MatroidCat to be the category of all matroids, in which case,
> the dual operation is actually a domain constructor.  That is, the above
> signature cannot do what you are aiming for:
> 
>     MatroidCat():Category == ... with
>       dual: % -> %
> 
> because the % refers to a particular implementation of a domain which is a
> matroid, not the category itself.

Sorry, I have not yet read about Matroids, but in simple terms it is that
        dual: % -> %
transforms a concrete matroid M=(E, I) to M^D=(E, I^D) but doing this by 
assuming I^D = I (and thus M=M^D) which need of course not be the case).

So clearly that signiture is wrong.

 > The argument to dual is an element of a
> matroid. A plausible signature is:
> 
>       dual:() -> MatroidCat()
> 
> which associates a matroid to the current matroid.

That sounds promising but here I must oppose. The reason is that the 
resulting dual domain will probably be not very useful.

[snip]

But let's analyse this...

>     MatroidCat(): Category == Finite with
>       underlyingSet: () -> Finite
>       underlyingFamily: () -> Set %
>       span: Set % -> Set %
>       defining?: % -> Boolean  -- true if set is in underlyingFamily()
>       independent?:  Set % -> Boolean
>       circuit?: Set % -> Boolean
>       ...
>       dualSet: () -> Set %  -- constructs I^D
>       dual: () -> MatroidCat() 
>       dual()==Matroid(underlyingSet(), dualSet())
>       ...

Clearly, that category is very much involved and cannot be compiled 
without knowing about the constructor Matroid(E, I). But it's not that 
what I find problematic. It is the appearance of MatroidCat within the 
"with" expression. What comes after the == depends on what comes before.
I cannot say, that I like this very much. Would you do something like 
that in (mathematical) category theory? The "with" expression alone is 
not a value until MatroidCat is known.

What else is bad is that the dual is always constructed by the domain 
constructor Matroid. You don't allow other implementations (other 
constructors).

> Alternatively, instead of using functions dual(), you can have a domain
> constructor:
> 
>     DualSet(M:MatroidCat): Set Set underlyingSet M == ...
>       
>     Dual(M:MatroidCat):MatroidCat == 
>       E:= underlyingSet(M)
>       I:=underlyingFamily(M)
>       J:=DualSet(M)
>       Matroid(E, J)

Well, that demonstrates what I mean by "the resulting dual domain will 
probably be not very useful" above.

Suppose you create a very special matroid M which inherits from 
MatroidCat but additionally from many other categories. If you now say

N == Dual(M)

you will get something that is constructed by the constructor Matroid 
(which might actually not be that what you want -- remember there are 
also several implementations of polynomials and they are all good for 
something).

So the next idea would be something like

   Dual(M: MatroidCat, MAT: ??? -> MatroidCat): MatroidCat ==
     MAT(underlyingSet M, DualSet M);

Well, what can you do if you now say

N == Dual(M, MyMatroid)

? Actually not much, since that N is of type MatroidCat and nothing 
more. No additional features are available even if MyMatroid would 
return something of category MyMatroidCat that is much richer than 
MatroidCat itself.

With the above Dual constructor, you explicitly restrict the exports to 
MatroidCat. And I would have no other idea to add features than to use 
"pretend". Brrrrrhhh.

> A more practical implementation may have this outline:
> 
>    MatroidCat(E:Finite, I:Set Set E): Category == Finite with
>      span: Set % -> Set %
>      independent?:  Set % -> Boolean
>      circuit?: Set % -> Boolean
>      ...
> 
> 
>    Matroid(E: SetCategory, I:Set Set E):MatroidCat(E,I) == ... with
> 
>    DualSet(E:SetCategory, I:Set Set E):List List E == 
> 
>    Dual(E:SetCategory, I:Set Set E):MatroidCat(E, DualSet(E,I)) == ...

I like that somehow much better, but the same "restriction process" as 
above takes place. Things are not so easy with a dual functor.

> If you do NOT want to implement dual as a domain constructor, then you may try
> implementing Matroid as the DOMAIN of all matroids. However, Axiom does not
> allow dependent types at the code level (only at the declaration level for
> constructors).
> 
>    Matroid(): SetCategory == ...
> 
>      Rep:= Record(E:SetCategory, I:Set Set E)
> 
> probably won't work in Axiom, but Aldor may.

Did you really mean SetCategory? So to create a new element you would 
write a function.

   matroid(A: SetCategory, B: Set Set A): % == per [A, B];

and call it with

   matroid(Integer, [[1,2], [3,4,5]]);

That sounds to me as follows: If E' \supset E and I \subseteq Power(E) 
then the matroids (E, I) and (E', I) are the same. I cannot believe that.

\start
Date: Wed, 5 Apr 2006 07:36:03 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis
Subject: Developers and Axiom (was Re: typo in src/boot/Makefile.pamphlet)

--- Bill Page wrote:

> Ah, now wouldn't it be wonderful if we actually had a group
> of Axiom developers who were willing and able to do what you
> suggest! As far as I know, in two years I am the only one
> besides Tim who has ever committed anything to the main
> branch and I haven't done that in over a year... :(
> 
> I think we need a theory to explain why what you suggest has
> not happened yet. Here are some possible explanations (in no
> particular order):
> 
> 1) the literate programming (pamphlet) format is more effort
>    that most people are willing to commit to the project.

I'm not sure this is such a problem (at least, for me it is not - I
find it forces me to think about the problem and lets me document my
thoughts, which are both Good Things.)  I would like to have a better
editing environment for pamphlets, and I have somewhere the beginnings
of a literate-document Emacs mode based on work by Jay and Ralf.  I'll
have to get back to that and see if I can push it more towards proper
functionality.  (As a literate document it's probably literate to the
point of blathering, but since I didn't and don't know much about Emacs
I found it helpful - if and when it gets stuck into Axiom someone with
a better grasp of things can trim it down to sanity.) It needs to be
licensed under GPL because otherwise a truly insane amount of works
needs to be duplicated instead of being re-used from other sources, but
since Emacs itself is GPL hopefully for this one file that would be OK?

> 2) Tim's manual, re-check-everything-twice is intimidating
>    to other developers -- nobody wants to commit their
>    "mistakes" to the archive.

Heh - that part doesn't worry me too much, except the concern that I
might put in some epic stupidity that doesn't get noticed for a while.

> 3) Setting up and using arch with sftp write access is too
>    complex. It's easier to just let Tim do it.

Arch is certainly complex - I know I need to sit down with the
documentation and really study it.

> 4) There are not enough people who have sufficiently deep
>    experience with the Axiom source code and those that do
>    are already too busy doing other things.

Probably my biggest problem - my job has undergone a radical change in
the last month and a half and I have found myself with a lot more time
sinks and responsibilities.  Hopefully in the next few weeks things
will settle down into more of a routine again.

> 5) The centralized source code repository model sucks. The
>    current multiple-branch approach in the Axiom archive is
>    not being used effectively. People are still unwilling to
>    take responsibility for maintain a particular centrally
>    accessible branch.

I think, in my case at least, I feel like most of what I will be
capable of doing in the short term doesn't warrant an entire new
branch.  The emacs mode, for example, is just a single incomplete .el
file, not (yet) of much use to anyone.

Also, I think a lot of us are waiting on two things before we begin to
mess with Axiom in a major way:

1)  As I understand it, Tim is doing a rewrite of much of the core of
the system into modern, sane Lisp.  I rather doubt most of us can match
the skill and knowledge he brings to that task, and I know I can't even
come close.  I don't want to start mucking at that level when the odds
are high I would produce an inferior product.

Possible corrective action:  I don't know how accurate my perception of
what Tim was/is doing is here, so I might be totally off base. 
(Apologies to Tim if I am.)  But what might be a good way to ease new
folks into this would be to define certain sections of the code that
can be cleaned up without needing significant awareness of the overall
design issues of Axiom.  Not insisting on literate documentation at the
outset, but just point out some areas where budding or good lisp
programmers could help with minimal chance of causing harm or doing
work that might become redundant/irrelevant.

2)  Aldor vs. SPAD.  We are agreed that Aldor is the way to go in the
future, both for refactoring old code and creating new code, but we
still have no free Aldor compiler and no word on when we might have
one.  So I think a lot of us are holding off on major work until the
issue is resolved one way or the other.

Possible corrective action:  We've GOT to do something about this. 
Bill, IIRC you mentioned in an earlier email that a contact at NAG was
open to discussing the issue?  Without offense to Aldor.org, which I'm
sure has things going on behind the scenes we don't (and shouldn't)
know about, perhaps we should open discussions with NAG about the
issue.  I think there was work that occurred at Aldor.org post-NAG,
which would definitely be useful to us and should be pursued, but if we
can at least start working with A version of Aldor I think it will be a
Good Thing.  If Aldor.org's improvements can be eventually released we
will be in a good position to incorporate them into our branch, and in
the meantime the ambiguity of Aldor in Axiom can end and we can start
transitioning away from SPAD for real.

\start
Date: Wed, 5 Apr 2006 12:53:12 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Developers and Axiom (was Re: typo in src/boot/Makefile.pamphlet)

CY writes:

>                                         I would like to have a better
> editing environment for pamphlets, and I have somewhere the beginnings
> of a literate-document Emacs mode based on work by Jay and Ralf. 

and another private email writes:

> I've been looking at a number of literate programming tools for
> lisp/scheme (narrowing to l2t and the Scheme Elucidator), but ultimately
> neither does what I want - the former actually seems to eschew the main
> benefit of literate programming by separating code from its commentary;
> the latter cannot deal at all with local definitions or modules (though I
> think I can see how to fix this, the time required is likely more than I
> have). So I've come back to noweb.

so this is the method i use and i find it very productive:

noweb is a trivial idea really. 
 1) create a latex file that explains the program
 2) embed the source code for each program chunk into the latex file
    surrounded by the "chunk definition tag"

    <<any string>>=
        code
    @
 
 3) call the resulting file foo.pamphlet
 4) to get the documentation do:
     
     noweave foo.pamphlet >foo.tex
     latex foo.tex
     xdvi foo.dvi

    all noweave really does is change the chunks into verbatim blocks.

 5) to get the program do

     notangle foo.pamphlet >foo.c
     gcc foo.c

    all notangle really does is collect the chunk definitions in a hashtable
    on the first passs and then recursively expand them on the second pass.

in general i find the most effective way to work is:

 a) start emacs

emacs -nw 

 b) (split the screen in two) this gives you two buffers 
    at once on the screen the "C-x o" visits the "other buffer" 
    so you can switch back and forth

C-x 2 

 c) edit the foo.pamphlet file

C-x C-f foo.pamphlet

 d) start a shell in the other buffer

C-x 0
M-x shell

 e) now you have half the screen visiting the foo.pamphlet file
    and the other half of the screen running a shell in an emacs buffer.

    The general editing sequence is as follows:
   
    edit the file, 
    C-x C-s to save the changes, 
    C-x o to switch to the shell
    run notangle 
    run noweave

 f) but we can simplify this process considerably.

    1) we want to see the changes in the document as we make them.
       to so this use xdvi to visit the foo.dvi file thus:

xdvi foo.dvi &

       xdvi has the property that if it is running and the dvi file
       has changed it will automatically reread the dvi file and 
       display the changes. this means that every time we save the
       file and run latex we only need to click on the xdvi window
       and we see the new text immediately.

    2) create a makefile that automatically does all the work. call it
       Makefile.foo:

in Makefile.foo
=====================================================================

all: doc code test

doc:
	noweave -t8 -delay foo.pamphlet >foo.tex
	latex foo.tex
	latex foo.tex
	

code:
	notangle -R"code" foo.pamphlet >foo.c
	gcc -o foo foo.c

test:
	notangle -R"test" foo.pamphlet >testcase
	foo testcase

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

    make -f Makefile.foo 

    * this extracts the documentation and updates the dvi file
      (which we can see immediately by clicking on xdvi)
    * this extracts the code and compiles it
    * this runs the newly compiled code on the test cases

Note that the code in the literate program is assumed to be expanded
under the tag <<code>>= but you could make it anything by changing
the notangle line.

Note that the test cases in the literate program are assumed to be
expanded under the tag <<test>> but you could make it anything by
changing the notangle line



     3) now the real magic happens with emacs....

        in emacs it is possible to set the "compile" command or
        you can use a "command line macro". i use the macro approach.

        in emacs you can record a whole set of keystrokes and make
        them into a command line macro that you can execute with "C-x e"

        after i've changed the source file i want to 
          a) save the changes (C-x C-s)
          b) switch to the shell buffer (C-x o)
          c) make -f Makefile.foo to run the makefile
          d) switch back to my program to continue editing.

        using the command line macro i can have this all happen in 1 keystroke
   
        to create a command line macro you type "C-x (" to start recording
        and "C-x )" to stop recording.

        so, with a split screen and the cursor in your code buffer and
        the shell in the other buffer do:

        C-x (                 <== start recording
        C-x C-s               <== save the changes
        C-o                   <== switch to the shell
        M-x >                 <== go to the end of the shell buffer
        make -f Makefile.foo  <== run make
        C-x o                 <== switch back to the code buffer
        C-x )                 <== stop recording

and now you have all the magic because "C-x e" does it all.
       
 do forever
   type your changes to your literate program, 
   type "C-x e" to noweave, latex, notangle, compile, test, and update xdvi
   click on xdvi to see the changes

i find it extremely productive. i run "C-x e" every 10 lines of changes
(about once every minute or two) so i know that the latest change will
compile, latex, and run the test cases properly.

\start
Date: Wed, 05 Apr 2006 18:33:58 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Developers and Axiom (was Re: typo in src/boot/Makefile.pamphlet)

Hello,

Unfortunately, I cannot do everything in zero time. Have you tried 
ALLPROSE. I want to integrate a variant of it (which is just the editing 
part) with Axiom, but I first have to figure out all this ARCH stuff.

So you must be a bit patient.

The basic idea is. You edit your files with two windows open. One is 
emacs and the other one is xdvi. Of course you edit your stuff in emacs 
where you would probably use mmm-mode (connected with aldor-mode, 
makefile-mode or whatever). Then you noweave and latex your stuff to 
show it in a prettyprinted form in xdvi (with many hyperlinks added). If 
you see in xdvi viewer a mistake, then (by using the inverse search 
facility of xdvi you jump immediately into the file in emacs (that works 
across file boundaries).

That's how I currently edit aldor files. And I hope I will some day be 
able to do it also for other files in Axiom.

But of course, some commands for emacs as Tim described are useful anyway.

Tim, is your way of editing somewhere on the wiki so that you simply 
could point other people to it?

We should have several such examples. I guess that would help new people 
to start working.

\start
Date: Wed, 5 Apr 2006 16:12:23 -0700
From: Antoine Hersen
To: list
Subject: Personel Section in MathAction ?

Hello,

When I am working on Axiom, I often have ideas, comments, "lesson learned",
TODO. They most of the time end-up in various notebooks, files, notes in
documents or nowhere. Some may have value for other but are not "front page
ready".

It will be nice to have a Perso section on MathAction much like the sandbox=
,
that is no diff are send to the list.

Will this be interesting for other people to ?
Easy to implement ?

Antoine Hersen

------=_Part_14128_14507486.1144278743990

Hello,<br><br>When I am working on Axiom, I often have ideas, comments, &qu=
ot;lesson learned&quot;, TODO. They most of the time end-up in various note=
books, files, notes in documents or nowhere. Some may have value for other =
but are not &quot;front page ready&quot;.
<br><br>It will be nice to have a Perso section on MathAction much like the=
 sandbox, that is no diff are send to the list.<br><br>Will this be interes=
ting for other people to ?<br>Easy to implement ?<br><br>Antoine Hersen
<br><br>

\start
Date: Wed, 5 Apr 2006 18:44:55 -0700 (PDT)
From: Cliff Yapp
To: Antoine Hersen
Subject: Re: Personel Section in MathAction ?

Maybe you want to take a look at http://portal.axiom-developer.org?

That's pretty much what I use it for ;-)

--- Antoine Hersen wrote:

> Hello,
> 
> When I am working on Axiom, I often have ideas, comments, "lesson
> learned",
> TODO. They most of the time end-up in various notebooks, files, notes
> in
> documents or nowhere. Some may have value for other but are not
> "front page
> ready".
> 
> It will be nice to have a Perso section on MathAction much like the
> sandbox,
> that is no diff are send to the list.
> 
> Will this be interesting for other people to ?
> Easy to implement ?
> 
> Antoine Hersen
> > _______________________________________________
> Axiom-developer mailing list
> list
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 

\start
Date: Thu, 06 Apr 2006 07:28:02 +0200
From: Christian Aistleitner
To: list
Subject: Re: [Aldor-l] operations working in general, but not in special cases -- help needed

Hello Martin,

looks like I did not understand correctly, what you mean by matroid and  
what you actually need.
However ...

> I think that William Sit got it right

...you got a solution to your problem.

> Are we going to meet on the workshop?

\start
Date: Wed, 05 Apr 2006 21:52:48 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: typo in src/boot/Makefile.pamphlet

Hi Gaby,

I am happy that you raised that problem.

On 04/05/2006 06:30 AM, Gabriel Dos Reis wrote:

> and expertise.  Key factors for that, I believe, are:
> 
>    * instant availability of patches applied to mainline

Well, it should be very simple that any patch that is sent to Tim is 
immediately applied to a branch axiom--main-unstable--1
That would be the hottest branch and always up-to date.
The axiom--main--1 branch would be the stable line. Code can only enter 
there if it has survived public review on the unstable branch.

In fact, we could have (and actually we have) several unstable branches 
already. There are already different people responsible for them and a 
policy of how to update things there is completely open. But you are 
right. It would be nice to have the "hottest" branch available.

I think that flexibility of tla is a bit too much. There are simple 
guidelines missing of how to do things efficiently without the need to 
read several hundred pages. (I am trying to learn already since I would 
like to contribute code.)

>    * public informative review that helps gain understanding of why
>      things are the way they are, possible improvements, and things
>      that should not be tried.  That is very essential to attain
>      critical mass of people understanding the system.

Since I have no idea about how this works, could you be a bit more specific?

\start
Date: 06 Apr 2006 10:27:55 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: typo in src/boot/Makefile.pamphlet

Ralf Hemmecke writes:

| Hi Gaby,
| 
| I am happy that you raised that problem.
| 
| On 04/05/2006 06:30 AM, Gabriel Dos Reis wrote:
| 
| > and expertise.  Key factors for that, I believe, are:
| >    * instant availability of patches applied to mainline
| 
| Well, it should be very simple that any patch that is sent to Tim is
| immediately applied to a branch axiom--main-unstable--1
| That would be the hottest branch and always up-to date.
| The axiom--main--1 branch would be the stable line. Code can only
| enter there if it has survived public review on the unstable branch.

I agree. Well, almost.  Almost because I do not believe *every* patch
should be applied to the branch.  I believe patches that survive
public review should be immediately applied.  It is good to have
unstable branch where experiments are conducted, but I think we need
one branch that is unstable but not too unstable.

| In fact, we could have (and actually we have) several unstable
| branches already. There are already different people responsible for
| them and a policy of how to update things there is completely
| open. But you are right. It would be nice to have the "hottest" branch
| available.

I'm willing to take responsability for that, but I need general
agreement from the community (especially from Tim) for having that
sort branch with the intent that patches applied there will move to
the stable branch when they have survived enough testing and satisfy
The Master (Tim!) taste.

| I think that flexibility of tla is a bit too much. There are simple
| guidelines missing of how to do things efficiently without the need to
| read several hundred pages. (I am trying to learn already since I
| would like to contribute code.)

Can we move to SVN? (yes, it is a taboo subject but...)

| >    * public informative review that helps gain understanding of why
| >      things are the way they are, possible improvements, and things
| >      that should not be tried.  That is very essential to attain
| >      critical mass of people understanding the system.
| 
| Since I have no idea about how this works, could you be a bit more specific?

Well, in general a victim sends a patch for review.  Component
maintainers and/or maintainers with global write privilege (Tim, for
instance) review the patch publically.  If the patch is fine, they say
"OK" (that is rare when the victim is not very familiar with the
system).  Otherwise, they technically comment on what are wrong
about the patch and suggest directions for improvements. If the patch
is outrageous, let say the patch suggests to sink Axiom, then an
answer might be "don't propose that again." :-)

\start
Date: Thu, 06 Apr 2006 10:40:17 +0200
From: Ralf Hemmecke
To: list
Subject: Latex Package problem

Hello,

I am just compiling patch-47 axiom on standard debian sarge.

My compilation stops in the middle of compiling the documentation and 
just continues after I have pressed enter.

I've tracked down the problem to that here (see below).

Any hint? You probably will not tell me that my teTeX is too old. I 
think debians standard tetex 2.0.2c-8 should be OK.

Ralf

woodpecker:~/OTHER/Axiom/axiom--main--1/src/doc>latex endpaper.pamphlet
This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5)
entering extended mode
(./endpaper.pamphlet
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, 
ngerman, b
ahasa, basque, catalan, croatian, czech, danish, dutch, finnish, greek, 
iceland
ic, irish, italian, latin, magyar, norsk, norsk, portuges, romanian, 
russian, s
lovak, slovene, spanish, swedish, turkish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/book.cls
Document Class: book 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/bk10.clo))
(/usr/share/texmf/tex/latex/hyperref/hyperref.sty
(/usr/share/texmf/tex/latex/graphics/keyval.sty)
(/usr/share/texmf/tex/latex/hyperref/pd1enc.def)
(/usr/share/texmf/tex/latex/config/hyperref.cfg)

! Package keyval Error: final undefined.

See the keyval package documentation for explanation.
Type  H <return>  for immediate help.
  ...

l.1744 \ProcessOptionsWithKV{Hyp}

\start
Date: Thu, 06 Apr 2006 11:11:43 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: re: typo in src/boot/Makefile.pamphlet

Hi Gaby,

> I agree. Well, almost.  Almost because I do not believe *every* patch
> should be applied to the branch.

You probably have more years of experience than me. ;-)

> I believe patches that survive public review should be
 > immediately applied.

Fine.

> It is good to have unstable branch where experiments are
 > conducted.

Yes, I think that is good. You will probably suggest that for those 
experimental branches there might be other people responsible not you.

GNU ARCH lets you do this easily.

 > but I think we need one branch that is unstable but not too unstable.

That's a good point. It sounds like a three stage system.

A golden branch that will be the stable version. (axiom--main--1)
A silver branch that will be the almost stable branch (that is where you
     opted for maintaining)
Several experimental branches, where one person (or a group of people)
     agrees on how they do development until the experiment becomes
     resonably stable to be ready for the silver branch.

I would like that. No matter if you take my (perhaps naive) suggestion 
or anything else, but we should make clear an development model for 
Axiom that is easier to learn and includes *public* review before Tim 
gets the final decision.

> | In fact, we could have (and actually we have) several unstable
> | branches already. There are already different people responsible for
> | them and a policy of how to update things there is completely
> | open. But you are right. It would be nice to have the "hottest" branch
> | available.
> 
> I'm willing to take responsability for that, but I need general
> agreement from the community (especially from Tim) for having that
> sort branch with the intent that patches applied there will move to
> the stable branch when they have survived enough testing and satisfy
> The Master (Tim!) taste.

You get my full support. And to the others: That is a generous offer we 
should not reject that and let long years of experience with gcc enter 
into the Axiom world. We need even more people like Gaby.

> | I think that flexibility of tla is a bit too much. There are simple
> | guidelines missing of how to do things efficiently without the need to
> | read several hundred pages. (I am trying to learn already since I
> | would like to contribute code.)

> Can we move to SVN? (yes, it is a taboo subject but...)

Although I by now somehow think I can live with tla, I believe that we 
should not prevent you from doing things with SVN. If you are willing to 
maintain the silver branch using SVN, I see no point why we shouldn't 
accept that.

Of course, SVN has some weaknesses (especially not being able to do a 
star-merge), but since you could live with CVS for many years, I am sure 
you can cope with that missing feature anyway.

And there is a strong point for SVN. People currently seem to believe 
that it is the successor of CVS and they are quite eager to learn SVN.
So I expect the barrier to Axiom would be lowered. And that is certainly 
more important than sticking to a very flexible tla.

Well, I am actually not saying to remove tla, but if Gaby wants to 
maintain the silver branch using svn, then fine. Anyone who still wants 
to use tla, can do it, too.

> | >    * public informative review that helps gain understanding of why
> | >      things are the way they are, possible improvements, and things
> | >      that should not be tried.  That is very essential to attain
> | >      critical mass of people understanding the system.
> | 
> | Since I have no idea about how this works, could you be a bit more specific?
> 
> Well, in general a victim sends a patch for review.  Component
> maintainers and/or maintainers with global write privilege (Tim, for
> instance) review the patch publically.  If the patch is fine, they say
> "OK" (that is rare when the victim is not very familiar with the
> system).  Otherwise, they technically comment on what are wrong
> about the patch and suggest directions for improvements. If the patch
> is outrageous, let say the patch suggests to sink Axiom, then an
> answer might be "don't propose that again." :-)

But for public review, I must see the patch applied somewhere. I am not 
a machine that can read native "diff" output. Sorry, but I think you 
need to teach a bit. And in order not to hide this course inside the 
mail archive, it would be just great, if you could open up a page on 
AxiomWiki and let us know. (Thanks in advance.)

\start
Date: 06 Apr 2006 11:28:09 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: re: typo in src/boot/Makefile.pamphlet

Ralf Hemmecke writes:

[...]

| > It is good to have unstable branch where experiments are
|  > conducted.
| 
| Yes, I think that is good. You will probably suggest that for those
| experimental branches there might be other people responsible not you.
| 
| GNU ARCH lets you do this easily.

yes, I guess so :-)

|  > but I think we need one branch that is unstable but not too unstable.
| 
| That's a good point. It sounds like a three stage system.
| 
| A golden branch that will be the stable version. (axiom--main--1)
| A silver branch that will be the almost stable branch (that is where you
|      opted for maintaining)
| Several experimental branches, where one person (or a group of people)
|      agrees on how they do development until the experiment becomes
|      resonably stable to be ready for the silver branch.
| 
| I would like that. No matter if you take my (perhaps naive) suggestion
| or anything else, but we should make clear an development model for
| Axiom that is easier to learn and includes *public* review before Tim
| gets the final decision.

You make a good point.  

| > | In fact, we could have (and actually we have) several unstable
| > | branches already. There are already different people responsible for
| > | them and a policy of how to update things there is completely
| > | open. But you are right. It would be nice to have the "hottest" branch
| > | available.
| > I'm willing to take responsability for that, but I need general
| > agreement from the community (especially from Tim) for having that
| > sort branch with the intent that patches applied there will move to
| > the stable branch when they have survived enough testing and satisfy
| > The Master (Tim!) taste.
| 
| You get my full support. And to the others: That is a generous offer
| we should not reject that and let long years of experience with gcc
| enter into the Axiom world. We need even more people like Gaby.

Thanks for the kind words.

| > | I think that flexibility of tla is a bit too much. There are simple
| > | guidelines missing of how to do things efficiently without the need to
| > | read several hundred pages. (I am trying to learn already since I
| > | would like to contribute code.)
| 
| > Can we move to SVN? (yes, it is a taboo subject but...)
| 
| Although I by now somehow think I can live with tla, I believe that we
| should not prevent you from doing things with SVN. If you are willing
| to maintain the silver branch using SVN, I see no point why we
| shouldn't accept that.

There are tools to convert CVS repositories to SVN ones; I don't know
whether similar tools exist for converting tla archive to SVN.  The
issue is whether Tim is OK with that idea.

| Of course, SVN has some weaknesses (especially not being able to do a
| star-merge), but since you could live with CVS for many years, I am
| sure you can cope with that missing feature anyway.

I understand.

[...]

| > | >    * public informative review that helps gain understanding of why
| > | >      things are the way they are, possible improvements, and things
| > | >      that should not be tried.  That is very essential to attain
| > | >      critical mass of people understanding the system.
| > | | Since I have no idea about how this works, could you be a bit
| > more specific?
| > Well, in general a victim sends a patch for review.  Component
| > maintainers and/or maintainers with global write privilege (Tim, for
| > instance) review the patch publically.  If the patch is fine, they say
| > "OK" (that is rare when the victim is not very familiar with the
| > system).  Otherwise, they technically comment on what are wrong
| > about the patch and suggest directions for improvements. If the patch
| > is outrageous, let say the patch suggests to sink Axiom, then an
| > answer might be "don't propose that again." :-)
| 
| But for public review, I must see the patch applied somewhere. I am
| not a machine that can read native "diff" output. Sorry, but I think
| you need to teach a bit. And in order not to hide this course inside
| the mail archive, it would be just great, if you could open up a page
| on AxiomWiki and let us know. (Thanks in advance.)

OK.  I'm currently attending the C++ commitee meeting (Berlin) where it
is easier for me to read/write mails from a terminal than launching a
browser (slow connection).  So, I'll try to honor your request tonight
(assuming I finished by then what I had to do).  If I don't get a
chance to do it (I'll try hard), there is no chance I'll do it before
the week of 16 April when I'm back to work place.


I'm glad we can work out a plan to make a live branch.

\start
Date: Thu, 06 Apr 2006 13:26:53 +0200
From: Ralf Hemmecke
To: list
Subject: Mathaction and Spammers

Look at

http://wiki.axiom-developer.org/MathActionDevelopment

it seems that spammers somehow can extract the mathaction email-address 
and write to such a page. Can there something be done (apart from 
manually removing it)?

Bill, is there a way to include a spamchecker?

\start
Date: Thu, 6 Apr 2006 08:06:42 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Mathaction and Spammers

On April 6, 2006 7:27 AM Ralf Hemmecke wrote:
> 
> Look at
> 
> http://wiki.axiom-developer.org/MathActionDevelopment
> 
> it seems that spammers somehow can extract the mathaction 
> email-address and write to such a page.

I have deleted the spam. In fact I have regularly deleted about
3 or 4 examples of this kind of spam on the Axiom Wiki almost
everyday over the last month or so. This spam is not coming via
email. Believe it or not some abuser actually goes to the trouble
of posting such messages to random pages. The point, I think, is
to increase the "link counts" to the target pages by "seeding"
links to the pages from where ever wiki software allows them to
add links. This makes it much more likely that the search engines
like google will index their pages.

I regularly use "recent changes" to check for this stuff and
delete it using the Zope undo feature (if possible, sometimes it
is not if there has been an later update to the wiki), or by
copying an earlier un-spammed version of the page to current.


> Can there something be done (apart from manually removing it)?
>

One thing that would slow them down at least would be to require
users to identify themselves via 'preferences' before being allowed
to post a comment.
 
> Bill, is there a way to include a spamchecker?
> 

I will look into this some more, but it is difficult on the web.
The Zwiki developers have been struggling with this for some time.

\start
Date: Thu, 06 Apr 2006 14:23:22 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Mathaction and Spammers

Hi Bill,

On 04/06/2006 02:06 PM, Bill Page wrote:
> On April 6, 2006 7:27 AM Ralf Hemmecke wrote:
>> Look at
>>
>> http://wiki.axiom-developer.org/MathActionDevelopment
>>
>> it seems that spammers somehow can extract the mathaction 
>> email-address and write to such a page.
> 
> I have deleted the spam. In fact I have regularly deleted about
> 3 or 4 examples of this kind of spam on the Axiom Wiki almost
> everyday over the last month or so. This spam is not coming via
> email. Believe it or not some abuser actually goes to the trouble
> of posting such messages to random pages. The point, I think, is
> to increase the "link counts" to the target pages by "seeding"
> links to the pages from where ever wiki software allows them to
> add links. This makes it much more likely that the search engines
> like google will index their pages.

Very cool! I really hope that some day such people can be sued and 
punished. They cost other people's time.

> I regularly use "recent changes" to check for this stuff and
> delete it using the Zope undo feature (if possible, sometimes it
> is not if there has been an later update to the wiki), or by
> copying an earlier un-spammed version of the page to current.

Well actually you deserve a BIG THANKS for all this work. Where would 
Axiom be today without all your effort.

>> Can there something be done (apart from manually removing it)?

> One thing that would slow them down at least would be to require
> users to identify themselves via 'preferences' before being allowed
> to post a comment.

But they still could edit the page, I have no idea whether they could 
let a program automatically edit a page, though.

>> Bill, is there a way to include a spamchecker?

> I will look into this some more, but it is difficult on the web.
> The Zwiki developers have been struggling with this for some time.

I am not so much into this busines, but what I think is that before 
anything from a comment is added to the page it is sent through a 
spam-filter like SpamAssassin using its Bayesian option.

\start
Date: Thu, 6 Apr 2006 15:09:39 +0200
From: Frederic Lehobey
To: list
Subject: SCM discussion (silver branch?)

Hi,

On Thu, Apr 06, 2006 at 11:28:09AM +0200, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> [...]
> 
> | > It is good to have unstable branch where experiments are
> |  > conducted.

> |  > but I think we need one branch that is unstable but not too unstable.
> | 
> | That's a good point. It sounds like a three stage system.
> | 
> | A golden branch that will be the stable version. (axiom--main--1)
> | A silver branch that will be the almost stable branch (that is where you
> |      opted for maintaining)
> | Several experimental branches, where one person (or a group of people)
> |      agrees on how they do development until the experiment becomes
> |      resonably stable to be ready for the silver branch.

> | > I'm willing to take responsability for that, but I need general
> | > agreement from the community (especially from Tim) for having that
> | > sort branch with the intent that patches applied there will move to
> | > the stable branch when they have survived enough testing and satisfy
> | > The Master (Tim!) taste.

This is somewhat the Linus Torvalds / Andrew Morton approach for
developing the Linux kernel.

> There are tools to convert CVS repositories to SVN ones; I don't know
> whether similar tools exist for converting tla archive to SVN.  The

See Tailor: http://www.darcs.net/DarcsWiki/Tailor

How hard is it to settle a public subversion server?  Do you have
access to the appropriate hosting resources?

Best regards,
Frederic
(still believing that patches matter more than the tools)
http://lehobey-rennes.dyndns.org/dokuwiki/doku.php?id=doc:veille:gestion_de_code_source

\start
Date: 06 Apr 2006 15:39:40 +0200
From: Gabriel Dos Reis
To: Frederic Lehobey
Subject: Re: SCM discussion (silver branch?)

Frederic Lehobey writes:

| Hi,
| 
| On Thu, Apr 06, 2006 at 11:28:09AM +0200, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > 
| > [...]
| > 
| > | > It is good to have unstable branch where experiments are
| > |  > conducted.
| 
| > |  > but I think we need one branch that is unstable but not too unstable.
| > | 
| > | That's a good point. It sounds like a three stage system.
| > | 
| > | A golden branch that will be the stable version. (axiom--main--1)
| > | A silver branch that will be the almost stable branch (that is where you
| > |      opted for maintaining)
| > | Several experimental branches, where one person (or a group of people)
| > |      agrees on how they do development until the experiment becomes
| > |      resonably stable to be ready for the silver branch.
| 
| > | > I'm willing to take responsability for that, but I need general
| > | > agreement from the community (especially from Tim) for having that
| > | > sort branch with the intent that patches applied there will move to
| > | > the stable branch when they have survived enough testing and satisfy
| > | > The Master (Tim!) taste.
| 
| This is somewhat the Linus Torvalds / Andrew Morton approach for
| developing the Linux kernel.

Exactly right.  It was also the Richard Stallman model of managing old gcc.

| > There are tools to convert CVS repositories to SVN ones; I don't know
| > whether similar tools exist for converting tla archive to SVN.  The
| 
| See Tailor: http://www.darcs.net/DarcsWiki/Tailor

thanks; I'll look into that.

| How hard is it to settle a public subversion server?

not very difficult.

| Do you have access to the appropriate hosting resources?

Not yet (though I do have write access); but if we have Tim's buy-in
then I'll expect that he would grant access to however will be in
charge of that branch. 

\start
Date: Thu, 06 Apr 2006 09:59:11 -0400
From: William Sit
To: Martin Rubey
Subject: Re: operations working in general, but not in special cases -- help needed

Dear Martin:

Martin Rubey wrote:
> William Sit writes:
> > I assume you want MatroidCat to be the category of all matroids,
> 
> No, at least not originally. I wanted MatroidCat be the "category" (in the
> sense of axiom/aldor) of those domains, which represent matroids. I.e., an
> element of a domain which in turn belongs to MatroidCat would be a matroid.

One should carefully distinguish a domain from a domain constructor, which
constructs domains (plural) using given parameters. Perhaps by "domain" in your
last line above meant "domain constructor" and "element" meant a domain
constructed with a given set of parameters for the domain constructor? Like:

  Matroid(E:Finite, I: Set Set E): MatroidCat == ...

is a domain constructor, whereas Matroid(GF(5), [[0,1],[0,2],[0,3],[0,4]]) is a
domain (whether the given parameters define a matroid or not requires a proof).

(Otherwise, I am not following: An element of a domain which in turn belongs to
MatroidCat should be an element of a matroid, not a matroid.)
 
> > in which case, the dual operation is actually a domain constructor.  That is,
> > the above signature cannot do what you are aiming for:
> >
> >     MatroidCat():Category == ... with
> >       dual: % -> %
> >
> > because the % refers to a particular implementation of a domain which is a
> > matroid, not the category itself. The argument to dual is an element of a
> > matroid. A plausible signature is:
> >
> >       dual:() -> MatroidCat()
> >
> > which associates a matroid to the current matroid.
> 
> So, in your view, MatroidCat would contain all matroids, and a domain belonging
> to MatroidCat would be a specific matroid?

Not quite: yes, a domain belonging to MatroidCat would be a specific matroid,
but "belong" must be taken with a grain of salt.  MatroidCat is NOT the set
(class, domain, whatever) of all matroids. It is different from the mathematical
concept of a category, which would include all objects of that category
(matroids) as well as morphisms. A category in Axiom simply specifies what
functions should be exported by a domain of that category. A domain "belongs" to
an Axiom category by declaration when it implements the specified functions
using a particular data structure (given by Rep) for its elements, subject to
certain implicit conventions. A domain constructor for objects (= domain) in the
category builds one object per instance of a given set of parameters. So in a
limited sense, a domain constructor is the part of a functor that maps objects
of one category to objects of another.
 
> > If you do NOT want to implement dual as a domain constructor, then you may
> > try implementing Matroid as the DOMAIN of all matroids. However, Axiom does
> > not allow dependent types at the code level (only at the declaration level
> > for constructors).
> >
> >    Matroid(): SetCategory == ...
> >
> >      Rep:= Record(E:SetCategory, I:Set Set E)
> >
> > probably won't work in Axiom, but Aldor may. The advantage is that this will
> > allow domain constructors implemented as functions, and operations on
> > matroids (not matroid elements) are also possible. So for example, one may
> > test whether two matroids are equal or isomorphic.
> 
> That's what I had in mind.

I can only think of one rough parallel: Axiom algebra library has a domain IDEAL
which represents the set of all polynomial ideals in a polynomial ring. But
there, the ideals belong to a fixed mathematical object, the multivariate
polynomial ring. So one can do all sorts of operations on ideals (like
intersection, union etc), AND at the same time use operations in the polynomial
ring on polynomials IN ideals. In your case, while we are not viewing the set of
all matroids as if the matroids are all subsets of one big set, it seems
possible to implement using the domain and functions approach rather than the
category and domain constructor approach (more below). The choice will be
influenced by how differently Axiom treats constructors from functions. Ideally,
there should be no difference!
 
> > Given any (not necessarily planar) graph G = (N, A), where N is the node set and
> > A the arc set, there is always a corresponding matroid M = (E, I) called a
> > graphic matroid. (Theorem 4.1, p. 271). Hence a graphic matroid always has a
> > dual matroid called the cographic matroid. So there are TWO matroids for every
> > graph G.
> 
> Well, yes. Usually one says that the graphic matroid corresponds to the graph,
> though.

Not sure what your point is.
We have two definitions here: Given a graph G, we can construct its graphic
matroid M(G).  So, yes, M(G) "corresponds" to G. Then we can define a matroid M
to be graphic if there is a graph G such that M = M(G). If M is graphic, it is
not a priori true that there is a unique G such that M=M(G), and until uniquness
is proved, one cannot speak of THE graph of a graphic matroid. (Does any one
know if this holds: if M(G1) is isomorphic to M(G2) as matroids, then G1 is
isomorphic to G2 as graphs?) One can always speak of THE graphic matroid of a
graph.
 
> > This means two domain constructors:
> >
> >     GraphicMatroid(G: GraphCat):MatroidCat == ...
> >
> >     CographicMatroid(G: GraphCat):MatroidCat == ...
> 
> If I follow this route I should put all matroidal properties of graphs into
> MatroidCat, and only those properties which are not matroidal into GraphCat I
> think I like this idea.

That is right, but GraphCat should be independent of MatroidCat. A graph is a
graph, not a matroid. The graphic matroid M(G) of a graph G is a matroid, and
that construction is part of a functor (hence a domain constructor in Axiom).
 
> > > Example 2, Differential Equations
> > >
> > > It is quite easy to see that the class of holonomic functions is closed
> > > under integration
> > >
> > > However, we all know that the class of rational functions is *not* closed
> > > under integration
> >
> > The integrate operation is more like the minus or divide operation. Since
> > they operate on elements (not domains), you can simply export integrateIfCan
> > in RatCat.
> 
> yes.
> 
> > The two examples you gave present two different problems.
> 
> It very much depends on how you view the problem(s). Of course, taking your
> approach, these are different problems, but I do think that one can see them as
> a single problem, too.

I don't dictate any approach! I simply analyse the questions you asked. In fact,
I also considered the construction of a DOMAIN called AllMatroids of all
matroids, and in that domain, the dual of any ELEMENT (which is a matroid) may
be constructed, but the implementation of any operation on elements of a matroid
will depend on extracting information from the representation, which is not a
matroid, but data representating a matroid.  On the other hand,  the dual GRAPH
of a graph should not be constructed in AllMatroids because a graph is not a
matroid. The dual matroid of M(G) where G is a graph may be constructed,
provided M(G) can be implemented with a signature:

     graphic(G:GraphCat):AllMatroids ==

Here is where things get limited by the language. It does not seem that
graphic() is a domain constructor, since it only constructs an ELEMENT of
AllMatroids. It does not seem to be a function either, since GraphCat is not a
domain. Two possibilities: we define a DOMAIN AllGraphs of all graphs, much like
AllMatroids. We can then have 
  
     graphic(G:AllGraphs):AllMatroids ==

as a function exported from AllGraphs. The other possibility is to do:

    GraphCat(...) == ...
      graphic: () ->AllMatroids

\start
Date: Thu, 06 Apr 2006 16:19:07 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: SCM discussion (silver branch?)
Cc: Frederic Lehobey

> | See Tailor: http://www.darcs.net/DarcsWiki/Tailor

By the way, if some people like to favour tla, ... when I experimented a 
bit with svn and tla, I once had a working copy that was an svn working 
copy and a tla working copy at the same time.

That basically says that it would be easy to update that copy from SVN 
AND tla, if you like. And you could also commit your work back to 
different archive types.

\start
Date: Thu, 6 Apr 2006 11:28:07 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: SCM discussion (silver branch?)
Cc: Frederic Lehobey

Gaby,

I've created an SVN repository at the sourceforge.net/projects/axiom site.
It is a clone of the CVS version.

Please create a userid for yourself on sourceforge and
mail the information to me. I'll set you up as an administrator.

The SVN version is expected to be used as a hotpatch 'latest change' version. 
The CVS version will still track the Arch. 
On a best-effort, two-month interval I'll look to merge the changes
from the Sourceforge/SVN to the Arch/Sourceforge CVS/Savannah CVS.

Congrats. You're now the "Andrew Morton" of the project.
Manage it well. You have my sympathy :-)

\start
Date: Thu, 6 Apr 2006 11:31:48 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SCM discussion (silver branch?)
Cc: Frederic Lehobey

Axiom is now available under Arch, CVS, and SVN.
If Bill wants we can also create a DARCS server.

\start
Date: Thu, 6 Apr 2006 11:15:46 -0400
From: Bill Page
To: Tim Daly
Subject: RE: SCM discussion (silver branch?)
Cc: Frederic Lehobey

On April 6, 2006 11:32 AM Tim Daly (root) wrote:
> 
> Axiom is now available under Arch, CVS, and SVN.
> If Bill wants we can also create a DARCS server.
> 

??? darcs does not require server software. For public access
all that is required is a web server.

We have already had the axiom--main--1 and axiom--winodws--1
branches accessible in a darcs repository for more than a year.
See:

http://wiki.axiom-developer.org/MathActionRepository

\start
Date: Thu, 6 Apr 2006 12:06:10 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: SCM discussion (silver branch?)
Cc: Frederic Lehobey

If any other developer feels the desire to maintain their own SVN
branch this can also be set up on sourceforge. You can use this
for 'public development' if you like.

I'd expect that you coordinate with Gaby to have your changes 
integrated for 'public test and approval'.

Before accepting changes into the main branch I expect them to be
professionally documented and tested. How Gaby maintains his 
public beta branch is entirely up to him.

\start
Date: Thu, 6 Apr 2006 17:24:40 +0200 (CEST)
From: Bertfried Fauser
To: Ralf Hemmecke
Subject: Re: Mathaction and Spammers

Hi,

I had the same problem with my wiki, which I removed from my website since
it was not actively used. A spamfilte (I don't know how to include this
into a wiki) however will also filter out many simple changes. Lots of
FrontEnd update mails are moved to my local spam filter as some other
axiom mails too. So, presumably just filtering a diff of a web paer
through a spamm filter will prevent quite a number of alterations to be
possible.

What about the general need to register to be able to make changes. Then a
black list could exlude members who do spamming?

\start
Date: Thu, 6 Apr 2006 18:38:30 +0200
From: Frederic Lehobey
To: list
Subject: Re: Compiling Axiom from arch source on Debian sarge

Hi,

On Thu, Apr 06, 2006 at 10:40:17AM +0200, Ralf Hemmecke wrote:

> I am just compiling patch-47 axiom on standard debian sarge.
>
> My compilation stops in the middle of compiling the documentation and
> just continues after I have pressed enter.

I wanted to check this and started a compilation on Debian sarge from
the latest arch sources.

Unfortunately, I experience exactly the same failure as Balbir Thomas:
http://lists.gnu.org/archive/html/axiom-developer/2005-02/msg00168.html

I have found
http://wiki.axiom-developer.org/131AwkBackslashCausesFailureInSrcAlgebraM=
akefile
But this explanation does not seem to be the correct one in this case.

$ awk --version
GNU Awk 3.1.4
Copyright =A9 1998, 1991-2003 Free Software Foundation, Inc.

\start
Date: Thu, 6 Apr 2006 13:33:02 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Latex Package problem

It appears that your hyperref package does not match my hyperref package.

\start
Date: Thu, 6 Apr 2006 19:18:35 +0200
From: Frederic Lehobey
To: David Mentre
Subject: Re: Compiling Axiom from arch source on Debian sarge

Hi,

On Thu, Apr 06, 2006 at 06:49:02PM +0200, David MENTRE wrote:

> Have you checked that the src/algebra/Makefile has the same backslash
> issue or a different one? There might a regression in latest awk.

The offending lines are not anymore in src/algebra/Makefile.

Here is the end of the output of a $ make -d

    ...

    No need to remake target `/home/fdl/axiom/tpd/mnt/linux/src/algebra/zerodim.spad'.
    Considering target file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.o'.
     File `/home/fdl/axiom/tpd/int/algebra/ABELGRP.o' does not exist.
     Looking for an implicit rule for `/home/fdl/axiom/tpd/int/algebra/ABELGRP.o'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.lsp'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.c'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.cc'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.C'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.cpp'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.p'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.f'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.F'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.r'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.s'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.S'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.mod'.
     Trying pattern rule with stem `ABELGRP.o'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.o,v'.
     Trying pattern rule with stem `ABELGRP.o'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.o,v'.
     Trying pattern rule with stem `ABELGRP.o'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.o'.
     Trying pattern rule with stem `ABELGRP.o'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.o'.
     Trying pattern rule with stem `ABELGRP.o'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.o'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.lsp'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.lsp'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP.lsp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.lsp,v'.
      Trying pattern rule with stem `ABELGRP.lsp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.lsp,v'.
      Trying pattern rule with stem `ABELGRP.lsp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.lsp'.
      Trying pattern rule with stem `ABELGRP.lsp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.lsp'.
      Trying pattern rule with stem `ABELGRP.lsp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.lsp'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.c'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.c'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.y'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.l'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.w'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.w'.
      Trying pattern rule with stem `ABELGRP.c'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.c,v'.
      Trying pattern rule with stem `ABELGRP.c'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.c,v'.
      Trying pattern rule with stem `ABELGRP.c'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.c'.
      Trying pattern rule with stem `ABELGRP.c'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.c'.
      Trying pattern rule with stem `ABELGRP.c'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.c'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.y'.
      Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.y'.
       Avoiding implicit rule recursion.
       Avoiding implicit rule recursion.
       Trying pattern rule with stem `ABELGRP.y'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.y,v'.
       Trying pattern rule with stem `ABELGRP.y'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.y,v'.
       Trying pattern rule with stem `ABELGRP.y'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.y'.
       Trying pattern rule with stem `ABELGRP.y'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.y'.
       Trying pattern rule with stem `ABELGRP.y'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.y'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.l'.
      Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.l'.
       Avoiding implicit rule recursion.
       Avoiding implicit rule recursion.
       Trying pattern rule with stem `ABELGRP.l'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.l,v'.
       Trying pattern rule with stem `ABELGRP.l'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.l,v'.
       Trying pattern rule with stem `ABELGRP.l'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.l'.
       Trying pattern rule with stem `ABELGRP.l'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.l'.
       Trying pattern rule with stem `ABELGRP.l'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.l'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.w'.
      Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.w'.
       Avoiding implicit rule recursion.
       Avoiding implicit rule recursion.
       Trying pattern rule with stem `ABELGRP.w'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.w,v'.
       Trying pattern rule with stem `ABELGRP.w'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.w,v'.
       Trying pattern rule with stem `ABELGRP.w'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.w'.
       Trying pattern rule with stem `ABELGRP.w'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.w'.
       Trying pattern rule with stem `ABELGRP.w'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.w'.
      Trying pattern rule with stem `ABELGRP'.
      Rejecting impossible implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.w'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.cc'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.cc'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP.cc'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.cc,v'.
      Trying pattern rule with stem `ABELGRP.cc'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.cc,v'.
      Trying pattern rule with stem `ABELGRP.cc'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.cc'.
      Trying pattern rule with stem `ABELGRP.cc'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.cc'.
      Trying pattern rule with stem `ABELGRP.cc'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.cc'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.C'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.C'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP.C'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.C,v'.
      Trying pattern rule with stem `ABELGRP.C'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.C,v'.
      Trying pattern rule with stem `ABELGRP.C'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.C'.
      Trying pattern rule with stem `ABELGRP.C'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.C'.
      Trying pattern rule with stem `ABELGRP.C'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.C'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.cpp'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.cpp'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP.cpp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.cpp,v'.
      Trying pattern rule with stem `ABELGRP.cpp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.cpp,v'.
      Trying pattern rule with stem `ABELGRP.cpp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.cpp'.
      Trying pattern rule with stem `ABELGRP.cpp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.cpp'.
      Trying pattern rule with stem `ABELGRP.cpp'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.cpp'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.p'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.p'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.web'.
      Trying pattern rule with stem `ABELGRP.p'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.p,v'.
      Trying pattern rule with stem `ABELGRP.p'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.p,v'.
      Trying pattern rule with stem `ABELGRP.p'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.p'.
      Trying pattern rule with stem `ABELGRP.p'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.p'.
      Trying pattern rule with stem `ABELGRP.p'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.p'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.web'.
      Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.web'.
       Avoiding implicit rule recursion.
       Avoiding implicit rule recursion.
       Trying pattern rule with stem `ABELGRP.web'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.web,v'.
       Trying pattern rule with stem `ABELGRP.web'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.web,v'.
       Trying pattern rule with stem `ABELGRP.web'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.web'.
       Trying pattern rule with stem `ABELGRP.web'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.web'.
       Trying pattern rule with stem `ABELGRP.web'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.web'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.f'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.f'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.F'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.r'.
      Trying pattern rule with stem `ABELGRP.f'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.f,v'.
      Trying pattern rule with stem `ABELGRP.f'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.f,v'.
      Trying pattern rule with stem `ABELGRP.f'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.f'.
      Trying pattern rule with stem `ABELGRP.f'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.f'.
      Trying pattern rule with stem `ABELGRP.f'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.f'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.F'.
      Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.F'.
       Avoiding implicit rule recursion.
       Avoiding implicit rule recursion.
       Trying pattern rule with stem `ABELGRP.F'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.F,v'.
       Trying pattern rule with stem `ABELGRP.F'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.F,v'.
       Trying pattern rule with stem `ABELGRP.F'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.F'.
       Trying pattern rule with stem `ABELGRP.F'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.F'.
       Trying pattern rule with stem `ABELGRP.F'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.F'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.r'.
      Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.r'.
       Avoiding implicit rule recursion.
       Avoiding implicit rule recursion.
       Trying pattern rule with stem `ABELGRP'.
       Rejecting impossible implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.l'.
       Trying pattern rule with stem `ABELGRP.r'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.r,v'.
       Trying pattern rule with stem `ABELGRP.r'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.r,v'.
       Trying pattern rule with stem `ABELGRP.r'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.r'.
       Trying pattern rule with stem `ABELGRP.r'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.r'.
       Trying pattern rule with stem `ABELGRP.r'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.r'.
     Trying pattern rule with stem `ABELGRP'.
     Rejecting impossible implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.F'.
     Trying pattern rule with stem `ABELGRP'.
     Rejecting impossible implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.r'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.s'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.s'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.S'.
      Trying pattern rule with stem `ABELGRP.s'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.s,v'.
      Trying pattern rule with stem `ABELGRP.s'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.s,v'.
      Trying pattern rule with stem `ABELGRP.s'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.s'.
      Trying pattern rule with stem `ABELGRP.s'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.s'.
      Trying pattern rule with stem `ABELGRP.s'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.s'.
      Trying pattern rule with stem `ABELGRP'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.S'.
      Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.S'.
       Avoiding implicit rule recursion.
       Avoiding implicit rule recursion.
       Trying pattern rule with stem `ABELGRP.S'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.S,v'.
       Trying pattern rule with stem `ABELGRP.S'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.S,v'.
       Trying pattern rule with stem `ABELGRP.S'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.S'.
       Trying pattern rule with stem `ABELGRP.S'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.S'.
       Trying pattern rule with stem `ABELGRP.S'.
       Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.S'.
     Trying pattern rule with stem `ABELGRP'.
     Rejecting impossible implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.S'.
     Trying pattern rule with stem `ABELGRP'.
     Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.mod'.
     Looking for a rule with intermediate file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.mod'.
      Avoiding implicit rule recursion.
      Trying pattern rule with stem `ABELGRP.mod'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/ABELGRP.mod,v'.
      Trying pattern rule with stem `ABELGRP.mod'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.mod,v'.
      Trying pattern rule with stem `ABELGRP.mod'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/RCS/ABELGRP.mod'.
      Trying pattern rule with stem `ABELGRP.mod'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/s.ABELGRP.mod'.
      Trying pattern rule with stem `ABELGRP.mod'.
      Trying implicit prerequisite `/home/fdl/axiom/tpd/int/algebra/SCCS/s.ABELGRP.mod'.
     No implicit rule found for `/home/fdl/axiom/tpd/int/algebra/ABELGRP.o'.
     Finished prerequisites of target file `/home/fdl/axiom/tpd/int/algebra/ABELGRP.o'.
    Must remake target `/home/fdl/axiom/tpd/int/algebra/ABELGRP.o'.
make[3]: Entering directory `/home/fdl/axiom/tpd/src/algebra'
make[3]: *** No rule to make target `/home/fdl/axiom/tpd/int/algebra/ABELGRP.o', needed by `src'.  Stop.
make[3]: Leaving directory `/home/fdl/axiom/tpd/src/algebra'
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x0807f780 PID 25876 
make[2]: *** [algebradir] Error 2
Removing child 0x0807f780 PID 25876 from chain.
make[2]: Leaving directory `/home/fdl/axiom/tpd/src'
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x08078680 PID 25793 
make[1]: *** [srcdir] Error 2
Removing child 0x08078680 PID 25793 from chain.
make[1]: Leaving directory `/home/fdl/axiom/tpd'
Got a SIGCHLD; 1 unreaped children.
Reaping losing child 0x08076c58 PID 25753 
make: *** [all] Error 2
Removing child 0x08076c58 PID 25753 from chain.

\start
Date: Thu, 6 Apr 2006 14:07:47 -0400
From: Tim Daly
To: Frederic Lehobey
Subject: Re: Compiling Axiom from arch source on Debian sarge

I suspect that your failure is the same as Balbir's.
Did you stop the build and attempt to restart it?
There is a problem with the awk script addition to the src/algebra/Makefile.

\start
Date: Thu, 6 Apr 2006 19:58:54 +0200
From: Frederic Lehobey
To: Tim Daly
Subject: Re: Compiling Axiom from arch source on Debian sarge

Hi,

On Thu, Apr 06, 2006 at 02:07:47PM -0400, root wrote:
> I suspect that your failure is the same as Balbir's.
> Did you stop the build and attempt to restart it?

No I did not (if I remember correctly).  But I am usure whether it had
really started from scratch again (I think so) after a failure for a
missing dependency (I have had two failures because of missing
dependencies and cleaned the build only once).  To be sure of it I
have started a new round:

$ make clean
$ make

Is that enough or are there special files I have to remove by hand
first?

\start
Date: Thu, 6 Apr 2006 20:09:34 +0200
From: Frederic Lehobey
To: list
Subject: Re: Compiling Axiom from arch source on Debian sarge

Hi,

On Thu, Apr 06, 2006 at 07:58:54PM +0200, Frederic Lehobey wrote:

> dependencies and cleaned the build only once).  To be sure of it I
> have started a new round:
> 
> $ make clean
> $ make
> 
> Is that enough or are there special files I have to remove by hand
> first?

Problem still occurs.  I will try later another new build from scratch
(directory wiped).

\start
Date: Thu, 06 Apr 2006 20:17:22 +0200
From: Gregory Vanuxem
To: Frederic Lehobey
Subject: Re: Compiling Axiom from arch source on Debian sarge

Le jeudi 06 avril 2006 =C3=A0 19:58 +0200, Frederic Lehobey a =C3=A9crit =
:
> Hi,
>
> On Thu, Apr 06, 2006 at 02:07:47PM -0400, root wrote:
> > I suspect that your failure is the same as Balbir's.
> > Did you stop the build and attempt to restart it?
>
> No I did not (if I remember correctly).  But I am usure whether it had
> really started from scratch again (I think so) after a failure for a
> missing dependency (I have had two failures because of missing
> dependencies and cleaned the build only once).  To be sure of it I
> have started a new round:
>
> $ make clean
> $ make
>
> Is that enough or are there special files I have to remove by hand
> first?

See this thread:

http://lists.gnu.org/archive/html/axiom-developer/2006-03/msg00112.html

\start
Date: Thu, 6 Apr 2006 18:49:02 +0200
From: David Mentre
To: Frederic Lehobey
Subject: Re: Compiling Axiom from arch source on Debian sarge

Hello Fred,

2006/4/6, Frederic Lehobey:
> Unfortunately, I experience exactly the same failure as Balbir Thomas:
> http://lists.gnu.org/archive/html/axiom-developer/2005-02/msg00168.html
>
> I have found
> http://wiki.axiom-developer.org/131AwkBackslashCausesFailureInSrcAlgebraM=
akefile
> But this explanation does not seem to be the correct one in this case.
>
> $ awk --version
> GNU Awk 3.1.4

Have you checked that the src/algebra/Makefile has the same backslash
issue or a different one? There might a regression in latest awk.

\start
Date: Thu, 6 Apr 2006 15:17:13 -0400
From: Tim Daly
To: Frederic Lehobey
Subject: Re: Compiling Axiom from arch source on Debian sarge

> $ make clean
> $ make
> 
> Is that enough or are there special files I have to remove by hand
> first?

unfortunately, due to the awk scripts (and a failure of the clean stanza)
this is not enough. you need to removed two awk scripts and all of
the Makefile and Makefile.dvi files in the src directory. 
 
make clean
rm -rf int obj mnt lsp/gcl*
cd src
for i in `find . -name "Makefile"` ; do rm -f $i ; done
for i in `find . -name "Makefile.dvi"` ; do rm -f $i ; done


It is actually easier to just nuke the install and refetch it.

I've been meaning to fix this. I'll try to get it into the --patch-48 release.

\start
Date: Thu, 6 Apr 2006 12:52:25 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: Mathaction and Spammers

Bill Page [Bill Page] wrote:
> On April 6, 2006 7:27 AM Ralf Hemmecke wrote:
> > 
> > Look at
> > 
> > http://wiki.axiom-developer.org/MathActionDevelopment
> > 
> > it seems that spammers somehow can extract the mathaction 
> > email-address and write to such a page.
> 
> I have deleted the spam. In fact I have regularly deleted about
> 3 or 4 examples of this kind of spam on the Axiom Wiki almost
> everyday over the last month or so. This spam is not coming via
> email. Believe it or not some abuser actually goes to the trouble
> of posting such messages to random pages. The point, I think, is
> to increase the "link counts" to the target pages by "seeding"
> links to the pages from where ever wiki software allows them to
> add links. This makes it much more likely that the search engines
> like google will index their pages.

there is also the banned_links property of the ZWiki folder, which can
contain regexes that are banned.  Are you using this Bill?  Mine
currently contains:

<\s*div\s+style\s*=\s*['"]\s*display\s*:\s*none\s*;?['"]>
(?:\.ec\d+|58798309dyb|bzyc|yunching|fadaka|fixtab|hobbyworkshop|port5|topsitesranking|shigao|quiw|isavecoupons|free-poker.*|g4h5|freeonlineslots.*|poker-game.*|mrstab|onlinecasino.*|glwb|zerohops|areaseo|rwr|insulate|itascacc|gayhomes)\.(?:com|net|org|cn|org\.uk|info|ru)
(?:mujweb\.cz|buy-soma-online\.biz\.st)
(?:albenza|elimite|eurax|vermox|tamiflu|amoxicillin|tetracycline|zithromax|buspar|colchicine|zyloprim|alesse|mircette|triphasil|yasmin|aldactone|norvasc|darvocet|diazepam|didrex|diethylpropion|diflucan|effexor|clonazepam|cyclobenzaprine|fluoxetine|fosamax|fioricet|flexeril|lexapro|lipitor|hydrocodone|levitra|viagra|cialis)

A more sophisticated, long-term solution is to add code to ZWiki to
check against SURBL: http://www.surbl.org/  (Spam URI Realtime
Blocklists)

\start
Date: Thu, 6 Apr 2006 16:10:29 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Mathaction and Spammers

Bob,

On April 6, 2006 3:52 PM you wrote:
> ... 
> there is also the banned_links property of the ZWiki folder,
> which can contain regexes that are banned.  Are you using
> this Bill?

No, I did not have this configured. Do you know what version
of ZWiki introduced this feature? I am not sure it will work
with ZWiki on MathAction which is still at version ZWiki-0-36-2
but I will give it a try.

> Mine
> currently contains:
> 
> <\s*div\s+style\s*=\s*['"]\s*display\s*:\s*none\s*;?['"]>
> ...

Thanks, Bob. I have copied your regexs verbatim into a
banned_links (lines) property on MathAction. We will see
if that cures the problem ...
 
> A more sophisticated, long-term solution is to add code to
> ZWiki to check against SURBL: http://www.surbl.org/  (Spam
> URI Realtime Blocklists)
> 

I guess that means I am going to have to get around to
updating the ZWiki code on MathAction, right? :)

\start
Date: Thu, 6 Apr 2006 13:52:29 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: Mathaction and Spammers

Bill Page [Bill Page] wrote:
> > A more sophisticated, long-term solution is to add code to
> > ZWiki to check against SURBL: http://www.surbl.org/  (Spam
> > URI Realtime Blocklists)
> 
> I guess that means I am going to have to get around to
> updating the ZWiki code on MathAction, right? :)

I have not kept current with the ZWiki code for a year or so...and given
the hassles I've had in the past I'm not looking forward to upgrading.
I think the ZWiki monthly-release cycle is a terrible idea...  If there
existed a "stable" release for it that would be better.

I have 0.42 on my machine.

\start
Date: Thu, 06 Apr 2006 23:21:33 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Latex Package problem

Mine says

\ProvidesPackage{hyperref}
   [2003/01/22 v6.73n
   Hypertext links for LaTeX]

\ProvidesPackage{keyval}
                  [1999/03/16 v1.13 key=value parser (DPC)]

That is Standard on Debian Sarge.

What do you happen to use? And why do you need that "final" anyway?

Ralf

On 04/06/2006 07:33 PM, root wrote:
> It appears that your hyperref package does not match my hyperref package.

\start
Date: Thu, 6 Apr 2006 18:14:25 -0400
From: Tim Daly
To: Camm Maguire
Subject: gcl-2.6.7 on debian

Camm,

I tried to build Axiom on a debian machine and get:

creating makedefc
sed: file conftest.s1 line 61:  unterminated `s' command
creating windows/gcl.iss
sed: file conftest.s1 line 61:  unterminated `s' command
creating windows/sysdir.bat
sed: file conftest.s1 line 61:  unterminated `s' command
creating windows/install.lsp
sed: file conftest.s1 line 61:  unterminated `s' command

\start
Date: 07 Apr 2006 00:42:55 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: SCM discussion (silver branch?)
Cc: Frederic Lehobey

Tim Daly writes:

| Gaby,
| 
| I've created an SVN repository at the sourceforge.net/projects/axiom site.
| It is a clone of the CVS version.
| 
| Please create a userid for yourself on sourceforge and
| mail the information to me. I'll set you up as an administrator.
| 
| The SVN version is expected to be used as a hotpatch 'latest change' version. 

As a friend says, "be careful about what you ask, you might get it" :-)

That was fast!  Thanks for listening to the voices and taking those
measures.  I'll try not to fumble the whole thing.

| The CVS version will still track the Arch. 
| On a best-effort, two-month interval I'll look to merge the changes
| from the Sourceforge/SVN to the Arch/Sourceforge CVS/Savannah CVS.

That is great!

| Congrats. You're now the "Andrew Morton" of the project.
| Manage it well. You have my sympathy :-)

Many thanks for the confidence vote.  I count on your expertise for
reviews :-)

\start
Date: Thu, 6 Apr 2006 23:02:46 -0400
From: Tim Daly
To: list
Subject: offline

I'll be offline and unavailable until Tuesday. 
Talk amongst yourselves :-) 

\start
Date: Thu, 06 Apr 2006 17:24:58 -0700
From: Simon Michael
To: list
Subject: Re: Mathaction and Spammers

Hi all,

sometimes we've struggled, sometimes we stay ahead in the wiki-spam arms 
race. Bill, you probably know about the recent edits_need_username feature 
- this has been keeping all my wikis spam free for a while. You should be 
able to achieve the same if you keep up with the more recent Zwiki 
versions, chat me if I can help in any way.

\start
Date: 07 Apr 2006 11:54:27 +0200
From: Gabriel Dos Reis
To: list
Subject: Axiom silver branch

Hello,

  As you now, Tim set up an SVN server for accessing the "silver branch"
of Axiom on sourceforge

    http://sf.net/projets/axiom

I would like to discuss the organization of branches and procedures.


That repository as far as I can tell contains all of current Axiom
sources.  That means that if you execute the command

   svn co https://svn.sourceforge.net/svnroot/axiom axiom

then you get the whole thing -- which you rarely want, except when
you're administrator or "core" developer.

I propose the following -- meaning I would appreciate feedback from
you -- for organizing the SVN repository:

  * have axiom/trunk contains the silver branch sources
  
  * create axiom/branches/gold to contain the sources for the "gold branch".

  * people interested in experiments based on the silver branch will
    create  their branches as axiom/branches/xxx, where "xxx" is the
    name of a specific branch.

    I'll write a doc about how to create a branch, how to merge, etc.

\start
Date: Fri, 7 Apr 2006 12:07:51 +0200
From: David Mentre
To: list
Subject: Fwd: Axiom silver branch

Oops, forgot the list.

---------- Forwarded message ----------

Hello Gaby,

07 Apr 2006 11:54:27 +0200, Gabriel Dos Reis=
:
> I propose the following -- meaning I would appreciate feedback from
> you -- for organizing the SVN repository:
>
>   * have axiom/trunk contains the silver branch sources
>
>   * create axiom/branches/gold to contain the sources for the "gold branc=
h".
>
>   * people interested in experiments based on the silver branch will
>     create  their branches as axiom/branches/xxx, where "xxx" is the
>     name of a specific branch.
>
>     I'll write a doc about how to create a branch, how to merge, etc.

Ok for me as long as all of this is documented (i.e. meaning of each
part of the svn hierarchy) somewhere on the wiki.

\start
Date: Fri, 07 Apr 2006 13:38:58 +0200
From: Ralf Hemmecke
To: David Mentre
Subject: Re: Fwd: Axiom silver branch

Also OK for me, but we should somewhere (either sourceforge or better on 
the AxiomWiki) keep a list of branches (similar (or better) than 
http://wiki.axiom-developer.org/ArchUsage) and what are they good for 
(including a responsible person for that branch etc).

axiom-dev will be automatically informed if something is changed on the 
wiki so we all can keep track about who works on which branch.

On 04/07/2006 12:07 PM, David MENTRE wrote:
> Oops, forgot the list.
> 
> d.
> 
> ---------- Forwarded message ----------
> 
> Hello Gaby,
> 
> 07 Apr 2006 11:54:27 +0200, Gabriel Dos Reis:
>> I propose the following -- meaning I would appreciate feedback from
>> you -- for organizing the SVN repository:
>>
>>   * have axiom/trunk contains the silver branch sources
>>
>>   * create axiom/branches/gold to contain the sources for the "gold branch".
>>
>>   * people interested in experiments based on the silver branch will
>>     create  their branches as axiom/branches/xxx, where "xxx" is the
>>     name of a specific branch.
>>
>>     I'll write a doc about how to create a branch, how to merge, etc.
> 
> Ok for me as long as all of this is documented (i.e. meaning of each
> part of the svn hierarchy) somewhere on the wiki.

\start
Date: 07 Apr 2006 13:47:59 +0200
From: Gabriel Dos Reis
To: list
Subject: Re: Fwd: Axiom silver branch

Ralf Hemmecke writes:

| Also OK for me, but we should somewhere (either sourceforge or better
| on the AxiomWiki) keep a list of branches (similar (or better) than
| http://wiki.axiom-developer.org/ArchUsage) and what are they good for
| (including a responsible person for that branch etc).
| 
| axiom-dev will be automatically informed if something is changed on
| the wiki so we all can keep track about who works on which branch.

Very good points, and I totally agree.

I'll write more on the procedures and post it to the list. I hope to
have a connection tonight.

\start
Date: Fri, 7 Apr 2006 15:13:02 +0200
From: Frederic Lehobey
To: Tim Daly
Subject: Re: Compiling Axiom from arch source on Debian sarge

Hi,

On Thu, Apr 06, 2006 at 03:17:13PM -0400, root wrote:

> unfortunately, due to the awk scripts (and a failure of the clean stanza)
> this is not enough. you need to removed two awk scripts and all of
> the Makefile and Makefile.dvi files in the src directory. 
>  
> make clean
> rm -rf int obj mnt lsp/gcl*
> cd src
> for i in `find . -name "Makefile"` ; do rm -f $i ; done
> for i in `find . -name "Makefile.dvi"` ; do rm -f $i ; done

Seems it worked for me (compilation goes further).  Thanks.  Thanks
also to Greg for pointing a very recent thread on the same problem.
Frederic

\start
Date: Fri, 7 Apr 2006 15:25:59 +0200
From: Frederic Lehobey
To: list
Subject: Re: Latex Package problem

Hi,

On Thu, Apr 06, 2006 at 10:40:17AM +0200, Ralf Hemmecke wrote:

> I am just compiling patch-47 axiom on standard debian sarge.
> 
> My compilation stops in the middle of compiling the documentation and 
> just continues after I have pressed enter.
> 
> I've tracked down the problem to that here (see below).

> woodpecker:~/OTHER/Axiom/axiom--main--1/src/doc>latex endpaper.pamphlet

I am trying to confirm this.  What I see is slightly different.  The
compilation is simply stalled at this step (no way to press enter):

...
4 making /home/fdl/axiom/tpd/mnt/linux/doc/bookvol1.dvi from /home/fdl/axiom/tpd/src/doc/bookvol1.pamphlet
This is makeindex, version 2.14 [02-Oct-2002] (kpathsea + Thai support).
Scanning input file bookvol1.idx.....done (1127 entries accepted, 0 rejected).
Sorting entries............done (12024 comparisons).
Generating output file bookvol1.ind.....done (875 lines written, 0 warnings).
Output written in bookvol1.ind.
Transcript written in bookvol1.ilg.
4 making /home/fdl/axiom/tpd/mnt/linux/doc/endpaper.dvi from /home/fdl/axiom/tpd/src/doc/endpaper.pamphlet


This is weird as Camm package successfully backports to sarge...

\start
Date: Fri, 07 Apr 2006 15:38:07 +0200
From: Ralf Hemmecke
To: Frederic Lehobey
Subject: Re: Latex Package problem

To be honest, when I compiled axiom--main--1 I also realized that 
"pressing enter" did not help. I had to press "q".

But strangely now a lot of "ENTER" helped.

Tim still hasn't said why he needs the "final" in src/doc/endpaper.pamphlet

\usepackage[dvips,final,colorlinks=true,pdfstartview=FitH]{hyperref}


otherwise it could simply be removed. (It works without "final" at my 
place.)

Comment: Since that file uses pstricks you cannot produce a pdf file 
from it.

Ralf

On 04/07/2006 03:25 PM, Frederic Lehobey wrote:
> Hi,
> 
> On Thu, Apr 06, 2006 at 10:40:17AM +0200, Ralf Hemmecke wrote:
> 
>> I am just compiling patch-47 axiom on standard debian sarge.
>>
>> My compilation stops in the middle of compiling the documentation and 
>> just continues after I have pressed enter.
>>
>> I've tracked down the problem to that here (see below).
> 
>> woodpecker:~/OTHER/Axiom/axiom--main--1/src/doc>latex endpaper.pamphlet
> 
> I am trying to confirm this.  What I see is slightly different.  The
> compilation is simply stalled at this step (no way to press enter):
> 
> ...
> 4 making /home/fdl/axiom/tpd/mnt/linux/doc/bookvol1.dvi from /home/fdl/axiom/tpd/src/doc/bookvol1.pamphlet
> This is makeindex, version 2.14 [02-Oct-2002] (kpathsea + Thai support).
> Scanning input file bookvol1.idx.....done (1127 entries accepted, 0 rejected).
> Sorting entries............done (12024 comparisons).
> Generating output file bookvol1.ind.....done (875 lines written, 0 warnings).
> Output written in bookvol1.ind.
> Transcript written in bookvol1.ilg.
> 4 making /home/fdl/axiom/tpd/mnt/linux/doc/endpaper.dvi from /home/fdl/axiom/tpd/src/doc/endpaper.pamphlet
> 
> 
> This is weird as Camm package successfully backports to sarge...

\start
Date: 07 Apr 2006 15:53:54 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Editing wiki frontpage

Hi Bill,

  How does one edit the wiki front-page?  What I'm interested is to put
a link from the front-page to a separate page that documents the SVN source
code is organized and how to do check outs and check ins.

\start
Date: Fri, 7 Apr 2006 10:00:08 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Latex Package problem
Cc: Frederic Lehobey

On April 7, 2006 9:38 AM Ralf Hemmecke wrote:
> 
> To be honest, when I compiled axiom--main--1 I also realized that 
> "pressing enter" did not help. I had to press "q".
> 
> But strangely now a lot of "ENTER" helped.
> 
> Tim still hasn't said why he needs the "final" in 
> src/doc/endpaper.pamphlet
> 
> \usepackage[dvips,final,colorlinks=true,pdfstartview=FitH]{hyperref}
> 
> otherwise it could simply be removed. (It works without "final"
> at my place.)

That is strange. "final" is a standard option of the hyperref
package. See

http://www.tug.org/applications/hyperref/ftp/doc/manual.html

3.1  General options

Firstly, the options to specify general behavior and page size.

draft 	boolean 	false all hypertext options are turned off
final 	boolean 	true 	all hypertext options are turned on

-------

I use the "final" option all the time in the Axiom source
pamphlet files on MathAction.

> 
> Comment: Since that file uses pstricks you cannot produce a
> pdf file from it.
> 

latex <file>.tex
dvips <file>.dvi
ps2pdf <file>.ps

works for me. See:

http://www.tug.org/PSTricks/main.cgi?file=pdf/pdfoutput

\start
Date: Fri, 7 Apr 2006 10:13:23 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Editing wiki frontpage

Gaby,

On April 7, 2006 9:54 AM you wrote:
> 
> How does one edit the wiki front-page?  What I'm interested 
> is to put a link from the front-page to a separate page that
> documents the SVN source code is organized and how to do check
> outs and check ins.
> 

Editing the FrontPage (and a few other "special" pages on
the Axiom Wiki) requires a Zope user id. Right now, only me,
Rubey Martin, and Ralf Hemmecke have this sort of user id.
If you are interested in sharing responsibility for the
content of these pages, I have no problem providing you
with similar access.

On the other hand, if all you would like is a link on the
FrontPage, then just let me know the page name you want and
I will add the link for you.

\start
Date: Fri, 07 Apr 2006 16:20:03 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Latex Package problem
Cc: Frederic Lehobey

Hi

On 04/07/2006 04:00 PM, Bill Page wrote:

> That is strange. "final" is a standard option of the hyperref
> package. See
> 
> http://www.tug.org/applications/hyperref/ftp/doc/manual.html

I actually also find it strange because remember, I've read about it.

> 3.1  General options
> 
> Firstly, the options to specify general behavior and page size.
> 
> draft 	boolean 	false all hypertext options are turned off
> final 	boolean 	true 	all hypertext options are turned on

The page is not totally clear. What should the "true" after final stand for?

> I use the "final" option all the time in the Axiom source
> pamphlet files on MathAction.
> 
>> Comment: Since that file uses pstricks you cannot produce a
>> pdf file from it.

> latex <file>.tex
> dvips <file>.dvi
> ps2pdf <file>.ps
> 
> works for me.

Sorry, I meant "pdflatex" does not produce anything nice.

\start
Date: Fri, 07 Apr 2006 16:34:11 +0200
From: Ralf Hemmecke
To: list
Subject: Re: Latex Package problem

As I told you before my (standard debian) hyperref.sty is

\ProvidesPackage{hyperref}
   [2003/01/22 v6.73n
   Hypertext links for LaTeX]

The one from http://www.tug.org/applications/hyperref/
says

\ProvidesPackage{hyperref}
   [2003/11/30 v6.74m
   Hypertext links for LaTeX]

And the differences tell me that the newer version contains the 
following code that is not in 6.73n.

\define@key{Hyp}{final}[true]{%
   \Hy@boolkey{draft}{#1}%
   \ifHy@draft
     \Hy@draftfalse
   \else
     \Hy@drafttrue
   \fi
}

So in order to avoid problems for poor Debian users, I would suggest to 
simply remove "final". I believe that will not affect the output in any way.

\start
Date: Fri, 7 Apr 2006 10:44:36 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Latex Package problem

Ralf,

On April 7, 2006 10:34 AM you wrote:
> ... 
> And the differences tell me that the newer version contains
> the following code that is not in 6.73n.
> 
> \define@key{Hyp}{final}[true]{%
>    \Hy@boolkey{draft}{#1}%
>    \ifHy@draft
>      \Hy@draftfalse
>    \else
>      \Hy@drafttrue
>    \fi
> }
>

Good detective work! Thanks.
 
> So in order to avoid problems for poor Debian users,
> I would suggest to simply remove "final". I believe that
> will not affect the output in any way.
> 

I think you are right. Can someone post a patch for Tim
to apply to the main branch?

Or better: Maybe someone could commit a change to the new
SVN silver archive ... (remember to add a sentence to the
pamphlet file explaining the change).

\start
Date: Fri, 07 Apr 2006 17:00:12 +0200
From: Ralf Hemmecke
To: list
Subject: Re: ActiveAxiomDevelopers

Hello core axiom developers -- whatever that means ;-)

Could you look at
   http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers

If you believe that you belong to that group then step forward and enter 
your data there.

We should become more of a "community" and try to be more aquainted with 
each other.

All the best

\start
Date: Fri, 7 Apr 2006 11:51:49 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom silver branch

> ... 
> That repository as far as I can tell contains all of current Axiom
> sources.  That means that if you execute the command
> 
>    svn co https://svn.sourceforge.net/svnroot/axiom axiom
> 
> then you get the whole thing -- which you rarely want, except when
> you're administrator or "core" developer.
> 

Can someone confirm they successfully done a checkout of this archive?

I am trying to do this using the TortoiseSVN add-in for Windows XP

http://tortoisesvn.tigris.org
http://tortoisesvn.sourceforge.net

but after transferring about 30 Mbytes it gives me the following
error message:

  Error  REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
  Error  REPORT of '/svnroot/axiom/!svn/vcc/default':
           Could not read response body:
             Secure connection truncated
               (https://svn.sourceforge.net)

Does anyone have an idea what this might mean or where I can go
to findout?

A subsequent 'update' fails apparently at the same point.

\start
Date: Fri, 7 Apr 2006 16:53:35 +0100
From: Harry Georgiou
To: list
Subject: how to install

I have windows XP SP2 how do I install and use axiom on ,y machine from the
desktop or do I need to go into Dos-Prompt

Yours faithfully

Charalambos Georgiou

\start
Date: Fri, 07 Apr 2006 18:14:41 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Axiom silver branch

svn co https://svn.sourceforge.net/svnroot/axiom/trunk silver-branch
[snip]
A  silver-branch/axiom/lsp/Makefile.pamphlet
Checked out revision 27.

It seems that I've got it without any problem.

Is now someone telling me that I can commit to that branch through 
"https"? If yes, under which name will my commit appear?

Ralf

On 04/07/2006 05:51 PM, Bill Page wrote:
>> ... 
>> That repository as far as I can tell contains all of current Axiom
>> sources.  That means that if you execute the command
>>
>>    svn co https://svn.sourceforge.net/svnroot/axiom axiom
>>
>> then you get the whole thing -- which you rarely want, except when
>> you're administrator or "core" developer.
>>
> 
> Can someone confirm they successfully done a checkout of this archive?
> 
> I am trying to do this using the TortoiseSVN add-in for Windows XP
> 
> http://tortoisesvn.tigris.org
> http://tortoisesvn.sourceforge.net
> 
> but after transferring about 30 Mbytes it gives me the following
> error message:
> 
>   Error  REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
>   Error  REPORT of '/svnroot/axiom/!svn/vcc/default':
>            Could not read response body:
>              Secure connection truncated
>                (https://svn.sourceforge.net)
> 
> Does anyone have an idea what this might mean or where I can go
> to findout?
> 
> A subsequent 'update' fails apparently at the same point.

\start
Date: Fri, 7 Apr 2006 12:19:44 -0400
From: Bill Page
To: Harry Georgiou
Subject: RE: how to install

On Sent: April 7, 2006 11:54 AM Charalambos Georgiou wrote:

> I have windows XP SP2 how do I install and use axiom on my
>  machine from the desktop or do I need to go into Dos-Prompt

See:

http://wiki.axiom-developer.org/FrontPage

specifically download the Windows installation program here:

http://wiki.axiom-developer.org/AxiomDownload#windows

\start
Date: Fri, 7 Apr 2006 12:19:44 -0400
From: Bill Page
To: Harry Georgiou
Subject: RE: how to install

On Sent: April 7, 2006 11:54 AM Charalambos Georgiou wrote:

> I have windows XP SP2 how do I install and use axiom on my
>  machine from the desktop or do I need to go into Dos-Prompt

See:

http://wiki.axiom-developer.org/FrontPage

specifically download the Windows installation program here:

http://wiki.axiom-developer.org/AxiomDownload#windows

\start
Date: Fri, 7 Apr 2006 12:47:46 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Axiom silver branch

On April 7, 2006 12:15 PM Ralf Hemmecke wrote:
> 
> svn co https://svn.sourceforge.net/svnroot/axiom/trunk silver-branch
> [snip]
> A  silver-branch/axiom/lsp/Makefile.pamphlet
> Checked out revision 27.
> 
> It seems that I've got it without any problem.

That's good. I am still trying to diagnose the problem with
access by TortoiseSVN. Apparently it is designated as supported
software by SourceForge, so perhaps I will send them a query.

http://sourceforge.net/docs/F07/en/#top

> 
> Is now someone telling me that I can commit to that branch through 
> "https"? If yes, under which name will my commit appear?
> 

Yes. You must be registered on SourceForce as an Axiom developer,
then if you attempt an svn commit to the archive you will be
prompted for your SourceForge user id and password.

\start
Date: Fri, 07 Apr 2006 20:35:44 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Axiom silver branch

>> Is now someone telling me that I can commit to that branch through 
>> "https"? If yes, under which name will my commit appear?

> Yes. You must be registered on SourceForce as an Axiom developer,
> then if you attempt an svn commit to the archive you will be
> prompted for your SourceForge user id and password.

Well, a have a sf account, but how do I become an "Axiom developer"?

\start
Date: Fri, 7 Apr 2006 14:52:40 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Axiom silver branch

On April 7, 2006 2:36 PM Ralf Hemmecke wrote:
> 
> >> Is now someone telling me that I can commit to that branch through 
> >> "https"? If yes, under which name will my commit appear?
> 
> > Yes. You must be registered on SourceForce as an Axiom developer,
> > then if you attempt an svn commit to the archive you will be
> > prompted for your SourceForge user id and password.
> 
> Well, a have a sf account, but how do I become an "Axiom developer"?
> 

Just ask either me or Tim Daly. :)

I have added you as a developer with SVN access right at the
Axiom project on SourceForge .

\start
Date: Fri, 07 Apr 2006 20:59:55 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Axiom silver branch

Hi Gaby,

On 04/07/2006 11:54 AM, Gabriel Dos Reis wrote:
> Hello,
> 
>   As you now, Tim set up an SVN server for accessing the "silver branch"
> of Axiom on sourceforge
> 
>     http://sf.net/projets/axiom
> 
> I would like to discuss the organization of branches and procedures.

> That repository as far as I can tell contains all of current Axiom
> sources.

As Tim said, its a copy of the CVS stuff. I am not completely sure but I 
would bet that this is the same as

   arch@axiom-developer.org--axiom--axiom--main--1--patch-47

However, from the svn-log I only find that there is a "patch-45". No 
idea to what that corresponds.

My tla mirror of axiom--main--1 tells me

     arch@axiom-developer.org--axiom/axiom--main--1--patch-47
       book volume 1, cleanup
       Tim Daly
       2006-01-02 18:03:49 GMT
     arch@axiom-developer.org--axiom/axiom--main--1--patch-46
       book volume 5, bug fixes
       Tim Daly
       2005-10-31 01:33:51 GMT
     arch@axiom-developer.org--axiom/axiom--main--1--patch-45
       merge aldor patches, fix C code
       Tim Daly
       2005-09-04 15:51:14 GMT

Hmmm.

> I propose the following -- meaning I would appreciate feedback from
> you -- for organizing the SVN repository:
> 
>   * have axiom/trunk contains the silver branch sources

Fine. You could even call it "axiom/silver" and "axiom/gold", if you 
want? ;-) But maybe that confuses people who are used to the "trunk", 
"branches", "tag" suggestion of the subversion people.

>   * create axiom/branches/gold to contain the sources for the "gold branch".

I actually ask myself whether this gold thing is needed here at all, 
since Tim is actually maintaining it. Do you want to have axiom--main--1 
just a "mirror" of Tim's axiom--main--1 thing?

>   * people interested in experiments based on the silver branch will
>     create  their branches as axiom/branches/xxx, where "xxx" is the
>     name of a specific branch.

Fine with me. But somehow I would wish for the policy that branches and 
their details must be linked from an AxiomWiki page. Or are there 
Sourceforge tools to maintain such a webpage?

>     I'll write a doc about how to create a branch, how to merge, etc.

Thank you that you took over this job.

\start
Date: 07 Apr 2006 22:24:13 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom silver branch

Bill Page writes:

| > ... 
| > That repository as far as I can tell contains all of current Axiom
| > sources.  That means that if you execute the command
| > 
| >    svn co https://svn.sourceforge.net/svnroot/axiom axiom
| > 
| > then you get the whole thing -- which you rarely want, except when
| > you're administrator or "core" developer.
| > 
| 
| Can someone confirm they successfully done a checkout of this archive?

I did with both 

  svn co https://svn.sourceforge.net/svnroot/axiom axiom

and 

  svn co https://svn.sourceforge.net/svnroot/axiom/trunk axiom.trunk


But, I'm a SuSE Linux user and I built subversion 1.3.1 myself -- I
don't think that should matter.

\start
Date: 07 Apr 2006 22:26:50 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Axiom silver branch

Ralf Hemmecke writes:

| svn co https://svn.sourceforge.net/svnroot/axiom/trunk silver-branch
| [snip]
| A  silver-branch/axiom/lsp/Makefile.pamphlet
| Checked out revision 27.

That is correct.

| It seems that I've got it without any problem.
| 
| Is now someone telling me that I can commit to that branch through
| "https"? If yes, under which name will my commit appear?

I have not investigated yet how that server is set up but I think
cannot commit to that branch without a user account and proper write
access.  More on that when Tim is back and we sort out the procedure.

The idea is that people with write access should commit their own
patch after review (and of course testing).

\start
Date: 07 Apr 2006 22:28:17 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom silver branch

Bill Page writes:

| On April 7, 2006 2:36 PM Ralf Hemmecke wrote:
| > 
| > >> Is now someone telling me that I can commit to that branch through 
| > >> "https"? If yes, under which name will my commit appear?
| > 
| > > Yes. You must be registered on SourceForce as an Axiom developer,
| > > then if you attempt an svn commit to the archive you will be
| > > prompted for your SourceForge user id and password.
| > 
| > Well, a have a sf account, but how do I become an "Axiom developer"?
| > 
| 
| Just ask either me or Tim Daly. :)
| 
| I have added you as a developer with SVN access right at the
| Axiom project on SourceForge .

Great!

We should have a list of people with write access to the repository
somewhere. 

\start
Date: 07 Apr 2006 22:40:05 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Axiom silver branch

Ralf Hemmecke writes:

| Hi Gaby,
| 
| On 04/07/2006 11:54 AM, Gabriel Dos Reis wrote:
| > Hello,
| >   As you now, Tim set up an SVN server for accessing the "silver
| > branch"
| > of Axiom on sourceforge
| >     http://sf.net/projets/axiom
| > I would like to discuss the organization of branches and procedures.
| 
| > That repository as far as I can tell contains all of current Axiom
| > sources.
| 
| As Tim said, its a copy of the CVS stuff. I am not completely sure but
| I would bet that this is the same as
| 
|    arch@axiom-developer.org--axiom--axiom--main--1--patch-47
| 
| However, from the svn-log I only find that there is a "patch-45". No
| idea to what that corresponds.

Hmm, I would investigate further.  I also contains the branch "daly",
which I thought was the Tim's current version of the gold branch.

| My tla mirror of axiom--main--1 tells me
| 
|      arch@axiom-developer.org--axiom/axiom--main--1--patch-47
|        book volume 1, cleanup
|        Tim Daly
|        2006-01-02 18:03:49 GMT
|      arch@axiom-developer.org--axiom/axiom--main--1--patch-46
|        book volume 5, bug fixes
|        Tim Daly
|        2005-10-31 01:33:51 GMT
|      arch@axiom-developer.org--axiom/axiom--main--1--patch-45
|        merge aldor patches, fix C code
|        Tim Daly
|        2005-09-04 15:51:14 GMT
| 
| Hmmm.
| 
| > I propose the following -- meaning I would appreciate feedback from
| > you -- for organizing the SVN repository:
| >   * have axiom/trunk contains the silver branch sources
| 
| Fine. You could even call it "axiom/silver" and "axiom/gold", if you
| want? ;-) But maybe that confuses people who are used to the "trunk",
| "branches", "tag" suggestion of the subversion people.

yes; repository/branches/xxx is close to what people read in tutorials
and books on svn so I would not like to introduce an extra level, when
for most potential Axiom developers, the goal is not to know all the
arcanes of SVN.  I believe we should set it up in a way that they can
copy-n-paste commands with minimal changes to get started with hacking
on Axiom.

| 
| >   * create axiom/branches/gold to contain the sources for the "gold branch".
| 
| I actually ask myself whether this gold thing is needed here at all,
| since Tim is actually maintaining it. Do you want to have
| axiom--main--1
| just a "mirror" of Tim's axiom--main--1 thing?

I'm fine with leaving it entirely out if that is what the community
wants, especially Tim.

| >   * people interested in experiments based on the silver branch will
| >     create  their branches as axiom/branches/xxx, where "xxx" is the
| >     name of a specific branch.
| 
| Fine with me. But somehow I would wish for the policy that branches
| and their details must be linked from an AxiomWiki page. Or are there
| Sourceforge tools to maintain such a webpage?

I strongly favour the policy for branches, setup steps, and other
administrivia be documented so that potential contributors don't have
to "chase" the information.

As I said, I'm on a trip and I don't expect to much time and
connectivity to do that before two weeks.  But, I'm workign on it.

\start
Date: Fri, 07 Apr 2006 22:53:43 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: Axiom silver branch

Le vendredi 07 avril 2006 =C3=A0 22:40 +0200, Gabriel Dos Reis a =C3=A9cr=
it :

> Hmm, I would investigate further.  I also contains the branch "daly",
> which I thought was the Tim's current version of the gold branch.

Probably the patch #47 branch since macroexpandall is not modified...

\start
Date: Fri, 7 Apr 2006 17:43:54 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom silver branch

On April 7, 2006 4:28 PM Gabriel Dos Reis wrote:
> ... 
> We should have a list of people with write access to the repository
> somewhere. 

See:

http://sourceforge.net/project/memberlist.php?group_id=48359

There is a lot of good stuff on SourceForge that we are not using
yet. Tim and I just have not had time... Take a look around and see
what you think we can use best. E.g. They have a pretty neat server
farm for producing binaries on various platforms.

\start
Date: Fri, 07 Apr 2006 18:59:33 -0400
From: Raymond Rogers
To: Tim Daly
Subject: Re: FC5: rsync, lsp, 2412, etc

root wrote:
> Ray,
> 
> I just got the FC5 image this week so I have not yet tried to
> build an image there.
> 
> Tim
> 
> 
Tim,
	Evidently you moved the bash fix into CVS.  The make staggers on.
	My FC5 doesn't have libXpm.a and the software selector can't find it.
Any suggestions, or should I try to rebuild it?

\start
Date: 08 Apr 2006 18:19:39 +0200
From: Francois Maltey
To: list
Subject: I can't test if %i exists or not.

hello,

I'm trying to improve TRMANIP in manip.spad.

I want to know if the expressions have the Complex notion or not.

In this package I can add the function :

    ifComplex : F -> Boolean
    ifComplex (arg) ==
      (R is Complex Integer) or (R is Complex Fraction Integer) _
        or (R is Fraction Complex Integer)

the arg has no use, but with this arg I can test the function ifComplex
in the interpreter for a given expression.

I re^10-read previous mails about the qestion,
and the wiki page SandBoxManipulatingDomains, but...

1/ I can't find a better function than ifComplex for the test
<< %i exists in Expression >>.
Even if theses cases are the more current, they aren't all the cases.

2/ I can neither get %i (or imaginary()$R) in F, nor get
imag(expr) in a *.spad file although it's possible in interpreter
thanks to the file efstruc.spad (?).

In manip.spad my testing function is

testing : F -> F
testing arg == ...

I can't compile :
testing arg ==
   dom(arg)=devaluate(Expression Complex Integer)$Lisp => 999::R::F
   arg

the test is always false
testing arg ==
   F has ComplexCategory R => imaginary()::F
   arg

it's right for Complex Integer
testing arg ==
  R is Complex Integer => 987::Integer::R::F
  arg

but then I can't hold the << %i >> number.

testing arg ==
  R is Complex Integer => (imaginary()$Complex Integer)::F
  arg

When I run I get
>> System error:
   Caught fatal error [memory may be damaged]

May you give me one of the keys ? I ignore where I shall look ?
Is there any link with SExpressions...

\start
Date: Sat, 08 Apr 2006 19:23:16 +0200
From: Ralf Hemmecke
To: Francois Maltey
Subject: Re: I can't test if %i exists or not.

On 04/08/2006 06:19 PM, Francois Maltey wrote:
> hello,

> I'm trying to improve TRMANIP in manip.spad.

Well, since you are doing this privately without sharing your
understanding, there are not many on the list that can help.

By now you should have quite some understanding of all TRMANIP stuff.
I very much hope that in the process of trying to improve it you are
actually documenting the current SPAD code. If not than ALL your work is
in vain, because your "improvement" is actually NO improvement.

I know that sounds harsh, but if you are working on some code then the
first real improvement is that you document that code (or at least what
you understand of it) and let us all know.

You should open a new tla (or maybe now an svn) branch and work in
public. Don't fear that we consider your code poor or anything... most
of us don't know so much about the internals of the ALGEBRA code. We are
all eager to learn and I would say that YOU are now the expert for the
TRMANIP stuff. So let us know in a pamphlet style what you have learned.

I have looked into manip.spad and efstuc.spad. Since I haven't worked
with that packages I don't even understand what the parameters R and F
actually stand for. The documentation is really poor. If we want Axiom
to survive then it MUST be documented in an understandable way!!!

> I want to know if the expressions have the Complex notion or not.
> 
> In this package I can add the function :
> 
>     ifComplex : F -> Boolean
>     ifComplex (arg) ==
>       (R is Complex Integer) or (R is Complex Fraction Integer) _
>         or (R is Fraction Complex Integer)
> 
> the arg has no use, but with this arg I can test the function ifComplex
> in the interpreter for a given expression.

Well, you have pointed to efstruc.spad. In there
(TrigonometricManipulations) I find a function

     complexForm: F -> Complex F
       ++ complexForm(f) returns \spad{[real f, imag f]}.

Since the parameters of
TrigonometricManipulations(R, F)

   R : Join(GcdDomain, OrderedSet, RetractableTo Integer,
            LinearlyExplicitRingOver Integer)
   F : Join(AlgebraicallyClosedField, TranscendentalFunctionCategory,
            FunctionSpace R)

  are pretty similar to TranscendentalManipulations(R, F)

   R : Join(OrderedSet, GcdDomain)
   F : Join(FunctionSpace R, TranscendentalFunctionCategory)

I would guess that with a bit of luck you can use it for your test.
(Simply test "not zero? imag f".) But maybe for that the argument

   F: AlgebraicallyClosedField

is decisive.

Yes, and now when I write this (which is without much knowledge about
actual implementations in Axiom) I somehow believe the improvement that
you want to add might already be (somewhere hidden, for example in
efstruc.spad) implemented in Axiom. Unfortunately nobody knows. :-(

Have you somewhere opened a WikiPage that explains your plan in clear
terms. Posting on axiom-dev is not always enough.

\start
Date: 08 Apr 2006 21:55:32 +0200
From: Francois Maltey
To: Ralf Hemmecke
Subject: Re: I can't test if %i exists or not.

Hello Ralf,

> I would guess that with a bit of luck you can use it for your test.
> (Simply test "not zero? imag f".) But maybe for that the argument
>
>    F: AlgebraicallyClosedField
>
> is decisive.

This is THE good idea, I make good tests with :

 F has AlgebraicallyClosedField and R has imaginary:()-> R => ...

So you advise me to look at *.pamphlet files.

The first aim is perhaps to explain from A to Z how Expressions works,
in the pamphlet files.

I can do nothing interesting before I really understand how expressions are.

But can you show me a good *.pamphlet file.
All the *.pamphlet file I see only have source data and copyright data.

\start
Date: Sat, 8 Apr 2006 22:24:43 +0200
From: Frederic Lehobey
To: Axiom developers <list>
Subject: Example pamphlet file

Hi,

On Sat, Apr 08, 2006 at 09:55:32PM +0200, Francois Maltey wrote:

> But can you show me a good *.pamphlet file.
> All the *.pamphlet file I see only have source data and copyright data.

Tim often gives dhmatrix.spad.pamphlet as an example.

\start
Date: Sat, 8 Apr 2006 22:34:38 +0200
From: Frederic Lehobey
To: list
Subject: Re: Axiom silver branch

Hi,

On Fri, Apr 07, 2006 at 11:51:49AM -0400, Bill Page wrote:

> Can someone confirm they successfully done a checkout of this archive?

> but after transferring about 30 Mbytes it gives me the following
> error message:
>
>   Error  REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
>   Error  REPORT of '/svnroot/axiom/!svn/vcc/default':
>            Could not read response body:
>              Secure connection truncated
>                (https://svn.sourceforge.net)

I am seeing this almost all the time:

svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not read response=
 body: Secure connection truncated (https://svn.sourceforge.net)

(on Debian sarge) for the command:

$ svn co https://svn.sourceforge.net/svnroot/axiom/trunk/axiom silver

I have tried this something like 10 times.  And for the 1 or 2 times
it completed, I got the following error after make:

----------------------------------------------------------------
$ LANG=C make
13 making noweb
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
 incomplete literal tree

gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error exit delayed from previous errors
/bin/sh: line 1: cd: /home/fdl/axiom/silver/obj/noweb/src/c: No such file=
 or directory
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|--- modules.c	Wed Mar 28 13:49:22 2001
|+++ modules.c.tpd	Mon Nov 18 22:26:35 2002
--------------------------
----------------------------------------------------------------

Therefore I am not sure I can trust svn from sourceforge.  The branch
has been impossible to use so far for me.

It *might* be a problem with my provider not allowing enough ssh
traffic (very hard to prove but I have suspicions from other
problems).

It might also simply be sourceforge too overloaded.

\start
Date: Sat, 08 Apr 2006 23:22:25 +0200
From: Ralf Hemmecke
To: Francois Maltey
Subject: Re: I can't test if %i exists or not.

On 04/08/2006 09:55 PM, Francois Maltey wrote:
> This is THE good idea, I make good tests with :

>  F has AlgebraicallyClosedField and R has imaginary:()-> R => ...

I have really no idea whether this is what you want. Please write an 
AxiomWiki page and explain your "improvement" goals.

> So you advise me to look at *.pamphlet files.

Hmm, if nobody steps forward to explain something, then the source is 
the only truth, n'est pas? ;-)

> The first aim is perhaps to explain from A to Z how Expressions works,
> in the pamphlet files.

Very big task, but since you have at least some idea, go ahead. Some 
hints are better than nothing.

> I can do nothing interesting before I really understand how expressions are.

> But can you show me a good *.pamphlet file. 

dhmatrix.spad

But I guess, that is a bit too ambitious for the moment. If you just 
write in there what you think several code pieces could mean that is 
already something.

> All the *.pamphlet file I see only have source data and copyright data.

Unfortunately, most files are just SPAD code in pamphlet style with 
missing documentation. (For that reason, they should not be called 
pamphlets, but formally they are.)

If you are starting to document, you should split the big code pieces 
into digestable ones and write your latex text inbetween.

However, make sure that notangle applied to the file gives the same 
output as before.

Good luck. You are the Expression EXPERT by now... or is Martin claiming 
that ;-) ?

\start
Date: Sat, 8 Apr 2006 17:25:08 -0400
From: Bill Page
To: Frederic Lehobey
Subject: RE: Axiom silver branch

On April 8, 2006 4:35 PM Frederic Lehobey wrote:
> 
> On Fri, Apr 07, 2006 at 11:51:49AM -0400, Bill Page wrote:
> 
> > Can someone confirm they successfully done a checkout of 
> this archive?
> 
> > but after transferring about 30 Mbytes it gives me the following
> > error message:
> > 
> >   Error  REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
> >   Error  REPORT of '/svnroot/axiom/!svn/vcc/default':
> >            Could not read response body:
> >              Secure connection truncated
> >                (https://svn.sourceforge.net)
> 
> I am seeing this almost all the time:
> 
> svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
> svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not 
> read response body: Secure connection truncated 
> (https://svn.sourceforge.net)
> 
> (on Debian sarge) for the command:
> 
> $ svn co https://svn.sourceforge.net/svnroot/axiom/trunk/axiom
>    silver
> 
> I have tried this something like 10 times.

That is very bad news. :( I was hoping that this error was
confined to Windows.

> And for the 1 or 2 times it completed, I got the following error
> after make:
> 
> ----------------------------------------------------------------
> $ LANG=C make
> 13 making noweb
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
>  incomplete literal tree
> ... 
> 
> Therefore I am not sure I can trust svn from sourceforge.
> The branch has been impossible to use so far for me.

The same for me. :( I think the error above with tar file is
probably caused by the fact that the .tgz files in the current
CVS and tla archives are not properly marked as 'binary' files.
This has caused me problem before when using the Axiom CVS
under Windows because some Windows CVS packages do silly things
like automatically converting the unix line ending to CF LF on
Windows and of course that trashes any binary file that the
system thinks is text.

Apparently this is a known complication when converting CVS
archives to SVN. E.g.

http://list.coin-or.org/pipermail/project-managers/2005-October/000008.html
http://subversion.tigris.org/faq.html#binary-files

Storing binary files in a source code archive is something that
I have always objected to, but Tim insists on re-distributing
code this way. I really think we should stop doing this.

> 
> It *might* be a problem with my provider not allowing enough
> ssh traffic (very hard to prove but I have suspicions from
> other problems).
> 
> It might also simply be sourceforge too overloaded.

In my case I have no other problems using ssh to the sourceforge
site from Windows using other software.

\start
Date: Sat, 8 Apr 2006 23:47:06 +0200
From: Frederic Lehobey
To: list
Subject: Re: Axiom silver branch

Hi,

On Sat, Apr 08, 2006 at 05:25:08PM -0400, Bill Page wrote:
> On April 8, 2006 4:35 PM Frederic Lehobey wrote:

> > svn: REPORT request failed on '/svnroot/axiom/!svn/vcc/default'
> > svn: REPORT of '/svnroot/axiom/!svn/vcc/default': Could not
> > read response body: Secure connection truncated
> > (https://svn.sourceforge.net)

> That is very bad news. :( I was hoping that this error was
> confined to Windows.

:-(

> > And for the 1 or 2 times it completed, I got the following error
> > after make:
> >
> > ----------------------------------------------------------------
> > $ LANG=C make
> > 13 making noweb
> > tar: Skipping to next header
> > tar: Archive contains obsolescent base-64 headers
> >  incomplete literal tree
> > ...
> >
> > Therefore I am not sure I can trust svn from sourceforge.
> > The branch has been impossible to use so far for me.
>
> The same for me. :( I think the error above with tar file is
> probably caused by the fact that the .tgz files in the current
> CVS and tla archives are not properly marked as 'binary' files.

Thanks for the explanation.  I was wondering whether it was related to
the ssh problem.  (Hence my 10 attempts have been made from scratch as
I did not know whether I could trust svn on interrupted downloads --
and it takes time...)

> Storing binary files in a source code archive is something that
> I have always objected to, but Tim insists on re-distributing
> code this way. I really think we should stop doing this.

Please, provide the relevant patches. This is exactly what needs the
silver branch and what it is intended for.  :-)

> In my case I have no other problems using ssh to the sourceforge
> site from Windows using other software.

You mean using other software than svn or on other repositories than
axiom?  (I believe axiom repository is a large one compared to other
projects.)

\start
Date: Sat, 8 Apr 2006 14:58:24 -0700
From: Antoine Hersen
To: list
Subject: Bug with abbrev and aldor domain

Hello,

I get a ">> System error: Value stack overflow" when I use an
abbreviation created for an Aldor compiled Domain.

Join a minimal Domain an an input file recreating the error.



Regards,
Antoine Hersen

Transcript off the error :

T1 := SomeDomainThatNeedToBeAbbriviated(x,F)

   (5)  SomeDomainThatNeedToBeAbbriviated(x,Fraction Integer)
                                                                 Type: Doma=
in


test: LFP
                                                                   Type: Vo=
id

test := [0,0,1/x,x/(x**2+3)]

             1    x
   (7)  [0,0,-,------]
             x  2
               x  + 3
                 Type: List Fraction UnivariatePolynomial(x,Fraction Intege=
r)

a1 := test :: T1


               1    x
   (8)  D [0,0,-,------]
               x  2
                 x  + 3
                  Type: SomeDomainThatNeedToBeAbbriviated(x,Fraction Intege=
r)


)abbrev domain AAA SomeDomainThatNeedToBeAbbriviated

   AAA abbreviates domain SomeDomainThatNeedToBeAbbriviated


T2 := AAA(x,F)

   (9)  SomeDomainThatNeedToBeAbbriviated(x,Fraction Integer)
                                                                 Type: Doma=
in

a1 := test :: T1

   Loading /home/antoine/project/dfinite_2/bug for domain
      SomeDomainThatNeedToBeAbbriviated

   >> System error:
   Value stack overflow.

------=_Part_41044_27836253.1144533504493

#include "axiom.as"
-- $Id: dfinite.as,v 2.3 2006/04/08 20:16:50 antoine Exp antoine $

INT ==> Integer; 
NNI ==> NonNegativeInteger;
P ==> UnivariatePolynomial(x ,F);
FP ==> Fraction P ;
VFP ==> Vector FP;
LFP ==> List FP;
MFP ==> Matrix FP;



SomeDomainThatNeedToBeAbbriviated(x:Symbol,F:Field): with {   
    
	coerce: LFP -> % ;
	coerce: % -> LFP ;
	coerce: % -> OutputForm ;

}  == add {
	Rep ==> LFP;
	import from INT, NNI ;
	import from F, P, LFP, VFP, List VFP, List P;
	import from PrintPackage ;
	import from Vector VFP ;
	import from MFP;
	import from List MFP ;


	coerce (f:LFP):% == per f; 
	coerce (f:%):LFP == rep f;

	coerce (f:%):OutputForm == {
		a1 := rep f :: OutputForm ;
		a2 := message("D ")$OutputForm;
		hconcat(a2,a1) }
 
}

------=_Part_41044_27836253.1144533504493

)clear all
-- $Id$
-- Various test


-- We redefine some of the macro    
F ==> FRAC Integer
P ==> UnivariatePolynomial(x ,F)
FP ==> Fraction P 
LFP ==> List FP

-- The type we are going to use
T1 := SomeDomainThatNeedToBeAbbriviated(x,F)

      
test: LFP
test := [0,0,1/x,x/(x**2+3)]

a1 := test :: T1


)abbrev domain AAA SomeDomainThatNeedToBeAbbriviated 


T2 := AAA(x,F)

a1 := test :: T1

\start
Date: Sun, 9 Apr 2006 00:47:52 +0200
From: Frederic Lehobey
To: list
Subject: Re: Latex Package problem


Hi,

On Fri, Apr 07, 2006 at 10:44:36AM -0400, Bill Page wrote:

> Ralf,

> Good detective work! Thanks.
> 
> > So in order to avoid problems for poor Debian users,
> > I would suggest to simply remove "final". I believe that
> > will not affect the output in any way.
> >
>
> I think you are right. Can someone post a patch for Tim
> to apply to the main branch?

Thanks to Ralf work, we have the solution.  Here is a (simple and
obvious) patch.  I confirm it now works on Debian sarge.

> Or better: Maybe someone could commit a change to the new
> SVN silver archive ... (remember to add a sentence to the
> pamphlet file explaining the change).

Well the file is a pure TeX file, so I have added only a TeX comment.
And for svn, it will be another time (see other thread).  :-)

Fr=E9d=E9ric

--mP3DRpeJDSE+ciuQ
	filename="hyperref-final-not-on-debian-sarge.patch"

--- src/doc/endpaper.pamphlet~	2006-04-07 18:07:27.000000000 +0000
+++ src/doc/endpaper.pamphlet	2006-04-08 18:48:54.000000000 +0000
@@ -1,6 +1,14 @@
 \documentclass{book}
 %\usepackage{../../src/scripts/tex/axiom}
-\usepackage[dvips,final,colorlinks=true,pdfstartview=FitH]{hyperref}
+% 
+% 2006-04-08.  The original (correct) usepackage line below
+%\usepackage[dvips,final,colorlinks=true,pdfstartview=FitH]{hyperref}
+% has been changed to the following one in order to ease the
+% compilation of axiom on distributions (like Debian sarge) that have
+% an older version of hyperref TeX package (where the `final' option
+% is missing).  It should be restored once the latest versions (>=
+% 2003/11/30 v6.74m) of hyperref are more widespread.
+\usepackage[dvips,colorlinks=true,pdfstartview=FitH]{hyperref}
 \usepackage{pstricks}
 \usepackage{pst-node}
 \begin{document}

\start
Date: Sat, 08 Apr 2006 19:13:25 -0400
From: Raymond Rogers
To: list
Subject: FC5 success (well sort of)

Finally got around to getting it running.
Below is how to get a working version; except....
The text entry in the browser window doesn't seem to work and doesn't
report errors(:  and htsearch permissions aren't set to execute.  There
is probably a make error I missed.  If somebody doesn't give me a hint I
will save the make output and examine it. I usually do that, but
neglected this time since it's so strange.
BTW: presume I have forgotten or mistyped something; you will have a
happier life.

Ray

******************
I can package this up in a bash script if wanted.  But I hope most of it
will go away.  The Makefile.pamphlet will be updated; and the libXpm.a
will go into the release.
In other words look around a little before using these instructions;
make sure they make sense at the time and date you are using them.

If somebody wants I can edit the Makefile.pamphlet to retarget X11 paths
for FC5.

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

To get a functioning axiom on Fedora 5 as of 4/10/06
*****************
root
libXpm.a is missing from the DVD install
get libXpm from
http://mirror.mcs.anl.gov/fedora-linux-core/5/source/SRPMS/
do a build and install.  Of course it goes to different place,
Apparently they changed to X11R7 and put it in /usr/local/lib/
for now:
ln -s /usr/local/lib/libXpm.a  /usr/X11R6/lib/libXpm.a


go to some convenient directory and
make sure to mv any old axiom; a bad previous compile gummed up the cvs

cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/axiom co axiom
(my editor wrapped the last line)

cd axiom
./configure
make
should build and test
make install

cd /usr/src/axiom/mnt/linux/bin
chmod a+x htsearch


user home:  .bashrc  , or /etc/profile or /etc/bashrc
 PATH=$PATH:/usr/local/axiom/mnt/linux/bin

\start
Date: Sat, 8 Apr 2006 16:42:54 -0700
From: Antoine Hersen
To: list
Subject: Patch : Remove warning message when comipiling	with aldor

Hello,

** Problem :
When compiling using aldor the defaults compiler args emit a warning :

* Ex :
  Compiling AXIOM source code from file dfinite.as using AXIOM-XL
compiler and options -O -Fasy -Fao -Flsp -laxiom
-Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra
  Use the system command )set compiler args to change these options.
#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'

** Solution :
Fix modify default options.

** Test :
I recompiled Axiom from scratch and then I recompiled aldor support.
I run some test and I did not find any regression.

Regards,
Antoine Hersen

------=_Part_41636_30350222.1144539774849

--- ../axiom--main--1--patch-47/src/doc/book.pamphlet=092006-01-12 06:28:55=
.000000000 -0800
+++ ../dev/src/doc/book.pamphlet=092006-04-07 01:43:51.000000000 -0700
@@ -60541,7 +60541,7 @@
 system command.
 The current defaults are
 \begin{verbatim}
--O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom
+-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom
 \end{verbatim}
 These options mean:
 \begin{itemize}
@@ -60552,7 +60552,7 @@
 file,
 \index{Lisp!code generation}
 \item {\tt -laxiom}: use the {\tt axiom} library {\tt libaxiom.al},
-\item {\tt -Mno-AXL\_W\_WillObsolete}: do not display messages
+\item {\tt -Mno-ALDOR\_W\_WillObsolete}: do not display messages
 about older generated files becoming obsolete, and
 \item {\tt -DAxiom}: define the global assertion {\tt Axiom} so that the
 Aldor libraries for generating stand-alone code
--- ../axiom--main--1--patch-47/src/doc/bookvol1.pamphlet=092006-01-12 06:3=
1:10.000000000 -0800
+++ ../dev/src/doc/bookvol1.pamphlet=092006-04-07 01:50:04.000000000 -0700
@@ -13024,7 +13024,7 @@
 system command.
 The current defaults are
 \begin{verbatim}
--O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom
+-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom
 \end{verbatim}
 These options mean:
 \begin{itemize}
@@ -13035,7 +13035,7 @@
 file,
 \index{Lisp!code generation}
 \item {\tt -laxiom}: use the {\tt axiom} library {\tt libaxiom.al},
-\item {\tt -Mno-AXL\_W\_WillObsolete}: do not display messages
+\item {\tt -Mno-ALDOR\_W\_WillObsolete}: do not display messages
 about older generated files becoming obsolete, and
 \item {\tt -DAxiom}: define the global assertion {\tt Axiom} so that the
 Aldor libraries for generating stand-alone code
--- ../axiom--main--1--patch-47/src/interp/setvars.boot.pamphlet=092006-01-=
12 06:26:22.000000000 -0800
+++ ../dev/src/interp/setvars.boot.pamphlet=092006-04-07 01:28:13.000000000=
 -0700
@@ -317,7 +317,7 @@
 output       library in which to place compiled code    
 input        controls libraries from which to load compiled code 
 args         arguments for compiling AXIOM code        
-             -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete
+             -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
              -DAxiom -Y $AXIOM/algebra

 \end{verbatim}
@@ -333,7 +333,7 @@
 <<setAsharpArgs>>=
 setAsharpArgs arg ==
   arg = "%initialize%" =>
-    $asharpCmdlineFlags := '"-O -Fasy -Fao -Flsp -laxiom -Mno-AXL__W__Wi=
llObsolete -DAxiom -Y $AXIOM/algebra"
+    $asharpCmdlineFlags := '"-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR__W__=
WillObsolete -DAxiom -Y $AXIOM/algebra"
   arg = "%display%" =>
     $asharpCmdlineFlags
   (null arg) or (arg = "%describe%") or (first arg = '_?) =>
@@ -2121,14 +2121,14 @@
 (DEFUN |displaySetVariableSettings| (|setTree| |label|) (PROG (|setOption|=
 |st| |opt| |subtree| |subname|) (RETURN (SEQ (PROGN (COND ((BOOT-EQUAL |la=
bel| (QUOTE ||)) (SPADLET |label| (MAKESTRING ")set"))) ((QUOTE T) (SPADLET=
 |label| (STRCONC (MAKESTRING " ") (|object2String| |label|) (MAKESTRING " =
"))))) (|centerAndHighlight| (STRCONC (MAKESTRING "Current Values of ") |la=
bel| (MAKESTRING " Variables")) $LINELENGTH (QUOTE | |)) (TERPRI) (|sayBrig=
htly| (CONS (MAKESTRING "Variable     ") (CONS (MAKESTRING "Description    =
                            ") (CONS (MAKESTRING "Current Value") NIL)))) (=
SAY (|fillerSpaces| $LINELENGTH (|specialChar| (QUOTE |hbar|)))) (SPADLET |=
subtree| NIL) (DO ((#0=#:G2822 |setTree| (CDR #0#)) (|setData| NIL)) ((OR=
 (ATOM #0#) (PROGN (SETQ |setData| (CAR #0#)) NIL)) NIL) (SEQ (EXIT (COND (=
(NULL (|satisfiesUserLevel| (ELT |setData| 2))) NIL) ((QUOTE T) (SPADLET |s=
etOption| (|object2String| (ELT |setData| 0))) (SPADLET |setOption| (STRCON=
C |setOption| (|fillerSpaces| (SPADDIFFERENCE 13 (|#| |setOption|)) (MAKEST=
RING " ")) (ELT |setData| 1))) (SPADLET |setOption| (STRCONC |setOption| (|=
fillerSpaces| (SPADDIFFERENCE 55 (|#| |setOption|)) (MAKESTRING " ")))) (SP=
ADLET |st| (ELT |setData| 3)) (COND ((BOOT-EQUAL |st| (QUOTE FUNCTION)) (SP=
ADLET |opt| (COND ((|functionp| (ELT |setData| 4)) (FUNCALL (ELT |setData| =
4) (QUOTE |%display%|))) ((QUOTE T) (MAKESTRING "unimplemented")))) (COND (=
(PAIRP |opt|) (SPADLET |opt| (PROG (#1=#:G2828) (SPADLET #1# NIL) (RETURN=
 (DO ((#2=#:G2833 |opt| (CDR #2#)) (|o| NIL)) ((OR (ATOM #2#) (PROGN (SET=
Q |o| (CAR #2#)) NIL)) #1#) (SEQ (EXIT (SETQ #1# (APPEND #1# (CONS |o| (CON=
S (MAKESTRING " ") NIL)))))))))))) (|sayBrightly| (|concat| |setOption| (QU=
OTE |%b|) |opt| (QUOTE |%d|)))) ((BOOT-EQUAL |st| (QUOTE STRING)) (SPADLET =
|opt| (|object2String| (|eval| (ELT |setData| 4)))) (|sayBrightly| (CONS |s=
etOption| (|bright| |opt|)))) ((BOOT-EQUAL |st| (QUOTE INTEGER)) (SPADLET |=
opt| (|object2String| (|eval| (ELT |setData| 4)))) (|sayBrightly| (CONS |se=
tOption| (|bright| |opt|)))) ((BOOT-EQUAL |st| (QUOTE LITERALS)) (SPADLET |=
opt| (|object2String| (|translateTrueFalse2YesNo| (|eval| (ELT |setData| 4)=
)))) (|sayBrightly| (CONS |setOption| (|bright| |opt|)))) ((BOOT-EQUAL |st|=
 (QUOTE TREE)) (PROGN (|sayBrightly| (CONS |setOption| (|bright| (MAKESTRIN=
G "...")))) (SPADLET |subtree| (QUOTE T)) (SPADLET |subname| (|object2Strin=
g| (ELT |setData| 0))))))))))) (TERPRI) (COND (|subtree| (PROGN (|sayBright=
ly| (CONS (MAKESTRING "Variables with current values of") (APPEND (|bright|=
 (MAKESTRING "...")) (CONS (MAKESTRING "have further sub-options. For examp=
le,") NIL)))) (|sayBrightly| (CONS (MAKESTRING "issue") (APPEND (|bright| (=
MAKESTRING ")set ")) (CONS |subname| (CONS (MAKESTRING " to see what the op=
tions are for") (APPEND (|bright| |subname|) (CONS (MAKESTRING ".") (CONS (=
QUOTE |%l|) (CONS (MAKESTRING "For more information, issue") (APPEND (|brig=
ht| (MAKESTRING ")help set")) (CONS (MAKESTRING ".") NIL)))))))))))))))))))=

 ;setAsharpArgs arg ==
 ;  arg = "%initialize%" =>
-;    $asharpCmdlineFlags := '"-O -Fasy -Fao -Flsp -laxiom -Mno-AXL__W__W=
illObsolete -DAxiom -Y $AXIOM/algebra"
+;    $asharpCmdlineFlags := '"-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR__W_=
_WillObsolete -DAxiom -Y $AXIOM/algebra"
 ;  arg = "%display%" =>
 ;    $asharpCmdlineFlags
 ;  (null arg) or (arg = "%describe%") or (first arg = '_?) =>
 ;    describeAsharpArgs()
 ;  $asharpCmdlineFlags := first(arg)

-(DEFUN |setAsharpArgs| (|arg|) (COND ((BOOT-EQUAL |arg| (QUOTE |%initializ=
e%|)) (SPADLET |$asharpCmdlineFlags| (MAKESTRING "-O -Fasy -Fao -Flsp -laxi=
om -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra"))) ((BOOT-EQUAL |arg|=
 (QUOTE |%display%|)) |$asharpCmdlineFlags|) ((OR (NULL |arg|) (BOOT-EQUAL =
|arg| (QUOTE |%describe%|)) (BOOT-EQUAL (CAR |arg|) (QUOTE ?))) (|describeA=
sharpArgs|)) ((QUOTE T) (SPADLET |$asharpCmdlineFlags| (CAR |arg|)))))
+(DEFUN |setAsharpArgs| (|arg|) (COND ((BOOT-EQUAL |arg| (QUOTE |%initializ=
e%|)) (SPADLET |$asharpCmdlineFlags| (MAKESTRING "-O -Fasy -Fao -Flsp -laxi=
om -Mno-ALDOR_W_WillObsolete -DAxiom -Y $AXIOM/algebra"))) ((BOOT-EQUAL |ar=
g| (QUOTE |%display%|)) |$asharpCmdlineFlags|) ((OR (NULL |arg|) (BOOT-EQUA=
L |arg| (QUOTE |%describe%|)) (BOOT-EQUAL (CAR |arg|) (QUOTE ?))) (|describ=
eAsharpArgs|)) ((QUOTE T) (SPADLET |$asharpCmdlineFlags| (CAR |arg|)))))
 ;describeAsharpArgs() ==
 ;  sayBrightly LIST (
 ;   '%b,'")set compiler args ",'%d,_
--- ../axiom--main--1--patch-47/src/interp/setvart.boot.pamphlet=092006-01-=
12 06:31:00.000000000 -0800
+++ ../dev/src/interp/setvart.boot.pamphlet=092006-04-07 01:33:56.000000000=
 -0700
@@ -107,7 +107,7 @@
 output       library in which to place compiled code    
 input        controls libraries from which to load compiled code 
 args         arguments for compiling AXIOM code        
-             -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete
+             -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
              -DAxiom -Y $AXIOM/algebra

 \end{verbatim}
@@ -173,7 +173,7 @@
   quotes.

  The current setting is
- "-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete
+ "-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
   -DAxiom -Y $AXIOM/algebra"
 \end{verbatim}
 <<compilerargs>>=
@@ -186,7 +186,7 @@
           STRING
           $asharpCmdlineFlags
           chkDirectory
-          "-O -Fasy -Fao -Flsp -laxiom -Mno-AXL__W__WillObsolete -DAxiom -=
Y $AXIOM/algebra"))
+          "-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR__W__WillObsolete -DAxiom=
 -Y $AXIOM/algebra"))
        NIL)
 @
 \section{expose}

\start
Date: Sat, 08 Apr 2006 19:56:25 -0400
From: Raymond Rogers
To: list
Subject: Re: FC5 success (well sort of)

As I mentioned: I forgot somethings

Lack of this causes the build to fail; although the runtime didn't seem to care.  I probably didn't
test enough.
echo 0 >/proc/sys/kernel/randomize_va_space
reboot reset it???  But, as I said, it still ran.

Because I did testing under the build directory after "make install", the real chmod should be

chmod a+x /usr/lib/axiom/bin/htsearch

Ray



Raymond E. Rogers wrote:
> Finally got around to getting it running.
> Below is how to get a working version; except....
> The text entry in the browser window doesn't seem to work and doesn't
> report errors(:  and htsearch permissions aren't set to execute.  There
> is probably a make error I missed.  If somebody doesn't give me a hint I
> will save the make output and examine it. I usually do that, but
> neglected this time since it's so strange.
> BTW: presume I have forgotten or mistyped something; you will have a
> happier life.
> 
> Ray
> 
> ******************
> I can package this up in a bash script if wanted.  But I hope most of it
> will go away.  The Makefile.pamphlet will be updated; and the libXpm.a
> will go into the release.
> In other words look around a little before using these instructions;
> make sure they make sense at the time and date you are using them.
> 
> If somebody wants I can edit the Makefile.pamphlet to retarget X11 paths
> for FC5.
> 
> ********************
> 
> To get a functioning axiom on Fedora 5 as of 4/10/06
> *****************
> root
> libXpm.a is missing from the DVD install
> get libXpm from
> http://mirror.mcs.anl.gov/fedora-linux-core/5/source/SRPMS/
> do a build and install.  Of course it goes to different place,
> Apparently they changed to X11R7 and put it in /usr/local/lib/
> for now:
> ln -s /usr/local/lib/libXpm.a  /usr/X11R6/lib/libXpm.a
> 
> 
> go to some convenient directory and
> make sure to mv any old axiom; a bad previous compile gummed up the cvs
> 
> cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/axiom co axiom
> (my editor wrapped the last line)
> 
> cd axiom
> ../configure
> make
> should build and test
> make install
> 
> cd /usr/src/axiom/mnt/linux/bin
> chmod a+x htsearch
> 
> 
> user home:  .bashrc  , or /etc/profile or /etc/bashrc
>  PATH=$PATH:/usr/local/axiom/mnt/linux/bin

\start
Date: 08 Apr 2006 20:47:04 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: gcl-2.6.7 on debian

Greetings!

Yes - my guess -- emacs is not installed?  The Debian package is setup
to require the packages listed under Build-depends: in debian/control
at build time, one of which is an emacs.  The error message obviously
needs work :-).

Take care,

Tim Daly writes:

> Camm,
> 
> I tried to build Axiom on a debian machine and get:
> 
> creating makedefc
> sed: file conftest.s1 line 61:  unterminated `s' command
> creating windows/gcl.iss
> sed: file conftest.s1 line 61:  unterminated `s' command
> creating windows/sysdir.bat
> sed: file conftest.s1 line 61:  unterminated `s' command
> creating windows/install.lsp
> sed: file conftest.s1 line 61:  unterminated `s' command

\start
Date: Sat, 08 Apr 2006 21:17:41 -0500
From: Jay Belanger
To: list
Subject: Re: Developers and Axiom

Tim Daly writes:
...
>      3) now the real magic happens with emacs....
>
>         in emacs it is possible to set the "compile" command or
>         you can use a "command line macro". i use the macro approach.
>
>         in emacs you can record a whole set of keystrokes and make
>         them into a command line macro that you can execute with "C-x e"
>
>         after i've changed the source file i want to
>           a) save the changes (C-x C-s)
>           b) switch to the shell buffer (C-x o)
>           c) make -f Makefile.foo to run the makefile
>           d) switch back to my program to continue editing.
>
>         using the command line macro i can have this all happen in 1 keystroke
>
>         to create a command line macro you type "C-x (" to start recording
>         and "C-x )" to stop recording.
>
>         so, with a split screen and the cursor in your code buffer and
>         the shell in the other buffer do:
>
>         C-x (                 <== start recording
>         C-x C-s               <== save the changes
>         C-o                   <== switch to the shell
>         M-x >                 <== go to the end of the shell buffer
>         make -f Makefile.foo  <== run make
>         C-x o                 <== switch back to the code buffer
>         C-x )                 <== stop recording
>
> and now you have all the magic because "C-x e" does it all.
>
>  do forever
>    type your changes to your literate program,
>    type "C-x e" to noweave, latex, notangle, compile, test, and update xdvi
>    click on xdvi to see the changes
>
> i find it extremely productive. i run "C-x e" every 10 lines of changes
> (about once every minute or two) so i know that the latest change will
> compile, latex, and run the test cases properly.

But you need half the screen devoted to a shell, which really
shouldn't be necessary.  Why not simply have a command which runs the
makefile with `shell-command' or something similar?
(local-set-key "\C-ce" 
               (lambda () 
                  (interactive)
                  (shell-command "make -f Makefile.foo &")))
Or something could be arranged so any output goes to a (normally
non-showing) buffer, which could be displayed in case of an error.

\start
Date: Sat, 8 Apr 2006 23:34:54 -0400
From: Bill Page
To: Frederic Lehobey
Subject: RE: Axiom silver branch

On April 8, 2006 5:47 PM Frederic Lehobey wrote:
> ... 
> On Sat, Apr 08, 2006 at 05:25:08PM -0400, Bill Page wrote:
> > Storing binary files in a source code archive is something that
> > I have always objected to, but Tim insists on re-distributing
> > code this way. I really think we should stop doing this.
> 
> Please, provide the relevant patches. This is exactly what needs
> the silver branch and what it is intended for.  :-)
> 

Indeed. But these two patches will introduce two new dependencies:
both gcl and noweb would have to be installed *before* building
Axiom. Personally, I don't think that this is a problem. Tim Daly
resists. Are there any other opinions?

The first patch is really most of Camm Maquire's patch to build
Axiom on Debian without re-compiling gcl. On Debian gcl is a
build dependency, just like gcc.

The second patch was suggested by Norman Ramsey (author of noweb)
a couple of years ago. It provides a simple awk script to allow
noweb to be used with Axiom pamphlet files without modifications
to noweb.

Together these two patches eliminate the need to build noweb and
gcl as part of the Axiom build and thus eliminate the need for
the corresponding .tgz files in the source code archive.

> > In my case I have no other problems using ssh to the sourceforge
> > site from Windows using other software.
> 
> You mean using other software than svn or on other repositories
> than axiom?  (I believe axiom repository is a large one compared
> to other projects.)
> 

CVS/ssh with Axiom on SourceForge.

So far as I can tell the problem we are having with SVN does not
have anything to do with ssh or network connectivity.

\start
Date: Sat, 8 Apr 2006 21:53:16 -0700
From: Antoine Hersen
To: list
Subject: Speeding up Aldor domain compilation

Hello,

Is there a modification to the compiler argument that will speed up
the compilation for a Domain.

Compilation take over 3 minutes. Mostly when compiling the generated lisp c=
ode.

Any ideas ?

\start
Date: Sun, 09 Apr 2006 11:05:17 +0200
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Patch : Remove warning message when comipiling with aldor

Thank you Antoine,

Since -Mno-AXL_W_WillObsolete is just related to message output and does 
not change the behaviour of the compiler (hopefully -- you know, we 
cannot look inside the Aldor compiler), the patch should be OK.

But I have the suspicion that -Mno-AXL_W_WillObsolete and 
-Mno-ALDOR_W_WillObsolete are currently (Aldor 1.0.2) identical in 
behaviour except that the first one issues a warning that "AXL_" is an 
old prefix for that flag.

So the only thing that changes is that
 > #1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
will no longer show. So I welcome the patch.

% grep -l -R "AXL_W_WillObsolete" *
doc/book.pamphlet
doc/bookvol1.pamphlet
hyper/pages/ug16.ht
interp/setvars.boot.pamphlet
interp/setvart.boot.pamphlet

The file ug16.ht is missing in your patch, however the file says

% !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk.

but I have no idea from what ht.awk created that. It's somehow a poor 
comment in my eyes. But at least better than nothing.

I have not recompiled Axiom for that but I believe without that that 
this patch does the right thing. (At least it does not hurt.)

\start
Date: Sun, 09 Apr 2006 11:12:59 +0200
From: Ralf Hemmecke
To: Jay Belanger
Subject: Re: Developers and Axiom

Hi Jay,

What I like in this mail is that people come forward with things that 
work well for them and try to advertise. We can all learn from that. Not 
every emacs user knows about all the many ways that emacs can help to 
make work more productive.

What about a wiki "EmacsAxiomBestPractice" where something like that 
here would be written?

Ralf

On 04/09/2006 04:17 AM, Jay Belanger wrote:
> Tim Daly writes:
> ...
>>      3) now the real magic happens with emacs....
>>
>>         in emacs it is possible to set the "compile" command or
>>         you can use a "command line macro". i use the macro approach.
>>
>>         in emacs you can record a whole set of keystrokes and make
>>         them into a command line macro that you can execute with "C-x e"
>>
>>         after i've changed the source file i want to
>>           a) save the changes (C-x C-s)
>>           b) switch to the shell buffer (C-x o)
>>           c) make -f Makefile.foo to run the makefile
>>           d) switch back to my program to continue editing.
>>
>>         using the command line macro i can have this all happen in 1 keystroke
>>
>>         to create a command line macro you type "C-x (" to start recording
>>         and "C-x )" to stop recording.
>>
>>         so, with a split screen and the cursor in your code buffer and
>>         the shell in the other buffer do:
>>
>>         C-x (                 <== start recording
>>         C-x C-s               <== save the changes
>>         C-o                   <== switch to the shell
>>         M-x >                 <== go to the end of the shell buffer
>>         make -f Makefile.foo  <== run make
>>         C-x o                 <== switch back to the code buffer
>>         C-x )                 <== stop recording
>>
>> and now you have all the magic because "C-x e" does it all.
>>
>>  do forever
>>    type your changes to your literate program,
>>    type "C-x e" to noweave, latex, notangle, compile, test, and update xdvi
>>    click on xdvi to see the changes
>>
>> i find it extremely productive. i run "C-x e" every 10 lines of changes
>> (about once every minute or two) so i know that the latest change will
>> compile, latex, and run the test cases properly.
> 
> But you need half the screen devoted to a shell, which really
> shouldn't be necessary.  Why not simply have a command which runs the
> makefile with `shell-command' or something similar?
> (local-set-key "\C-ce" 
>                (lambda () 
>                   (interactive)
>                   (shell-command "make -f Makefile.foo &")))
> Or something could be arranged so any output goes to a (normally
> non-showing) buffer, which could be displayed in case of an error.

\start
Date: Sun, 09 Apr 2006 12:29:15 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

On 04/09/2006 05:34 AM, Bill Page wrote:
> On April 8, 2006 5:47 PM Frederic Lehobey wrote:
>> ... 
>> On Sat, Apr 08, 2006 at 05:25:08PM -0400, Bill Page wrote:
>>> Storing binary files in a source code archive is something that
>>> I have always objected to, but Tim insists on re-distributing
>>> code this way. I really think we should stop doing this.
>> Please, provide the relevant patches. This is exactly what needs
>> the silver branch and what it is intended for.  :-)
>>
> 
> Indeed. But these two patches will introduce two new dependencies:
> both gcl and noweb would have to be installed *before* building
> Axiom. Personally, I don't think that this is a problem. Tim Daly
> resists. Are there any other opinions?

We actually have (at least) two types of people.
1) Axiom users
2) Axiom developers

I guess, Axiom users are usually happy if they can download a binary 
package for their machine that works without a problem.
Unfortunately, we don't have a person who is willing to maintain such a 
collection of binaries. Somebody interested in that?

So some Axiom users have to become "Axiom builder", i.e. they have to 
download the sources and type "./configure; make; make install".

If that were all they have to do then fine, but if "configure" fails, it 
just tells you that something that is a prerequisit is not on the system 
(in Axiom there actually is no proper configure script). Then that 
person has to figure out where to get that from, install it and 
"configure" again (and maybe finding the next missing thing). That is a 
real burden, and in some sense Tim is right to minimise the effort of 
someone who just wants to _use_ Axiom.


I remember when I released my ALLPROSE many people complained that 
something is missing that they could not find. And I had given links to 
all the files on my website and prerequisites were also mentioned in the 
.dvi file. But people don't read. :-(
So yesterday, I tried to package up all the things together with 
ALLPROSE. However, I am doing this quite unwillingly.

A) It costs more time for me to package things up.
B) I feel uneasy to distribute something that is not mine, but produced 
by other people. Yes, even if it is under GPL.
C) I don't even really know whether I am allowed to do this
For example framed.sty says.

% framed.sty   v 0.8a   21-Jul-2003
% Copyright (C) 1992-2003 by Donald Arseneau
% These macros may be freely transmitted, reproduced, or modified
% provided that this notice is left intact.

If I put it together with allprose.tar.gz (GPL2) in a meta-archive, 
would that mean that framed.sty is also GPL2? (I would not want to do 
this since I don't think that I should change any license the author has 
set.)

Well Axiom is doing similar things with GCL. Even more, GCL is part of 
the Axiom archive. Hmmm...



I would feel better if if Axiom becomes something like a shell that 
depends on several prerequisites. That would make Camm's work much 
easier, and maybe we should simply learn from him. Yes, that would mean 
for each version we have to say what is the minimum version of the 
dependency object.

Well, but not all people use DEBIAN. How would other people be easy with 
not having gcl and noweb in their Axiom distribution?

There are maybe two options.
1) We have two archives, one is the prerequisite thing and one is the 
Axiom stuff we are actually focused on. Looks a bit similar to what we 
have now, but Axiom would NOT have any Makefile target that deals with 
building the prerequisites. Those Makefile things should be in the other 
archive. So this would be different from the current situation.

2) There is just one archive and this is Axiom without noweb, gcl and 
any other additional useful package. AND there is an installation script 
(Makefile or whatever) which is responsible for setting the stage so 
that Axiom will compile without complaining. That script checks if gcl 
is there in the right version, if not it would get it via "wget" from 
the internet and "make" it. Same with "noweb" etc.

I feel it is somehow a disadvantage to have a need for an internet 
connection for installation, but in some sense it is a bit like Debian 
or other GNU/Linux distributions.

The real disadvantage is when you want to press Axiom on a CD. Of course 
you must also provide the most important prerequisites like gcl and 
noweb on the CD since you cannot expect internet connection then.

We clearly already have some prerequisite. However, could somebody say 
what the prerequisites are apart from gcl and noweb? We rely on some 
"standard linux distribution". But what is "standard"? Debian 
dependencies show "libc6 (>= 2.3.2.ds1-4)" and "libgmp3". Interesting... 
I don't find them in our "zips" directory. ;-)



And what about the Axiom developers? Well, if they see that they are 
missing gcl (./configure would tell them), they look at an AxiomWiki 
page and follow the steps manually (until we have the script mentioned 
above).

Ah, yes, wasn't there someone who wanted to write some autoconf/automake 
stuff for Axiom? I would really appreciate that. It cannot hurt if we 
learn about such standard tools. Am I wrong?

All the best

\start
Date: Sun, 09 Apr 2006 12:47:07 +0200
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Speeding up Aldor domain compilation

Hi Antoine,

You are always sooo specific. :-)
There are two compilers for Axiom, but I now assume you mean the Aldor 
compiler.

On 04/09/2006 06:53 AM, Antoine Hersen wrote:
> Hello,
> 
> Is there a modification to the compiler argument that will speed up
> the compilation for a Domain.

> Compilation take over 3 minutes.


The standard command line options include "-O". That is the same as 
"-Q2". I guess, if you remove that or put "-Q0" that should speed up a bit.

> Mostly when compiling the generated lisp code.

There is a way "-C args=..." to pass arguments to the C compiler, but I 
don't know of a way for the lisp compiler.

Why takes so long is probably also because libaxiom is a big monster 
with many many interdependencies. But that is a guess.

\start
Date: Sun, 09 Apr 2006 16:01:26 +0200
From: David Mentre
To: Frederic Lehobey
Subject: Re: Axiom silver branch

Frederic Lehobey writes:

> $ svn co https://svn.sourceforge.net/svnroot/axiom/trunk/axiom silver

I have successfuly checked out revision 27 with this command (by the
way, how did you check the authentication of the certificate?

I've not yet tried to compile the silver branch.

\start
Date: Sun, 09 Apr 2006 16:02:14 +0200
From: Gregory Vanuxem
To: Raymond Rogers
Subject: Re: FC5 success (well sort of)

Hi,

Le samedi 08 avril 2006 =C3=A0 19:13 -0400, Raymond E. Rogers a =C3=A9cri=
t :

[...]

> The text entry in the browser window doesn't seem to work

Did you try with "Num Lock" disabled. On french keyboard I have to
disable "numeric keypad".

Hope that helps.

\start
Date: Sun, 09 Apr 2006 16:04:33 +0200
From: David Mentre
To: Frederic Lehobey
Subject: Re: Axiom silver branch

Frederic Lehobey writes:

> I have tried this something like 10 times.  And for the 1 or 2 times
> it completed, I got the following error after make:
>
> ----------------------------------------------------------------
> $ LANG=C make
> 13 making noweb
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
>  incomplete literal tree
>
> gzip: stdin: invalid compressed data--format violated

However I confirm I obtain the same error. The gziped tar is corrupted
(probably, as Bill suggested, because those tar file are not marked as
binary).

\start
Date: Sun, 09 Apr 2006 16:13:23 +0200
From: David Mentre
To: Bill Page
Subject: Removing external binaries from Axiom source tree: a proposal (was: Re: Axiom silver branch)
Cc: Frederic Lehobey

Hello Bill,

Bill Page writes:

> Storing binary files in a source code archive is something that
> I have always objected to, but Tim insists on re-distributing
> code this way. I really think we should stop doing this.

I can understand Tim point of view: do not depend on external sources
and manage complexity by providing the "Axiom-blessed" versions of
noweb, gcl, etc.

One possible solution to this issue would be:

 1. remove noweb, gcl, etc. sources from axiom source tree ;

 2. put them in a repository somewhere on axiom-developer.org ;

 3. write a shell script, much like GARNOME for Gnome ou Konstruct for
    KDE that fetches source dependencies from axiom-developper.org,
    build them and then build Axiom itself. 

This script could be a separate one or be part of ./configure (e.g. with
option --fetch-and-build-dependencies).

What do you think of it?

\start
Date: Sun, 9 Apr 2006 07:50:25 -0700 (PDT)
From: Cliff Yapp
To: David Mentre, Bill Page
Subject: Re: Removing external binaries from Axiom source tree: a proposal (was: Re: Axiom silver branch)
Cc: Frederic Lehobey

--- David Mentre wrote:

> Hello Bill,
> 
> Bill Page writes:
> 
> > Storing binary files in a source code archive is something that
> > I have always objected to, but Tim insists on re-distributing
> > code this way. I really think we should stop doing this.
> 
> I can understand Tim point of view: do not depend on external sources
> and manage complexity by providing the "Axiom-blessed" versions of
> noweb, gcl, etc.

This is true to a point, and indeed I think this is how many
applications on Windows work, but Linux distributions tend to not work
this way and I think that is a good thing.  Debian in particular
handles these things well.  I think a compromise solution would be a
good idea.
 
> One possible solution to this issue would be:
> 
>  1. remove noweb, gcl, etc. sources from axiom source tree ;
> 
>  2. put them in a repository somewhere on axiom-developer.org ;

Check.

>  3. write a shell script, much like GARNOME for Gnome ou Konstruct
>     for KDE that fetches source dependencies from axiom-
>     developper.org, build them and then build Axiom itself. 
> 
> This script could be a separate one or be part of ./configure (e.g.
> with option --fetch-and-build-dependencies).
> 
> What do you think of it?

I like it.  I think the cases break down as follows:

1.  Linux.   Varies by distribution, but in general there are systems
in place to handle external dependencies and it is expected that
applications will work this way.  I think Axiom itself should go ahead
and rely on external dependencies, but the degree of "external" doesn't
have to be fixed depending on the situation.  A shell script to either
retrieve the required files from a CD or download them from the web
sounds like an excellent idea.

Incidently, I just now noticed the Axiom+Aldor binary on the downloads
section - thanks, somebody!  It turned out I was abile to build it
myself but I'm quite glad to see that there.  I notice, however, that
we seem to still be distributing the Sept2005 source tarball as the
primary source build?  Should we update that?  

2.  Windows.  Windows builds of just about anything open source tend to
be painful in the extreme, and I don't think we should worry about how
"easy" this is for casual users and developers - the usual worry is
whether it's possible for EXPERTS to build it.  For windows, I like the
idea of a "make install.exe" script which downloads, builds, and
packages everything needed.  Then we can debug the logic in that on a
per-version basis (at least, this always seemed to happen with Maxima
releases)  As a first approximation the main motivation to do a
complete build of Axiom on Windows is probably for distribution
purposes (and I notice our Windows binary is very old, so this hasn't
been done in a while) so I think that focus would be a logical one. 
Most Windows users don't compile applications at all.

3.  Mac we can worry about once its working, but I think they have a
fairly standard way of doing things?

\start
Date: Sun, 09 Apr 2006 11:34:52 -0400
From: Raymond Rogers
To: Gregory Vanuxem
Subject: Re: FC5 success (well sort of)

Vanuxem Grégory wrote:
> Hi,
> 
> Le samedi 08 avril 2006 à 19:13 -0400, Raymond E. Rogers a écrit :
> 
> [...]
> 
>> The text entry in the browser window doesn't seem to work 
> 
> Did you try with "Num Lock" disabled. On french keyboard I have to
> disable "numeric keypad".
> 
> Hope that helps.
> 
> Cheers,
> 
> Greg

Surely you jest!!  OTOH: your right!
sigh....

This explains why I was able to use the browser remotely under ssh
from a WinXp laptop, and not from my computer console.  :-(

Should I try to fix this?  Since it doesn't involve the fractal
internal linkages of the axiom/spad/lisp system I might have success.

Greg: I copied the list, since it doesn't enhance people's opinions to
have hidden "secret" keys/states in machines.

\start
Date: 09 Apr 2006 20:06:41 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

Hello,

  I'm sorry to hear people have had trouble checking out the SVN tree.
When I ried check out, it was from a hotel where the connection was
very poor but I did not have problems checking out several copy and
variants of the source tree.
I'm still not in a place where I can do much right now.  But, I'm
collecting all the suggestions here.

Bill Page writes:

| On April 8, 2006 5:47 PM Frederic Lehobey wrote:
| > ... 
| > On Sat, Apr 08, 2006 at 05:25:08PM -0400, Bill Page wrote:
| > > Storing binary files in a source code archive is something that
| > > I have always objected to, but Tim insists on re-distributing
| > > code this way. I really think we should stop doing this.
| > 
| > Please, provide the relevant patches. This is exactly what needs
| > the silver branch and what it is intended for.  :-)
| > 
| 
| Indeed. But these two patches will introduce two new dependencies:
| both gcl and noweb would have to be installed *before* building
| Axiom. Personally, I don't think that this is a problem. Tim Daly
| resists. Are there any other opinions?

I believe we should keep noweb.

For GCL, I see two paths:

  (1) keep it in the source tree, but do not build it automatically:
  (2) go with Bill's suggestion and ditch it completely from the
      source tree.

My preference would be (1), but I can be persuaded to do (2) if we
can't make (1) work.

By (1), I mean
   (a) if configure dectects that there is a "reasonable" GCL
       installed, we do not need to build our own version. Or,

   (b) continue doing we're already doing today.

| The first patch is really most of Camm Maquire's patch to build
| Axiom on Debian without re-compiling gcl. On Debian gcl is a
| build dependency, just like gcc.

Not all linux distro come with a pre-installed GCL; I would like we
work for broader linxu distros as much as possible.  I would like to
see us in a position when we have a build machinery that makes it
possible to Axiomn with virtually all linux flavours -- not just debian.
I believe Axiom will gain a lot by doing that.

| The second patch was suggested by Norman Ramsey (author of noweb)
| a couple of years ago. It provides a simple awk script to allow
| noweb to be used with Axiom pamphlet files without modifications
| to noweb.
| 
| Together these two patches eliminate the need to build noweb and
| gcl as part of the Axiom build and thus eliminate the need for
| the corresponding .tgz files in the source code archive.

That is interesting.  Do you have links to those patches so that we
can see how we could/should consider them and work out the details
with Tim?

\start
Date: 09 Apr 2006 20:12:43 +0200
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

Ralf Hemmecke writes:

| On 04/09/2006 05:34 AM, Bill Page wrote:
| > On April 8, 2006 5:47 PM Frederic Lehobey wrote:
| >> ... On Sat, Apr 08, 2006 at 05:25:08PM -0400, Bill Page wrote:
| >>> Storing binary files in a source code archive is something that
| >>> I have always objected to, but Tim insists on re-distributing
| >>> code this way. I really think we should stop doing this.
| >> Please, provide the relevant patches. This is exactly what needs
| >> the silver branch and what it is intended for.  :-)
| >>
| > Indeed. But these two patches will introduce two new dependencies:
| > both gcl and noweb would have to be installed *before* building
| > Axiom. Personally, I don't think that this is a problem. Tim Daly
| > resists. Are there any other opinions?
| 
| We actually have (at least) two types of people.
| 1) Axiom users
| 2) Axiom developers
| 
| I guess, Axiom users are usually happy if they can download a binary
| package for their machine that works without a problem.

Indeed.  For such users, we should not require checkout from SVN
tree.  We should be able to provide binaries or pristine sources they
can build from.  When back to work place, I will propose a plan that
consists in building weekly snapshots for non-core developers users.

| Unfortunately, we don't have a person who is willing to maintain such
| a collection of binaries. Somebody interested in that?
| 
| So some Axiom users have to become "Axiom builder", i.e. they have to
| download the sources and type "./configure; make; make install".

100% agreed.

[...]

| Well, but not all people use DEBIAN. How would other people be easy
| with not having gcl and noweb in their Axiom distribution?

I'm not proposing this seriously, but thought it worths mentioning:
in the Perl community, the updated can compute the dependencies, and
automatically download the missing bits (if permitted).  Food for
thought. 

[...]

| Ah, yes, wasn't there someone who wanted to write some
| autoconf/automake stuff for Axiom?

yup, me :-/
I can't do all things at the same time; we have to work gradually.

\start
Date: 09 Apr 2006 21:32:00 +0200
From: Francois Maltey
To: list
Subject: how use trace for a domain

Hello,

I want to follow axiom in his computation for the imag (sin (%i)).

So I try
)trace imag                 -- I get imag isn't a function.

I reread the 30-year book and test
)trace EXPR

Then I rerun the command :

imag (sin (%i))
   >> System error:
   Bind stack overflow.

The first time I get about 55 pages of
...
  1<enter Expression.denom,81 : ((0 . 0) 0 . 1)
  1>exit  Expression.denom,81 : (0 . 1)
 1>exit  Expression.kernels,48 : NIL
 1<enter Expression.kernels,48 : ((1 #<vector 095e6a80> (2 0 . 1) (0 0 . -1=
)) 1 #<vector 095e6a80> (1 0 . 2))
  1<enter Expression.numer,79 : ((1 #<vector 095e6a80> (2 0 . 1) (0 0 . -1)=
) 1 #<vector 095e6a80> (1 0 . 2))
...


We make a mistake, I or axiom ?

\start
Date: Sun, 9 Apr 2006 22:23:35 +0200
From: Frederic Lehobey
To: list
Subject: noweb patch

Hi,

On Sun, Apr 09, 2006 at 08:06:41PM +0200, Gabriel Dos Reis wrote:
> Bill Page writes:
> | On April 8, 2006 5:47 PM Frederic Lehobey wrote:
> | > On Sat, Apr 08, 2006 at 05:25:08PM -0400, Bill Page wrote:
> | > > Storing binary files in a source code archive is something that
> | > > I have always objected to, but Tim insists on re-distributing
> | > > code this way. I really think we should stop doing this.
> | >
> | > Please, provide the relevant patches. This is exactly what needs
> | > the silver branch and what it is intended for.  :-)

> | Indeed. But these two patches will introduce two new dependencies:
> | both gcl and noweb would have to be installed *before* building
> | Axiom. Personally, I don't think that this is a problem. Tim Daly
> | resists. Are there any other opinions?
>
> I believe we should keep noweb.

Why?

> work for broader linxu distros as much as possible.  I would like to
> see us in a position when we have a build machinery that makes it
> possible to Axiomn with virtually all linux flavours -- not just debian=
.
> I believe Axiom will gain a lot by doing that.

A `dream' of mine would be to provide also axiom as a kilk
application: http://klik.atekon.de/

> | The second patch was suggested by Norman Ramsey (author of noweb)
> | a couple of years ago. It provides a simple awk script to allow
> | noweb to be used with Axiom pamphlet files without modifications
> | to noweb.
> |
> | Together these two patches eliminate the need to build noweb and
> | gcl as part of the Axiom build and thus eliminate the need for
> | the corresponding .tgz files in the source code archive.
>
> That is interesting.  Do you have links to those patches so that we
> can see how we could/should consider them and work out the details
> with Tim?

Camm Maguire's patch can be recovered from there:
http://ftp.debian.org/debian/pool/main/a/axiom/axiom_20050901-6.diff.gz
(This is a huge patch covering all the diffs needed for packaging
axiom in Debian), see: http://packages.qa.debian.org/a/axiom.html).
Maybe there is a better reference.

Norman Ramsey's patch is there:
http://lists.gnu.org/archive/html/axiom-developer/2005-12/msg00226.html

>From the discussion that followed, what was asked by Tim for inclusion
of this latter patch was proper documentation (which unfortunately I
am not -- yet? -- able to provide).

With respect to Bill questions, the scheme I favor would be:
 * no tar and no patch of external source in the silver branch (it is
for the developpers, isn't it?).  It makes the sources easier to
fetch.
 * keep the noweb and gcl sources in Tim's branch.

Hope for Tim to accept one day a proper solution that do not require
patching gcl nor noweb.  We have first to prove its viability in the
silver branch.

In the meanwhile, provide a conditional build (to be tested in silver
too): if there are locally available and convenient gcl and noweb do
not build them.  Otherwise fall back to the current build.

I think axiom users and newcomers should always be pointed at Tim's
branch (the stable one that builds everywhere!).  The silver branch
should be more experimental and intended at developers (or wannabe
developers).  I do not see the point in weekly versions as suggested
by Gabriel.

\start
Date: Sun, 9 Apr 2006 21:02:00 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: Speeding up Aldor domain compilation

On April 9, 2006 12:53 AM Antoine Hersen wrote:
> 
> Is there a modification to the compiler argument that will
> speed up the compilation for a Domain.
> 
> Compilation take over 3 minutes. Mostly when compiling the 
> generated lisp code.
> 
> Any ideas ?
> 

I do not understand what you mean by "compilation take over
3 minutes". I have compiled many domains in Aldor and no
compilation I ever did took more than a few seconds. We
regularly compile Aldor domains on the Axiom wiki with no
noticable delay more than any other simple Axiom calculation.

The only explanation I can think of is that your computer
must be very limited in memory and that it spends an extreme
amount of time swapping to disk.

\start
Date: Mon, 10 Apr 2006 09:41:01 +0700 (NOVST)
From: Andrey G. Grozin
To: Frederic Lehobey
Subject: Re: noweb patch

On Sun, 9 Apr 2006, Frederic Lehobey wrote:
> A `dream' of mine would be to provide also axiom as a kilk
> application: http://klik.atekon.de/
Please, NO!!

It asks the user to execite an arbitrary code from an untrusted place in 
the Internet. No sane person should do this. Ever.

\start
Date: Mon, 10 Apr 2006 10:27:48 +0200
From: Frederic Lehobey
To: Andrey G. Grozin
Subject: klik or not?

Hi,

On Mon, Apr 10, 2006 at 09:41:01AM +0700, Andrey G. Grozin wrote:
> On Sun, 9 Apr 2006, Frederic Lehobey wrote:
> >A `dream' of mine would be to provide also axiom as a kilk
> >application: http://klik.atekon.de/
> Please, NO!!
>
> It asks the user to execite an arbitrary code from an untrusted place i=
n
> the Internet. No sane person should do this. Ever.

OK.

This is a sensible objection.  Though: the binary might be signed by
the developers or any other trusted person; it might also be run from
a chroot.  I think anyways we are still very far from a `klikable'
axiom.

\start
Date: 10 Apr 2006 11:10:34 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: how use trace for a domain

Dear Francois,

the command you are looking after is

)tr XXX )ops imag

where XXX is the domain/package/category your imag is implemented in. To find
out which package it is, you proceed as follows:

(1) -> )se me bo on
(1) -> imag (sin (%i))

 Function Selection for complex
      Arguments: (NNI,PI) 
   -> no appropriate complex found in NonNegativeInteger 
   -> no appropriate complex found in PositiveInteger 
   -> no appropriate complex found in Integer 
   -> no appropriate complex found in NonNegativeInteger 
   -> no appropriate complex found in PositiveInteger 
   -> no appropriate complex found in Integer 

 Modemaps from Associated Packages 
   no modemaps

 Remaining General Modemaps 
   [1] (D1,D1) -> D from D if D has COMPCAT D1 and D1 has COMRING
 
 [1]  signature:   (INT,INT) -> COMPLEX INT
      implemented: slot $(Integer)(Integer) from COMPLEX INT
 
   Loading /home/rubey/axiom/mnt/linux/algebra/INT.o for domain Integer
      
   Loading /home/rubey/axiom/mnt/linux/algebra/COMPLEX.o for domain 
      Complex 

 Function Selection for sin
      Arguments: COMPLEX INT 
   -> no appropriate sin found in Complex Integer 
   -> no appropriate sin found in Complex Integer 

 Modemaps from Associated Packages 
   no modemaps

 Remaining General Modemaps 
   [1] D -> D from D if D has TRIGCAT
   [2] FortranExpression(D1,D2,D3) -> FortranExpression(D1,D2,D3)
            from FortranExpression(D1,D2,D3)
            if D1: LIST SYMBOL and D2: LIST SYMBOL and D3 has FMTC
 
 [1]  signature:   EXPR COMPLEX INT -> EXPR COMPLEX INT
      implemented: slot $$ from EXPR COMPLEX INT

 Function Selection for imag
      Arguments: EXPR COMPLEX INT 
   -> no appropriate imag found in Expression Complex Integer 
   -> no appropriate imag found in Expression Complex Integer 

 Modemaps from Associated Packages 
   no modemaps

 Remaining General Modemaps 
   [1] D1 -> D1 from TrigonometricManipulations(D2,D1)
            if D2 has Join(GcdDomain,OrderedSet,RetractableTo Integer,
            LinearlyExplicitRingOver Integer) and D1 has Join(
            AlgebraicallyClosedField,TranscendentalFunctionCategory,
            FunctionSpace D2)
   [2] D2 -> Expression D3 from ComplexTrigonometricManipulations(D3,D2
            )
            if D3 has Join(IntegralDomain,OrderedSet,RetractableTo 
            Integer) and D2 has Join(AlgebraicallyClosedField,
            TranscendentalFunctionCategory,FunctionSpace Complex D3)
         
   [3] D -> D1 from D if D has COMPCAT D1 and D1 has COMRING
   -> no appropriate map found in Expression Complex Integer 
   -> no appropriate map found in Complex Integer 
   -> no appropriate map found in Expression Integer 
   -> no appropriate map found in Integer 
   -> no appropriate map found in Complex Integer 
   -> no appropriate map found in Integer 

 Modemaps from Associated Packages 
   [1] ((D4 -> D5),Expression D4) -> Expression D5
            from ExpressionFunctions2(D4,D5)
            if D4 has ORDSET and D5 has ORDSET
   [2] ((D4 -> D1),Kernel D4) -> D1 from ExpressionSpaceFunctions2(D4,
            D1)
            if D4 has ES and D1 has ES
   [3] ((D4 -> D5),Complex D4) -> Complex D5 from ComplexFunctions2(D4,
            D5)
            if D4 has COMRING and D5 has COMRING
 
 [1]  signature:   EXPR COMPLEX INT -> EXPR INT
      implemented: slot (Expression (Integer))(Expression (Complex (Integer))) from CTRIGMNP(INT,EXPR COMPLEX INT)
 [2]  signature:   EXPR COMPLEX INT -> EXPR COMPLEX INT
      implemented: slot (Expression (Complex (Integer)))(Expression (Complex (Integer))) from TRIGMNIP(COMPLEX INT,EXPR COMPLEX INT)
 
          2
        %e  - 1
   (1)  -------
          2%e
                                                     Type: Expression Integer

Now you have to look up "imag" in the mess above. You find

 Function Selection for imag
     Arguments: EXPR COMPLEX INT 

and at the end of axioms search you find

 [1]  signature:   EXPR COMPLEX INT -> EXPR INT
      implemented: slot (Expression (Integer))(Expression (Complex (Integer))) from CTRIGMNP(INT,EXPR COMPLEX INT)
 [2]  signature:   EXPR COMPLEX INT -> EXPR COMPLEX INT
      implemented: slot (Expression (Complex (Integer)))(Expression (Complex (Integer))) from TRIGMNIP(COMPLEX INT,EXPR COMPLEX INT)
 
Axiom takes the first matching signature, so you now know that it's 

"imag" from CTRIGMNP(INT,EXPR COMPLEX INT)

If you now say

)tr CTRIGMNP )ops imag

you'll get what you wanted.

The bind stack overflow when tracing EXPR is a bug.

\start
Date: Mon, 10 Apr 2006 16:06:24 +0200
From: Gregory Vanuxem
To: Raymond Rogers
Subject: Re: FC5 success (well sort of)

Hi,

Le dimanche 09 avril 2006 =C3=A0 11:34 -0400, Raymond E. Rogers a =C3=A9c=
rit :
> Vanuxem Gr=C3=A9gory wrote:
> > Hi,
> >
> > Le samedi 08 avril 2006 =C3=A0 19:13 -0400, Raymond E. Rogers a =C3=A9=
crit :
> >
> > [...]
> >
> >> The text entry in the browser window doesn't seem to work
> >
> > Did you try with "Num Lock" disabled. On french keyboard I have to
> > disable "numeric keypad".
> >
> > Hope that helps.
> >
> > Cheers,
> >
> > Greg
>
> Surely you jest!!  OTOH: your right!

No, sorry. Sometimes I quickly write emails that contain some
abominations so I thought that you have, perhaps, forgotten to disable
"Num Lock". But if you think you have found a bug in Axiom and not in
your libraries file a bug on Mathaction.

> sigh....
> This explains why I was able to use the browser remotely under ssh from=
 a WinXp laptop, and not
> from my computer console.  :-(
>
> Should I try to fix this?  Since it doesn't involve the fractal interna=
l linkages of the
> axiom/spad/lisp system I might have success.

Why not. Send documented patch to Timothy Daly
(Tim Daly) and Gabriel Dos Reis
(Gabriel Dos Reis). CC it, too, to
list for public review.

Cheers,

Greg
>
> Greg: I copied the list, since it doesn't enhance people's opinions to =
have hidden "secret"
> keys/states in machines.

\start
Date: Mon, 10 Apr 2006 11:19:46 -0400
From: William Sit
To: Francois Maltey
Subject: Re: )trace and RANDOM() bugs (was how use trace for a domain)

Francois Maltey wrote:

> )trace EXPR
> imag (sin (%i))
>    >> System error:
>    Bind stack overflow.

This is related to IssueTracker #232, #233, 

I traced the problem to FRAC but so far am not able to pin point what it is. It
seems to have to do with coercion to output, but may be not.

The bug has nothing to do with imag, sin, or '%i'.  See SandBox Trace EXPR.
I am working on the report to IssueTracker #283 (nothing posted yet).

\start
Date: Mon, 10 Apr 2006 11:48:20 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom silver branch
Cc: Frederic Lehobey

> -----Original Message-----
>
> Hello,
>
>   I'm sorry to hear people have had trouble checking out the SVN
> tree. When I ried check out, it was from a hotel where the
> connection was very poor but I did not have problems checking
> out several copy and variants of the source tree. I'm still not
> in a place where I can do much right now.  But, I'm collecting
> all the suggestions here.
>

I don't know that the problem is with downloading the archive
using SVN on Windows and some linux platforms. It might be
network configuration related but it is also SVS specific since
I can download successfully using CVS on SourceForge through
the same machine and network connection. I hope this is something
that is corrected in newer versions of SVN.

Concerning storing binary files in the Axiom CVS and SVN archives
I think we should at least make it work correctly as it is before
we consider removing the binary files from the archive since if
the parameters are set correctly, this is supposed to work. After
it is working properly as is, we can then consider changing it to
eliminated the binary files for philosophical and efficiency
reasons.

In the SourceForge Axiom CVS archive I have set the binary mode
for all the *.tgz files in the zips directory using the command:

cvs admin -kb

as described here:

http://www.idevelopment.info/data/Programming/change_management/unix_cvs/=
PRO
GRAMMING_Working_with_Binary_Files.shtml

I have also requested a 'refresh' of the SourceForge Axiom SVN
from CVS, so that should correct the binary files problem and
permit Axiom to be build from the SVN archive. According to
SourceForge this might take 2 or 3 hours to complete. (Is SVN
really that slow?)

\start
Date: Mon, 10 Apr 2006 18:05:53 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

> In the SourceForge Axiom CVS archive I have set the binary mode
> for all the *.tgz files in the zips directory using the command:
> 
> cvs admin -kb
> 
> as described here:
> 
> http://www.idevelopment.info/data/Programming/change_management/unix_cvs/PRO
> GRAMMING_Working_with_Binary_Files.shtml

Hmm, I guess, if the binary flag for the file in CVS was not put there 
BEFORE the file is first checked into CVS then a later change will not 
help. I have not tested that, but I think that the file is already 
corrupted.

Why cannot we simply use the current patch-47 (plus Tim's changes) and 
generate the SVN stuff from that?

I think it would even be reasonable to release patch-48 and then start 
with these sources the SVN archive. Then we can forget about all the 
trouble with CVS and binaries.

Does someone need the history that is in the CVS currently? Aren't we 
satisfied with the history of axiom--main--1--patch-47?

\start
Date: Mon, 10 Apr 2006 13:42:05 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Axiom silver branch
Cc: Frederic Lehobey

On April 10, 2006 12:06 PM Ralf Hemmecke wrote:
>
> Bill Page wrote:
> > In the SourceForge Axiom CVS archive I have set the binary mode
> > for all the *.tgz files in the zips directory using the command:
> > 
> > cvs admin -kb
> > 
> > as described here:
> > 
> > http://www.idevelopment.info/data/Programming/change_managemen
> >   t/unix_cvs/PROGRAMMING_Working_with_Binary_Files.shtml

> Hmm, I guess, if the binary flag for the file in CVS was not put
> there BEFORE the file is first checked into CVS then a later change
> will not help. I have not tested that, but I think that the file
> is already corrupted.

No. There is no corruption in the CVS. You can do a checkout of
Axiom from the CVS and everything works fine, even though the
binary flag is not set. CVS actually assumes unix line endings
so there is really no conversion of the binary provided that you
only use CVS on a linux/unix platform. A problem only occurs with
CVS if you use a Windows (or other OS) version of CVS where the
line ending defaults to something else. Even in that case with
the newer versions of Windows one can simply specify that you
want to keep the "unix-style" line endings and everything works
out fine.

The problem occurs when you transfer a CVS containing binary
files that are not properly marked as such, to a SVN repository.
In that case the files are corrupted even on linux/unix. I do
not know the reason why this occurs in SVN - whether it is a
bug or just a design "feature". Anyway, but setting the correct
flags on CVS and *then* doing another transfer of the contents
of the CVS to SVN, everything should work out ok. (probably
not the last word ... ;)

> Why cannot we simply use the current patch-47 (plus Tim's
> changes) and generate the SVN stuff from that?

As far as I understand it, patch-47 is the content of the CVS
on SourceForge.

>
> I think it would even be reasonable to release patch-48 and
> then start with these sources the SVN archive. Then we can
> forget about all the trouble with CVS and binaries.

As I said, the trouble starts with SVN, not CVS.

> Does someone need the history that is in the CVS currently?
> Aren't we satisfied with the history of axiom--main--1--patch-47?

I think you might be right about the irrelevance of history
to the "silver" branch so that means we could optimize the
SVN archive and remove (most?) of this history.

\start
Date: Mon, 10 Apr 2006 13:54:53 -0400
From: Bill Page
To: Harry Georgiou
Subject: RE: how to install

On April 10, 2006 1:35 PM Harry wrote:
> 
> From the program that I downloaded and installed the program 
> works ok but it is in a Dos prompt gui, which I am ok with but
> not all the operations are kept as the scroll bar does not seem
> to be able to go back to the beginning whether that is to save
> memory I do not know.

Yes, Axiom runs in a "dos box" on Windows. The scrolling is
controlled by Windows and has nothing to do with Axiom.

> When I try to do graphics I get
> 	>> System error:	
> 	SOCK-SEND-INT is invalid as a function.
> 
> Protected-symbol-warn called with (NIL)
> 
> Do I need to install another add on package

No. As explained at

http://wiki.axiom-developer.org

Axiom graphics and hyperdoc are not yet implemented on Windows.

> and also in the tutorial pdf it talks about Texemacs or
> something and a drop down menu but the dos gui I have does
> not, is that meant to be something else I also need to
> install

If you want TeXmacs, then you must install it separately ...
again as explained at

http://wiki.axiom-developer.org

\start
Date: Mon, 10 Apr 2006 15:15:11 -0500
From: Jay Belanger
To: Ralf Hemmecke
Subject: Re: Developers and Axiom

Ralf Hemmecke writes:
...
> What about a wiki "EmacsAxiomBestPractice" where something like that
> here would be written?

Should that be added to the current "Axiom in Emacs" page, or should
"EmacsAxiomBestPractice" be a new page?  
I'd be happy to create the page.  It should probably start with Tim's
discussion, but I wouldn't want to add it without his okay.

\start
Date: 11 Apr 2006 10:01:20 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

Bill Page writes:

| > -----Original Message-----
| > From: Gabriel Dos Reis 
| > [mailto:Gabriel Dos Reis] 
| > Sent: April 9, 2006 2:07 PM
| > To: Bill Page
| > Cc: 'Frederic Lehobey'; 'Axiom developers'
| > Subject: Re: Axiom silver branch
| > 
| > 
| > 
| > Hello,
| > 
| >   I'm sorry to hear people have had trouble checking out the SVN
| > tree. When I ried check out, it was from a hotel where the
| > connection was very poor but I did not have problems checking
| > out several copy and variants of the source tree. I'm still not
| > in a place where I can do much right now.  But, I'm collecting
| > all the suggestions here.
| >
| 
| I don't know that the problem is with downloading the archive
| using SVN on Windows and some linux platforms. It might be
| network configuration related but it is also SVS specific since
| I can download successfully using CVS on SourceForge through
| the same machine and network connection. I hope this is something
| that is corrected in newer versions of SVN. 

I looked at the problem.  I believe the problem creped in when the
conversion from CVS to SVN was done -- though I need more
investigation.  I'm currently at a place where I cannot work (I can 
read mails for about 15min a day).  I'll be at working place next week.

| Concerning storing binary files in the Axiom CVS and SVN archives
| I think we should at least make it work correctly as it is before
| we consider removing the binary files from the archive since if
| the parameters are set correctly, this is supposed to work. After
| it is working properly as is, we can then consider changing it to
| eliminated the binary files for philosophical and efficiency
| reasons.

I agree.

| In the SourceForge Axiom CVS archive I have set the binary mode
| for all the *.tgz files in the zips directory using the command:
| 
| cvs admin -kb
| 
| as described here:
| 
| http://www.idevelopment.info/data/Programming/change_management/unix_cvs/PRO
| GRAMMING_Working_with_Binary_Files.shtml
| 
| I have also requested a 'refresh' of the SourceForge Axiom SVN
| from CVS, so that should correct the binary files problem and
| permit Axiom to be build from the SVN archive.

Thanks!

| According to
| SourceForge this might take 2 or 3 hours to complete. (Is SVN
| really that slow?)

yes, it is that fast, when you mind about the history of the commits
and such.... 

\start
Date: Tue, 11 Apr 2006 04:22:32 -0400
From: William Sit
To: Bill Page
Subject: error and editing

Hi Bill:

Last night, I accidentally modified the title of SandBox to [SandBox Trace EXPR]
but I think I managed to revert it back. Please verify, since Wiki seems to
automatically update all links once a title is modified.

I also found that the preview and resulting display after a save not to apply
line wrap so that a long paragraph is displayed as a long line. This happened
both for Firefox and IE (and I don't think it is my local settings). In other
words, the style is not handling html correctly. I tried all sorts of editing
style (pamphlet, etc) and none seem to help and I had to manually insert
linefeeds.

Somehow, [SandBox Trace EXPR and FRAC] has word wrap but [SandBox Trace
Analysed] does not. I left the first text paragraph like that as an example.

Changing the editing style modified the source too, for example, '0$EXPR' would
sometimes turn into $0$EXPR$ which would be quite confusing (to me at least).

I tried to find how to set the wrap line option in preferences but could not.

Sorry for the mess up and thanks for fixing up any left-overs.

\start
Date: Tue, 11 Apr 2006 04:30:55 -0400
From: William Sit
To: Martin Rubey,
Subject: Re: how use trace for a domain

Martin Rubey wrote:

> The bind stack overflow when tracing EXPR is a bug.

I have attempted to trace this with simple commands that exhibits this, like
2/3::FRAC INT. This is still work in progress (took already my weekend), but you
can take a look at [SandBox Trace Analyzed] and related pages. 

I probably don't have time until next week to continue. Feel free to correct any
errors I made or insert alternative explanation. The final pages will be made
part of IssueTracker #283.

My suspicion is it has to do with FRAC, )math, and of course )trace. Does anyone
knows how to trace )trace? (Tim: where is )trace and in what language is it
written?)

\start
Date: Tue, 11 Apr 2006 06:32:10 -0400
From: William Sit
To: Ralf Hemmecke
Subject: Re: operations working in general, but not in specialcases -- help needed

Ralf Hemmecke wrote on Wed, 05 Apr 2006 12:23:36 +0200:
> 
> Dear William,
> 
> I like most of what you have written, but I must oppose against a few
> things.
> 

> > I assume you want MatroidCat to be the category of all matroids, in which case,
> > the dual operation is actually a domain constructor.  That is, the above
> > signature cannot do what you are aiming for:
> >
> >     MatroidCat():Category == ... with
> >       dual: % -> %
> >
> > because the % refers to a particular implementation of a domain which is a
> > matroid, not the category itself.
> 
> Sorry, I have not yet read about Matroids, but in simple terms it is that
>         dual: % -> %
> transforms a concrete matroid M=(E, I) to M^D=(E, I^D) but doing this by
> assuming I^D = I (and thus M=M^D) which need of course not be the case).
> 
> So clearly that signiture is wrong.

There seems to be some confusion in this chain of emails about the word "dual".
I think Martin originally meant the dual of a matroid, not the dual of an
element of a matroid (whatever that means). So in the quoted setting, dual:%->%
is incorrect. It also does not mean constructing the dual of M=(E,I) with
M^D=(E, I), or anything else.
 
> > The argument to dual is an element of a
> > matroid. A plausible signature is:
> >
> >       dual:() -> MatroidCat()
> >
> > which associates a matroid to the current matroid.


You are quoting the above out of context. Here is what I wrote:

"I assume you want MatroidCat to be the category of all matroids, in which case,
the dual operation is actually a domain constructor.  That is, the above
signature cannot do what you are aiming for:

    MatroidCat():Category == ... with
      dual: % -> %

because the % refers to a particular implementation of a domain which is a
matroid, not the category itself. The argument to dual is an element of a
matroid. A plausible signature is:

      dual:() -> MatroidCat()

which associates a matroid to the current matroid."

I was explaining that in the displayed code above, the argument to dual is an
element x of a matroid and it would return an element y of the same matroid,
called the dual of x (whatever that mean).  The next sentence, "A plausible ..."
is to give a more correct signature for what Martin has in mind, constructing
the dual of the domain, which is a matroid. Thus:

   MatroidCat():Category == ... with
     dual:() -> MatroidCat()

It is much like the object oriented approach that associates other objects to
objects in the form M.dual (which refers to a constructor giving M^D), except in
Axiom syntax, it is dual() in the domain constructor of M.

> That sounds promising but here I must oppose. The reason is that the
> resulting dual domain will probably be not very useful.

The usefulness depends on what one does with the dual of the matroid in
computations. Usefulness has nothing to do with the implementation.
 
> But let's analyse this...
> 
> >     MatroidCat(): Category == Finite with
> >       underlyingSet: () -> Finite
> >       underlyingFamily: () -> Set %
> >       span: Set % -> Set %
> >       defining?: % -> Boolean  -- true if set is in underlyingFamily()
> >       independent?:  Set % -> Boolean
> >       circuit?: Set % -> Boolean
> >       ...
> >       dualSet: () -> Set %  -- constructs I^D
> >       dual: () -> MatroidCat()
> >       dual()==Matroid(underlyingSet(), dualSet())
> >       ...
> 
> Clearly, that category is very much involved and cannot be compiled
> without knowing about the constructor Matroid(E, I). But it's not that
> what I find problematic. It is the appearance of MatroidCat within the
> "with" expression. What comes after the == depends on what comes before.
> I cannot say, that I like this very much. Would you do something like
> that in (mathematical) category theory? The "with" expression alone is
> not a value until MatroidCat is known.

 All that MatroidCat() spells out is basically an (incomplete, declarative)
definition of a matroid, plus a bunch of operations and functions that are
useful for computations. Domains like the proposed Matroid(E,I) constructs
actual matroids and implements those operations and functions. So the signature:

      dual:()->MatroidCat()

simply says attach a new matroid to a given matroid. 

In terms of language design and computer science, self-referencing (more
generally, circular references) and the much related recursion technique is what
gives languages like Axiom their power. It is the equivalent to induction in
mathematics. I can find you many examples in Axiom where this is the case. For
example, see expr.spad and trace the representation Rep of EXPR INT (if you are
lazy, just go to [SandBox Trace Analyzed], which is still a work-in-progress
page, but good enough to illustrate this.)

> 
> What else is bad is that the dual is always constructed by the domain
> constructor Matroid. You don't allow other implementations (other
> constructors).

I don't think you are right, and indeed, quite the contrary. To construct the
dual matroid M^D from a given matroid M, you must start with some given data of
M. While it is conceivable you can have two different constructions of M^D with
the *same* data, it is rarely the case, and a different set of data representing
the same matroid M would necessarily require a different construction for its
dual. What Axiom allows, in the above scheme, is to give a categorical way of
constructing duals of matroids that use the same type of data representations.
Remember also, the above is an idealized version. In reality, the data for M
must be passed also the the MatroidCat. You should also note that I did not like
this approach: I prefer using a domain constructor Dual instead.

> > Alternatively, instead of using functions dual(), you can have a domain
> > constructor:
> >
> >     DualSet(M:MatroidCat): Set Set underlyingSet M == ...
> >
> >     Dual(M:MatroidCat):MatroidCat ==
> >       E:= underlyingSet(M)
> >       I:=underlyingFamily(M)
> >       J:=DualSet(M)
> >       Matroid(E, J)
> 
> Well, that demonstrates what I mean by "the resulting dual domain will
> probably be not very useful" above.
> 
> Suppose you create a very special matroid M which inherits from
> MatroidCat but additionally from many other categories. If you now say
> 
> N == Dual(M)
> 
> you will get something that is constructed by the constructor Matroid
> (which might actually not be that what you want -- remember there are
> also several implementations of polynomials and they are all good for
> something).

You are correct, but there is nothing to prevent you from having another domain
constructor that construct duals! I was using one example. You can put
subscripts to Dual and Matroid if you like (and in fact, some may not be using
underlyingSet or underlyingFamily, depending on how a matroid is given). Again,
that is the great flexibility of Axiom.

> So the next idea would be something like
> 
>    Dual(M: MatroidCat, MAT: ??? -> MatroidCat): MatroidCat ==
>      MAT(underlyingSet M, DualSet M);
> 
> Well, what can you do if you now say
> 
> N == Dual(M, MyMatroid)
> 
> ? Actually not much, since that N is of type MatroidCat and nothing
> more. No additional features are available even if MyMatroid would
> return something of category MyMatroidCat that is much richer than
> MatroidCat itself.

I have to remind you that MatroidCat can take parameters. Your example of
POLYCAT is exactly the right analogy. If we put MatroidCat(E:SetCategory, I:Set
Set E), then we can have in effect many matroid categories when the parameters E
and I are constructed by some set domain constructors, themselves possibly
parametrized. The additional features will be reflected this way, much like the
features of SUP, UP, SMP, POLY, etc.

> With the above Dual constructor, you explicitly restrict the exports to
> MatroidCat. And I would have no other idea to add features than to use
> "pretend". Brrrrrhhh.

Again, MatroidCat can take parameters, so extra features are not restricted.
The extra features are added because there are *many* MatroidCat's, just like
there are many POLYCAT's (may be we should call MatroidLitters?) There are extra
features in each of SUP, UP, SMP, and POLY and only *one* POLYCAT category
constructor!

> > A more practical implementation may have this outline:
> >
> >    MatroidCat(E:Finite, I:Set Set E): Category == Finite with
> >      span: Set % -> Set %
> >      independent?:  Set % -> Boolean
> >      circuit?: Set % -> Boolean
> >      ...
> >
> >
> >    Matroid(E: SetCategory, I:Set Set E):MatroidCat(E,I) == ... with
> >
> >    DualSet(E:SetCategory, I:Set Set E):List List E ==
> >
> >    Dual(E:SetCategory, I:Set Set E):MatroidCat(E, DualSet(E,I)) == ...
> 
> I like that somehow much better, but the same "restriction process" as
> above takes place. Things are not so easy with a dual functor.

I don't think I was planning to exhaust all possibilities. You are right to
point out that. But we can have *many* Dual constructors based on *other*
parameters.
Again, the analogy is the *other* parameters for construction of polynomial
rings, as in DMP(vl:List Symbol, R:Ring) and the parameters for the
corresponding POLYCAT is constructed from vl and R.


> > If you do NOT want to implement dual as a domain constructor, then you may try
> > implementing Matroid as the DOMAIN of all matroids. However, Axiom does not
> > allow dependent types at the code level (only at the declaration level for
> > constructors).
> >
> >    Matroid(): SetCategory == ...
> >
> >      Rep:= Record(E:SetCategory, I:Set Set E)
> >
> > probably won't work in Axiom, but Aldor may.
> 
> Did you really mean SetCategory? 


Yes I do. This says Matroid() constructs a set, and if you use (E,I) to
represent a matroid, then Matroid() constructs a set of some (E,I)'s where E, I
would vary subject to I being a subset of the power set of E.

> So to create a new element you would
> write a function.
> 
>    matroid(A: SetCategory, B: Set Set A): % == per [A, B];
> 
> and call it with
> 
>    matroid(Integer, [[1,2], [3,4,5]]);

Yes.
 
> That sounds to me as follows: If E' \supset E and I \subseteq Power(E)
> then the matroids (E, I) and (E', I) are the same. I cannot believe that.

Why? By definition, (E, I) and (E', I) are different matroids. The Rep above
shows they are different if E is not E'.  However, they are clearly isomorphic
as matroids. (That's why the ambient set E is not of much importance as long as
all the elements of I are subsets of E. We may as well use the union over all
sets in I as the set E. If you read the definition of a matroid I gave, nothing
in E outside of this union matters. There is also no requirement of any
algebraic structure on E. The whole essense of matroids depends on the set
relations among a (finite) family of finite subsets.

\start
Date: Tue, 11 Apr 2006 12:34:33 +0200
From: Ralf Hemmecke
To: Jay Belanger
Subject: Re: Developers and Axiom

Hi Jay,

Well, I somehow think it is better if there is just one page "Axiom in 
Emacs" (even though it does not completely fit). With too many pages, 
people get easily lost.

Anyway, I think that the Wiki needs a bit more structure. I have the 
feeling, it is a bit unorganised. Bill does a great job with all the 
wiki stuff and I think also others contribute a lot, but still, I am not 
  completely satisfied.

Bill, could you tell me how to move pages from one category to another?
It's not completely clear to me.

I somehow would like to see a more organised "Site Map". For my taste it 
should more look like the "table of contents" in a book. And perhaps 
some day we really can make a book out of the wiki by just pressing a 
button "Print".

I am not saying that I will do some reorganisation of the pages 
immediately, but I'd like to know how I could proceeed when I find some 
time and feel like that.


On 04/10/2006 10:15 PM, Jay Belanger wrote:
> Ralf Hemmecke writes:
> ...
>> What about a wiki "EmacsAxiomBestPractice" where something like that
>> here would be written?
> 
> Should that be added to the current "Axiom in Emacs" page, or should
> "EmacsAxiomBestPractice" be a new page?  
> I'd be happy to create the page.  

So Jay, just go ahead and add your text to "Axiom in Emacs".

 > It should probably start with Tim's
 > discussion, but I wouldn't want to add it without his okay.

See, that is what I once meant. People are just too kind. I am like Jay 
in some sense. I hesitate to add or modify other peoples comments.
But that is also bad, because pages become longer and longer by that and 
in this way unreadable or even useless. We need some more people who 
take the courage to edit pages.

So maybe we should create a page or a section "Editing Rules for Wiki 
Pages" on http://wiki.axiom-developer.org/CreatingNewPages that says 
something like

   If you add text to a wiki and you don't add your name then
   you agree that anyone can modify your text so that it looks
   better or better conveys the information.

Actually, that should be clear anyway...

In fact, I even think that there should no names on a wiki page at all. 
They all are written by "the axiom community". One cannot get credit for it.

\start
Date: Tue, 11 Apr 2006 10:35:28 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Axiom silver branch
Cc: Frederic Lehobey

On April 11, 2006 4:01 AM Gaby wrote:

> Bill Page wrote: 
> | In the SourceForge Axiom CVS archive I have set the binary mode
> | for all the *.tgz files in the zips directory using the command:
> | 
> | cvs admin -kb
> | 
> | as described here:
> | 
> | http://www.idevelopment.info/data/Programming/change_managemen
> | t/unix_cvs/PROGRAMMING_Working_with_Binary_Files.shtml
> | 
> | I have also requested a 'refresh' of the SourceForge Axiom SVN
> | from CVS, so that should correct the binary files problem and
> | permit Axiom to be build from the SVN archive.
>
> Thanks!

I tested it and it seems ok to me now. Perhaps some of the other
developers who have downloaded the SVN silver version should test
this. An 'svn update' should be sufficient. Then Axiom should build
from this archive.

> | According to SourceForge this might take 2 or 3 hours to
> | complete. (Is SVN really that slow?)
>
> yes, it is that fast, when you mind about the history of the
> commits and such.... 

I guess you can tell that a REALLY don't like SVN... To do the
same thing with darcs and tla only takes a few minutes at most.
Almost all my experiences with SVN have been sort of negative
in this way and to top it off it is way too much like CVS! :(

\start
Date: Tue, 11 Apr 2006 10:59:33 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Developers and Axiom

Ralf,

On April 11, 2006 6:35 AM you wrote:
> ... 
> Bill, could you tell me how to move pages from one category 
> to another? It's not completely clear to me.
> 

Use the 'rename' and 'reparent' options at the bottom of each
Axiom Wiki page.

> I somehow would like to see a more organised "Site Map". For 
> my taste it should more look like the "table of contents" in
> a book. And perhaps some day we really can make a book out of
> the wiki by just pressing a button "Print".

Good idea.

> 
> I am not saying that I will do some reorganisation of the pages 
> immediately, but I'd like to know how I could proceeed when I 
> find some time and feel like that.
> 

PLEASE do spend some time thinking about the re-organization.
I would really like you to do this.

> 
> See, that is what I once meant. People are just too kind. I 
> am like Jay  in some sense. I hesitate to add or modify other
> peoples comments. But that is also bad, because pages become
> longer and longer by that and in this way unreadable or even
> useless. We need some more people who take the courage to edit
> pages.

Yes! This is very true. We should assume that pages on the Axiom
Wiki are "shared public property". They no longer "belong" to the
author as such. Of course one can still use common courtesys in
communicating with the known authors but other than that EVERYONE
is free to modify and improve them as they see fit... The more
the better.

> 
> So maybe we should create a page or a section "Editing Rules for
> Wiki Pages" on http://wiki.axiom-developer.org/CreatingNewPages
> that says something like
> 
>    If you add text to a wiki and you don't add your name then
>    you agree that anyone can modify your text so that it looks
>    better or better conveys the information.

Yes, please add this.

> 
> Actually, that should be clear anyway...
> 
> In fact, I even think that there should no names on a wiki 
> page at all. They all are written by "the axiom community".
> One cannot get credit for it.
> 

I think anyone who spends time improving the site will in fact
"get credit" from the rest of the Axiom community. But of course
this is not formal credit in the sense most applicable to personal
promotion etc.

\start
Date: Tue, 11 Apr 2006 11:43:56 -0500
From: Jay Belanger
To: list
Subject: Re: Axiom silver branch

Bill Page writes:

> On April 11, 2006 4:01 AM Gaby wrote:
>
>> Bill Page wrote:
>> | In the SourceForge Axiom CVS archive I have set the binary mode
>> | for all the *.tgz files in the zips directory using the command:
>> |
>> | cvs admin -kb
>> |
>> | as described here:
>> |
>> | http://www.idevelopment.info/data/Programming/change_managemen
>> | t/unix_cvs/PROGRAMMING_Working_with_Binary_Files.shtml
>> |
>> | I have also requested a 'refresh' of the SourceForge Axiom SVN
>> | from CVS, so that should correct the binary files problem and
>> | permit Axiom to be build from the SVN archive.
>>
>> Thanks!
>
> I tested it and it seems ok to me now. Perhaps some of the other
> developers who have downloaded the SVN silver version should test
> this. An 'svn update' should be sufficient. Then Axiom should build
> from this archive.

Have you actually built it, or just downloaded it?
When I try to build it, I get a series of errors of the form:

  cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/prop-base/axiom.sty.svn-base': Permission denied
  cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/format': Permission denied
  cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/text-base/axiom.sty.svn-base': Permission denied
  cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/README.txt': Permission denied

I assume that when some recursive copy in the Makefile is called, it
tries to write over some subversion files (which of course don't have
permissions which allow that).  Am I the only one with this problem?

\start
Date: Tue, 11 Apr 2006 15:15:51 -0400
From: Bill Page
To: Jay Belanger
Subject: RE: Axiom silver branch

On Tuesday, April 11, 2006 12:44 PM Jay Belanger wrote:
> >> Bill Page wrote:
> >> | In the SourceForge Axiom CVS archive I have set the binary mode
> >> | for all the *.tgz files in the zips directory using the command:
> >> |
> >> | cvs admin -kb
> >> |
> >> | as described here:
> >> |
> >> | http://www.idevelopment.info/data/Programming/change_managemen
> >> | t/unix_cvs/PROGRAMMING_Working_with_Binary_Files.shtml
> >> |
> >> | I have also requested a 'refresh' of the SourceForge Axiom SVN
> >> | from CVS, so that should correct the binary files problem and
> >> | permit Axiom to be build from the SVN archive.
> >>
> >> Thanks!
> >
> > I tested it and it seems ok to me now. Perhaps some of the other
> > developers who have downloaded the SVN silver version should test
> > this. An 'svn update' should be sufficient. Then Axiom should
> > build from this archive.
>
> Have you actually built it, or just downloaded it?

I downloaded it and checked that I could successfully decompress
and untar the binary files. I did not attempt to build Axiom.

> When I try to build it, I get a series of errors of the form:
>
>   cp: cannot create regular file
> `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/prop-
> base/axiom.sty.svn-base': Permission denied

This error is exceedingly odd. It does not make sense that
that the Axiom build would be trying to create files in a
directory with the name '.svn' since that is a directory owned
by SVN.

>   cp: cannot create regular file
> `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/forma
> t': Permission denied
>   cp: cannot create regular file
> `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/text-
> base/axiom.sty.svn-base': Permission denied
>   cp: cannot create regular file
> `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/READM
> E.txt': Permission denied
>
> I assume that when some recursive copy in the Makefile is called,
> it tries to write over some subversion files (which of course don't
> have permissions which allow that).  Am I the only one with this
> problem?
>

I can try the build myself later today but I can not imagine
what would cause the Axiom build process to do that. Are you
sure you set the AXIOM variable properly? Can you provide more
information about this failure?

The directories being with '...mnt/linux/...' are created
during the Axiom build and should not be present in the SVN
archive and so should not contain a '.svn' subdirectory.
I am not sure what is going on.

\start
Date: Tue, 11 Apr 2006 12:26:36 -0700
From: Simon Michael
To: list
Subject: Re: Developers and Axiom

Hi,

http://zopewiki.org/BeBold links to a few more docs on that topic

Renaming pages is covered at http://zwiki.org/Editing

http://zwiki.org/PageHierarchy should clarify that feature. The axiom 
wiki's hierarchy can be seen via the "Site map" link on the front page. 
I've found it useful to display this right on the front page, but only to a 
certain depth, as at http://zwiki.org and http://zopewiki.org (requires a 
recent Zwiki).

\start
Date: Tue, 11 Apr 2006 12:32:51 -0700
From: Antoine Hersen
To: list
Subject: Book vol 3

------=_Part_8331_15225078.1144783971814

Hello,

I added \usepackage{hyperref}, converted some ps to pdf  to book vol3 and
used pdflatex.
The result is quite convinient for me.

Should I put it on the wiki ?
What is the policy for file hosting ?

\start
Date: Tue, 11 Apr 2006 15:52:13 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: Book vol 3

On Tuesday, April 11, 2006 3:33 PM Antoine Hersen wrote:

> I added \usepackage{hyperref}, converted some ps to pdf to
> book vol3 and used pdflatex. The result is quite convinient
> for me.
>
> Should I put it on the wiki ?
> What is the policy for file hosting ?

Thanks for doing this and offering to upload it for others.

There are several options:

1) You could register for access to the Axiom Portal at:

http://portal.axiom-developer.org

and upload it to your 'my folder'. Here it is accessible to
other users if you post the link. You can also "publish" it
and then it will be advertised as a new document for Axiom
Portal users.

2) You could upload it to the Axiom Wiki on a relevant page
e.g.

http://wiki.axiom-developer.org/AxiomDocumentation

(Click 'edit' then look for 'Upload a file or image' at the
bottom of the page.)

After uploading you will also probably want to add some
text to explain what it is and possibly move the link
to a more suitable place on the page.

3) You can modify the source for Book volume 3 here:

http://wiki.axiom-developer.org/book--main--1/Bookvol3

The pdf for these "pamphlet" files is generated via
dvips -> ps2pdf and will produce good quality hyperlinks.

Please ask if you need more explanation for any of these
options.

\start
Date: Tue, 11 Apr 2006 15:40:55 -0500
From: Jay Belanger
To: Bill Page
Subject: Re: Axiom silver branch

Bill Page writes:
...
>> When I try to build it, I get a series of errors of the form:
>> 
>>   cp: cannot create regular file 
>> `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/prop-
>> base/axiom.sty.svn-base': Permission denied
>
> This error is exceedingly odd. It does not make sense that
> that the Axiom build would be trying to create files in a
> directory with the name '.svn' since that is a directory owned
> by SVN.

It tries to create them because of recursive copies in the Makefile;
some .svn directories are subdirectories of directories that are being
copied. 

>> I assume that when some recursive copy in the Makefile is called,
>> it tries to write over some subversion files (which of course don't
>> have permissions which allow that).  Am I the only one with this
>> problem?
>> 
>
> I can try the build myself later today but I can not imagine
> what would cause the Axiom build process to do that. Are you
> sure you set the AXIOM variable properly? Can you provide more
> information about this failure?

Sure.  See below.

> The directories being with '...mnt/linux/...' are created
> during the Axiom build and should not be present in the SVN
> archive and so should not contain a '.svn' subdirectory.
> I am not sure what is going on.

The build process creates the .svn directories.
And when it tries to create the same .svn directory twice, it balks
because of the permissions of the contents.

Calling make will do the following (as near as I can tell):
  make noweb
  make litcmds
(These are the prerequisites for "make all".)
"make litcmds" has the line

  cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin

After litcmds, "make all" will turn Makefile.pamphlet into a
Makefile.linux, which will then be used.  "make all" in
Makefile.pamphlet will first "make rootdirs", which contains the line

  cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin

This will attempt to overwrite files previously copied to
.../bin/tex/.svn, which causes the error.
Without the .svn contents, the permissions of the files probably allow
overwriting, so no error.  I don't know why that command appears
twice; perhaps with no error, the duplication was hidden.

At the end is the output of "make".  (I added some "echo"s to
Makefile and Makefile.pamphlet so I could follow what was happening.)

Jay

[~]> cd /usr/local/belanger/axiom/silver
[silver]> ./configure
Linux

Configure complete. Now type

make

[silver]> make
Making NOWEB
13 making noweb
patching file modules.c
patching file Makefile
mnt.o: In function `emitfile':
mnt.c:(.text+0x36f): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
make[1]: [install-shell] Error 1 (ignored)
make[1]: [install-code] Error 1 (ignored)
texhash: Updating /home/belanger/.texmf-config/ls-R... 
texhash: Updating /home/belanger/.texmf-var/ls-R... 
texhash: /usr/local/share/texmf: directory not writable. Skipping...
texhash: /usr/share/texmf: directory not writable. Skipping...
texhash: /var/cache/fonts/ls-R: no write permission. Skipping...
texhash: /var/lib/texmf: directory not writable. Skipping...
texhash: Done.
make[1]: [install-elisp] Error 1 (ignored)
Making LITCMDS
0 SPAD=/usr/local/belanger/axiom/silver/mnt/linux SYS=linux SPD=/usr/local/belanger/axio
m/silver LSP=/usr/local/belanger/axiom/silver/lsp GCLDIR=/usr/local/belanger/axiom/silve
r/lsp/gcl-2.6.7 SRC=/usr/local/belanger/axiom/silver/src INT=/usr/local/belanger/axiom/s
ilver/int OBJ=/usr/local/belanger/axiom/silver/obj MNT=/usr/local/belanger/axiom/silver/
mnt ZIPS=/usr/local/belanger/axiom/silver/zips TMP=/usr/local/belanger/axiom/silver/obj/
tmp SPADBIN=/usr/local/belanger/axiom/silver/mnt/linux/bin INC=/usr/local/belanger/axiom
/silver/src/include CCLBASE=/usr/local/belanger/axiom/silver/obj/linux/ccl/ccllisp PART=
cprogs SUBPART=everything NOISE=-o /usr/local/belanger/axiom/silver/obj/tmp/trace GCLVER
SION=gcl-2.6.7 TANGLE=/usr/local/belanger/axiom/silver/mnt/linux/bin/lib/notangle VERSIO
N=Axiom (December 2005) PATCH=patch DOCUMENT=/usr/local/belanger/axiom/silver/mnt/linux/
bin/document WEAVE=/usr/local/belanger/axiom/silver/mnt/linux/bin/lib/noweave          
10 copying /usr/local/belanger/axiom/silver/src/scripts to /usr/local/belanger/axiom/sil
ver/mnt/linux/bin                                                                      
Making ALL
1 making a linux system, PART=cprogs SUBPART=everything
2 Environment SPAD=/usr/local/belanger/axiom/silver/mnt/linux SYS=linux SPD=/usr/local/b
elanger/axiom/silver LSP=/usr/local/belanger/axiom/silver/lsp GCLDIR=/usr/local/belanger
/axiom/silver/lsp/gcl-2.6.7 SRC=/usr/local/belanger/axiom/silver/src INT=/usr/local/bela
nger/axiom/silver/int OBJ=/usr/local/belanger/axiom/silver/obj MNT=/usr/local/belanger/a
xiom/silver/mnt ZIPS=/usr/local/belanger/axiom/silver/zips TMP=/usr/local/belanger/axiom
/silver/obj/tmp SPADBIN=/usr/local/belanger/axiom/silver/mnt/linux/bin INC=/usr/local/be
langer/axiom/silver/src/include CCLBASE=/usr/local/belanger/axiom/silver/obj/linux/ccl/c
cllisp PART=cprogs SUBPART=everything NOISE=-o /usr/local/belanger/axiom/silver/obj/tmp/
trace GCLVERSION=gcl-2.6.7 TANGLE=/usr/local/belanger/axiom/silver/mnt/linux/bin/lib/not
angle VERSION=Axiom (December 2005) PATCH=patch DOCUMENT=/usr/local/belanger/axiom/silve
r/mnt/linux/bin/document WEAVE=/usr/local/belanger/axiom/silver/mnt/linux/bin/lib/noweav
e                                                                                      
This is pdfeTeX, Version 3.141592-1.30.5-2.2 (Web2C 7.5.5)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./src/scripts/tex/axiom.sty)
No file Makefile.aux.
[1]
No file Makefile.toc.
[2] [3] [4] [5] [6] [7] [8]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 286--289
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23]
[24] [25] [26] [27] [28]
Overfull \hbox (83.99927pt too wide) in paragraph at lines 1072--1072
 []\OT1/cmtt/m/n/10 CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D$
{PLF} -I/usr/X11R6/include -I/usr/local/include"[]  
[29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43]
[44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] (./Makefile.aux)

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

 )
(see the transcript file for additional information)
Output written on Makefile.dvi (54 pages, 79724 bytes).
Transcript written on Makefile.log.
This is pdfeTeX, Version 3.141592-1.30.5-2.2 (Web2C 7.5.5)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./src/scripts/tex/axiom.sty)
(./Makefile.aux) [1] (./Makefile.toc [2]) [3] [4] [5] [6] [7] [8] [9]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 286--289
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]
[25] [26] [27] [28] [29]
Overfull \hbox (83.99927pt too wide) in paragraph at lines 1072--1072
 []\OT1/cmtt/m/n/10 CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D$
{PLF} -I/usr/X11R6/include -I/usr/local/include"[]  
[30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44]
[45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] (./Makefile.aux) )
(see the transcript file for additional information)
Output written on Makefile.dvi (55 pages, 103040 bytes).
Transcript written on Makefile.log.
make[1]: Entering directory `/usr/local/belanger/axiom/silver'
Making ROOTDIRS pamphlet
11 checking directory structure
12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLIN
UXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=gawk RANLIB=ranlib TOUCH=t
ouch TAR=tar AXIOMXLROOT=/usr/local/belanger/axiom/silver/mnt/linux/compiler O=o BYE=bye
 LISP=lsp DAASE=/usr/local/belanger/axiom/silver/src/share XLIB=/usr/X11R6/lib GCLOPTS=-
-enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024 SRCDIRS=bootdir int
erpdir sharedir algebradir etcdir clefdir docdir graphdir smandir hyperdir inputdir  PAT
CH=patch                                                                               
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
prop-base/axiom.sty.svn-base': Permission denied                                       
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
format': Permission denied                                                             
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
text-base/axiom.sty.svn-base': Permission denied                                       
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
README.txt': Permission denied                                                         
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
wcprops/axiom.sty.svn-work': Permission denied                                         
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
entries': Permission denied                                                            
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
dir-wcprops': Permission denied                                                        
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
empty-file': Permission denied                                                         
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/
props/axiom.sty.svn-work': Permission denied                                           
make[1]: *** [rootdirs] Error 1
make[1]: Leaving directory `/usr/local/belanger/axiom/silver'
make: *** [all] Error 2
[silver]> 

\start
Date: Tue, 11 Apr 2006 15:51:27 -0500
From: Jay Belanger
To: list
Subject: Re: Axiom silver branch

[Sorry if I'm double posting; the first time I posted this I got a
bounce message.]

Bill Page writes:
...
>> When I try to build it, I get a series of errors of the form:
>>
>>   cp: cannot create regular file
>> `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/prop-
>> base/axiom.sty.svn-base': Permission denied
>
> This error is exceedingly odd. It does not make sense that
> that the Axiom build would be trying to create files in a
> directory with the name '.svn' since that is a directory owned
> by SVN.

It tries to create them because of recursive copies in the Makefile;
some .svn directories are subdirectories of directories that are being
copied.

>> I assume that when some recursive copy in the Makefile is called,
>> it tries to write over some subversion files (which of course don't
>> have permissions which allow that).  Am I the only one with this
>> problem?
>>
>
> I can try the build myself later today but I can not imagine
> what would cause the Axiom build process to do that. Are you
> sure you set the AXIOM variable properly? Can you provide more
> information about this failure?

Sure.  See below.

> The directories being with '...mnt/linux/...' are created
> during the Axiom build and should not be present in the SVN
> archive and so should not contain a '.svn' subdirectory.
> I am not sure what is going on.

The build process creates the .svn directories.
And when it tries to create the same .svn directory twice, it balks
because of the permissions of the contents.

Calling make will do the following (as near as I can tell):
  make noweb
  make litcmds
(These are the prerequisites for "make all".)
"make litcmds" has the line

  cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin

After litcmds, "make all" will turn Makefile.pamphlet into a
Makefile.linux, which will then be used.  "make all" in
Makefile.pamphlet will first "make rootdirs", which contains the line

  cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin

This will attempt to overwrite files previously copied to
.../bin/tex/.svn, which causes the error.
Without the .svn contents, the permissions of the files probably allow
overwriting, so no error.  I don't know why that command appears
twice; perhaps with no error, the duplication was hidden.

At the end is the output of "make".  (I added some "echo"s to
Makefile and Makefile.pamphlet so I could follow what was happening.)

Jay

[~]> cd /usr/local/belanger/axiom/silver
[silver]> ./configure
Linux

Configure complete. Now type

make

[silver]> make
Making NOWEB
13 making noweb
patching file modules.c
patching file Makefile
mnt.o: In function `emitfile':
mnt.c:(.text+0x36f): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
make[1]: [install-shell] Error 1 (ignored)
make[1]: [install-code] Error 1 (ignored)
texhash: Updating /home/belanger/.texmf-config/ls-R...
texhash: Updating /home/belanger/.texmf-var/ls-R...
texhash: /usr/local/share/texmf: directory not writable. Skipping...
texhash: /usr/share/texmf: directory not writable. Skipping...
texhash: /var/cache/fonts/ls-R: no write permission. Skipping...
texhash: /var/lib/texmf: directory not writable. Skipping...
texhash: Done.
make[1]: [install-elisp] Error 1 (ignored)
Making LITCMDS
0 SPAD=/usr/local/belanger/axiom/silver/mnt/linux SYS=linux SPD=/usr/local/belanger/
axio
m/silver LSP=/usr/local/belanger/axiom/silver/lsp GCLDIR=/usr/local/belanger/axiom/
silve
r/lsp/gcl-2.6.7 SRC=/usr/local/belanger/axiom/silver/src INT=/usr/local/belanger/axiom
/s
ilver/int OBJ=/usr/local/belanger/axiom/silver/obj MNT=/usr/local/belanger/axiom/
silver/
mnt ZIPS=/usr/local/belanger/axiom/silver/zips TMP=/usr/local/belanger/axiom/silver/
obj/
tmp SPADBIN=/usr/local/belanger/axiom/silver/mnt/linux/bin INC=/usr/local/belanger/
axiom
/silver/src/include CCLBASE=/usr/local/belanger/axiom/silver/obj/linux/ccl/ccllisp
PART=
cprogs SUBPART=everything NOISE=-o /usr/local/belanger/axiom/silver/obj/tmp/trace
GCLVER
SION=gcl-2.6.7 TANGLE=/usr/local/belanger/axiom/silver/mnt/linux/bin/lib/notangle
VERSIO
N=Axiom (December 2005) PATCH=patch DOCUMENT=/usr/local/belanger/axiom/silver/mnt/
linux/
bin/document WEAVE=/usr/local/belanger/axiom/silver/mnt/linux/bin/lib/noweave         
10 copying /usr/local/belanger/axiom/silver/src/scripts to /usr/local/belanger/axiom/
sil
ver/mnt/linux/bin                                                                     
Making ALL
1 making a linux system, PART=cprogs SUBPART=everything
2 Environment SPAD=/usr/local/belanger/axiom/silver/mnt/linux SYS=linux SPD=/usr/local
/b
elanger/axiom/silver LSP=/usr/local/belanger/axiom/silver/lsp GCLDIR=/usr/local/
belanger
/axiom/silver/lsp/gcl-2.6.7 SRC=/usr/local/belanger/axiom/silver/src INT=/usr/local/
bela
nger/axiom/silver/int OBJ=/usr/local/belanger/axiom/silver/obj MNT=/usr/local/belanger
/a
xiom/silver/mnt ZIPS=/usr/local/belanger/axiom/silver/zips TMP=/usr/local/belanger/
axiom
/silver/obj/tmp SPADBIN=/usr/local/belanger/axiom/silver/mnt/linux/bin INC=/usr/local/
be
langer/axiom/silver/src/include CCLBASE=/usr/local/belanger/axiom/silver/obj/linux/ccl
/c
cllisp PART=cprogs SUBPART=everything NOISE=-o /usr/local/belanger/axiom/silver/obj/
tmp/
trace GCLVERSION=gcl-2.6.7 TANGLE=/usr/local/belanger/axiom/silver/mnt/linux/bin/lib/
not
angle VERSION=Axiom (December 2005) PATCH=patch DOCUMENT=/usr/local/belanger/axiom/
silve
r/mnt/linux/bin/document WEAVE=/usr/local/belanger/axiom/silver/mnt/linux/bin/lib/
noweav
e                                                                                     
This is pdfeTeX, Version 3.141592-1.30.5-2.2 (Web2C 7.5.5)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./src/scripts/tex/axiom.sty)
No file Makefile.aux.
[1]
No file Makefile.toc.
[2] [3] [4] [5] [6] [7] [8]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 286--289
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23]
[24] [25] [26] [27] [28]
Overfull \hbox (83.99927pt too wide) in paragraph at lines 1072--1072
 []\OT1/cmtt/m/n/10 CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D$
{PLF} -I/usr/X11R6/include -I/usr/local/include"[] 
[29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43]
[44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] (./Makefile.aux)

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

 )
(see the transcript file for additional information)
Output written on Makefile.dvi (54 pages, 79724 bytes).
Transcript written on Makefile.log.
This is pdfeTeX, Version 3.141592-1.30.5-2.2 (Web2C 7.5.5)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./src/scripts/tex/axiom.sty)
(./Makefile.aux) [1] (./Makefile.toc [2]) [3] [4] [5] [6] [7] [8] [9]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 286--289
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]
[25] [26] [27] [28] [29]
Overfull \hbox (83.99927pt too wide) in paragraph at lines 1072--1072
 []\OT1/cmtt/m/n/10 CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D$
{PLF} -I/usr/X11R6/include -I/usr/local/include"[] 
[30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44]
[45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] (./Makefile.aux) )
(see the transcript file for additional information)
Output written on Makefile.dvi (55 pages, 103040 bytes).
Transcript written on Makefile.log.
make[1]: Entering directory `/usr/local/belanger/axiom/silver'
Making ROOTDIRS pamphlet
11 checking directory structure
12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-DLIN
UXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=gawk RANLIB=ranlib TOUCH
=t
ouch TAR=tar AXIOMXLROOT=/usr/local/belanger/axiom/silver/mnt/linux/compiler O=o BYE=
bye
 LISP=lsp DAASE=/usr/local/belanger/axiom/silver/src/share XLIB=/usr/X11R6/lib GCLOPTS
=-
-enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=256*1024 SRCDIRS=bootdir
int
erpdir sharedir algebradir etcdir clefdir docdir graphdir smandir hyperdir inputdir 
PAT
CH=patch                                                                              
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
prop-base/axiom.sty.svn-base': Permission denied                                      
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
format': Permission denied                                                            
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
text-base/axiom.sty.svn-base': Permission denied                                      
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
README.txt': Permission denied                                                        
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
wcprops/axiom.sty.svn-work': Permission denied                                        
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
entries': Permission denied                                                           
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
dir-wcprops': Permission denied                                                       
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
empty-file': Permission denied                                                        
cp: cannot create regular file `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex
/.svn/
props/axiom.sty.svn-work': Permission denied                                          
make[1]: *** [rootdirs] Error 1
make[1]: Leaving directory `/usr/local/belanger/axiom/silver'
make: *** [all] Error 2
[silver]>

\start
Date: Tue, 11 Apr 2006 15:56:32 -0500
From: Jay Belanger
To: list
Subject: Re: Developers and Axiom

Ralf Hemmecke writes:

> Hi Jay,
>
> Well, I somehow think it is better if there is just one page "Axiom in
> Emacs" (even though it does not completely fit). With too many pages,
> people get easily lost.

On the other hand, since there's quite a bit that could be said about
Axiom and Emacs, and it might be easier to navigate if it's broken
down into sections.

\start
Date: Tue, 11 Apr 2006 17:23:27 -0400
From: Bill Page
To: William Sit
Subject: RE: error and editing

On Tuesday, April 11, 2006 4:23 AM William Sit wrote:
>
> Last night, I accidentally modified the title of SandBox to
> [SandBox Trace EXPR] but I think I managed to revert it back.
> Please verify, since Wiki seems to automatically update all
> links once a title is modified.

No problem. I think everything is back to the way it should
be.

>
> I also found that the preview and resulting display after
> a save not to apply line wrap so that a long paragraph is
> displayed as a long line. This happened both for Firefox and
> IE (and I don't think it is my local settings). In other
> words, the style is not handling html correctly. I tried all
> sorts of editing style (pamphlet, etc) and none seem to help
> and I had to manually insert linefeeds.

I think the problem was caused by a bug in the formatting
rules for StructuredText in ZWiki which is used on Axiom Wiki
for the Pamphlet page type. In your case the first line of text
contained :: which in StructuredText means "verbatim" text
follows. Normally this is handled properly but for some odd
reason in this case caused the rest of the text to be treated
as verbatim.

My solution was to add an initial heading like this:

Background

  Text that is initially indented under a line above defines
the previous line as a heading.

I also changed a few other places in your text where you
added headings like

Section 1. The Issues

  These are probably related ...

>
> Somehow, [SandBox Trace EXPR and FRAC] has word wrap but
> [SandBox Trace Analysed] does not. I left the first text
> paragraph like that as an example.

I think it looks ok now.

>
> Changing the editing style modified the source too, for
> example, '0$EXPR' would sometimes turn into $0$EXPR$ which
> would be quite confusing (to me at least).

In Axiom Wiki the $ can sometimes be confused with LaTeX
expressions. The best way to make sure this doesn't happen
is to escape the $ signs with \ like this '\$'. Without
you might see a LaTeX error message at the bottom of the
page.

>
> I tried to find how to set the wrap line option in
> preferences but could not.
>

No, as I explained above the failure to line wrap the
rest of the page was due to a bug in the way ZWiki treated
the first paragraph which contained a :: formatting
instruction. By adding the initial heading, it seems to
be possible to work-a-round this bug.

> Sorry for the mess up and thanks for fixing up any
> left-overs.
>

Not a problem. Please check it and see if it looks
better to you now.

\start
Date: 12 Apr 2006 08:41:25 +0200
From: Francois Maltey
To: Jay Belanger
Subject: Re: Developers and Axiom

Hello all, 

> > Well, I somehow think it is better if there is just one page "Axiom in
> > Emacs" (even though it does not completely fit). With too many pages,
> > people get easily lost.
> 
> On the other hand, since there's quite a bit that could be said about
> Axiom and Emacs, and it might be easier to navigate if it's broken
> down into sections.

I change (and improve ?) the axiomacs.el command in order to run
axiom in emacs.

It's right for my own use isn't perfect. 
If someone has questions about it and has good ideas we can see 
together how to do.

\start
Date: Wed, 12 Apr 2006 09:40:35 +0200
From: Ralf Hemmecke
To: Jay Belanger
Subject: Re: Developers and Axiom

Do what you think is most appropriate, somebody then might improve on 
it. We are all watching ;-) and after all it is important that the 
information is on the wiki. We can move around pages later. (But you are 
free to think of and suggest any good structure for AxiomWiki yourself.)

Ralf

On 04/11/2006 10:56 PM, Jay Belanger wrote:
> Ralf Hemmecke writes:
> 
>> Hi Jay,
>>
>> Well, I somehow think it is better if there is just one page "Axiom in
>> Emacs" (even though it does not completely fit). With too many pages,
>> people get easily lost.
> 
> On the other hand, since there's quite a bit that could be said about
> Axiom and Emacs, and it might be easier to navigate if it's broken
> down into sections.

\start
Date: 12 Apr 2006 09:40:50 +0200
From: Gabriel Dos Reis
To: Jay Belanger
Subject: Re: Axiom silver branch

Jay Belanger writes:

| Bill Page writes:
| ...
| >> When I try to build it, I get a series of errors of the form:
| >> 
| >>   cp: cannot create regular file 
| >> `/usr/local/belanger/axiom/silver/mnt/linux/bin/tex/.svn/prop-
| >> base/axiom.sty.svn-base': Permission denied
| >
| > This error is exceedingly odd. It does not make sense that
| > that the Axiom build would be trying to create files in a
| > directory with the name '.svn' since that is a directory owned
| > by SVN.
| 
| It tries to create them because of recursive copies in the Makefile;
| some .svn directories are subdirectories of directories that are being
| copied. 

Thanks for tracing down the problem!  My reading of your report is
that this is more of a problem without current build machinery than
with SVN.

Fixing this:
  (1) in short term: audit the recursive copy and exclude those
      administrative files and double copy attemps;

  (2) in long term: in addition of (1), support build out-of-source
      directory and encourage people to build out-of-source.

[...]

| Calling make will do the following (as near as I can tell):
|   make noweb
|   make litcmds
| (These are the prerequisites for "make all".)
| "make litcmds" has the line
| 
|   cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin

After doing this (in a corrected form), we should also create a stamp file.

| 
| After litcmds, "make all" will turn Makefile.pamphlet into a
| Makefile.linux, which will then be used.  "make all" in
| Makefile.pamphlet will first "make rootdirs", which contains the line
| 
|   cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin

This is not right.  It should depend on the stamp file (mentioned
above) and fire only if needed.

| 
| This will attempt to overwrite files previously copied to
| .../bin/tex/.svn, which causes the error.
| Without the .svn contents, the permissions of the files probably allow
| overwriting, so no error.  I don't know why that command appears
| twice; perhaps with no error, the duplication was hidden.

Indeed.  I'm very suspicious of that duplication.  Tim do you know why
we have gottten that overwrite?

\start
Date: Wed, 12 Apr 2006 09:58:02 +0200
From: Ralf Hemmecke
To: list
Subject: Re: [Events] (new)

Hi Bill,

That is a wonderful idea.

In order to get the AxiomWiki a bit more structured, it should be 
required that a page states at the top a short abstract like you did for 
the Evens page. So people would more easily know whether to put their 
information onto that page or open a new one.

The AxiomWiki page name is not always saying everything about the 
content of the page.

Ralf

\start
Date: Wed, 12 Apr 2006 11:15:36 +0200
From: Ralf Hemmecke
To: list
Subject: AxiomWiki TOC

Is there a simple way of writing a "table of contents" of a page at the 
top of it?

I've just looked at the sources of 
http://en.wikipedia.org/wiki/Wikipedia:Editing_policy
where it seems that they have a

__TOC__

for doing this.

Ralf

\start
Date: Wed, 12 Apr 2006 05:35:49 -0700
From: Simon Michael
To: list
Subject: Re: [Events] (new)

+1. Zwiki considers the first paragraph (up to a certain length) to be the 
page's summary and uses that in recent changes, search keywords and other 
places.

\start
Date: Wed, 12 Apr 2006 05:37:32 -0700
From: Simon Michael
To: list
Subject: Re: AxiomWiki TOC

The only simple way is to use the .. contents:: directive of the 
"restructured text" page type.. but that page type doesn't support LaTeX, 
axiom and the rest. Bill and I were just discussing it.

\start
Date: Wed, 12 Apr 2006 09:39:57 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Latex Package problem

re: Final

> What do you happen to use? And why do you need that "final" anyway?

I didn't add the final keyword in the first place.
I believe it was sent to me while we were busy trying to demonstrate
the use of hyperlinking in graph structures. I'll remove it in the 
next release.

\start
Date: Wed, 12 Apr 2006 09:42:20 -0400
From: Tim Daly
To: list
Subject: Re: [SkypeName] (new)

> Peer to peer voice service. Users may call each other computer-to-computer
> for free and may call landlines and cellphones for a fee. Include online
> chat and video. Skype is an alternative to irc, icq and other online chat
> programs.

I'm generally available on skype (I believe you can find me by
searching for my email address).

I'm generally available on gaim (pelzel000)

\start
Date: Wed, 12 Apr 2006 09:46:02 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom silver branch

> I would like to discuss the organization of branches and procedures.

I'd suggest that you create a new branch in the root version
of Makefile.pamphlet called 'silver'. So someone who wants to
build the silver version would use something like:

export AXIOM=~/mnt/silver

or 

export AXIOM=~/mnt/linux-silver

or some such. That way you can experiment with compatible changes
to the build procedures. Bill is quite interested in doing things
like building Axiom on native GCL and native noweb, both of which
I've rejected. A silver build can do anything you want.

\start
Date: Wed, 12 Apr 2006 09:51:04 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom silver branch

>   I just spoke with Benjamin (in CC:), from Red Hat, about possible
> inclusion of Axiom in linux distros, and Red Hat in particular.  That
> would increase the visbility of Axiom, I think.
> 
> Benjamin pointed out that a minimal requirement would be for Axiom to
> support cross-compilation, "easy" packaging, etc.  

I spoke with RedHat before and their management (and legal department)
have agreed to support the Doyen effort. Doyen is a liveCD packaging
effort for Axiom. We discussed the idea that RedHat would distribute
Doyen as a 'science platform' at conferences provided it was built on
fedora. Jose Alfredo has moved it from Knoppix to Fedora in the
latest release (http://sourceforge.net/projects/doyencd) 

\start
Date: Wed, 12 Apr 2006 09:52:21 -0400
From: Tim Daly
To: Frederic Lehobey
Subject: Re: Compiling Axiom from arch source on Debian sarge

> > unfortunately, due to the awk scripts (and a failure of the clean stanza)
> > this is not enough. you need to removed two awk scripts and all of
> > the Makefile and Makefile.dvi files in the src directory. 
> >  
> > make clean
> > rm -rf int obj mnt lsp/gcl*
> > cd src
> > for i in `find . -name "Makefile"` ; do rm -f $i ; done
> > for i in `find . -name "Makefile.dvi"` ; do rm -f $i ; done
> 
> Seems it worked for me (compilation goes further).  Thanks.  Thanks
> also to Greg for pointing a very recent thread on the same problem.
> Frederic

I'll fix the 'make clean' in the next release.

\start
Date: Wed, 12 Apr 2006 10:01:19 -0400
From: Tim Daly
To: Frederic Lehobey
Subject: Re: Latex Package problem

> I am just compiling patch-47 axiom on standard debian sarge.
> 
> My compilation stops in the middle of compiling the documentation and 
> just continues after I have pressed enter.

This is a symptom of a problem during latex processing.
Latex processing sends its output to a trace file called ${TMP}/trace.
This file lives in ${OBJ}/tmp/trace. and ${OBJ} is typically in obj/linux.
So you can look at the obj/linux/tmp/trace file.

Alternatively you can build Axiom and see the latex output on the console:

  make NOISE=

will cause the latex output to appear.

\start
Date: Wed, 12 Apr 2006 15:22:13 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Axiom silver branch

On 04/12/2006 03:46 PM, root wrote:
>> I would like to discuss the organization of branches and procedures.
> 
> I'd suggest that you create a new branch in the root version
> of Makefile.pamphlet called 'silver'. So someone who wants to
> build the silver version would use something like:
> 
> export AXIOM=~/mnt/silver
> 
> or 
> 
> export AXIOM=~/mnt/linux-silver

Sorry, I cannot see any point in doing this. If somebody checks out from 
the SVN silver branch to ~/silver then the compilation result is a 
SilverAxiom and it lives under ~/silver/${MNT}/${SYS}.

Exactly the same if you check out from the axiom--main--1 (gold) archive 
to ~/gold you get a GoldAxiom under ~/gold/${MNT}/${SYS}.

\start
Date: Wed, 12 Apr 2006 10:41:34 -0400
From: Tim Daly
To: Raymond Rogers
Subject: Re: FC5: rsync, lsp, 2412, etc

> Tim,
> 	Evidently you moved the bash fix into CVS.  The make staggers on.
> 	My FC5 doesn't have libXpm.a and the software selector can't find it.
> Any suggestions, or should I try to rebuild it?

src/include/xpm.h

\start
Date: Wed, 12 Apr 2006 11:23:13 -0400
From: Tim Daly
To: Frederic Lehobey
Subject: Re: Axiom silver branch

> Storing binary files in a source code archive is something that
> I have always objected to, but Tim insists on re-distributing
> code this way. I really think we should stop doing this.

Binary files exist no matter what we do. The Axiom root directory
contains binary image files as well as the src/doc/ps subdirectory.

As for the 'redistributing code' we differ on philosophy. 
I've written extensively on the difference in philosophy.

Bill and several others have taken the stance which can be positively
characterized as 

"first, we assume that the users have all the prerequisites...."

and negatively characterized as

"the users will have to guess...."


On the other hand I've taken the stance that can be positively 
characterized as

"axiom builds should 'just work'..."

and negatively characterized as

"fork the world and do it ourselves..."




I am regularly fielding questions of the form:

   > Camm,
   > 
   > I tried to build Axiom on a debian machine and get:
   > 
   > creating makedefc
   > sed: file conftest.s1 line 61:  unterminated `s' command
   > creating windows/gcl.iss
   > sed: file conftest.s1 line 61:  unterminated `s' command
   > creating windows/sysdir.bat
   > sed: file conftest.s1 line 61:  unterminated `s' command
   > creating windows/install.lsp
   > sed: file conftest.s1 line 61:  unterminated `s' command
   > 
   > 
   > suggestions?
   > 
   > Tim

   Yes - my guess -- emacs is not installed?  The Debian package is setup
   to require the packages listed under Build-depends: in debian/control
   at build time, one of which is an emacs.  The error message obviously
   needs work :-).

In a system as complex as Axiom it is impractical to expect users to
understand all the dependent paths. Even I get confused. However when
I understand the confusion I write makefile changes that ensure that
others do not have the same problems.

We COULD distribute Axiom and watch the builds fail over and over
again because users have broken versions of noweb or their native
version of GCL does not include the correct libraries or emacs is
not installed or their version of some software is not right for Axiom.

The practical effect of such a policy is that every user has the
responsibility of upgrading their system to meet our requirements.
And it means that Axiom WILL NOT build successfully on most systems.

I suggest you use the 'silver' system to experiment with trying to
remove binaries and require native GCL/noweb installs. My experience
tells me that you'll find it won't build everywhere. It certainly
will NOT build on any of my current systems as my native installs
do not include the required axiom patches.


Alternatively we COULD pursue the philosophy that Axiom should 'just work'.
That means that Axiom WILL build successfully on most systems. The 
practical effect of such a philosophy means that we distribute binaries
with patches until the patches are accepted in the upstream systems AND
the upstream systems become the standard in most distributions.

I still hold the fundamental philosophy that 'Axiom should just work'.

\start
Date: Wed, 12 Apr 2006 11:27:02 -0400
From: Tim Daly
To: Frederic Lehobey
Subject: Re: Latex Package problem

> +% 
> +% 2006-04-08.  The original (correct) usepackage line below
> +%\usepackage[dvips,final,colorlinks=true,pdfstartview=FitH]{hyperref}
> +% has been changed to the following one in order to ease the
> +% compilation of axiom on distributions (like Debian sarge) that have
> +% an older version of hyperref TeX package (where the `final' option
> +% is missing).  It should be restored once the latest versions (>=
> +% 2003/11/30 v6.74m) of hyperref are more widespread.
> +\usepackage[dvips,colorlinks=true,pdfstartview=FitH]{hyperref}
>  \usepackage{pstricks}
>  \usepackage{pst-node}
>  \begin{document}

patch applied.
fixed in the next release

\start
Date: Wed, 12 Apr 2006 11:32:31 -0400
From: Tim Daly
To: Raymond Rogers
Subject: Re: FC5 success (well sort of)

> cd axiom
> ./configure
> make
> should build and test
> make install
> 
> cd /usr/src/axiom/mnt/linux/bin
> chmod a+x htsearch

This is odd. The src/hyper/Makefile explicitly does:
     @chmod a+x ${OUTLIB}/htsearch
which should make it executable. It is executable in my builds.
Where does this happen to you?

\start
Date: Wed, 12 Apr 2006 11:35:03 -0400
From: Tim Daly
To: Raymond Rogers
Subject: Re: FC5 success (well sort of)


> To get a functioning axiom on Fedora 5 as of 4/10/06
> *****************
> root
> libXpm.a is missing from the DVD install
> get libXpm from
> http://mirror.mcs.anl.gov/fedora-linux-core/5/source/SRPMS/
> do a build and install.  Of course it goes to different place,
> Apparently they changed to X11R7 and put it in /usr/local/lib/
> for now:
> ln -s /usr/local/lib/libXpm.a  /usr/X11R6/lib/libXpm.a

NAG packaged libXpm.a with Axiom years ago but it has not been
a problem so it was not included. I'll look into the issue when
I do the FC5 build. I may have to recreate the library as part
of the FC5 install process. 

\start
Date: Wed, 12 Apr 2006 11:38:57 -0400
From: Tim Daly
To: Jay Belanger
Subject: Re: Developers and Axiom

> But you need half the screen devoted to a shell, which really
> shouldn't be necessary.  Why not simply have a command which runs the
> makefile with `shell-command' or something similar?
> (local-set-key "\C-ce" 
>                (lambda () 
>                   (interactive)
>                   (shell-command "make -f Makefile.foo &")))
> Or something could be arranged so any output goes to a (normally
> non-showing) buffer, which could be displayed in case of an error.

A useful idea. Thanks.

You can also do M-x compile and it will prompt you for a default 
make command line which it remembers.

I don't find 'half a screen' to be a limitation. My head is a very
small space and is the primary limitation.

\start
Date: Wed, 12 Apr 2006 11:40:31 -0400
From: Tim Daly
To: Antoine Hersen
Subject: Re: Speeding up Aldor domain compilation

> Compilation take over 3 minutes. Mostly when compiling the generated lisp code.
> 
> Any ideas ?

ummm, coffee break? :-)

\start
Date: Wed, 12 Apr 2006 11:44:51 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Patch : Remove warning message when comipiling with aldor

> % !! DO NOT MODIFY THIS FILE BY HAND !! Created by ht.awk.
> 
> but I have no idea from what ht.awk created that. It's somehow a poor 
> comment in my eyes. But at least better than nothing.

Some of the hypertex files were automatically created from the axiom book
by a series of sed and awk tools. It appears that these have not survived
into the present day. The tools required that the latex files follow
certain undocumented conventions. At this point the hypertex files are
completely divorced from the documentation so the comment no longer applies.

However, the divorce is not really a good philosophy and we need to 
make the whole hypertex documentation into pamphlet files eventually.
Kai's work will lead to a better situation in the future.

\start
Date: Wed, 12 Apr 2006 12:05:34 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

> Well Axiom is doing similar things with GCL. Even more, GCL is part of 
> the Axiom archive. Hmmm...
> 
> 
> 
> I would feel better if if Axiom becomes something like a shell that 
> depends on several prerequisites. That would make Camm's work much 
> easier, and maybe we should simply learn from him. Yes, that would mean 
> for each version we have to say what is the minimum version of the 
> dependency object.

Check the email archive. Camm has explicitly said that it is ok to 
package GCL with axiom. And Richard Stallman said that it is ok to
package GPL code with Axiom given our distribution system. I don't
want to reopen these license discussions as they went on for months.

Camm occasionally gets bug fixes and patches from us. Why does it make
life easier to force him to upgrade when we want to change things?

> Well, but not all people use DEBIAN. How would other people be easy with 
> not having gcl and noweb in their Axiom distribution?
> 
> There are maybe two options.
> 1) We have two archives, one is the prerequisite thing and one is the 
> Axiom stuff we are actually focused on. Looks a bit similar to what we 
> have now, but Axiom would NOT have any Makefile target that deals with 
> building the prerequisites. Those Makefile things should be in the other 
> archive. So this would be different from the current situation.
> 
> 2) There is just one archive and this is Axiom without noweb, gcl and 
> any other additional useful package. AND there is an installation script 
> (Makefile or whatever) which is responsible for setting the stage so 
> that Axiom will compile without complaining. That script checks if gcl 
> is there in the right version, if not it would get it via "wget" from 
> the internet and "make" it. Same with "noweb" etc.

Please use the 'silver' package to experiment with these options.
Remember that your results have to work everywhere. The sourceforge
people maintain a compile farm which sourceforge developers can access
to ensure that their packages work on other systems. Please experiment
with this resource.

> 
> I feel it is somehow a disadvantage to have a need for an internet 
> connection for installation, but in some sense it is a bit like Debian 
> or other GNU/Linux distributions.

Try finding the 'right' libXpm.a file for FC5. Even if you find it
you might find that it is not installed where you want it and that
other systems install things in odd places. The BSD systems are
wildly different from linux. Windows has no hope of conforming
to your expectations. 

> 
> The real disadvantage is when you want to press Axiom on a CD. Of course 
> you must also provide the most important prerequisites like gcl and 
> noweb on the CD since you cannot expect internet connection then.

In fact, the Doyen project (sourceforge.net/projects/doyencd) which is
trying to make Axiom into a 'science platform' on a live CD has exactly
this problem.

> We clearly already have some prerequisite. However, could somebody say 
> what the prerequisites are apart from gcl and noweb? We rely on some 
> "standard linux distribution". But what is "standard"? Debian 
> dependencies show "libc6 (>= 2.3.2.ds1-4)" and "libgmp3". Interesting... 
> I don't find them in our "zips" directory. ;-)

We only package things that break. If you look at the zips directory
history you'll find that we no longer distribute the X library include
files. This used to be a problem historically but has been fixed in
all distributions and the file is no longer shipped. 

> 
> And what about the Axiom developers? Well, if they see that they are 
> missing gcl (./configure would tell them), they look at an AxiomWiki 
> page and follow the steps manually (until we have the script mentioned 
> above).

Even the developers post 'it didn't work for me' messages.

We put up a new debian server (thanks to Ralf) at Risc Linz last week
and Axiom will not build there. Apparently the problem is that emacs
is not installed but I always use emacs and I got the error message
in an emacs shell buffer so either that's not the problem or the
Debian depends: stuff is not configured properly.

I think you'll discover that almost every system is broken in some
obscure way and if you distribute code that requires the developers
to 'figure it out' every time you'll lose developers.

> 
> Ah, yes, wasn't there someone who wanted to write some autoconf/automake 
> stuff for Axiom? I would really appreciate that. It cannot hurt if we 
> learn about such standard tools. Am I wrong?

Check the email archive. The issue is that autoconf/automake assume
that you're building a C program. ASDF is the lispish equivalent.
There is not much use for a 'standard screwdriver' in a project that
uses nails.

\start
Date: Wed, 12 Apr 2006 12:08:05 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Removing external binaries from Axiom source tree: a proposal (was: Re: Axiom silver branch)
Cc: Frederic Lehobey

> > Storing binary files in a source code archive is something that
> > I have always objected to, but Tim insists on re-distributing
> > code this way. I really think we should stop doing this.
> 
> I can understand Tim point of view: do not depend on external sources
> and manage complexity by providing the "Axiom-blessed" versions of
> noweb, gcl, etc.
> 
> One possible solution to this issue would be:
> 
>  1. remove noweb, gcl, etc. sources from axiom source tree ;
> 
>  2. put them in a repository somewhere on axiom-developer.org ;
> 
>  3. write a shell script, much like GARNOME for Gnome ou Konstruct for
>     KDE that fetches source dependencies from axiom-developper.org,
>     build them and then build Axiom itself. 
> 
> This script could be a separate one or be part of ./configure (e.g. with
> option --fetch-and-build-dependencies).
> 
> What do you think of it?

I suggest that you try this using the SVN/silver machinery.
It is easy to create a new silver makefile from the Makefile.pamphlet
which will no longer depend on the installed GCL and noweb.

\start
Date: Wed, 12 Apr 2006 12:13:25 -0400
From: Tim Daly
To: Raymond Rogers
Subject: Re: FC5 success (well sort of)

>> The text entry in the browser window doesn't seem to work 
> 
> Did you try with "Num Lock" disabled. On french keyboard I have to
> disable "numeric keypad".

This has been added to the FAQ file. 
It will be available in the next release --t

\start
Date: Wed, 12 Apr 2006 12:18:19 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

> | The second patch was suggested by Norman Ramsey (author of noweb)
> | a couple of years ago. It provides a simple awk script to allow
> | noweb to be used with Axiom pamphlet files without modifications
> | to noweb.
> | 
> | Together these two patches eliminate the need to build noweb and
> | gcl as part of the Axiom build and thus eliminate the need for
> | the corresponding .tgz files in the source code archive.
> 
> That is interesting.  Do you have links to those patches so that we
> can see how we could/should consider them and work out the details
> with Tim?

I'd suggest creating a branch of silver to experiment with this.

But make it work EVERYWHERE. I do an extensive amount of testing
with every change I make to the system to try to ensure that it
works everywhere and I didn't break anything. It is NOT sufficient
in a global project to just get it to work on one system. The
sourceforge.net site has a compile farm which includes a range
of systems. 

Whatever solution gets proposed it should 'just work'.

\start
Date: Wed, 12 Apr 2006 12:50:37 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

> I'm not proposing this seriously, but thought it worths mentioning:
> in the Perl community, the updated can compute the dependencies, and
> automatically download the missing bits (if permitted).  Food for
> thought. 

I spent about 2 days in CPAN hell. I installed a perl script.
It required an http module which was available on CPAN. I copied
the module which required a socket module. I copied it also.
That module required a time module. 

Seeing the inevitable I installed the automatic CPAN installer.
Then I set it free to install the time module. It installed over
100 other modules and then stopped because there was a loop in
the version dependencies that it could not resolve. And I had NO
idea why it even needed these modules.

I eventually erased ALL perl scripts on my system and dropped the project.


The moral of the story is that the dependency idea is fundamentally flawed.

Everyone assumes you can just 'automatically download gcl' and it will 
install. But my experience with this using CPAN, CTAN, Redhat's RPM
manager, debian's apt-get, and now fedora's yum is that IF it works then
it is great. But if it fails it (a) fails badly in obscure places and
(b) leaves my system broken in various ways.

After 36 years these computers contain my life's work. My working life
depends on reliable, working computers and I carefully manage the
configuration of these systems.  I am VERY, VERY reluctant to let some
random script 'upgrade' my whole computer system.

Carefully preface the comment that you 'automatically install gcl'
or 'automatically install noweb' or 'automatically install libXpm.a'
with:
  ASSUMING THE 35 PREREQUISITES SUCCESSFULLY INSTALLED....

You see, you have NO control over what SOMEONE ELSE claims to be a
prerequisite. And these get DYNAMICALLY extended over time. So now
GCL apparently depends on emacs. And emacs depends on a whole lot
of other things. Do you intend to force everyone to install or
upgrade their emacs? I won't EVER allow a script to upgrade my emacs.
EVER. 

Depending on 'automatically install gcl' is handwaving about magic.

Maybe the magic always works for you. It never does for me.

Axiom as it exists now 
 a) depends on very little
 b) never writes outside of its own directory (not even tmp files)
 c) builds everywhere (or tries to)

If a silver version of the system 'just works' I can be convinced
that it is a reasonable idea. But if installing axiom requires
installing gcl and installing gcl requires installing/upgrading emacs
there is no hope.

\start
Date: Wed, 12 Apr 2006 12:58:20 -0400
From: Tim Daly
To: Jay Belanger
Subject: Re: Developers and Axiom

Jay,

> > What about a wiki "EmacsAxiomBestPractice" where something like that
> > here would be written?
> 
> Should that be added to the current "Axiom in Emacs" page, or should
> "EmacsAxiomBestPractice" be a new page?  
> I'd be happy to create the page.  It should probably start with Tim's
> discussion, but I wouldn't want to add it without his okay.

You have my ok. If I publish to this list (as opposed to a private
email communication) you and anyone else has blanket permission to 
do with it what you will.

\start
Date: Wed, 12 Apr 2006 13:12:47 -0400
From: Tim Daly
To: Jay Belanger
Subject: Re: Axiom silver branch

> Calling make will do the following (as near as I can tell):
>   make noweb
>   make litcmds
> (These are the prerequisites for "make all".)
> "make litcmds" has the line
> 
>   cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin
> 
> After litcmds, "make all" will turn Makefile.pamphlet into a
> Makefile.linux, which will then be used.  "make all" in
> Makefile.pamphlet will first "make rootdirs", which contains the line
> 
>   cp -pr ${SRC}/scripts/* ${MNT}/${SYS}/bin
> 
> This will attempt to overwrite files previously copied to
> .../bin/tex/.svn, which causes the error.
> Without the .svn contents, the permissions of the files probably allow
> overwriting, so no error.  I don't know why that command appears
> twice; perhaps with no error, the duplication was hidden.
> 

I'll look into this. It hasn't been an issue in the past but
it appears to be unnecessary work.

\start
Date: Wed, 12 Apr 2006 18:26:53 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

Hi Tim,

> Axiom as it exists now 
>  a) depends on very little
>  b) never writes outside of its own directory (not even tmp files)
>  c) builds everywhere (or tries to)

Could you live with an axiom-built-procedure that
checks the system, if something is missing, it downloads the appropriate 
files (either from their original source place or from 
axiom-developer.org/prerequisites) and installs them following (b) from 
above.

The only difference to the current Axiom would be that checking and 
installing prerequisites is done before the actual axiom-make starts.
And, the axiom archive will be smaller, since some people might have 
already installed some software.

You said that now Axiom (via gcl) depends on Emacs, but I guess you 
don't want to include emacs into axiom--main--1, do you? (Otherwise 
axiom does not "just work". ;-) )

\start
Date: Wed, 12 Apr 2006 14:47:05 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Axiom silver branch

> On 04/12/2006 03:46 PM, root wrote:
> >> I would like to discuss the organization of branches and procedures.
> > 
> > I'd suggest that you create a new branch in the root version
> > of Makefile.pamphlet called 'silver'. So someone who wants to
> > build the silver version would use something like:
> > 
> > export AXIOM=~/mnt/silver
> > 
> > or 
> > 
> > export AXIOM=~/mnt/linux-silver
> 
> Sorry, I cannot see any point in doing this. If somebody checks out from 
> the SVN silver branch to ~/silver then the compilation result is a 
> SilverAxiom and it lives under ~/silver/${MNT}/${SYS}.
> 
> Exactly the same if you check out from the axiom--main--1 (gold) archive 
> to ~/gold you get a GoldAxiom under ~/gold/${MNT}/${SYS}.

The point is that a 'silver' section of the root Makefile.pamphlet
would allow you to completely change the build behavior of the system.
So you don't have to build lisp, for instance.

\start
Date: Wed, 12 Apr 2006 14:53:57 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

> > Axiom as it exists now 
> >  a) depends on very little
> >  b) never writes outside of its own directory (not even tmp files)
> >  c) builds everywhere (or tries to)
> 
> Could you live with an axiom-built-procedure that
> checks the system, if something is missing, it downloads the appropriate 
> files (either from their original source place or from 
> axiom-developer.org/prerequisites) and installs them following (b) from 
> above.
> 
> The only difference to the current Axiom would be that checking and 
> installing prerequisites is done before the actual axiom-make starts.
> And, the axiom archive will be smaller, since some people might have 
> already installed some software.
> 
> You said that now Axiom (via gcl) depends on Emacs, but I guess you 
> don't want to include emacs into axiom--main--1, do you? (Otherwise 
> axiom does not "just work". ;-) )

It appears that GCL depends on some awk/sed change that somehow
gets packaged with emacs (I'm guessing since I don't actually 
know the source but Camm has suggested that might be the problem).

I'm going to find the problem and write a GCL patch so that it
no longer occurs, send the patch to Camm, and put the patch in zips
against the current GCL versions.

That way Axiom 'just works'.

Curiously the issue first arises on a debian system which is supposed
to be really good at the whole dependency handling.

\start
Date: Wed, 12 Apr 2006 21:04:04 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Axiom silver branch
Cc: Frederic Lehobey

>> You said that now Axiom (via gcl) depends on Emacs, but I guess you 
>> don't want to include emacs into axiom--main--1, do you? (Otherwise 
>> axiom does not "just work". ;-) )
> 
> It appears that GCL depends on some awk/sed change that somehow
> gets packaged with emacs (I'm guessing since I don't actually 
> know the source but Camm has suggested that might be the problem).
> 
> I'm going to find the problem and write a GCL patch so that it
> no longer occurs, send the patch to Camm, and put the patch in zips
> against the current GCL versions.
> 
> That way Axiom 'just works'.
> 
> Curiously the issue first arises on a debian system which is supposed
> to be really good at the whole dependency handling.

I somehow cannot believe that the problem is an issue with emacs, since 
I work also on Debian Sarge on my laptop (maybe with a few other 
packages installed). And I have no proplem with compiling Axiom.

Looking at that ...

checking emacs site lisp directory... Warning: Lisp directory 
`/usr/local/share/emacs/site-lisp' does not exist.

... one difference is that at my laptop this directory exists.
Don't know how relevant that is, though.

/usr/local/share/emacs/21.4/site-lisp
checking emacs default.el... ./configure: line 6216: test: too many 
arguments

Hmmm. the above line looks like a bug in ./configure.

\start
Date: Wed, 12 Apr 2006 16:35:57 -0700
From: Bob McElrath
To: list
Subject: backups

Is the backup at http://axiom.risc.uni-linz.ac.at/ and the main
mathaction wiki synchronized?  i.e. if someone makes a change on the
risc.uni-linz.ac.at site, does it get propagated to the main site?  If
not, it is probably best not to advertise the backup site, because it
will just cause headaches if people use it.  (In fact, it is probably
best to keep it offline to prevent google discovering it and leading
people to use it)

\start
Date: Wed, 12 Apr 2006 20:08:07 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: backups

On Wednesday, April 12, 2006 7:36 Bob McElrath wrote:
>
> Is the backup at http://axiom.risc.uni-linz.ac.at/ and the
> main mathaction wiki synchronized?  i.e. if someone makes
> a change on the axiom.risc.uni-linz.ac.at site, does it
> get propagated to the main site?

Yes, I am using ZSyncer on both sites. Right now the process
is still manual - mostly due to a problem involving
"last_modified_date" on ZWiki pages separated by 7 timezones.
I am planning to synchronize the two sites at least once per
week. In the future I think this can be largely automated
(except for edit conflicts). Eventually we might get software
that makes this easier.

> If not, it is probably best not to advertise the backup
> site, because it will just cause headaches if people use
> it.  (In fact, it is probably best to keep it offline to
> prevent google discovering it and leading people to use
> it.)
>

An offline backup has it's merits and I think we should
continue to do that on a regular basis. Note that Tim
Daly has recently extended the service contract with
RoseHosting to include a nightly backup of the contents
of axiom-developer.

I have thought about how best to use the new mirror site
and I strongly believe that it should be a full and
completely accessible mirror of the main Axiom site.
Keeping a live mirror provides the incentive to keep the
backup site up to date. It is ready to go and immediately
in case of any problems with the other site. In the future
if they are allowed to diverge in content I also think
that is not necessarily such a bad thing - provided that
both sites remain open and accessible.

Perhaps some users will feel a greater affinity for a web
server that is physically closer to them? and as a result
they might devote more time to it than otherwise would be
the case. Also inevitably there may be a diversity of
interests in how Axiom is used and how it can be further
developed. Since this is an open source project, I think
we should not be afraid of such a possibility, although
given our current very limited resources it might be
prudent to try to concentrate our efforts on less ambitious
goals.

\start
Date: Wed, 12 Apr 2006 17:15:53 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: backups

Page, Bill [Bill Page] wrote:
> On Wednesday, April 12, 2006 7:36 Bob McElrath wrote:
> > 
> > Is the backup at http://axiom.risc.uni-linz.ac.at/ and the
> > main mathaction wiki synchronized?  i.e. if someone makes
> > a change on the axiom.risc.uni-linz.ac.at site, does it
> > get propagated to the main site?
> 
> Yes, I am using ZSyncer on both sites. Right now the process
> is still manual - mostly due to a problem involving
> "last_modified_date" on ZWiki pages separated by 7 timezones.
> I am planning to synchronize the two sites at least once per
> week. In the future I think this can be largely automated
> (except for edit conflicts). Eventually we might get software
> that makes this easier.

I tried to automate it with my mcelrath.org mirror but the problem I had
was with authentication, I think.

> I have thought about how best to use the new mirror site
> and I strongly believe that it should be a full and
> completely accessible mirror of the main Axiom site.
> Keeping a live mirror provides the incentive to keep the
> backup site up to date. It is ready to go and immediately
> in case of any problems with the other site. In the future
> if they are allowed to diverge in content I also think
> that is not necessarily such a bad thing - provided that
> both sites remain open and accessible.

In every instance where someone has made a "backup" site that I have
seen, it just causes confusion for users, and eventually drifts until
they aren't the same, causing further confusion.

For some reason bizarre physicists do this a lot.  I think it's a bad
idea.  ...Just my 2 cents.

Links to the other site for large downloads would be a good idea though.

> Perhaps some users will feel a greater affinity for a web
> server that is physically closer to them?

On the web, who can tell?

\start
Date: Wed, 12 Apr 2006 21:24:45 -0400
From: Tim Daly
To: Bob McElrath
Subject: Re: backups

We do need a mirror site because all of our information is in one place.
This was brought home clearly by a hardware failure which, fortunately,
was not a disaster. 

I've contracted for nightly backups of the system so a single failure
can be recovered. But it's time for us to start protecting the assets
against many possible failures. I've neglected this issue too long.

The fact that the backup site will require hand maintenance to keep
in sync is actually a feature. My experience with fully automated
systems is that they get neglected and some minor error (eg a disk
fills up) causes them to become worthless rather quickly. Systems
that get used a lot tend to live. Those that don't die of code rot.

Bill can also, if he so desires, make the RISC site a darcs repository.
That way we can have virtually every non-microsoft source code tool
in use and people can decide which one they like best.

Besides the backup nature of the site I'm hoping that students at
RISC will take an interest in Axiom. We would then have the ability
to work with them locally and support their efforts. In the long term
I think the association is at least as important as the backup/mirror,
if not more so.

\start
Date: Wed, 12 Apr 2006 17:44:07 -0700
From: Bob McElrath
To: Tim Daly
Subject: Re: backups

root [Tim Daly] wrote:
> We do need a mirror site because all of our information is in one place.
> This was brought home clearly by a hardware failure which, fortunately,
> was not a disaster. 

I wasn't arguing against backups ;)

> Besides the backup nature of the site I'm hoping that students at
> RISC will take an interest in Axiom. We would then have the ability
> to work with them locally and support their efforts. In the long term
> I think the association is at least as important as the backup/mirror,
> if not more so.

I hope that is successful!

\start
Date: Wed, 12 Apr 2006 23:13:40 -0400
From: Bill Page
To: list
Subject: [GeneralDiscussion] Plone Bibliography

Bob McElrath wrote:
>
> I was looking at Plone again today for the portal I'm developing,
> and was wondering...what the heck do you do with the bibliography?
> I see you're using it on mathaction, but is it any better than a
> glorified list?  Can I \cite{important_paper} to make citations
> appear?  Much googling couldn't answer this question for me...
>

Import bibtex citations into a database. Edit citations. Search
the database (along with the rest of the contents of the portal).
Extract bibtex citations for inclusion in LaTeX documents and/or
.bib file. I guess it is a little better than a glorified list. :)

Hmmm... since we have some direct support for LaTeX on Plone
(via ZWiki) then I suppose it might make sense to make this
more transparent, extracting citations from the Plone bibliography
database and running bibtex all automatically... :) By-golly
it's easy to get overly ambitious!

\start
Date: Wed, 12 Apr 2006 23:15:59 -0400
From: Bill Page
To: Simon Michael
Subject: darcsweb source code repository browser (was: victory!)

Simon,

On Wednesday, April 12, 2006 7:42 PM you wrote:
> Bill Page:
> > How can you tell which are duplicates?
> >  
> You'll see them in darcsweb once it's working, or just in
> darcs changes
> - they have the same title and (which I think is the
> clincher) the same timestamp, I think.
>
> > still am not able to fully use 'darcsweb'. I have darcsweb-0.15
> > running under python2.4.2 with darcs 1.0.5 installed here
> I'm using the latest darcsweb pulled from
> http://users.auriga.wearlab.de/~alb/repos/darcsweb
> - not sure what version that is - and python 2.4.2.
>

Ok, I added an explicit path to darcs:

-        #darcspath = "/home/me/bin/"
+       darcspath = "/usr/local/bin/"

and provided a cache

-        #cachedir = '/tmp/darcsweb-cache'
+       cachedir = '/tmp'

and now darcsweb works on MathAction:

http://page.axiom-developer.org/darcsweb.cgi

I think this is a really cool way to browse the souce code!
It's a bit slow with a big repository like axiom--main--1
but the annotations and shading are very nice. E.g.

http://page.axiom-developer.org/darcsweb.cgi?r=axiom--main--1;a=annot=
ate
_shade;f=/Makefile

and the searching is quite impressive, e.g.

http://page.axiom-developer.org/darcsweb.cgi?r=axiom--main--1&a=searc=
h&s
=clifford

\start
Date: Wed, 12 Apr 2006 20:21:42 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: [GeneralDiscussion] Plone Bibliography

Page, Bill [Bill Page] wrote:
> Bob McElrath wrote:
> > 
> > I was looking at Plone again today for the portal I'm developing,
> > and was wondering...what the heck do you do with the bibliography?
> > I see you're using it on mathaction, but is it any better than a
> > glorified list?  Can I \cite{important_paper} to make citations
> > appear?  Much googling couldn't answer this question for me...
> > 
> 
> Import bibtex citations into a database. Edit citations. Search
> the database (along with the rest of the contents of the portal).
> Extract bibtex citations for inclusion in LaTeX documents and/or
> .bib file. I guess it is a little better than a glorified list. :)

Okay a little better than a list but still functionally separated from
the wiki and Plone documents.

> Hmmm... since we have some direct support for LaTeX on Plone
> (via ZWiki) then I suppose it might make sense to make this
> more transparent, extracting citations from the Plone bibliography
> database and running bibtex all automatically... :) By-golly
> it's easy to get overly ambitious!

I don't know if that's overly ambitious, but at least in my field we
have arXiv.org references such as hep-ph/0509024 which would be easy to
parse and make a link to the arXiv, as well as a footnote containing the
authors, title, journal reference etc, as would appear in a latex
document.

I want to make it as easy as possible for people to add a \cite{blah}.
The bibliography is already there (or at least accessable on SPIRES
and the arXiv) so all that is needed is for the wiki page to recognize
the \cite.

\start
Date: Wed, 12 Apr 2006 20:28:20 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Simon Michael
Subject: Re: darcsweb source code repository browser (was: victory!)

> and now darcsweb works on MathAction:
> 
> http://page.axiom-developer.org/darcsweb.cgi
> 
> I think this is a really cool way to browse the souce code!
> It's a bit slow with a big repository like axiom--main--1
> but the annotations and shading are very nice. E.g.

I gotta agree - as a first impression I really like the look of
darcsweb!
 
Thanks for another amazing new feature!

\start
Date: Wed, 12 Apr 2006 23:40:53 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: [GeneralDiscussion] Plone Bibliography

On Wednesday, April 12, 2006 11:22 PM Bob McElrath wrote:
> ..
> Bill Page wrote:
> > Hmmm... since we have some direct support for LaTeX on Plone
> > (via ZWiki) then I suppose it might make sense to make this
> > more transparent, extracting citations from the Plone
> > bibliography database and running bibtex all automatically...
> > :) By-golly it's easy to get overly ambitious!
>
> I don't know if that's overly ambitious, but at least in my
> field we have arXiv.org references such as hep-ph/0509024 which
> would be easy to parse and make a link to the arXiv, as well as
> a footnote containing the authors, title, journal reference etc,
> as would appear in a latex document.

Do you mean online access to arXiv.org using "hep-ph/0509024" as
a search key to retrieve and parse the citation info... I think
that is ambitious. Are there any web tools for arXiv that make
this easier?

>
> I want to make it as easy as possible for people to add a
> \cite{blah}.

I think the problem is not the \cite but rather the 'blah' ...
'blah' must be a simple, useful and unique identifier of a
published document. That is not easy in general.

> The bibliography is already there (or at least accessable on
> SPIRES and the arXiv) so all that is needed is for the wiki
> page to recognize the \cite.
>

Parsing static data like 'hep-ph/0509024' into a clickable url
is easy but extracting and formating citation information is
rather hard to do in general. That's why we have tools like
BiBtex and EndNote, etc.

One thing that I am quite interested in for other reasons is
a project called DSpace:

http://dspace.org

This is an aggressive and rapidly developing project fueled by
HP, and MIT to produce a free open source digital archive. It
is very rapidly be adopted by the university research library
community and I have already set it up a few times for several
of my clients. It is not so hard to setup for personal use.
DSpace already provides integration of a local archive with a
web-wide "handle" server that simplies urls that reference
archive content and make it possible to move the content with
out changing the document handle.

Maybe integrating something like this might be worthwhile...
but beware: This a Java/JSP web application - somewhat different
world that Zope and Python. ;)

\start
Date: Wed, 12 Apr 2006 21:15:30 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: [GeneralDiscussion] Plone Bibliography list

Page, Bill [Bill Page] wrote:
> Do you mean online access to arXiv.org using "hep-ph/0509024" as
> a search key to retrieve and parse the citation info... I think
> that is ambitious. Are there any web tools for arXiv that make
> this easier?

Yes.

SPIRES: http://www.slac.stanford.edu/ indexes everything on the arXiv,
provides bibtex for it, and forward-tracks the articles into journals.
There are several highly non-trivial way to interrogate its database.

Other services include NASA Abstract service:
    http://adsabs.harvard.edu/abstract_service.html
Citebase:
    http://www.citebase.org/cgi-bin/citations?id=oai:arXiv.org:hep-ph/0506151
of course there are others more relevant to other branches of science...

> > I want to make it as easy as possible for people to add a
> > \cite{blah}.
> 
> I think the problem is not the \cite but rather the 'blah' ...
> 'blah' must be a simple, useful and unique identifier of a
> published document. That is not easy in general.

Well we have several terse identifiers that can be recognized:
    hep-ph/0509024      (arxiv.org)
    math.NT/0604263     (arxiv.org)
    McElrath:2005bp     (bibtex entries in the SPIRES database:
             http://www.slac.stanford.edu/spires/find/hep/www?key=6255744&FORMAT=WWWBRIEFBIBTEX)
    doi:10.1103/PhysRevD.72.103508 (http://scitation.aip.org/jhtml/doi.jsp)
    2006PhRvD..73a5011G (NASA ADS)
I'm sure there are others (ISBN, etc).  These are easy to look up, and a
lot easier to copy than full bibliographic info.  Given any of those I
know how to get the bibtex via an HTTP request, which can be fed to the
Plone Bibliography.  Then a nice citation can be rendered as part of the
wiki page.  See the bottom of http://mcelrath.org/Notes/TODO for an
example of such a rendering.

> > The bibliography is already there (or at least accessable on
> > SPIRES and the arXiv) so all that is needed is for the wiki
> > page to recognize the \cite.
> 
> Parsing static data like 'hep-ph/0509024' into a clickable url
> is easy but extracting and formating citation information is
> rather hard to do in general. That's why we have tools like
> BiBtex and EndNote, etc.

I want to get the info out of the Plone Bibliography, or have the server
interrogate external bibliography servers.

> One thing that I am quite interested in for other reasons is
> a project called DSpace:
> 
> http://dspace.org
> 
> This is an aggressive and rapidly developing project fueled by
> HP, and MIT to produce a free open source digital archive. It
> is very rapidly be adopted by the university research library
> community and I have already set it up a few times for several
> of my clients. It is not so hard to setup for personal use.
> DSpace already provides integration of a local archive with a
> web-wide "handle" server that simplies urls that reference
> archive content and make it possible to move the content with
> out changing the document handle.

interesting...

> Maybe integrating something like this might be worthwhile...
> but beware: This a Java/JSP web application - somewhat different
> world that Zope and Python. ;)

Well just yesterday I was forced to use a Java application, and it
crashed my browser, again.  A few days before that I decided to try
(again) the Java interface to Maple.  UUUGGGHHHH it's slow.  What's
that?  A fork in my eye?  Aaaahhh much better.

\start
Date: Thu, 13 Apr 2006 01:07:33 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: [GeneralDiscussion] Plone Bibliography

On Thursday, April 13, 2006 12:16 AM Bob McElrath wrote:
> ...
> Bill Page wrote:
> > Parsing static data like 'hep-ph/0509024' into a clickable url
> > is easy but extracting and formating citation information is
> > rather hard to do in general. That's why we have tools like
> > BiBtex and EndNote, etc.
>
> I want to get the info out of the Plone Bibliography,

Maybe \cite{axiombib/1005298} could call e.g.

wget http://portal.axiom-developer.org/refs/axiombib/1005298/download

[page@axiom-developer]# cat download

@Inproceedings{1005298,
  author = {Jacques Carette},
  title = {Understanding expression simplification},
  year = {2004},
  URL =
{http://www.cas.mcmaster.ca/\~carette/publications/simplification.pdf},
  abstract = {},
  booktitle = {Proceedings of the 2004 international symposium on
Symbolic and algebraic computation},
  publisher = {ACM Press,},
  pages = {72 - 79}
}

but you still have to make this bibtex entry look pretty in HTML.

\start
Date: Wed, 12 Apr 2006 22:11:28 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: [GeneralDiscussion] Plone Bibliography list

Page, Bill [Bill Page] wrote:
> On Thursday, April 13, 2006 12:16 AM Bob McElrath wrote:
> > ...
> > Bill Page wrote:
> > > Parsing static data like 'hep-ph/0509024' into a clickable url
> > > is easy but extracting and formating citation information is
> > > rather hard to do in general. That's why we have tools like
> > > BiBtex and EndNote, etc.
> > 
> > I want to get the info out of the Plone Bibliography,
> 
> Maybe \cite{axiombib/1005298} could call e.g.
> 
> wget http://portal.axiom-developer.org/refs/axiombib/1005298/download
> 
> [page@axiom-developer]# cat download
> 
> @Inproceedings{1005298,
>   author = {Jacques Carette},
>   title = {Understanding expression simplification},
>   year = {2004},
>   URL =
> {http://www.cas.mcmaster.ca/\~carette/publications/simplification.pdf},
>   abstract = {},
>   booktitle = {Proceedings of the 2004 international symposium on
> Symbolic and algebraic computation},
>   publisher = {ACM Press,},
>   pages = {72 - 79}
> }
> 
> but you still have to make this bibtex entry look pretty in HTML.

Well a document rendering Archetype in Plone should be able to access
the same info programatically.  (The Bibliography can already render
entries)

If the entry doesn't exist, it can be retreived and inserted as bibtex,
and then accessed programatically using the Plone Bibliography.

\start
Date: Thu, 13 Apr 2006 01:18:53 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: [GeneralDiscussion] Plone Bibliography

On Thursday, April 13, 2006 1:11 AM Bob McElrath wrote:
> ...
> Well a document rendering Archetype in Plone should be able to
> access the same info programatically.  (The Bibliography can
> already render entries)
>

Indeed. If you are up to the task of calling Archetypes in
CMFPlone from a Wiki, then I say go for it! :)

> If the entry doesn't exist, it can be retreived and inserted
> as bibtex, and then accessed programatically using the Plone
> Bibliography.
>

Doing this with one or two clicks would be real nice.

\start
Date: Wed, 12 Apr 2006 22:34:59 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: [GeneralDiscussion] Plone Bibliography list

Page, Bill [Bill Page] wrote:
> On Thursday, April 13, 2006 1:11 AM Bob McElrath wrote:
> > ... 
> > Well a document rendering Archetype in Plone should be able to
> > access the same info programatically.  (The Bibliography can
> > already render entries)
> >
> 
> Indeed. If you are up to the task of calling Archetypes in
> CMFPlone from a Wiki, then I say go for it! :)
>  
> > If the entry doesn't exist, it can be retreived and inserted 
> > as bibtex, and then accessed programatically using the Plone
> > Bibliography.
> 
> Doing this with one or two clicks would be real nice.

I was thinking zero clicks.  As in, add \cite{arXiv:hep-ph/0123456} to
your wiki page and the rest is automatic from the user's perspective.

\start
Date: Thu, 13 Apr 2006 14:04:03 +0200
From: Ralf Hemmecke
To: Tim Daly, Bill Page
Subject: Re: backups

>> Besides the backup nature of the site I'm hoping that students at
>> RISC will take an interest in Axiom. We would then have the ability
>> to work with them locally and support their efforts. In the long term
>> I think the association is at least as important as the backup/mirror,
>> if not more so.
> 
> I hope that is successful!

Me, too. ;-)

But it needs more than just running a mirror of the Axiom site at a RISC 
server. I am constantly trying to show the potential of Axiom/Aldor, but 
it is not so easy since there are still lots of bugs hidden and the main 
goal of students here is to get their PhD and not to fix bugs. They want 
to and should invent and implement new algorithms.

But you cannot expect someone to implement something in a not-so-robust 
system which doesn't let you track bugs easily. I am not only speaking 
of Axiom, but there is definitely need for a better user interface.
Although I am not yet a big fan of Texmacs, because it is yet another 
language (besides LaTeX) to learn, I somehow think that it should become 
a more integrated into axiom and become the default userinterface.

BTW, if we could find money (sponsors) to finance a PhD student at RISC
who works for half a day on Axiom, I guess that the RISC faculty would 
love that. (OK, that was just a thought...)


It is currently not the case that everyone wants to jump on Axiom. All 
Axiom developers have to work hard to make other people more aware that 
Axiom is progressing. Yes, it is not just coding, we also need 
advertising Axiom. Does anyone know, how we could do this? Maybe a "job 
offer" to become an unpaid Axiom developer? Sorry, it should read:

    ... to become a pioneer in the development of a next generation
    computer algebra and theorem proving system.

\start
Date: Thu, 13 Apr 2006 14:35:52 +0200
From: David Mentre
To: Ralf Hemmecke
Subject: User interface, TeXmacs and Axiom (was: Re: backups)

Hello,

2006/4/13, Ralf Hemmecke:
> But you cannot expect someone to implement something in a not-so-robust
> system which doesn't let you track bugs easily.

In a short summary, what would you like to have?

> I am not only speaking of Axiom, but there is definitely need for a bette=
r user interface.

I agree, even if the current text interface is not that bad. Do not
forget that somebody is working on a web interface (with Tim?).

> Although I am not yet a big fan of Texmacs, because it is yet another
> language (besides LaTeX) to learn, I somehow think that it should become
> a more integrated into axiom and become the default userinterface.

I like TeXmacs *but* it has some big issues for me, one of the biggest
being it is quite slow (the interface is not snappy enough). And Joris
is focusing developments of other aspects (graphics mode) rather than
fixing those issues. The development API is not very well documented
neither.

\start
Date: Thu, 13 Apr 2006 08:41:58 -0700
From: Bob McElrath
To: David Mentre
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

David MENTRE [David Mentre] wrote:
> > Although I am not yet a big fan of Texmacs, because it is yet another
> > language (besides LaTeX) to learn, I somehow think that it should become
> > a more integrated into axiom and become the default userinterface.
> 
> I like TeXmacs *but* it has some big issues for me, one of the biggest
> being it is quite slow (the interface is not snappy enough). And Joris
> is focusing developments of other aspects (graphics mode) rather than
> fixing those issues. The development API is not very well documented
> neither.

I wish I had enough time to further develop the mozilla/axiom interface
I started.  I really think that's the way to go.

What happened to Kai's branch?  Can I still try it?

\start
Date: Thu, 13 Apr 2006 12:02:39 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: User interface,
Cc: David Mentre

On Thursday, April 13, 2006 11:42 AM Bob McElrath wrote:
> ...
> I wish I had enough time to further develop the mozilla/axiom
> interface I started.  I really think that's the way to go.

At one point Bob, you also had a nice demo of Axiom inside
a TiddlyWiki. I thought that was a really nice idea for
personal use.

>
> What happened to Kai's branch?  Can I still try it?
>

'tla abrowse' shows that

    axiom--GUI
      axiom--GUI--1
        base-0 .. patch-3

still exists so you can extract it from the archive and
try it. Last time I tried (about 6 months ago) to build
this it failed. Kai is still here on this list so perhaps
he can help if you get into trouble. I think it would be
great to move this work forward.

You can also browse the source online here:

http://wiki.axiom-developer.org/axiom--GUI--1/FrontPage

\start
Date: Thu, 13 Apr 2006 18:16:12 +0200
From: Ralf Hemmecke
To: David Mentre
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

On 04/13/2006 02:35 PM, David MENTRE wrote:
> 2006/4/13, Ralf Hemmecke:
>> But you cannot expect someone to implement something in a not-so-robust
>> system which doesn't let you track bugs easily.
> 
> In a short summary, what would you like to have?

Hmm, actually, I cannot speak much about Axiom, but whether it's Aldor 
or Axiom doesn't matter that much. I am missing a debugger that let's 
you run a program step by step and shows the corresponding source code 
in an editor like window. All newer IDEs have this feature.

Yes I know that one should rather think before one programs and I also 
like the work of Christian Aistleitner quite a lot

http://www.risc.uni-linz.ac.at/software/aldor/aldorunit

But sometimes it's also quite useful if you can comfortably step through 
your code, showing variables and everything.

Well and for Aldor the biggest problem is that the compiler is buggy. 
One never knows whether the bug is in your own source or in the 
compiler. There is definitely need for improvement.

For Axiom I remember that it sometimes showes strange error messages or 
suggests that you should debug in BOOT. A user should actually never see 
anything else than Aldor/SPAD. When I started with Axiom, I was always 
disappointed when I saw the BOOT prompt. And even though I know some 
lisp, that frightens me if I want to do Algebra and I end up in LISP.

I hope it was short enough. Hmmm, I think I should add something to the 
Axiom WishList. ;-)

>> I am not only speaking of Axiom, but there is definitely need for a
 >> better user interface.

> I agree, even if the current text interface is not that bad.

But Axiom does not yet have something like a worksheet format. That was 
the reason why I referred to Texmacs.

We might end up in getting an interface to write live pamphlet files. 
But I guess, that is a bit tricky, since all the <<...>> chunks are 
somehow like macros and thus the code does not need to appear in the 
order you write.

 > Do not forget that somebody is working on a web interface (with Tim?).

Can I already see something that works? Or is that still unfinished?
I cannot remember that I heard a release announcement.

>> Although I am not yet a big fan of Texmacs, because it is yet another
>> language (besides LaTeX) to learn, I somehow think that it should become
>> a more integrated into axiom and become the default userinterface.

> I like TeXmacs *but* it has some big issues for me, one of the biggest
> being it is quite slow (the interface is not snappy enough).

Well, yes, that TeXmacs is slow also disturbed me quite a lot, but Axiom 
needs to have something comparable to M&M for it's interface.

You could say, that AxiomWiki is something like a worksheet format, but 
it is a bit inconvenient to work with, if you always have to press the 
edit button.

\start
Date: Thu, 13 Apr 2006 13:16:57 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)
Cc: David Mentre

 > Do not forget that somebody is working on a web interface (with Tim?).

Yes, I have been working on an AJAX version of the browser pages.
It's basically a hand rewrite using latex, javascript, etc.

\start
Date: Thu, 13 Apr 2006 09:30:30 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)
Cc: David Mentre

Page, Bill [Bill Page] wrote:
> On Thursday, April 13, 2006 11:42 AM Bob McElrath wrote:
> > ... 
> > I wish I had enough time to further develop the mozilla/axiom 
> > interface I started.  I really think that's the way to go.
> 
> At one point Bob, you also had a nice demo of Axiom inside
> a TiddlyWiki. I thought that was a really nice idea for
> personal use.

I like it too but the FIFO I was using is really good at hanging
mozilla/firefox.

I'm one of those annoying people with more ideas than time...

> > What happened to Kai's branch?  Can I still try it?
> > 
> 
> 'tla abrowse' shows that
> 
>     axiom--GUI
>       axiom--GUI--1
>         base-0 .. patch-3
> 
> still exists so you can extract it from the archive and
> try it. Last time I tried (about 6 months ago) to build
> this it failed. Kai is still here on this list so perhaps
> he can help if you get into trouble. I think it would be
> great to move this work forward.
> 
> You can also browse the source online here:
> 
> http://wiki.axiom-developer.org/axiom--GUI--1/FrontPage

Is development continuing on this?

\start
Date: Thu, 13 Apr 2006 09:34:39 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: [GeneralDiscussion] Plone Bibliography list

Bob McElrath wrote:
> > > If the entry doesn't exist, it can be retreived and inserted 
> > > as bibtex, and then accessed programatically using the Plone
> > > Bibliography.
> > 
> > Doing this with one or two clicks would be real nice.
> 
> I was thinking zero clicks.  As in, add \cite{arXiv:hep-ph/0123456} to
> your wiki page and the rest is automatic from the user's perspective.

By the way, someone at SLAC (SPIRES) expressed a strong interest in
this, and even offered to host a copy of the database on the same server
as the wiki!  I guess it's only about 5 GB.

Not so useful for math, but I'll try to keep an eye out for how to
expand this beyond physics.

\start
Date: Thu, 13 Apr 2006 11:21:04 -0700
From: Antoine Hersen
To: list
Subject: Problem with defining Zero

Hello,

I am trying to defined a zero in a domain compiled with Aldor.

But I am getting :

0$NTBA(x,FRAC INT)
   Internal Error
   The function Zero with signature hashcode is missing from domain
      UNPRINTABLE

Here a small exemple in the SandBox
http://wiki.axiom-developer.org/SanBoxZero

\start
Date: Thu, 13 Apr 2006 21:41:11 +0200
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Problem with defining Zero

Hello Antoine.


First, in Aldor it is suggested to write
   Rep == LPF;
instead of your
   Rep ==> LPF;

Second, there is some magic going on here that I cannot explain.

http://wiki.axiom-developer.org/SandBoxZero

Clearly, you specify:

    Zero:() -> % ;

in the exports, but nowhere you say something like

   0: %

So it should be clear that there is no 0$NTBA.
HOWEVER, why does Axiom )show the signature

   0: () -> %

Can somebody explain why Zero and 0 should be the same? I am almost 100% 
sure that there is not such syntactic sugar in the Aldor compiler, so I 
guess Axiom is treating Zero and 0 identically, **but** not in finding 
the implementation. Is that behaviour documented somewhere in Axiom?

How to do it right?

Replace
    Zero:() -> % ;
by
   0: %;
and
   Zero():% == { per [0$FP] }
by
    0 :% == { per [0$FP] }

And say

    dummy (f:%):% == 0;

The )show will be identical. STRANGE!!! It should show
   0: %
instead of
   0: () -> %

But

(3) -> 0$NTBA(x,FRAC INT)

    (3)  D [0]

works.

\start
Date: Thu, 13 Apr 2006 12:41:09 -0700
From: Antoine Hersen
To: list
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

Hello,

My experience is making a good UI is a lot of works( aka way more than you
imagine), especially if you go out the basic widget. ( I had a 30 line long
rent there ).

Before choosing a solution we should set goals and there relative
importance. My try :

+ Attracting new user :
   - sexy look
   - toolbox
   - template

+ Productive Environment :
   - easy to write pages long code :
         - pretty print
         - indentation
         - source code management
   - Good integration with the debugger
   - A easy work flown( edit, compile, test)
   - An know script langange( scheme, python)

+ Axiom specific
   - Ease the write of pamphlet( writing literate programs is a lot of adde=
d
work, that does not benefit the writer that much, so we should make it easy
as possible

The candidates :
+ Web based, Browser based : for Mozilla http://www.xulplanet.com/ maybe
using MathML.
Personally I have mixed fealling,  it is very hip and I will like for the
tools to mature( think about Java UI for exemple Map... )

+ TeXmacs, the screenshot does looks good.

+ My big favorite imaxima :
http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html

Why :
Emacs work everywhere, with extensive menu an icon it is not that scary.

We should be able to manage pamphlet in a elegant way. And think about
everything that is already included, source code management, non various
charset ....

And very powerful and well documented language elisp !!!!

+ Start from scratch ( using http://mcclim.cliki.net/index )

Other issue( I am sure it has been discussed before) :
  - Improved documentation browser aware of pamphlet
  - Improved plot 2D, 3D viewer.

Some of this issue are problems common to all open source CAS, common
solution will have more hands working on it.

Regards,

Antoine Hersen

PS : About debugging it is mostly a language tools issue,

------=_Part_16688_31823381.1144957269581

Hello,<br><br>My experience is making a good UI is a lot of works( aka way =
more than you imagine), especially if you go out the basic widget. ( I had =
a 30 line long rent there ).<br><br>Before choosing a solution we should se=
t goals and there relative importance. My try :
<br>
<br>+ Attracting new user :<br>
&nbsp;&nbsp; - sexy look<br>&nbsp;&nbsp; - toolbox<br>&nbsp;&nbsp; - templa=
te<br><br>
+ Productive Environment :<br>
&nbsp;&nbsp; - easy to write pages long code :<br>&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; - pretty print<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; - indentation<br>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; - source=
 code management<br>
&nbsp;&nbsp; - Good integration with the debugger<br>&nbsp;&nbsp; - A easy =
work flown( edit, compile, test)<br>&nbsp;&nbsp; - An know script langange(=
 scheme, python) <br>
<br>+ Axiom specific<br>&nbsp;&nbsp; - Ease the write of pamphlet( writing =
literate programs is a lot of added work, that does not benefit the writer =
that much, so we should make it easy as possible<br><br>The candidates :<br=
>+ Web based, Browser based : for Mozilla
<a href="http://www.xulplanet.com/">http://www.xulplanet.com/</a> maybe u=
sing MathML.<br>Personally I have mixed fealling,&nbsp; it is very hip and =
I will like for the tools to mature( think about Java UI for exemple Map...=
 )<br>
<br>+ TeXmacs, the screenshot does looks good.<br><br>+ My big favorite ima=
xima :<br><a href="http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.h=
tml">http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html</a><br><br>
Why :<br>Emacs work everywhere, with extensive menu an icon it is not that =
scary.<br><br>We should be able to manage pamphlet in a elegant way. And th=
ink about everything that is already included, source code management, non =
various charset ....
<br><br>And very powerful and well documented language elisp !!!!<br><br>+ =
Start from scratch ( using <a href="http://mcclim.cliki.net/index">http:/=
/mcclim.cliki.net/index</a> )<br><br>Other issue( I am sure it has been dis=
cussed before) :
<br>&nbsp; - Improved documentation browser aware of pamphlet<br>&nbsp; - I=
mproved plot 2D, 3D viewer.<br><br>Some of this issue are problems common t=
o all open source CAS, common solution will have more hands working on it.<=
br><br>
Regards,<br><br>Antoine Hersen<br><br>PS : About debugging it is mostly a l=
anguage tools issue,<br>

\start
Date: Thu, 13 Apr 2006 15:45:54 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: Problem with defining Zero

On Thursday, April 13, 2006 2:21 PM Antoine Hersen wrote:
>
> I am trying to defined a zero in a domain compiled with Aldor.
>
> But I am getting :
>
> 0$NTBA(x,FRAC INT)
>    Internal Error
>    The function Zero with signature hashcode is missing from domain
>       UNPRINTABLE
>
> Here a small exemple in the SandBox
> http://wiki.axiom-developer.org/SanBoxZero
>
> Any ideas ?
>

You should write '0' in Aldor instead of 'Zero'. See

http://wiki.axiom-developer.org/SandBoxZero

Click 'diff' to see what I changed.

\start
Date: Thu, 13 Apr 2006 21:52:18 +0200
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Problem with defining Zero

And here an addon to my last mail that explains why I think Axiom should 
not show

   0: () -> %

where I define

   0: %

I am sure you can read that.

Ralf
---------------------------------------------------------------------

#include "aldor"
NTBA(T: OutputType with {0: %}): OutputType with {
    0: %;
    0: () -> %;
}  == add {
    Rep == List T;
    import from T, List T;
    0: % == per empty;
    0(): % == per [0]; -- identical to "per [0$T];".
    (tw: TextWriter) << (x: %): TextWriter == tw << rep x;
}

main(): () == {
	import from TextWriter, Character, String;
	import from NTBA Integer;
	stdout << "0   = " << 0   << newline;
	stdout << "0() = " << 0() << newline;
}

main();

#if OUTPUT
woodpecker:~/scratch>aldor -grun -laldor ntba.as
0   = []
0() = [0]
#endif

\start
Date: Thu, 13 Apr 2006 15:54:17 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: User interface,TeXmacs and Axiom

On Thursday, April 13, 2006 3:41 PM Antoine Hersen wrote:
> ...=09
> The candidates :
> ...
> + My big favorite imaxima :
> http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html
>
> Why :
> Emacs work everywhere, with extensive menu an icon it is
> not that scary.

+1

Yes, I think such a tool for Axiom would be great!

Who can we get to work on this?

\start
Date: Thu, 13 Apr 2006 13:01:09 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Antoine Hersen
Subject: re: User interface,TeXmacs and Axiom

> On Thursday, April 13, 2006 3:41 PM Antoine Hersen wrote:
> > ...	
> > The candidates :
> > ...
> > + My big favorite imaxima :
> > http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html
> >
> > Why :
> > Emacs work everywhere, with extensive menu an icon it is
> > not that scary.
> 
> +1
> 
> Yes, I think such a tool for Axiom would be great!
> 
> Who can we get to work on this?

I'm poking at it a little, but I'm not planning on adding the graphical
output of Imaxima for quite a while - that's non-trivial and I'm not
sure it works on Windows.

I'm building off of Jay's efforts, but I'm starting with a terminal
mode and working up in an effort to learn elisp so it will take quite
some time :-/.

\start
Date: Thu, 13 Apr 2006 15:07:07 -0500
From: Jay Belanger
To: Bill Page
Subject: re: User interface,TeXmacs and Axiom

Bill Page writes:
...
>> + My big favorite imaxima :
>> http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html
...
> +1
>
> Yes, I think such a tool for Axiom would be great!

I relies on a good TeX installation, which would add more overhead.
IMaxima, to the best of my knowledge, just provides a (very) nice
running Maxima; it doesn't do any of the other things (such as help
with debugging or help writing code) that Antoine suggested.

> Who can we get to work on this?

I know that someone is working on Emacs-Axiom interaction, but I
wouldn't mind working on some sort of IAxiom that could later be
absorbed.

\start
Date: Thu, 13 Apr 2006 13:37:02 -0700
From: Bob McElrath
To: Bill Page
Subject: re: User interface,TeXmacs and Axiom

Page, Bill [Bill Page] wrote:
> On Thursday, April 13, 2006 3:41 PM Antoine Hersen wrote:
> > ...	
> > The candidates :
> > ...
> > + My big favorite imaxima :
> > http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html
> >
> > Why :
> > Emacs work everywhere, with extensive menu an icon it is
> > not that scary.
> 
> +1
> 
> Yes, I think such a tool for Axiom would be great!
> 
> Who can we get to work on this?

I worry a lot this group is bifurcating more than it is collaborating.

We have N code repositories using 4 different version control softwares,
4 GUI's, 4 programming languages, 2 websites, etc.

Getting images out of tex is a hack and always has been.  We can either
push on better tools to make them better (e.g. MathML), or keep
incrementing the number of hacks we have collecting dust.

\start
Date: Thu, 13 Apr 2006 22:47:15 +0200
From: Pierre Doucy
To: Antoine Hersen
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

Antoine, I very much agree with you... until you start saying that
Emacs might do the trick ;-)

Emacs is indeed very portable, very powerful, but also extremely scary
at first sight, in particular if you're not used to coding. Although
it is not impossible to master it, it requires a lot of implication
from the end user, which is not a good thing.

I would rather use eclipse which, from a certain point of view, is
"emacs 30 years later" : the "interface for everything and nothing in
particular" approach, plus a certain degree of "cleanliness".
It may not be the sexiest of environments, but one can easily build a
very powerful user interface without coding the whole thing from
scratch. Plus, it may be possible to write an abstract algebra
environment that can be specialized for many algebra systems.

Just my two cents...

Regards,

Pierre



On 4/13/06, Antoine Hersen wrote:
> Hello,
>
> My experience is making a good UI is a lot of works( aka way more than yo=
u
> imagine), especially if you go out the basic widget. ( I had a 30 line lo=
ng
> rent there ).
>
> Before choosing a solution we should set goals and there relative
> importance. My try :
>
> + Attracting new user :
>     - sexy look
>    - toolbox
>    - template
>
>  + Productive Environment :
>     - easy to write pages long code :
>          - pretty print
>          - indentation
>          - source code management
>     - Good integration with the debugger
>    - A easy work flown( edit, compile, test)
>    - An know script langange( scheme, python)
>
> + Axiom specific
>    - Ease the write of pamphlet( writing literate programs is a lot of ad=
ded
> work, that does not benefit the writer that much, so we should make it ea=
sy
> as possible
>
> The candidates :
> + Web based, Browser based : for Mozilla http://www.xulplanet.com/ maybe
> using MathML.
> Personally I have mixed fealling,  it is very hip and I will like for the
> tools to mature( think about Java UI for exemple Map... )
>
> + TeXmacs, the screenshot does looks good.
>
> + My big favorite imaxima :
> http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html
>
>  Why :
> Emacs work everywhere, with extensive menu an icon it is not that scary.
>
> We should be able to manage pamphlet in a elegant way. And think about
> everything that is already included, source code management, non various
> charset ....
>
> And very powerful and well documented language elisp !!!!
>
> + Start from scratch ( using http://mcclim.cliki.net/index )
>
> Other issue( I am sure it has been discussed before) :
>   - Improved documentation browser aware of pamphlet
>   - Improved plot 2D, 3D viewer.
>
> Some of this issue are problems common to all open source CAS, common
> solution will have more hands working on it.

\start
Date: Thu, 13 Apr 2006 15:50:58 -0500
From: Jay Belanger
To: Bill Page
Subject: re: User interface,TeXmacs and Axiom

Bob McElrath writes:
...
> I worry a lot this group is bifurcating more than it is collaborating.
>
> We have N code repositories using 4 different version control softwares,
> 4 GUI's, 4 programming languages, 2 websites, etc.

The bifurcations apparently make everything a power of 2.

> Getting images out of tex is a hack and always has been.  We can either
> push on better tools to make them better (e.g. MathML), or keep
> incrementing the number of hacks we have collecting dust.

You say "hack" like it's a bad thing.
I believe there will always be those who want to interact with Axiom through
Emacs, and so why not make it look nice?  I would think that the
IMaxima analogue would fall under the "make better tools better"
umbrella rather than the "hacks collecting dust", particularly since
IMaxima itself has been very well received.

\start
Date: Thu, 13 Apr 2006 16:57:12 -0400
From: Bill Page
To: Bob McElrath
Subject: re: User interface,TeXmacs and Axiom

On Thursday, April 13, 2006 4:37 PM Bob McElrath wrote:
> ...
> I worry a lot this group is bifurcating more than it is
> collaborating.
>
> We have N code repositories using 4 different version control
> softwares, 4 GUI's, 4 programming languages, 2 websites, etc.
>

I think you worry too much. :)

It is true that we have many different goals, tools, ideas
etc. and too few people and time. But I have come to
appreciate that one of the characteristics of open source
projects is that variety is a good thing even when you think
don't have the resouces to support it - the reason is that
variety usually attracts resources. You only have to look
at the enormous range of open source software available now
compared to commercial products in just five years time.
But sooner or later free thinking open source developers
will "think with their feet" and re-focus efforts on those
things that seem most likely to advance.

> Getting images out of tex is a hack and always has been.

Well, you are the author of one of the best efforts I know
to do that so I greatly respect your opinion, but I tend to
disagree. TeX/LaTeX is one of the most robust pieces of
software we have for this purpose. Tools like 'dvipng' are
making it easier to deal with TeX output in image form.

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

> We can either push on better tools to make them better
> (e.g. MathML), or keep incrementing the number of hacks
> we have collecting dust.
>

Well the MathAction website is not "collecting dust" and it
depends on LaTeX and your code. Other similar systems like
WikiMedia also make extensive use of LaTeX (with MathML
optional).

http://meta.wikimedia.org/wiki/Help:Formula
http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Mathematics/Arch
ive10#Another_small_step_towards_MathML_support_in_MediaWiki

I have no problems "pushing" for better MathML but I still
think using it in a production system is too uncertain.
The necessary infrastructure (mostly MathML compatible browsers)
are not out there yet (give it a couple more years?)

I liked an idea you mentioned a few months ago about MathML
support in jsMath. That way LaTeX or MathML is a choice you
can make in javascript at your browser.

\start
Date: Thu, 13 Apr 2006 23:06:39 +0200
From: Pierre Doucy
To: Jay Belanger
Subject: re: User interface,TeXmacs and Axiom

Even if diversity is a good thing, Bob has a point.
That's very good news if people want to hack stuff around Axiom, but
it there is not a clear line, like an official GUI, an official SCM,
etc...

I must admit that Axiom's offering is confusing. I don't think
newcomers (and people in general) like to have the choice. The first
time I came across axiom, I wanted a quick way to give it a try, not
having to make endless decisions without really knowing which is best.

Pierre


On 4/13/06, Jay Belanger wrote:
>
> Bob McElrath writes:
> ...
> > I worry a lot this group is bifurcating more than it is collaborating.
> >
> > We have N code repositories using 4 different version control softwares=
,
> > 4 GUI's, 4 programming languages, 2 websites, etc.
>
> The bifurcations apparently make everything a power of 2.
>
> > Getting images out of tex is a hack and always has been.  We can either
> > push on better tools to make them better (e.g. MathML), or keep
> > incrementing the number of hacks we have collecting dust.
>
> You say "hack" like it's a bad thing.
> I believe there will always be those who want to interact with Axiom thro=
ugh
> Emacs, and so why not make it look nice?  I would think that the
> IMaxima analogue would fall under the "make better tools better"
> umbrella rather than the "hacks collecting dust", particularly since
> IMaxima itself has been very well received.

\start
Date: Thu, 13 Apr 2006 17:08:01 -0400
From: Bill Page
To: Pierre Doucy
Subject: RE: User interface, TeXmacs and Axiom (was: Re: backups)

On Thursday, April 13, 2006 4:47 PM Pierre Doucy wrote:
> ...
> I would rather use eclipse which, from a certain point of
> view, is "emacs 30 years later" : the "interface for
> everything and nothing in particular" approach, plus a
> certain degree of "cleanliness". It may not be the sexiest
> of environments, but one can easily build a very powerful
> user interface without coding the whole thing from
> scratch. Plus, it may be possible to write an abstract
> algebra environment that can be specialized for many
> algebra systems.
>

I would very much like to know more about the possibility
of using eclipse for this purpose. But nearly everything
I have read about eclipse on the web has tended to turn
me off. Although there appears to be an emphasis on open
source in the eclipse projects, the content of the web
sites I have visited tend to look more like commerical
java promotional material from the IBM-era than "real life".
;)

But maybe I don't have the right information. Can you
suggest a place to get more information about eclipse?
Where and how to download it? How to use it for somethig
approximating emacs? In general a good source of information?

\start
Date: Thu, 13 Apr 2006 17:18:26 -0400
From: Bill Page
To: Pierre Doucy
Subject: re: User interface,TeXmacs and Axiom

On Thursday, April 13, 2006 5:07 PM Pierre Doucy wrote:
>
> Even if diversity is a good thing, Bob has a point.
> That's very good news if people want to hack stuff around
> Axiom, but it there is not a clear line, like an official
> GUI, an official SCM, etc...
>

Well, this is the developer email list ... :)

> I must admit that Axiom's offering is confusing. I don't
> think newcomers (and people in general) like to have the
> choice. The first time I came across axiom, I wanted a quick
> way to give it a try, not having to make endless decisions
> without really knowing which is best.
>

A lot of people are apparently learning about Axiom and
giving it a try for the first time at:

http://wiki.axiom-developer.org

(Click SandBox)

Of course people also want something at their own desks
so we try to make it easy to download and install a
"standard" version of Axiom that includes the traditional
hyperdoc tools and graphics if possible (not yet possible
for Windows users). I don't think new users really need to
spend much time worrying about which is best.

\start
Date: Thu, 13 Apr 2006 14:26:50 -0700
From: Bob McElrath
To: Bill Page
Subject: re: User interface,TeXmacs and Axiom

Page, Bill [Bill Page] wrote:
> On Thursday, April 13, 2006 5:07 PM Pierre Doucy wrote:
> > 
> > Even if diversity is a good thing, Bob has a point.
> > That's very good news if people want to hack stuff around
> > Axiom, but it there is not a clear line, like an official
> > GUI, an official SCM, etc...
> >
> 
> Well, this is the developer email list ... :)

I'd suggest that diversity is good, but eventually we should focus our
meager resources, and choose an official SCM and GUI.

The reason for much of the diversity is that we're all exploring
different ways of doing things without knowing what is best.

But we can't explore forever.  Perhaps we could set some kind of
deadline, and all vote on e.g. an official SCM and repository location.
(of course what people do privately is their own business -- this would
be about what is presented on the website to outside non-developers)

A similar argument can be made for the GUI.

\start
Date: Thu, 13 Apr 2006 14:40:35 -0700
From: Antoine Hersen
To: Pierre Doucy
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

Hello Pierre

Antoine, I very much agree with you... until you start saying that
> Emacs might do the trick ;-)


I am using emacs day and night lately , I might be biased ..

Emacs is indeed very portable, very powerful, but also extremely scary
> at first sight, in particular if you're not used to coding. Although
> it is not impossible to master it, it requires a lot of implication
> from the end user, which is not a good thing.


Not true ...
http://bc.tech.coop/blog/060302.html

I think if we use CUA( cut and paste like windows)
Hide everything scary, create menu and toolbox. Therefore dumbing down
emacs, write clear install direction maybe it will be manageable for
"normal" people ?


I would rather use eclipse which, from a certain point of view, is
> "emacs 30 years later" : the "interface for everything and nothing in
> particular" approach, plus a certain degree of "cleanliness".
> It may not be the sexiest of environments, but one can easily build a
> very powerful user interface without coding the whole thing from
> scratch.


That is an excellent possibility I overlook.
It is a strong choice, I dont think emacs will dye anytime soon but Eclispe
has surely a larger user base, strong corporate support and a modern look
and feel.

Some issue :

Interactive ability ?
we should look to Python and co plug-in to see what they do.

Displaying math ? Is there some work done there ?
I guess using latex back-end to generate png might be an option.

Managing noweb and latex, how much work will it be ?

Do yo want to investigate Pierre ?

In general how many people able to work on the project have good java skill
?
How many for elisp ?
I am sure we will be able to get other CAS interested to such a project.

I know by experience that Pierre is quite skilled in Java :)

Regards,

Antoine Hersen


On 4/13/06, Antoine Hersen wrote:
> > Hello,
> >
> > My experience is making a good UI is a lot of works( aka way more than
> you
> > imagine), especially if you go out the basic widget. ( I had a 30 line
> long
> > rent there ).
> >
> > Before choosing a solution we should set goals and there relative
> > importance. My try :
> >
> > + Attracting new user :
> >     - sexy look
> >    - toolbox
> >    - template
> >
> >  + Productive Environment :
> >     - easy to write pages long code :
> >          - pretty print
> >          - indentation
> >          - source code management
> >     - Good integration with the debugger
> >    - A easy work flown( edit, compile, test)
> >    - An know script langange( scheme, python)
> >
> > + Axiom specific
> >    - Ease the write of pamphlet( writing literate programs is a lot of
> added
> > work, that does not benefit the writer that much, so we should make it
> easy
> > as possible
> >
> > The candidates :
> > + Web based, Browser based : for Mozilla http://www.xulplanet.com/ mayb=
e
> > using MathML.
> > Personally I have mixed fealling,  it is very hip and I will like for
> the
> > tools to mature( think about Java UI for exemple Map... )
> >
> > + TeXmacs, the screenshot does looks good.
> >
> > + My big favorite imaxima :
> > http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html
> >
> >  Why :
> > Emacs work everywhere, with extensive menu an icon it is not that scary=
.
> >
> > We should be able to manage pamphlet in a elegant way. And think about
> > everything that is already included, source code management, non variou=
s
> > charset ....
> >
> > And very powerful and well documented language elisp !!!!
> >
> > + Start from scratch ( using http://mcclim.cliki.net/index )
> >
> > Other issue( I am sure it has been discussed before) :
> >   - Improved documentation browser aware of pamphlet
> >   - Improved plot 2D, 3D viewer.
> >
> > Some of this issue are problems common to all open source CAS, common
> > solution will have more hands working on it.

\start
Date: Thu, 13 Apr 2006 17:53:16 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: User interface, TeXmacs and Axiom (was: Re: backups)

On Thursday, April 13, 2006 5:41 PM Antoine Hersen wrote:

> Not true ...
>
> http://bc.tech.coop/blog/060302.html

I love it! :) Thanks.
	
> I think if we use CUA( cut and paste like windows) Hide
> everything scary, create menu and toolbox. Therefore
> dumbing down emacs, write clear install direction maybe
> it will be manageable for "normal" people ?

Although the only thing I can think of when I set down at a
unix console is 'vi', even I could be persuaded to live with
the 'xemacs' gui. ;)

\start
Date: Fri, 14 Apr 2006 00:09:19 +0200
From: Pierre Doucy
To: Bill Page
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

>
> I would very much like to know more about the possibility
> of using eclipse for this purpose. But nearly everything
> I have read about eclipse on the web has tended to turn
> me off. Although there appears to be an emphasis on open
> source in the eclipse projects, the content of the web
> sites I have visited tend to look more like commerical
> java promotional material from the IBM-era than "real life".
> ;)

That's right, IBM actually put a lot of money and effort into eclipse,
and want us to know about that. But using it everyday these times, I
have to admit that they did a very good job.

>
> But maybe I don't have the right information. Can you
> suggest a place to get more information about eclipse?
> Where and how to download it? How to use it for somethig
> approximating emacs? In general a good source of information?
>

http://www-128.ibm.com/developerworks/opensource/library/os-ecplug/?Open&ca=
=daw-ec-dr
is a good start for writing eclipse plugins.

This one is also great :
http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html
it teaches how to create a perspective

How to write a debugger for eclipse :
http://www.eclipse.org/articles/Article-Debugger/how-to.html

And this is the page where you can find lots of technicle articles.
http://www.eclipse.org/articles/index.html

And this is the documentation for users :
http://www.eclipse.org/documentation/main.html

To download it, click the huge "Eclipse SDK 3.1.2" link here :
http://www.eclipse.org/downloads/
Un{zip|tar} it, launch the executable, and you're on !

As is, you really won't do much except edit java code, but you can add
tons of plug-ins to do everything from UML modeling to regexp
debugging, etc...

\start
Date: Thu, 13 Apr 2006 18:25:53 -0400
From: Bill Page
To: Pierre Doucy
Subject: Eclipse (was: User interface,TeXmacs and Axiom)

On Thursday, April 13, 2006 6:09 PM Pierre Doucy wrote:
> ...
> To download it, click the huge "Eclipse SDK 3.1.2" link here :
> http://www.eclipse.org/downloads/
> Un{zip|tar} it, launch the executable, and you're on !
> ...
> Hope that helps
>

\start
Date: Fri, 14 Apr 2006 00:25:58 +0200
From: Pierre Doucy
To: Antoine Hersen
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

On 4/13/06, Antoine Hersen wrote:
> Hello Pierre
>
>
> > Antoine, I very much agree with you... until you start saying that
> > Emacs might do the trick ;-)
>
>
> I am using emacs day and night lately , I might be biased ..
>
> > Emacs is indeed very portable, very powerful, but also extremely scary
> > at first sight, in particular if you're not used to coding. Although
> > it is not impossible to master it, it requires a lot of implication
> > from the end user, which is not a good thing.
>
>
> Not true ...
> http://bc.tech.coop/blog/060302.html
>  I think if we use CUA( cut and paste like windows)
> Hide everything scary, create menu and toolbox. Therefore dumbing down
> emacs, write clear install direction maybe it will be manageable for
> "normal" people ?
>

The thing is, there are no installation directions. Eclipse is self
contained (much like an OSX app) so you copy it somewhere, click the
executable, and voila !
But stripping it down to the bare minimum for axiom would be a good
idea (i.e. the eclipse kernel + the axiom plugin).

>
>
> > I would rather use eclipse which, from a certain point of view, is
> > "emacs 30 years later" : the "interface for everything and nothing in
> > particular" approach, plus a certain degree of "cleanliness".
> > It may not be the sexiest of environments, but one can easily build a
> > very powerful user interface without coding the whole thing from
> > scratch.
>
>
> That is an excellent possibility I overlook.
> It is a strong choice, I dont think emacs will dye anytime soon but Eclis=
pe
> has surely a larger user base, strong corporate support and a modern look
> and feel.
>
> Some issue :
>
> Interactive ability ?
> we should look to Python and co plug-in to see what they do.

jython ( http://www.jython.org ) or jruby ( http://jruby.sf.net )
should do the trick...

>
> Displaying math ? Is there some work done there ?
> I guess using latex back-end to generate png might be an option.

that
www.esr.ruhr-uni-bochum.de/VCLab/software/HotEqn/HotEqn.html
might help (beware, it tends to crash mozilla-based browsers)

>
> Managing noweb and latex, how much work will it be ?

Noweb shouldn't be too difficult to handle. Even a complete java
rewrite is feasible.

Latex is quite a different matter. If HotEqn isn't enough, that might
become a dependency (which is bad).

>
> Do yo want to investigate Pierre ?

Yep, but I won't be able to until the beginning of may.

>
> In general how many people able to work on the project have good java ski=
ll
> ?
> How many for elisp ?
> I am sure we will be able to get other CAS interested to such a project.
>
> I know by experience that Pierre is quite skilled in Java :)

I perfectly know what you're talking about. That whole xml
serialization stuff was a mistake. I apologize. (private joke).

Pierre

>
> Regards,
>
> Antoine Hersen
>
>
>
> > On 4/13/06, Antoine Hersen wrote:
> > > Hello,
> > >
> > > My experience is making a good UI is a lot of works( aka way more tha=
n
> you
> > > imagine), especially if you go out the basic widget. ( I had a 30 lin=
e
> long
> > > rent there ).
> > >
> > > Before choosing a solution we should set goals and there relative
> > > importance. My try :
> > >
> > > + Attracting new user :
> > >     - sexy look
> > >    - toolbox
> > >    - template
> > >
> > >  + Productive Environment :
> > >     - easy to write pages long code :
> > >          - pretty print
> > >          - indentation
> > >          - source code management
> > >     - Good integration with the debugger
> > >    - A easy work flown( edit, compile, test)
> > >    - An know script langange( scheme, python)
> > >
> > > + Axiom specific
> > >    - Ease the write of pamphlet( writing literate programs is a lot o=
f
> added
> > > work, that does not benefit the writer that much, so we should make i=
t
> easy
> > > as possible
> > >
> > > The candidates :
> > > + Web based, Browser based : for Mozilla http://www.xulplanet.com/ ma=
ybe
> > > using MathML.
> > > Personally I have mixed fealling,  it is very hip and I will like for
> the
> > > tools to mature( think about Java UI for exemple Map... )
> > >
> > > + TeXmacs, the screenshot does looks good.
> > >
> > > + My big favorite imaxima :
> > >
> http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html
> > >
> > >  Why :
> > > Emacs work everywhere, with extensive menu an icon it is not that sca=
ry.
> > >
> > > We should be able to manage pamphlet in a elegant way. And think abou=
t
> > > everything that is already included, source code management, non vari=
ous
> > > charset ....
> > >
> > > And very powerful and well documented language elisp !!!!
> > >
> > > + Start from scratch ( using http://mcclim.cliki.net/index )
> > >
> > > Other issue( I am sure it has been discussed before) :
> > >   - Improved documentation browser aware of pamphlet
> > >   - Improved plot 2D, 3D viewer.
> > >
> > > Some of this issue are problems common to all open source CAS, common
> > > solution will have more hands working on it.
> > >
> > > PS : About debugging it is mostly a language tools issue,

\start
Date: Thu, 13 Apr 2006 17:15:58 -0700
From: Bob McElrath
To: Pierre Doucy
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

Pierre Doucy [Pierre Doucy] wrote:
> > Displaying math ? Is there some work done there ?
> > I guess using latex back-end to generate png might be an option.
> 
> that
> www.esr.ruhr-uni-bochum.de/VCLab/software/HotEqn/HotEqn.html
> might help (beware, it tends to crash mozilla-based browsers)
> 
> > Managing noweb and latex, how much work will it be ?
> 
> Noweb shouldn't be too difficult to handle. Even a complete java
> rewrite is feasible.

Warning: expect violent opposition.

$ apt-get install eclipse
$ eclipse

... Error:
JVM terminated. Exit code=127
/usr/lib/kaffe/pthreads/bin/java
-Djava.library.path=/usr/lib/jni
-Dgnu.gcj.precompiled.db.path=/var/lib/gcj-4.0/classmap.db
-Dgnu.gcj.runtime.VMClassLoader.library_control=never
-Dosgi.locking=none
-jar /usr/share/eclipse/startup.jar
-os linux
-ws gtk
-arch x86
-launcher /usr/lib/eclipse/eclipse
-name Eclipse
-showsplash 600
-exitdata 222c800c
-install /usr/share/eclipse
-vm /usr/lib/kaffe/pthreads/bin/java
-vmargs
-Djava.library.path=/usr/lib/jni
-Dgnu.gcj.precompiled.db.path=/var/lib/gcj-4.0/classmap.db
-Dgnu.gcj.runtime.VMClassLoader.library_control=never
-Dosgi.locking=none
-jar /usr/share/eclipse/startup.jar 

Maybe I'm horribly stupid, but this kind of shit makes me hate java with
a passion.

That, and your HotEqn stuff doesn't work either.

I've reinstalled java 1000 times and occasionally I can get something to
work.  But, I have better things to do with my time.

\start
Date: Thu, 13 Apr 2006 20:20:27 -0700
From: Antoine Hersen
To: list
Subject: User Profiles

Hello,

In the on going discussion about the UI I think we need to know what
problems we are trying to solve and especially for whom.

It will be interesting to create some user profiles, they will have a name
and cool and positive biography.
They are not complete or exhaustive just representative at best.
All are possible CAS user but maybe not prime target for Axiom, should they
be or not ? Such profiles will help us discuss those questions.

Why is it interesting to have such profile. It help to put names on categor=
y
of user find way to attract more people to the project.

I have started a page http://wiki.axiom-developer.org/UserProfiles that is
just an example I am half clueless about it.
So please please go modify it, change names, add persona, expend, cut,
correct, comments.

We could also imagine creating a web survey for current and possible user ?

Regards,
Antoine Hersen

I got A in Marketing 10 :)

\start
Date: Fri, 14 Apr 2006 00:24:32 -0400
From: Raymond Rogers
To: Pierre Doucy, Antoine Hersen
Subject: Re: User interface, TeXmacs and Axiom

Bob McElrath wrote:
> Pierre Doucy [Pierre Doucy] wrote:
>>> Displaying math ? Is there some work done there ?
>>> I guess using latex back-end to generate png might be an option.
>> that
>> www.esr.ruhr-uni-bochum.de/VCLab/software/HotEqn/HotEqn.html
>> might help (beware, it tends to crash mozilla-based browsers)
>>
>>> Managing noweb and latex, how much work will it be ?
>> Noweb shouldn't be too difficult to handle. Even a complete java
>> rewrite is feasible.
> 
> Warning: expect violent opposition.
> 
> $ apt-get install eclipse
> $ eclipse
> 
> .... Error:
I am running FC5 and had no problem.  I forget whether it came in the distribution or I yum(med) it
in.  I think the later.

\start
Date: Fri, 14 Apr 2006 10:04:31 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: re: User interface,TeXmacs and Axiom

On 04/13/2006 10:01 PM, C Y wrote:
> --- Bill Page wrote:
>> On Thursday, April 13, 2006 3:41 PM Antoine Hersen wrote:
>>> ...	
>>> The candidates :
>>> ...
>>> + My big favorite imaxima :
>>> http://members3.jcom.home.ne.jp/imaxima/Site/Welcome.html
>>>
>>> Why :
>>> Emacs work everywhere, with extensive menu an icon it is
>>> not that scary.
>> +1
>>
>> Yes, I think such a tool for Axiom would be great!
>>
>> Who can we get to work on this?
> 
> I'm poking at it a little, but I'm not planning on adding the graphical
> output of Imaxima for quite a while - that's non-trivial and I'm not
> sure it works on Windows.

I've browsed a bit through it... and to me Imath looks somewhat similar 
to preview-latex (http://www.gnu.org/software/auctex/preview-latex).

Maybe if Axioms TeX output is rendered via preview-latex it would give 
the same result. (Sorry, I have no idea how to do this.)

And another remark... Many of us are (X)Emacs users, but you cannot 
expect from an ordinary Axiom User to know all the Emacs stuff. So we 
should not force users to learn Emacs if they just want to use Axiom.

\start
Date: Fri, 14 Apr 2006 10:37:13 +0200
From: David Mentre
To: Antoine Hersen
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

Hello Antoine,

2006/4/13, Antoine Hersen:
> My experience is making a good UI is a lot of works( aka way more than yo=
u
> imagine)

My own experience is the same as yours.

> Before choosing a solution we should set goals and there relative
> importance. My try :

Nice summary. Could you put this on the Wiki and post the URL here?

Regarding Emacs, Eclipse, TeXmacs, ... None of them convinced me
entirely (I'm an Emacs user, reading mail and news and coding with
Emacs). Regarding Axiom, Common Lisp is a known (and standardized)
scripting language, with a lot of documentation, tutorials and
external libraries. Axiom is already written in Common Lisp, so it
would reduce the number of languages to standardize our tools on it.

You have underline an important point: we must use external
codes/projects because we can't reinvent the wheel. But we also have
our own long term objectives, that require a certain level of quality.
External code will never match exactly what we need, so we must
choose, on each specific case, whether we reuse an existing solution
or re-invent one that suites better our needs.

\start
Date: Fri, 14 Apr 2006 11:09:09 +0200
From: Ralf Hemmecke
To: list
Subject: re: User interface,TeXmacs and Axiom

On Thursday, April 13, 2006 4:37 PM Bob McElrath wrote:
> I worry a lot this group is bifurcating more than it is
> collaborating.

Me too, but please help to do something against it. For example, 
somebody could collect a list of all the various archives we now have to 
  access the Axiom sources.

CVS, SVN, TLA, Darcs?, etc.

Who could create that site?

I've only found http://wiki.axiom-developer.org/ArchUsage
and
http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers
so far, but it needs more structure and just ONE page with all the 
access methods.

Every branch MUST have a responsible maintainer. If there is none than 
this branch is dead and should be removed so that no newcomer is 
intimitated by this amount of branches.

\start
Date: Fri, 14 Apr 2006 11:11:34 +0200
From: Ralf Hemmecke
To: list
Subject: Glossary

In order to start bringing AxiomWiki more into the shape of a book, I 
have started

http://wiki.axiom-developer.org/SandBoxGlossary

Feel free to add/edit something there.

Could someone tell me why

   **[Aldor]**

doesn't show in boldface?

\start
Date: Fri, 14 Apr 2006 11:15:32 +0200
From: Ralf Hemmecke
To: Pierre Doucy
Subject: re: User interface,TeXmacs and Axiom

On 04/13/2006 11:06 PM, Pierre Doucy wrote:
> Even if diversity is a good thing, Bob has a point.
> That's very good news if people want to hack stuff around Axiom, but
> it there is not a clear line, like an official GUI, an official SCM,
> etc...
> 
> I must admit that Axiom's offering is confusing. I don't think
> newcomers (and people in general) like to have the choice. The first
> time I came across axiom, I wanted a quick way to give it a try, not
> having to make endless decisions without really knowing which is best.

You get my support. In the mail where I suggested to create a website 
with all the different SCM's and how to get and work on Axiom, it should 
clearly be stated which one it the preferred method.

We now have already something with Gold and Silver, but it's not yet 
written clearly somewhere except (a bit) on

http://wiki.axiom-developer.org/SandBoxActiveAxiomDevelopers

but that is surely not the right place for it.

\start
Date: Fri, 14 Apr 2006 11:35:54 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

On 04/13/2006 11:53 PM, Page, Bill wrote:
> On Thursday, April 13, 2006 5:41 PM Antoine Hersen wrote:
> 
>> Not true ...
>>
>> http://bc.tech.coop/blog/060302.html
> 
> I love it! :) Thanks.

I like that, too! ;-)

\start
Date: Fri, 14 Apr 2006 08:07:38 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: re: User interface,TeXmacs and Axiom

--- Ralf Hemmecke wrote:

> >> Who can we get to work on this?
> > 
> > I'm poking at it a little, but I'm not planning on adding the
> > graphical output of Imaxima for quite a while - that's non-trivial
> > and I'm not sure it works on Windows.
> 
> I've browsed a bit through it... and to me Imath looks somewhat
> similar to preview-latex
> (http://www.gnu.org/software/auctex/preview-latex).
> 
> Maybe if Axioms TeX output is rendered via preview-latex it would
> give the same result. (Sorry, I have no idea how to do this.)

Yes, for a number of features it is desirable to have tex output
rendered.

My biggest question on doing this is if there is any way to re-set
Axiom's line numbers.  The way I have in mind is admittedly a hack but
should work fine for most purposes, but in order for it to be
"transparent" to the user I need to be able to "roll back" the Axiom
line number to where it was before I start my "internal" TeX work.  In
Maxima there is a variable which holds the current line number and we
re-set that - is there a similar mechanism in Axiom?

Alternatively, a way to send "non-line-based" input that is evaluated
outside the traditional input-output pair scheme would work, too.

> And another remark... Many of us are (X)Emacs users, but you cannot 
> expect from an ordinary Axiom User to know all the Emacs stuff.

I'll agree with the sentiment that we need one "official" GUI for most
uses, but that doesn't mean that an Emacs interface is in opposition to
that goal.

Axiom, in its current state, is much more for programmers and
developers than for end users.  An Emacs inteface which helps those
people seems like a logical step at this time.  An "official" GUI, of
sufficient quality to be worthy of the Axiom project, is EXTREMELY
non-trivial and will need some components that are still in development
elsewhere (the STIX Fonts being an example.)  There is no clear winner
in the best way to do a GUI, and given the number of other tasks we
need to complete I'm not sure worrying about an end user level GUI is
important yet.  I posted a link a while back to a thesis done on CAS
GUI design - I would want to read and understand that before I start
doing anything serious.  I have my biases like anyone else, the primary
ones being:

1) I don't care to use a web browser as a primary GUI for anything - I
love Bill's work on the Axiom webpages, but I prefer a local GUI
program for my "primary" use.  This probably makes me a dinosaur, but
oh well. 

2) I like the idea of a Lisp based GUI, even though my idea of an
optimal solution would require libraries only just being started.

Either or both of these notions may be nonsense, but they explain my
interest in things like McCLIM, Garnet, cl-typesetting, etc.

> So we should not force users to learn Emacs if they just want to
> use Axiom.

I agree.  However, the kind of interface the modern CAS user expects
will take a LOT of non-trivial work, and there is not likely to be much
of a concensus on the "best" way to do it.  Also, before we do a GUI we
would probably need to bring B-natural or something like it to
maturity.

\start
Date: Fri, 14 Apr 2006 08:21:45 -0700 (PDT)
From: Cliff Yapp
To: David Mentre, Antoine Hersen
Subject: Re: User interface, TeXmacs and Axiom (was: Re: backups)

--- David Mentre wrote:

> Hello Antoine,
> 
> 2006/4/13, Antoine Hersen:
> > My experience is making a good UI is a lot of works( aka way more
> > than you imagine)
> 
> My own experience is the same as yours.

Amen.

> > Before choosing a solution we should set goals and there relative
> > importance. My try :
> 
> Nice summary. Could you put this on the Wiki and post the URL here?

Agreed - good summary.

> Regarding Emacs, Eclipse, TeXmacs, ... None of them convinced me
> entirely (I'm an Emacs user, reading mail and news and coding with
> Emacs). Regarding Axiom, Common Lisp is a known (and standardized)
> scripting language, with a lot of documentation, tutorials and
> external libraries. Axiom is already written in Common Lisp, so it
> would reduce the number of languages to standardize our tools on it.

Agreed.

> You have underline an important point: we must use external
> codes/projects because we can't reinvent the wheel. But we also have
> our own long term objectives, that require a certain level of
> quality.

My thought on this is to try and pick the best external tool available,
use it, and as time and resources become available bring it up to our
own quality standards.  Admittedly just a thought, at the moment.

> External code will never match exactly what we need, so we must
> choose, on each specific case, whether we reuse an existing solution
> or re-invent one that suites better our needs.

True.

\start
Date: Fri, 14 Apr 2006 19:19:38 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: re: User interface,TeXmacs and Axiom

> Axiom, in its current state, is much more for programmers and
> developers than for end users.  An Emacs inteface which helps those
> people seems like a logical step at this time.

Hmmm, at first I thought you are right. But what does it mean to have an 
axiom interface for developers? If you develop a package you write some 
Aldor (instead of SPAD) code. The only thing you would need is a support 
to load your package into axiom. But that is nothing. If you work with 
Axiom you are a user.

> An "official" GUI, of sufficient quality to be worthy of the Axiom project,
> is EXTREMELY non-trivial.

That should become part of the WishList and after a while it should 
develop into a project description where somebody could start to work on it.

>> So we should not force users to learn Emacs if they just want to
>> use Axiom.

> I agree.  However, the kind of interface the modern CAS user expects
> will take a LOT of non-trivial work, and there is not likely to be much
> of a concensus on the "best" way to do it.

Well, one thing I would start with is a description of what features we 
would like that GUI to have. The implementation or what tools/languages 
is then used to implement it is a completely different issue.
And maybe after we have a proper problem description, we should contact 
open source developers that are knowledgable in GUI building in order to 
implement our whishes. I think, just saying "we need a 'nice' GUI" is 
not enough. We could talk forever.

It seems that you are one of the people with much interest in GUI. Start 
a Wiki and try to collect opinions, wishes, ideas, links to relevant 
papers. That all should finally become a problem description.

Yes, we need something like that also for other subprojects.

Kai Kaminski made a kind of project description on the wiki before he 
started.

http://wiki.axiom-developer.org/AxiomUI

We should have this for any subproject, together with a list of all 
these subprojects.

> Also, before we do a GUI we would probably need to bring B-natural
 > or something like it to maturity.

Well, I think a prerequisite of this is that Aldor gets support for 
reflections. And a prerequisite of that is that the aldor compiler 
becomes open source or at least that there is a developer at aldor.org 
who implements reflections.

\start
Date: Fri, 14 Apr 2006 11:40:50 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: re: User interface,TeXmacs and Axiom

--- Ralf Hemmecke wrote:

> > Axiom, in its current state, is much more for programmers and
> > developers than for end users.  An Emacs inteface which helps those
> > people seems like a logical step at this time.
> 
> Hmmm, at first I thought you are right. But what does it mean to
> have an axiom interface for developers? If you develop a package you
> write some Aldor (instead of SPAD) code. The only thing you would
> need is a support to load your package into axiom. But that is
> nothing. If you work with Axiom you are a user.

True, in a way.  I guess I was thinking "working for the sake of
creating a good CAS" vs. "working to use the CAS to solve other
problems".  That's still fuzzy though - for mathematical research work
they might be the same thing!

Anyway, Emacs seems a popular tool for the "working for the sake of a a
better CAS" crowd (which is what we are at this time).

> > An "official" GUI, of sufficient quality to be worthy of the
> > Axiom project, is EXTREMELY non-trivial.
> 
> That should become part of the WishList and after a while it should 
> develop into a project description where somebody could start to work
> on it.

Right.

> Well, one thing I would start with is a description of what features
> we  would like that GUI to have. The implementation or what
> tools/languages is then used to implement it is a completely
> different issue. And maybe after we have a proper problem
description, 
> we should contact open source developers that are knowledgable in GUI
> building in order to implement our whishes. I think, just saying "we
> need a 'nice' GUI" is not enough. We could talk forever.

True.  OK, if we want to be more specific, a while back I outlined a
few ideas for a CAS GUI here, and a couple more were added: 

http://maxima.sourceforge.net/wiki/index.php/CY%27s%20conceptual%20stuff

(was thinking Maxima, but works for any CAS)

I have some of that stuffed into my portal site somewhere - I should
spruce it up and put it in the WIKI.  Obviously those are just a few
drops in an ocean, but it's something.

> It seems that you are one of the people with much interest in GUI.
> Start a Wiki and try to collect opinions, wishes, ideas, links to
> relevant papers. That all should finally become a problem
description.

Sounds like a plan.  I'll see what I can do.  I have a couple papers on
plotting issues and techniques, besides the GUI design thesis - I think
there might be a bib file out there somewhere we could use as a
reference too.  I'll need to dig that out of my archives.

Pity there are no academic programs where this kind of thing could get
funded.  (In the US anyway.)

> Yes, we need something like that also for other subprojects.
> 
> Kai Kaminski made a kind of project description on the wiki before he
> started.
> 
> http://wiki.axiom-developer.org/AxiomUI
> 
> We should have this for any subproject, together with a list of all 
> these subprojects.

How many are there?  GUI, maybe the units stuff once I get it out of
hibernation, web based interfaces, JET code for differential equations,
others?

> > Also, before we do a GUI we would probably need to bring B-natural
>  > or something like it to maturity.
> 
> Well, I think a prerequisite of this is that Aldor gets support for 
> reflections. And a prerequisite of that is that the aldor compiler 
> becomes open source or at least that there is a developer at
> aldor.org who implements reflections.

Right.  Still, I suppose that need not stop the collection of ideas.

\start
Date: Fri, 14 Apr 2006 12:03:49 -0700
From: Bob McElrath
To: Cliff Yapp
Subject: re: User interface,TeXmacs and Axiom

C Y [Cliff Yapp] wrote:
> True.  OK, if we want to be more specific, a while back I outlined a
> few ideas for a CAS GUI here, and a couple more were added: 
> 
> http://maxima.sourceforge.net/wiki/index.php/CY%27s%20conceptual%20stuff
> 
> (was thinking Maxima, but works for any CAS)

Neat ideas!

I really like the parenthesis matching idea.  This is something Maple
needs badly.  Mathematica has it, but it also reflows the entire input
box when it does it -- something I abhor.

I also really like the folding parenthesis idea.  So much that I would
turn it on as default for anything longer than 2 lines.  I'm an expert
at getting Maple/Mathematica to generate truly gigantic expressions.

You show an example (Ex3) on that page that is similar to
Maple/Mathematica's visual inputs.  e.g. you type 'integrate' and it
puts up the limits, integrand and variable of integration as empty
boxes.  Then the user has to do a lot of keyboard and mouse gymnastics
to select each box and put the proper thing in it.  Instead, I would
suggest something more similar to latex.  e.g. if I type \int_a^bx~dx
it knows to put the x as the integrand, a and b as the limits, and x as
the variable of integration (where the '~d' cues for the variable of
integration).  A slightly different example would be
\int_{a+1}^{b-1}x~dx where the use of curly braces tells the interface
to keep putting things in the limit/superscript box until it sees the
'}'.  This prevents the user from having to move over to the arrow keys
or mouse to indicate that he's done typing the limit of integration.

Another idea I've mentioned before is to have meta-information in a
sidebar.  With a browser-based interface it is easy to use an
onMouseOver handler to display something about each subexpression
(and/or highlight it).  I think it would be most useful to display type
information "integer" or "polynomial" in a sidebar, and any assumptions
about it.

\start
Date: Fri, 14 Apr 2006 12:07:03 -0700
From: Simon Michael
To: list
Subject: Re: Glossary

> Could someone tell me why
> 
>   **[Aldor]**
> 
> doesn't show in boldface?

Hi.. Structured Text's ** doesn't work with brackets inside. You have to 
use HTML tags instead::

  <b>[Aldor]</b>

It works as you'd expect in Restructured Text, which doesn't yet support 
LaTeX (but might soon).

That looks like a useful page - note also you can generate that sort of 
thing automatically, showing eg. the page's first paragraph; here's an 
example: http://zopewiki.org/Glossary .

\start
Date: Fri, 14 Apr 2006 13:09:08 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Summer of Code is on again!

http://code.google.com/soc/

\start
Date: Fri, 14 Apr 2006 16:25:46 -0400
From: Bill Page
To: Simon Michael
Subject: re: Glossary

On April 14, 2006 5:12 AM Ralf Hemmecke wrote:
> 
> In order to start bringing AxiomWiki more into the shape of
> a book, I have started
> 
> http://wiki.axiom-developer.org/SandBoxGlossary
> 
> Feel free to add/edit something there.
> ...

Thanks, Ralf. I think that is very useful.

On April 14, 2006 3:07 PM Simon Michael wrote:
> 
> That looks like a useful page - note also you can generate 
> that sort of thing automatically, showing eg. the page's
> first paragraph; here's an 
> example: http://zopewiki.org/Glossary .
> 

Thanks, Simon. That is seriously cool. I installed that tidy
little DTML script here:

http://wiki.axiom-developer.org/SandBoxSiteGlossary

as a test. I think the result is quite impressive for an
automatically generated glossary. :)

What do you think Ralf? Perhaps both of these should have
links from the FrontPage?

\start
Date: Fri, 14 Apr 2006 16:41:20 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Summer of Code is on again!

On April 14, 2006 4:09 PM C Y wrote:
> ...
> Summer of Code is on again!
> 
> http://code.google.com/soc/
> 

Great! I think this was a great success last year. I hope
this year Axiom can directly participate in SoC instead of
working through a proxy organization. (Although I think
it was very generous of Heow Eide-Goodman at LispNYC
http://www.lispnyc.org/home.clp to help us out last
year by sub-sponsoring the AxiomUI project.)

http://wiki.axiom-developer.org/AxiomUI

For information about registering as a mentoring organization
see:

http://code.google.com/soc/mentorfaq.html#7

7. How should a mentoring organization submit their application
to Summer of Code 2006?

Please email the SoC program administrators at

   soc2006support@google.com

to advise Google of your interest. We will notify you of
acceptance or rejection as soon as possible. Please ensure
that your organization meets all eligibility requirements
outlined in this FAQ and our Terms of Service before applying. 

-------

So, who wants to draft the the email? :)

I guess we should review and update out Summer Of Code page
at:

http://wiki.axiom-developer.org/SummerOfCode

and related:

http://wiki.axiom-developer.org/WishList
http://wiki.axiom-developer.org/AwardOfBounties

\start
Date: Fri, 14 Apr 2006 14:41:11 -0700
From: Bob McElrath
To: Simon Michael
Subject: re: Glossary

Simon Michael [Simon Michael] wrote:
> >Could someone tell me why
> >
> >  **[Aldor]**
> >
> >doesn't show in boldface?
> 
> Hi.. Structured Text's ** doesn't work with brackets inside. You have to 
> use HTML tags instead::
> 
>  <b>[Aldor]</b>
> 
> It works as you'd expect in Restructured Text, which doesn't yet support 
> LaTeX (but might soon).

ReStructured Text is not an appropriate choice because:
    1) ReST treats anything within $dollar signs$ as RCS keywords and
    strips it (but this can be turned off)
    2) ReST has its own use for the backslash \.  It is an escape
    character that prevents ReST processing.  This seems incompatible
    with \begin{stuff}\end{stuff} and \[\] etc. as appears in latex.
    3) Math can in principle be included via the ReST directive syntax:
        .. latex:: x^2
    however this is very un-latex like.

So, like any input syntax, it is always possible to put math in and
process it with some tool, but it requires a perverse and un-latex like
syntax.  (see also MediaWiki, twiki, etc.)

\start
Date: Fri, 14 Apr 2006 18:30:10 -0700
From: Bob McElrath
To: list
Subject: new FORM paper

People here may be interested in this new paper today:

http://www.arxiv.org/abs/cs.SC/0604052

We describe the implementation of facilities for the communication with
external resources in the Symbolic Manipulation System FORM. This is
done according to the POSIX standards defined for the UNIX operating
system. We present a number of examples that illustrate the increased
power due to these new capabilities. 

\start
Date: Sat, 15 Apr 2006 12:14:04 +0200
From: David Mentre
To: list
Subject: ACL2 plugin for Eclipse

Hello,

In light of recent discussions on this list, here is an announcement
that might interest some axiom-developer@ readers. Some researchers have
written an Eclispe's plugin for ACL2. ACL2 is a proof assistant written
in Common Lisp. This package could show interested people :

 - how to integrate Common Lisp written software into Eclipse;

 - how to use Eclipse capabilities to enhance the Common Lisp software.

I'm personally not interested in Eclipse so I won't look further at this
software. 

\start
Date: Fri, 14 Apr 2006 17:22:35 -0400
From: Peter Dillinger
To: list
Subject: ACL2s mailing lists & new version

We have dubbed our Eclipse plug-in and ACL2 modifications "ACL2s" (for
"ACL2 Sedan").  More information is available on the web page:

http://naxos.cc.gt.atl.ga.us/acl2s/

We have also created some mailing lists specifically for this tool, so
that we don't have to spam official ACL2 lists with ACL2s-specific
topics or use ad-hoc collections of email addresses:  (some of you
have been pre-added to both subscribable lists and some to just
acl2s-announce; you have recieved a welcome messages for lists you
have been pre-subscribed to)

* https://mailman.cc.gatech.edu/mailman/listinfo/acl2s-announce
- Subscribe if you want to recieve announcements about new
  versions/features, etc.  (Major announcements will continue to be
  sent to acl2 lists.)

* https://mailman.cc.gatech.edu/mailman/listinfo/acl2s-help
- Subscribe if you want to read and/or contribute to discussions
  about ACL2s problems or design philosophies, etc.

* acl2s-bugs@cc.gatech.edu
- Destination for bug info, feature requests, or general comments.
  Goes to the authors only (for now, me & Pete Manolios)


For those interested, a new version has been released (plugin 0.4.1,
hooks 2.9.4-4), which includes Daron's latest CCG termination
analysis, some code cleanup and bug fixes.

\start
Date: Sat, 15 Apr 2006 12:41:01 -0400
From: Raymond Rogers
To: list
Subject: "make" suggestions for $AXIOM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While rebuilding and enduring my usual typos it occurred to me that

echo export AXIOM=`pwd`/mnt/$SYSNAME
echo 'export PATH=$AXIOM/bin:$PATH'

might be replaced by
. export AXIOM=`pwd`/mnt/$SYSNAME
. export PATH=$AXIOM/bin:$PATH'

Eliminating one source of error.
Alternately this seems to be used mostly by tangle, notangle and such.  A cursory examination
indicates that changing
$AXIOM/bin/lib to
 ../../bin/lib (or even ./) might work.

but the documentation might fail(: (or be simplified?)

If there is any interest I can try one (or both); I don't know which alternative would be more
compatible with the present style.

\start
Date: Sat, 15 Apr 2006 15:24:57 -0400
From: Raymond Rogers
To: Tim Daly
Subject: Re: FC5 success (well sort of)

not only doesn't it show up in the build output, but it is not even
there in src/hyper/Makefile Would you like a copy of the created
Makefile in src/hyper/ ? A lot of stuff happens, but not this.  Or you
could send me a copy of your Makefile.pamphlet; mine doesn't have
"chmod" .

Ray

root wrote:
> Raymond,
> 
> 
>> cd axiom
>> ./configure
>> make
>> should build and test
>> make install
>>
>> cd /usr/src/axiom/mnt/linux/bin
>> chmod a+x htsearch
> 
> This is odd. The src/hyper/Makefile explicitly does:
>      @chmod a+x ${OUTLIB}/htsearch
> which should make it executable. It is executable in my builds.
> Where does this happen to you?

\start
Date: Sat, 15 Apr 2006 21:38:11 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Glossary
Cc: Simon Michael

Hello,

>> http://wiki.axiom-developer.org/SandBoxGlossary

> Thanks, Ralf. I think that is very useful.

> On April 14, 2006 3:07 PM Simon Michael wrote:
>> That looks like a useful page - note also you can generate 
>> that sort of thing automatically, showing eg. the page's
>> first paragraph; here's an 
>> example: http://zopewiki.org/Glossary .

Well, at least my page started some useful discussion. ;-)

> Thanks, Simon. That is seriously cool. I installed that tidy
> little DTML script here:
> 
> http://wiki.axiom-developer.org/SandBoxSiteGlossary
> 
> as a test. I think the result is quite impressive for an
> automatically generated glossary. :)
> 
> What do you think Ralf? Perhaps both of these should have
> links from the FrontPage?

I have nothing against renaming SandBoxGlossary to [Glossary] and 
linking to it from the frontpage, but I think it would be a mistake to 
have [Site Index] and [Glossary] and [Site Map].

If you read the front page and see those three links. On which you would 
click?

For [Site Index] to become useful, there must be a [Conventions] site, 
where it is stated that a new page MUST start with a kind of "abstract" 
that is self-contained enough to be useful for a site-index.

However, I somehow feel that a Glossary does not need to describe ALL 
pages. If it were possible to specify on a page whether the first 
paragraph (and the page name) should go into the glossary or not, would 
be more appropriate, I think.

For example, I would not like to see all the IssueTracker stuff, and 
also the SandBox pages should not make it into the glossary.

Anyway, http://wiki.axiom-developer.org/SiteIndex makes it more easy to
go through the pages and restructure the AxiomWiki. Thank you, Simon and 
Bill.

So until, we have nice "first paragraphs" and a nice book structure, I 
am voting for SiteIndex and SiteMap. My SandBoxGlossary, will probably 
be removed later. I somehow like the autogenerated page more if the 
content on the corresponding pages is well done.

\start
Date: Sun, 16 Apr 2006 13:27:10 -0400
From: Tim Daly
To: Camm Maguire
Subject: configure.in.patch

Camm,

I'm rebuilding axiom on gcl-2.6.8pre and I noticed that Axiom is still
carrying this patch which I'd have thought would affect several GCL
system. Perhaps you want to put it into gcl-2.6.8?

--- configure.in	Sat Jan 15 14:17:17 2005
+++ configure.in.tpd	Tue Jan 17 09:32:15 2006
@@ -538,7 +538,7 @@
 	# results, and the version is kept in special file).
     
 	if test -r /etc/.relid -a "X`uname -n`" = "X`uname -s`" ; then
-	    system=MP-RAS-`${AWK} '{print $3}' /etc/.relid'`
+	    system=MP-RAS-`${AWK} '{print $3}' '/etc/.relid'`
 	fi
 	if test "`uname -s`" = "AIX" ; then
 	    system=AIX-`uname -v`.`uname -r`



\start
Date: Sun, 16 Apr 2006 18:52:54 +0200
From: Ralf Hemmecke
To: list
Subject: Re: [#284 axiom crashes for a Graebner basis.]

Hello Axiom developers,

I don't know how you feel...

But I somehow don't feel like answering such a simple mistake if I don't 
know to whom I answer. I somehow vote for the requirement to register 
before one can write something to a non-SandBox page or before 
submitting on IssueTracker.

Ralf

On 04/16/2006 04:18 PM, anonymous wrote:
> I try :
> 
> \begin{axiom}
> )expose LinGroebnerPackage
> P1 := HDMP ([a,b,c,d],Integer) := a*c+5*b*d - 7
> P2 := HDMP ([a,b,c,d],Integer) ;= a*d+b*c - 17
> computeBasis [P1,P2]
> \end{axiom}
> 
> and axiom is gone...

\start
Date: Sun, 16 Apr 2006 17:18:26 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: re: [#284 axiom crashes for a Graebner basis.]

Ralf,

On April 16, 2006 12:53 PM you wrote:
> 
> I don't know how you feel...
> 
> But I somehow don't feel like answering such a simple mistake 
> if I don't know to whom I answer. I somehow vote for the
> requirement to register before one can write something to
> a non-SandBox page or before submitting on IssueTracker.
> 

I don't have any problems answering someone who remains
anonymous either by choice or because they just don't
understand the wiki environment...

I worry that if we require registration that we will seriously
reduce the accessibility of this service to potential Axiom
users.

And the point remains that inspite of the typographical errors
this sequence of commands (after the typos are corrected) does
crash Axiom.

Regards,
Bill Page.

> > )expose LinGroebnerPackage
> > P1 := HDMP ([a,b,c,d],Integer) := a*c+5*b*d - 7
> > P2 := HDMP ([a,b,c,d],Integer) ;= a*d+b*c - 17
> > computeBasis [P1,P2]

\start
Date: Sun, 16 Apr 2006 20:06:13 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: axiom.risc

Camm,

This patch is NOT in 2.6.8pre. I just hand-patched it in. 

--- configure	2006-04-14 18:11:38.692002016 +0200
+++ configure.tpd	2006-04-14 18:17:23.868312995 +0200
@@ -6187,7 +6187,7 @@
 echo "configure:6188: checking emacs site lisp directory" >&5
 if [ "$EMACS_SITE_LISP" = "unknown" ] ; then
 	if [ "$EMACS" != "" ] ; then
-		EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l conftest.el 2>&1 | sed -e /Loading/d | sed -e /load/d `
+		EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l conftest.el 2>&1 | grep -v ^Warning: | sed -e /Loading/d | sed -e /load/d `
 	else
 		EMACS_SITE_LISP=""
 	fi

This is in 2.6.8pre, which alas has really been delayed too long now.

\start
Date: Mon, 17 Apr 2006 03:18:16 -0400
From: Tim Daly
To: list
Subject: --patch-48

axiom--main--1--patch-48 is in arch on axiom-developer.org
in cvs on savannah.nongnu.org
in cvs on sourceforge.net

it is not in svn on sourceforge.net as my svn client
does not understand ssh and i need to rebuild it.

t

=======================================================================
Summary: gcl-2.6.8pre, maple integration buglist
Keywords: 

20060416 tpd --patch-48
20060416 tpd Makefile remove gcl from lsp subdirectory when cleaning
20060416 tpd lsp/Makefile gcl-2.6.8pre.configure.patch applied
20060416 tpd Makefile noweb patches reverted due to missing tempfile fn
20060416 tpd src/input/Makefile add mapleok.input
20060416 tpd src/input/mapleok.input added
20060416 tpd Makefile noweb.src.shell.roff.mm.patch applied
20060416 tpd Makefile noweb.src.lib.toascii.nw.patch applied
20060416 tpd Makefile noweb.src.shell.toroff.patch applied
20060416 tpd Makefile noweb.src.shell.noroff.patch applied
20060416 tpd Makefile noweb.src.shell.roff.nw.patch applied
20060416 tpd Makefile noweb.src.shell.nonu.patch applied
20060416 tpd Makefile noweb.src.shell.cpif.patch applied
20060416 tpd Makefile noweb.src.lib.toascii.patch applied
20060416 tpd Makefile noweb.src.awk.totex.nw.patch applied
20060416 tpd Makefile noweb.src.awkname.patch applied
20060416 tpd lsp/Makefile gcl-2.6.8pre stanza created
20060416 tpd Makefile make litcmds conditional to stop duplicate copy
20060416 tpd Makefile GCLVERSION=gcl-2.6.8pre
20060416 tpd zips/gcl-2.6.8pre.cmpnew.gcl_cmpcall.lsp.patch created
20060416 tpd zips/gcl-2.6.8pre.cmpnew.gcl_cmpflet.lsp.patch created
20060416 tpd zips/gcl-2.6.8pre.unixport.init_gcl.lsp.in.patch created
20060416 tpd zips/gcl-2.6.8pre.unixport.makefile.patch created
20060416 tpd zips/gcl-2.6.8pre.h.linux.defs.patch created
20060416 tpd zips/gcl-2.6.8pre.configure.in.patch created
20060416 tpd zips/gcl-2.6.8pre.tgz created
20060412 gxv FAQ 40: Text entry fails in the hypertex browser window
20060412 fxl src/doc/endpaper removed 'final' option to hyperref
20060412 tpd Makefile fix clean stanza to delete subdirs
20060405 tpd src/input/bug10069 update documentation
20060405 tpd src/input/bug10069 remove duplicate cot(0.0)
20060404 tpd src/interp/bookvol5 *suppress-compiler-notes* t
20060404 tpd src/interp/bookvol5 *suppress-compiler-warnings* t
20060404 tpd src/interp/bookvol5 *compile-verbose* nil
20060402 gdr src/boot/Makefile \ennd -> \end typo fixed
20060331 gxv src/interp/macros.lisp fix bugs #114 and #196
20060307 tpd src/algebra/numtheor.spad minor syntactic edit in explanation
20060302 gxv src/algebra/sf.spad add doubleFloatFormat function
20060302 gxv src/interp/pf2sex.boot handle $useBFasDefault in float2sex
20060302 fxl src/doc/bookvol1 typo fixes
20060302 fxl Frederic Lehobey
20060216 axh src/hyper/Makefile add execute bit to htsearch, presea
20060216 axh Antoine.Hersen Antoine Hersen
20060211 gxv src/interp/foam_l.lisp fix PtrMagicEq final case
20060117 wsp lsp/Makefile missing quote mark in configure.in patch
20060116 mvz src/doc/book fix typo
20060116 mvz Matijs van Zuijlen
20060115 rxh src/interp/setq.lisp 2006 -> 2005
20060115 rxh README 2006 -> 2005
20060115 rxh src/algebra/Makefile add sort to findSpadFiles
20060115 rxh src/algebra/Makefile add sort to findBootstrapFiles
20060115 rxh Ralf Hemmecke
20060102 tpd src/interp/sys-pkg.lisp FOAD -> FOAM
20060102 tpd src/interp/bookvol5 add getenviron
20060102 tpd src/interp/bookvol5 add reclaim

\start
Date: Mon, 17 Apr 2006 17:00:39 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: --patch-48

Hi Tim,

Axiom does not compile for me on Debian testing. I think you have
applied one patch to configure.in but not to configure. Since gcl build
process does not generate configure from configure.in the build fails.
Applying the following patch (see zips/gcl-2.6.8pre.configure.in.patch)
corrects the problem (another way is to generate the configure script
with autoconf but EMACS_SITE_LISP patch is not applied).


--- lsp/gcl-2.6.8pre/configure  2006-04-17 16:26:00.584232250 +0200
+++ lsp/gcl-2.6.7/configure.new  2006-02-11 14:53:08.000000000 +0100
@@ -1711,7 +1711,7 @@
        # results, and the version is kept in special file).

        if test -r /etc/.relid -a "X`uname -n`" = "X`uname -s`" ; then
-           system=MP-RAS-`${AWK} '{print $3}' /etc/.relid'`
+           system=MP-RAS-`${AWK} '{print $3}' '/etc/.relid'`
        fi
        if test "`uname -s`" = "AIX" ; then

Cheers,

Greg


PS: I use the savannah cvs version --patch-48.

---------------------------------------------------------------------

Error returned:

checking for gcc... gcc
checking whether the C compiler (gcc -O2 -mtune=k8  ) works... yes
checking whether the C compiler (gcc -O2 -mtune=k8  ) is a
cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for gawk... gawk
checking system version (for dynamic loading)... checking for
makeinfo... makeinfo
./configure: line 2412: syntax error near unexpected token `('
./configure: line 2412: `    case "`(uname -sr) 2>/dev/null`" in'

\start
Date: Mon, 17 Apr 2006 11:11:23 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: --patch-48

checking... running a build from the sourceforge cvs now on debian. --t

\start
Date: Mon, 17 Apr 2006 17:28:01 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: --patch-48

Hi,

Another bad news. gcl-2.6.8pre, from axiom zips directory, does not
compile on Debian-amd64 (64bits OS and gcc 4.0.3). I will check out the
gcl-2.6.8pre from GCL cvs, investigate and inform Camm of these
failures.

Cheers,

Greg

Le lundi 17 avril 2006 =C3=A0 11:11 -0400, root a =C3=A9crit :
> checking... running a build from the sourceforge cvs now on debian. --t
>

\start
Date: 17 Apr 2006 12:28:39 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: axiom.risc

Greetings!

Tim, I just did a fresh checkout:

export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

and I see both the patch below and the relid patch in configure.in.
Am I missing something?

Take care,

Tim Daly writes:

> Camm,
> 
> This patch is NOT in 2.6.8pre. I just hand-patched it in. 
> 
> Tim
> 
> 
> 
> --- configure	2006-04-14 18:11:38.692002016 +0200
> +++ configure.tpd	2006-04-14 18:17:23.868312995 +0200
> @@ -6187,7 +6187,7 @@
>  echo "configure:6188: checking emacs site lisp directory" >&5
>  if [ "$EMACS_SITE_LISP" = "unknown" ] ; then
>  	if [ "$EMACS" != "" ] ; then
> -		EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l conftest.el 2>&1 | sed -e /Loading/d | sed -e /load/d `
> +		EMACS_SITE_LISP=`$EMACS -q -batch --no-site-file -l conftest.el 2>&1 | grep -v ^Warning: | sed -e /Loading/d | sed -e /load/d `
>  	else
>  		EMACS_SITE_LISP=""
>  	fi
> 
> This is in 2.6.8pre, which alas has really been delayed too long now.
> 
> 
> 

\start
Date: Mon, 17 Apr 2006 18:36:46 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: --patch-48

Hi,

Le lundi 17 avril 2006 =C3=A0 17:28 +0200, Vanuxem Gr=C3=A9gory a =C3=A9c=
rit :
> Hi,
>
> Another bad news. gcl-2.6.8pre, from axiom zips directory, does not
> compile on Debian-amd64 (64bits OS and gcc 4.0.3). I will check out the
> gcl-2.6.8pre from GCL cvs, investigate and inform Camm of these
> failures.


For information, lastest gcl-2.6.8pre from cvs compiles cleanly on
Debian-amd64. The sequence of commands to check it out was:

export CVSROOT=:pserver:anonymous@cvs.savannah.gnu.org:/sources/gcl
cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

\start
Date: Mon, 17 Apr 2006 12:35:41 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: axiom.risc

the likely explanation is that i made a mistake somewhere. sigh.
ok. i'll restart the patch cycle with a fresh gcl checkout.

\start
Date: Mon, 17 Apr 2006 12:39:19 -0400
From: Tim Daly
To: list
Subject: --patch-48

it appears that --patch-48 is flawed.
please do not use it.
a new patch will be avaiable soon.

\start
Date: Mon, 17 Apr 2006 23:56:34 -0400
From: Tim Daly
To: list
Subject: --patch-49

--patch-49 fixes --patch48 which used the wrong version of GCL.

this version works on debian (on the axiom-risc server).
please test it on other versions.

i tried to incorporate the debian patches from Camm but
they lack explanations so i am not sure why the changes 
are necessary.

this has been updated on arch, sourceforge and savannah.

t

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


Summary: fixed gcl-2.6.8pre to use the correct version
Keywords: 

20060417 tpd --patch-49
20060417 tpd zips/gcl-2.6.8pre.tgz updated
20060417 tpd zips/gcl-2.6.8pre.unixport.init_gcl.lsp.in.patch changed
20060417 tpd lsp/Makefile gcl-2.6.8pre.configure.patch reverted
20060417 tpd lsp/Makefile gcl-2.6.8pre.configure.in.patch reverted
20060417 rhx Ralf Hemmecke changed globally
20060417 tpd src/input/wester.input add )clear properties p
20060417 tpd src/input/Makefile fix dropt.input
20060417 tpd src/input/Makefile add zimmer.input
20060417 tpd src/input/zimmer.input fixed. 

\start
Date: Tue, 18 Apr 2006 11:42:43 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [AxiomDownload] 

Ralf,

I believe that it is/has been Tim Daly's procedure to first
update the tla archive, as and when patches are applied but
to only promote the code to CVS after more thorough testing -
about once every two months or so.  The same CVS is available
at both Savannah and Sourceforge, with sourceforge as a backup
site. So the tla archive is not always in synch with the CVS.
The tla archive is more current but less tested. Right, Tim?
Perhaps we should only call the CVS "gold".

I am not sure (yet) what we should say about the "silver" svn
version since it still seems highly experimental to me - at
least until we have an active maintainer of this version. As of
Tim's most recent patch-49, the code of the source in svn is out
of date.

Note that detailed information about how to use arch is available
elsewhere on the wiki at

http://wiki.axiom-developer.org/ArchUsage

although I guess it doesn't hurt to duplicate it a little.

Regards,
Bill Page.


On April 18, 2006 10:40 AM you wrote at

http://wiki.axiom-developer.org/AxiomDownload#msg20060418094013-0500@wiki=
.ax
iom-developer.org

> 
> ++added:
> +  * There are several ways to access the sources of Axiom:
> +
> +    * The CVS and tla archives are identical and refer to
> the Golden release of Axiom, i.e. the latest stable release.
> +
> +    * The SVN archive refers to the Silver release, i.e.
> this is the branch which is updated more often, but might be
> +    not so stable. Approximately every two months stable
> code moves from Silver to Gold.
> +
>    * The current Axiom source distribution is available via
>      CVS at:
>
>      * http://sourceforge.net/projects/axiom/
> ++added:
> +
> +  * A tla archive (GNU arch) can be obtained via::
> +
> +      tla my-id "Your Name <your@email-address.com>"
> +      tla register-archive arch@axiom-developer.org--axiom
> http://www.axiom-developer.org/archive/axiom
> +      tla my-default-archive arch@axiom-developer.org--axiom
> +      tla get axiom--main--1 GoldenAxiom
> +
> +      # later you would say the following in order to update
> +      cd GoldenAxiom
> +      tla update
> +
> +  * An svn archive (Subversion) can be obtained via::
> +
> +      svn co https://svn.sourceforge.net/svnroot/axiom/trunk =
SilverAxiom
> 

\start
Date: Tue, 18 Apr 2006 11:59:40 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [AxiomDownload]

> I believe that it is/has been Tim Daly's procedure to first
> update the tla archive, as and when patches are applied but
> to only promote the code to CVS after more thorough testing - 
> about once every two months or so.  The same CVS is available
> at both Savannah and Sourceforge, with sourceforge as a backup
> site. So the tla archive is not always in synch with the CVS.
> The tla archive is more current but less tested. Right, Tim?
> Perhaps we should only call the CVS "gold". 

Almost. The tla, sourceforge cvs, and savannah cvs are all updated
simultaneously with fully tested code.

> I am not sure (yet) what we should say about the "silver" svn
> version since it still seems highly experimental to me - at
> least until we have an active maintainer of this version. As of
> Tim's most recent patch-49, the code of the source in svn is out
> of date.

It is my intention that the sourceforge SVN golden branch will also
track the other three archives with fully tested code. Unfortunately
my SVN client cannot communicate with sourceforge yet because it
cannot speak ssh. I need to update my client.

\start
Date: Tue, 18 Apr 2006 18:06:09 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [AxiomDownload]

Hello Bill,

On 04/18/2006 05:42 PM, Bill Page wrote:
> Ralf,
> 
> I believe that it is/has been Tim Daly's procedure to first
> update the tla archive, as and when patches are applied but
> to only promote the code to CVS after more thorough testing - 
> about once every two months or so.  The same CVS is available
> at both Savannah and Sourceforge, with sourceforge as a backup
> site. So the tla archive is not always in synch with the CVS.
> The tla archive is more current but less tested. Right, Tim?
> Perhaps we should only call the CVS "gold".

Sorry for all the confusion that was introduced by my update of 
http://wiki.axiom-developer.org/AxiomDownload, but you see exactly this 
confusion should be resolved.

No, I would not call the CVS stuff "gold". We have blessed the gold and 
silver branches already. Let's call it "diamond". ;-)

Anyway, please let's make it completely clear what the release cycles of 
the various archives are. Otherwise nobody knows which source archive is 
good for which thing.

> I am not sure (yet) what we should say about the "silver" svn
> version since it still seems highly experimental to me - at
> least until we have an active maintainer of this version.
 > As of Tim's most recent patch-49, the code of the source in svn is out
> of date.

Well, I am actually also waiting for Gaby to post some more details 
about the process of how the development model for Axiom should be.

> Note that detailed information about how to use arch is available
> elsewhere on the wiki at
> 
> http://wiki.axiom-developer.org/ArchUsage
> 
> although I guess it doesn't hurt to duplicate it a little.

I know, and I also want to concentrate this to just one place, but we 
first should have a clear develepment model which includes a description 
of silver, gold, diamond or whatever.

Please let's reduce all this confusion. Suppose you are new to Axiom 
knowledgable in CVS and you want to contribute code to axiom. You look 
at FrontPage. AND THEN???

\start
Date: Tue, 18 Apr 2006 12:15:15 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: [AxiomDownload]

> Please let's reduce all this confusion. Suppose you are new to Axiom 
> knowledgable in CVS and you want to contribute code to axiom. You look 
> at FrontPage. AND THEN???

You should be able to fetch from tla or cvs and always get the latest
version of the system. I don't announce a new release until I've
"round-trip tested" (upload-destroy-download-compile-test) the sources.
There should be no confusion.

The actual, official state of your copy can be determined by looking
at the topmost entry in CHANGELOG. EVERY change to the system has a
journal entry in this file.

As for the SVN procedures that's really up to Gaby and the community
to decide. I have no opinion about it.

My mode of working will continue to be hand-merging (Naur) patch files that
get sent to me. If the group creates a silver branch that contains items
to be promoted we need to work out how this can be done. I should note
that it is vital to document the reasons for changes. I have been struggling
to merge Camm's debian changes because they don't have any documentation.

If I don't understand a change and can't test it I certainly won't merge it.
Otherwise the code quality "gets away from me".

\start
Date: Tue, 18 Apr 2006 13:16:13 -0400
From: Bill Page
To: Tim Daly
Subject: RE: [AxiomDownload]

On April 18, 2006 12:00 PM Tim Daly (root) wrote:
> ... 
> It is my intention that the sourceforge SVN golden branch
> will also track the other three archives with fully tested code.
> Unfortunately my SVN client cannot communicate with sourceforge
> yet because it cannot speak ssh. I need to update my client.
> 

Why do you need ssh? The protocol is https. No?

\start
Date: Tue, 18 Apr 2006 13:14:10 -0400
From: Tim Daly
To: Bill Page
Subject: Re: [AxiomDownload]

possibly not. the error from my SVN client was unclear and
i was guessing. i haven't taken the time to debug it yet.

\start
Date: Tue, 18 Apr 2006 13:28:08 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [AxiomDownload]

Ralf,

> On 04/18/2006 05:42 PM, Bill Page wrote:
> > Ralf,
> > 
> > I believe that it is/has been Tim Daly's procedure to first
> > update the tla archive, as and when patches are applied but
> > to only promote the code to CVS after more thorough testing - 
> > about once every two months or so.  The same CVS is available
> > at both Savannah and Sourceforge, with sourceforge as a backup
> > site. So the tla archive is not always in synch with the CVS.
> > The tla archive is more current but less tested. Right, Tim?
> > Perhaps we should only call the CVS "gold".
> 

Tim replied:

> The tla, sourceforge cvs, and savannah cvs are all updated
> simultaneously with fully tested code.

On April 18, 2006 12:06 PM you wrote:
> Sorry for all the confusion that was introduced by my update
> of http://wiki.axiom-developer.org/AxiomDownload, but you see 
> exactly this confusion should be resolved.
> 

So what you wrote is fine and my understanding of the process
was a little flawed. No problem.

> No, I would not call the CVS stuff "gold". We have blessed 
> the gold and silver branches already. Let's call it "diamond".
> ;-)

It seems just that one can obtain "gold" in more than one
way. :)

> 
> Anyway, please let's make it completely clear what the 
> release cycles of the various archives are. Otherwise
> nobody knows which source archive is good for which thing.

So far it seems that they are only good for one thing. ;)

> 
> > I am not sure (yet) what we should say about the "silver"
> > svn version since it still seems highly experimental to me -
> > at least until we have an active maintainer of this version.
> > As of Tim's most recent patch-49, the code of the source in
> > svn is out of date.
> 
> Well, I am actually also waiting for Gaby to post some more
> details about the process of how the development model for
> Axiom should be.

Yes. Is it also true that we have a "gold" branch in svn at
SourceForge?

> ... 
> Please let's reduce all this confusion. Suppose you are new
> to Axiom knowledgable in CVS and you want to contribute code
> to axiom. You look at FrontPage. AND THEN???
> 

This question is a good one although the scenario seems a little
doubtful to me (i.e. someone new to Axiom contributing code ...),
but I presume that before doing this they would first have at
least visited:

http://wiki.axiom-developer.org/BuildAxiom

which has a link to:

http://wiki.axiom-developer.org/AxiomDevelopment

There is a also a link there from FAQ.

Perhaps there should be a direct link from the FrontPage?

\start
Date: Tue, 18 Apr 2006 20:10:02 +0200
From: Gregory Vanuxem
To: list
Subject: "Please add new attributes" message when building aldor interface

Hi,


I have successfully built Axiom --patch-49 on my machine. And in the
process of building the Aldor interface (I followed the procedure
described in http://wiki.axiom-developer.org/AldorForAxiomissue) i
encountered the following undocumented issue:

the build process stopped with this message:

cp /usr/local/axiom/src/aldor/as/attrib.as.head  /usr/local/axiom/int/ald=
or/as/attrib.as
Please add new attributes to /attrib.as.head
make[1]: *** [/usr/local/axiom/int/aldor/as/attrib.as] Erreur 1
make[1]: *** Destruction du fichier
=C2=AB /usr/local/axiom/int/aldor/as/attrib.as =C2=BB
make[1]: quittant le r=C3=A9pertoire =C2=AB /usr/local/axiom/src/aldor =C2=
=BB

It seems that the build process stops to allow user to modify
attrib.as.head that contains attributes defined in the axiom library
(for example shallowMutable). Indeed the libaxiom.mk contains a "@false"
line 70. So I modified libaxiom.mk and commented out this "@false" and
the build completes without any problem. I successfully tested Aldor in
axiom with the sample provided. So my questions are: is it a known
issue ? Is the Aldor interface correct ? Am I alone with this issue ? Is
it normal that the build process stops (it's not documented on
Mathaction) ? Was src_aldor2.tgz changed (I did not encounter this issue
in the past)?

PS: I don't know if the following helps but I built Aldor interface in
two times (the first time I decompressed src_aldor2 in the axiom root
directory) and I use make version 3.81rc2

\start
Date: Tue, 18 Apr 2006 21:48:14 +0200
From: Ralf Hemmecke
To: list
Subject: Call for active participation

Hello friends of Axiom,

I'd like to invite you to improve Axiom's website

http://wiki.axiom-developer.org/

There is already quite a lot of information available, but it is perhaps 
not in a form that suits best the need of its users.

As you all know anyone can edit these pages and can improve them. Yes, 
also YOU can. But if you don't yet feel like editing pages in public, 
simply reply to that mail and tell us all what you like and dislike there.
(1) Which information should be more easily accessible?
(2) Which information you are constantly missing?
(3) Is the FrontPage good enough? Does it contain too much/too few 
information?
(4) What questions should be added to the FAQ page? (If you can manage, 
immediately enter your question there. Simply press the _edit_ link in 
the top right corner, enter your question and press SAVE.)
(5) ...

Please help. A better AXIOM depends on YOU.

Hope to hear from you

\start
Date: Tue, 18 Apr 2006 21:31:23 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Attempt at Emacs mode pamphlet

Cliff,

On April 18, 2006 8:25 PM you wrote:
> ...
> http://wiki.axiom-developer.org/SandBoxAxiomEmacsMode
> ... 
> The second part is a bug report for Bill - when I tried to create
> this web page, I got the following:
> 
> Some or all of this page may not have rendered properly, 
> because of the following error:
> 
> dvips: cd '/var/zope/var/LatexWiki/';
> /usr/local/teTeX/bin/i686-pc-linux-gnu/dvips -z
>  -o 'SandBox Axiom Emacs Mode.ps' 'SandBox Axiom Emacs Mode.dvi'
> This is dvips(k) 5.95a Copyright 2005 Radical Eye Software
> (www.radicaleye.com)
> /usr/local/teTeX/bin/i686-pc-linux-gnu/dvips: !
> DVI file can't be opened.
>

The problem is that the 'dvips' does not allow spaces in file
names. The pamphlet support on MathAction uses the page title
as an internal file name. It does this without checking for
spaces in the title. (This is a bug that I plan to fix soon.)
When you created the page you called it:

  SandBox Axiom Emacs Mode

and so the file name had spaces. I have changed the title to

 SandBoxAxiomEmacsMode

and now it works.

> Even more strangely, when I pressed the pdf link in the
> preview window of the editing form when I was uploading it,
> it seemed to work.

That is strange. I can't reproduce this behaviour.

> 
> One other minor quirk - I tried to use the upload-file option
> but I didn't quite see how to tell it to go ahead and upload - 
> Preview didn't do anything.  Probably just me :-/.
> 

I suppose it is confusing. The file upload option on the
bottom  of the edit page is probably not what you might
have expected it to be. The purpose is to upload a file
(such as an image) and create a link to the file in the
"structured text" part of the page.

A "pamphlet file" on mathaction consists of two parts: a
"document" part that contains the noweb source which will
be rendered as an attached pdf, dvi, or ps file; and a
"structured text" part that looks like other non-pamphlet
pages on the wiki:

  document part +
  structured text part

Both parts are optional but either one or the other (or
both) must be present.

If you add comments to a pamphlet page, these comments
are added to the structured text part of the page.
Similarly, if you you upload an image or binary file,
the link to that image or file is created in the
structured text part of the page.

The document part of the page begins with:

  \documentclass

and ends with:

  \end{document}

and as you might expect is treated as a noweb/latex document.
In addition, the structured text part of the page (if any)
follows '\end{document}'. The structured text part is
rendered directly as HTML like other pages on the wiki.
If no '\documentclass ... \end{document}' is present, then
the page is treated as consisting of structured text only.

The structured text part of the page may contain Axiom
commands and embedded LaTeX equations (but not LaTeX in
full generality like the document part).

I hope this is clear, but I probably need to describe this
better somewhere on the wiki. Right now the only good
description is here:

http://wiki.axiom-developer.org/210PamphletSupportOnMathAction

under "Revised Design".

\start
Date: Tue, 18 Apr 2006 22:22:40 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [AxiomDownload]

>> The tla, sourceforge cvs, and savannah cvs are all updated
>> simultaneously with fully tested code.

So my explanation on http://wiki.axiom-developer.org/AxiomDownload is right.

> It seems just that one can obtain "gold" in more than one
> way. :)

Good that this is now documented. However... the FrontPage says
"Axiom Binaries" and links to 
http://wiki.axiom-developer.org/AxiomDownload were now we have links to 
sources and binaries.

Maybe we should have AxiomDownloadBinary and AxiomDownloadSource. On the 
latter there would be this explanation of all the different access 
methods and a description of gold and silver flavours.

>> Anyway, please let's make it completely clear what the 
>> release cycles of the various archives are. Otherwise
>> nobody knows which source archive is good for which thing.

> So far it seems that they are only good for one thing. ;)

Hmm, let me guess...to rest there in silence? Gaby wanted to bring the 
barrier down for people to access and modify code. I added this 
paragraph on http://wiki.axiom-developer.org/AxiomDownload, because I 
wanted to make the sources more visible and in order to state the 
relations of all the different access methods. (There is still a link to 
ArchUsage missing...)

And... this question goes mostly to Tim, where on AxiomWiki is the 
procedure to submit patches to you (together with your quality 
requirements)?

>> Well, I am actually also waiting for Gaby to post some more
>> details about the process of how the development model for
>> Axiom should be.
> 
> Yes. Is it also true that we have a "gold" branch in svn at
> SourceForge?

Not even Gaby knows. Remember, he asked about that. Tim what would you say?

>> Please let's reduce all this confusion. Suppose you are new
>> to Axiom knowledgable in CVS and you want to contribute code
>> to axiom. You look at FrontPage. AND THEN???

> This question is a good one although the scenario seems a little
> doubtful to me (i.e. someone new to Axiom contributing code ...),
> but I presume that before doing this they would first have at
> least visited:
> 
> http://wiki.axiom-developer.org/BuildAxiom
> 
> which has a link to:
> 
> http://wiki.axiom-developer.org/AxiomDevelopment
> 
> There is a also a link there from FAQ.
> 
> Perhaps there should be a direct link from the FrontPage?

Let me suggest the following (but mind that I have not much experience 
with such things):

AxiomDevelopmentModel
This page should describe that we have a gold and silver branch, how 
they can be accessed and how one should submit changes. It should be 
explained that only sufficiently documented changes are accepted.
Furthermore it should link to ActiveDevelopmentBranches.


ActiveDevelopmentBranches
This should be similar to the list that is now on 
http://wiki.axiom-developer.org/ArchUsage
but also include the svn branches.
Most important here, branches without a maintainer do not show here.
Would be nice if this list is sorted by 'activeness'.

AxiomSources
Gives a list of places where to download the gold and silver versions.
Might also link to ActiveDevelopmentBranches.

AxiomBinaries
Gives a list of precompiled gold releases of Axiom.

Are there more/other ideas or suggestions?

\start
Date: Wed, 19 Apr 2006 08:49:55 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: re: Attempt at Emacs mode pamphlet

Hello,

>> dvips: cd '/var/zope/var/LatexWiki/';
>> /usr/local/teTeX/bin/i686-pc-linux-gnu/dvips -z
>>  -o 'SandBox Axiom Emacs Mode.ps' 'SandBox Axiom Emacs Mode.dvi'
>> This is dvips(k) 5.95a Copyright 2005 Radical Eye Software
>> (www.radicaleye.com)
>> /usr/local/teTeX/bin/i686-pc-linux-gnu/dvips: !
>> DVI file can't be opened.

> The problem is that the 'dvips' does not allow spaces in file
> names.

I have just taken an arbitrary foo.dvi and said

cp foo.dvi 'SandBox Axiom Emacs Mode.dvi'
dvips -z -o 'SandBox Axiom Emacs Mode.ps' 'SandBox Axiom Emacs Mode.dvi'

(The last thing is **exactly** as described in the error above.)
I get a .ps file (with spaces) on my Debian Sarge Linux box.

So if dvips is called with the quotation marks then that should be fine.

> I suppose it is confusing. 

> A "pamphlet file" on mathaction consists of two parts: a
> "document" part that contains the noweb source which will
> be rendered as an attached pdf, dvi, or ps file; and a
> "structured text" part that looks like other non-pamphlet
> pages on the wiki:
> 
>   document part +
>   structured text part
>
> Both parts are optional but either one or the other (or
> both) must be present.

Bill, that is, maybe worth another entry (AxiomWikiPageTypePamphlet or 
PamphletPageTypeAxiomWiki or both?) on 
http://wiki.axiom-developer.org/SandBoxGlossary?
Or better create a new page with a good first paragraph that can go 
automatically into the glossary.

> http://wiki.axiom-developer.org/210PamphletSupportOnMathAction 
> under "Revised Design".

Perfectly well hidden. ;-)

\start
Date: Wed, 19 Apr 2006 11:23:49 +0200
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: "Please add new attributes" message when building aldor interface

On 04/18/2006 08:10 PM, Vanuxem Gr=C3=A9gory wrote:
> Hi,
>
>
> I have successfully built Axiom --patch-49 on my machine. And in the
> process of building the Aldor interface (I followed the procedure
> described in http://wiki.axiom-developer.org/AldorForAxiomissue) i
> encountered the following undocumented issue:
>
> the build process stopped with this message:
>
> cp /usr/local/axiom/src/aldor/as/attrib.as.head  /usr/local/axiom/int/a=
ldor/as/attrib.as
> Please add new attributes to /attrib.as.head
> make[1]: *** [/usr/local/axiom/int/aldor/as/attrib.as] Erreur 1
> make[1]: *** Destruction du fichier
> =C2=AB /usr/local/axiom/int/aldor/as/attrib.as =C2=BB
> make[1]: quittant le r=C3=A9pertoire =C2=AB /usr/local/axiom/src/aldor =
=C2=BB
>
> It seems that the build process stops to allow user to modify
> attrib.as.head that contains attributes defined in the axiom library
> (for example shallowMutable). Indeed the libaxiom.mk contains a "@false=
"
> line 70. So I modified libaxiom.mk and commented out this "@false" and
> the build completes without any problem. I successfully tested Aldor in=

> axiom with the sample provided. So my questions are: is it a known
> issue ?

Item 9 on http://wiki.axiom-developer.org/AldorForAxiom
says...

     #  Build the Aldor interface

     Issue the following commands:

          $ cd aldor
          $ document Makefile.pamphlet
          $ make

     make stops with an error message. The next two steps correct the
     problem:

          $ touch ../../int/aldor/dep_spad.stamp
          $ document Make.functions.pamphlet

     Now complete build of the Aldor interface:

          $ make 2>&1 | tee aldor.log

     The build might take up to 2 hours or some machines.

I faintly remember that I did exactly that when I compiled the
interface. But I can tell you more when I rebuild it (which is not
likely in the next two weeks),

> Is the Aldor interface correct ?

I think so, but one never knows, since the whole stuff is more or less
completely undocumented. :-(

> Am I alone with this issue ? Is it normal that the build process stops =

 > (it's not documented on Mathaction) ? Was src_aldor2.tgz changed
 > (I did not encounter this issue in the past)?

Yes, the compilation stopped but not for the issue you described.
What you encountered should rather be seen as a feature than a bug.
So '@false' should remain there.

libaxiom.mk says
----BEGIN
# attrib.as - needs some special rules
# The second ensures that the build will fail if ATTREG.spad is modified.=


ALL_DIRS += $(MID)/as

$(MID)/as/attrib.as:: $(IN)/as/attrib.as.head $(MID)/as/.dir
	cp $(IN)/as/attrib.as.head  $@

$(MID)/as/attrib.as:: $(INT)/algebra/ATTREG.spad
	@echo "Please add new attributes to $(Ax0Dir)/attrib.as.head"
	@false
----END

So if ever ATTREG.spad changes the compilation stops. Hmm, that means it =

probably always stops if you do 'tla update' and recompile Axiom.
Maybe the dependency should rather be ATTREG.spad.pamphlet. But also
that does not sound correct, since I can simply modify the documentation =

without generating a different ATTREG.spad.

Probably the easiest thing would be to include the src_aldor2.tgz (in
extracted form) into the aldor distribution. Sure, you can only build
the interface, if you have Java around, but your problem would go away,
since whenever ATTREG.spad.pamphlet is modified one would modify
attrib.as.head appropriately BEFORE distributing new Axiom sources.
The timestamp of attrib.as should be newer than ATTREG.spad.

\start
Date: Wed, 19 Apr 2006 11:35:00 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: [AxiomDownload]

Hello Tim,

As you see, I have updated

   http://wiki.axiom-developer.org/FAQ

by taking some items from

   http://axiom.axiom-developer.org/axiom-website/faq.html

I hope, you don't mind. ;-)

> My mode of working will continue to be hand-merging (Naur) patch files that
> get sent to me.

Now it tells me only, how to send patches of single files to you.
What would be the procedure if my modification involves several files?
Remember people even might forget which files they actually modified. So 
how do they find out about all the different files. Would you use a 
'tla' command to create the patch? Maybe 'tla changeset'?

I would be happy if such a procedure gets added to the FAQ page.

\start
Date: Wed, 19 Apr 2006 14:48:29 +0200
From: Ralf Hemmecke
To: list
Subject: Axiom bibliography

Hello,

I just stumbled over this site.

http://liinwww.ira.uka.de/bibliography/Math/axiom.html

Maybe the original source

http://www.math.utah.edu:8080/pub/tex/bib/axiom.bib

might be interesting for the Axiom-References page.

\start
Date: Wed, 19 Apr 2006 09:29:07 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Axiom bibliography

Ralf,

On April 19, 2006 8:48 AM you wrote:
> 
> I just stumbled over this site.
> 
> http://liinwww.ira.uka.de/bibliography/Math/axiom.html
> 
> Maybe the original source
> 
> http://www.math.utah.edu:8080/pub/tex/bib/axiom.bib
> 
> might be interesting for the Axiom-References page.
> 

Nelson H. F. Beebe's bibliography is already loaded into the
bibliography on the Axiom Portal as indicated here:

http://portal.axiom-developer.org/refs

Note that it is also listed on Axiom Wiki here:

http://wiki.axiom-developer.org/FoundObjects

\start
Date: Wed, 19 Apr 2006 07:16:51 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Re: Axiom bibliography

--- Ralf Hemmecke wrote:

> Maybe the original source
> 
> http://www.math.utah.edu:8080/pub/tex/bib/axiom.bib
> 
> might be interesting for the Axiom-References page.
> 
> Ralf

Nelson Beebe is something of a legend when it comes to bibtex reference
files - it is his Macsyma/Maxima bibliography that is found in the
Maximabook, although I suspect it may now be out of sync with his
latest version.  He has far and away the most extensive collection of
bibtex files I have ever seen.

I see he has explicitly licensed this file as public domain, which
answers that question ;-).

I have always found his Bibtex files to be extremely well done and well
organized.  I know we have not yet arrived at a solution for the
problem of a bibtex file for Axiom pamphlets, but when we do arrive at
one I would suggest looking to this file as a starting point.  Indeed,
if he is interested it would probably be a good idea to work with him
on issues related to bibtex.

The problem of making a bibtex file into a pamphlet file is going to be
a big one, primarily because in order to make some sense of the one
(large) file it would be advisable to keep it ordered by date, author,
or some other key.  But the only way I know of which might be able to
achieve this would be to use some tool for the management of
bibliographies.  JabRef would be far and away my preference - it is the
leading open source solution that I am aware of, and I'm hoping its
Groups feature could be used somehow to manage things:

http://jabref.sourceforge.net/
http://jabref.sourceforge.net/images/Jabref-ScreenShot-MainWindow.png

but if we do use such a tool we have the problem of its being designed
to work with bibtex, not bibtex in pamphlet :-/.

>From what I can remember, it was Tim's wish that we have not just a
bibtex file but a file which also discusses the papers in question.  I
would suggest however, at least in this one case, that we try to work
within the bibtex format rather than going outside it.  Managing
bibliographies is a very complex business, particularly something as
large as Axiom's is likely to become, and if we want to include
anything outside of the standard and normal optional fields for a
bibtex entry perhaps something can be devised.  Jabref has some
provision for custom import and export if it comes to that, so maybe if
we have to we could teach it to associate latex text between entries
with a particular entry and thus make the pamphlet itself sortable.

Has anyone any particular ideas on this?  For me the issue will become
rapidly more concrete as I work on the Unit and Emacs pamphlets, both
of which (units especially) are likely to have a healthy bibliography
by the time they are "done".  Since this is a core design issue for the
Axiom literate document system it needs discussion and consideration by
all interested parties.  There are a LOT of papers to include even if
you just take the ones on Axiom itself - when you branch out to other
types of relevant programs (proof checkers, etc.) and then pure math in
general we're talking THOUSANDS of papers which might (should) wind up
being cited by Axiom.  Each pamphlet will include the specific papers
it references of course, but the Bibliography as a whole would probably
constitute a volume all by itself.  We'll need intelligent ways to
merge, sort, and manage this process.  I guess I would propose this as
a rough draft:

1.  Create and maintain a central bibliography, starting with the
Nelson Beebe axiom.bib file as a beginning.  Pamphlet authors would be
encouraged to use the citations already present if they want to cite an
existing paper.

2.  Each new pamphlet will undoubtedly cite papers and other works not
included in the main axiom.bib file.  They will most likely either
append these new entries on to the end of axiom.bib or maintain a
separate file.  When a new pamphlet is submitted to Axiom, part of the
inclusion process will be incorporating the new bibliography entries
into the main axiom.bib file.  This can be done either via a diff
(preferably of an altered axiom.bib which has been sorted by whatever
criteria we decide to organize the main file) or the inclusion of a bib
file which contains all the new references.  In the latter case,
someone with the correct tools can merge the new references into the
main file.

3.  We need some way to identify categories of paper within the main
bib file - maybe some kind of agreed upon keywords for each category of
paper.  This will evolve somewhat but most major categories should be
agreed upon in advance.  This will allow someone looking for a
particular paper to cite to quickly identify the relevant subset of the
bib file.  This will require jabref or some similar tool to handle
properly, but that is going to be unavoidable in such a large file.

4.  If things get too large, we might have to consider "group" based
bib files - I don't know what the size limits are for bibtex but it
must have some.

5.  IIRC there is some way to process bib files as TeX documents?  If
so we can make the bibliography file available on the wiki like any
regular pamphlet file.  I'll have to check that.

Comments?  This is an important issue and will become much more
important as time goes on, so now is the time to figure out what is
"right" and implement it.

\start
Date: Wed, 19 Apr 2006 17:35:44 +0200
From: Gregory Vanuxem
To: Ralf Hemmecke
Subject: Re: [Axiom-developer] "Please add new attributes" message when	building aldor interface


Hi,

Le mercredi 19 avril 2006 =C3=A0 11:23 +0200, Ralf Hemmecke a =C3=A9crit =
:

[...]

> > Am I alone with this issue ? Is it normal that the build process stop=
s
>  > (it's not documented on Mathaction) ? Was src_aldor2.tgz changed
>  > (I did not encounter this issue in the past)?
>
> Yes, the compilation stopped but not for the issue you described.
> What you encountered should rather be seen as a feature than a bug.
> So '@false' should remain there.

I agree

>
> libaxiom.mk says
> ----BEGIN
> # attrib.as - needs some special rules
> # The second ensures that the build will fail if ATTREG.spad is modifie=
d.
>
> ALL_DIRS += $(MID)/as
>
> $(MID)/as/attrib.as:: $(IN)/as/attrib.as.head $(MID)/as/.dir
> 	cp $(IN)/as/attrib.as.head  $@
>
> $(MID)/as/attrib.as:: $(INT)/algebra/ATTREG.spad
> 	@echo "Please add new attributes to $(Ax0Dir)/attrib.as.head"
> 	@false
> ----END
>
> So if ever ATTREG.spad changes the compilation stops. Hmm, that means i=
t
> probably always stops if you do 'tla update' and recompile Axiom.
> Maybe the dependency should rather be ATTREG.spad.pamphlet. But also
> that does not sound correct, since I can simply modify the documentatio=
n
> without generating a different ATTREG.spad.

Yes you're right, thanks, I read too quickly the libaxiom.mk (I built
Axiom and the Aldor interface in the background). I'm an idiot, I did
not even see this comment. So it seems that my version of ATTREG.spad
was more recent than attrib.as.head. Humm it's strange since I did not
modify ATTREG.spad and I decompressed src_ador2.tgz after the full build
of Axiom.

Cheers,

Greg

> Probably the easiest thing would be to include the src_aldor2.tgz (in
> extracted form) into the aldor distribution. Sure, you can only build
> the interface, if you have Java around, but your problem would go away,=

> since whenever ATTREG.spad.pamphlet is modified one would modify
> attrib.as.head appropriately BEFORE distributing new Axiom sources.
> The timestamp of attrib.as should be newer than ATTREG.spad.

\start
Date: Wed, 19 Apr 2006 17:54:26 +0200
From: David Mentre
To: Ralf Hemmecke
Subject: re: [AxiomDownload]

Hello Ralf,

2006/4/19, Ralf Hemmecke:
> Now it tells me only, how to send patches of single files to you.
> What would be the procedure if my modification involves several files?
> Remember people even might forget which files they actually modified. So
> how do they find out about all the different files. Would you use a
> 'tla' command to create the patch? Maybe 'tla changeset'?

Procedure that works for any Source Code Management system:

 1. you have your own modified Axiom in axiom-dxm/ (with relevant pamphlets=
)

 2. 'make clean' into axiom-dxm/

 3. checkout latest fresh cvs into axiom/, next to axiom-dxm/

 4. diff -Naur axiom/ axiom-dxm/ > wonderful-feature-dxm.patch

 5. send wonderful-feature-dxm.patch to Tim and axiom-developer@.

\start
Date: Wed, 19 Apr 2006 17:57:32 +0200
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: "Please add new attributes" message when building aldor interface

 > So it seems that my version of ATTREG.spad
> was more recent than attrib.as.head. Humm it's strange since I did not
> modify ATTREG.spad and I decompressed src_ador2.tgz after the full build
> of Axiom.

I hope this all goes away soon. I have already started to move the Java 
code to Aldor. Unfortunately, I have not made progress since several 
weeks. :-(

Anyway, part of the code of Peter Broadbery is included in the Axiom 
distribution. I actually don't understand why src_aldor2 is not in 
axiom--main--1. There is no need to connect it with the MAKE of axiom. 
But if people have installed JAVA and have installed Aldor, they would 
just need to say 'make aldor-interface' or something the like. And the 
JAVA process would start to produce the dependency graph and then run 
aldor to produce libaxiom.al. That would be much simpler.

Once we have that more people would try to use Aldor and of course we 
would try to remove any dependency on JAVA in a future release.

So what do you think about including (an extracted) src_aldor2.tgz in 
--patch-50? If you want you can explicitly state that this part is to 
use at one's own risk. But it would be a bit simpler than the current 
steps at http://wiki.axiom-developer.org/AldorForAxiom

\start
Date: Wed, 19 Apr 2006 18:08:04 +0200
From: Ralf Hemmecke
To: David Mentre
Subject: re: [AxiomDownload]

Thanks David,

But haven't I read in the tla documentation that directories are a 
problem. With the procedure you give one cannot rename directories. Am I 
wrong?

The good think is that the procedure is independent of an SCM. ;-)

Ralf

On 04/19/2006 05:54 PM, David MENTRE wrote:
> Hello Ralf,
> 
> 2006/4/19, Ralf Hemmecke:
>> Now it tells me only, how to send patches of single files to you.
>> What would be the procedure if my modification involves several files?
>> Remember people even might forget which files they actually modified. So
>> how do they find out about all the different files. Would you use a
>> 'tla' command to create the patch? Maybe 'tla changeset'?
> 
> Procedure that works for any Source Code Management system:
> 
>  1. you have your own modified Axiom in axiom-dxm/ (with relevant pamphlets)
> 
>  2. 'make clean' into axiom-dxm/
> 
>  3. checkout latest fresh cvs into axiom/, next to axiom-dxm/
> 
>  4. diff -Naur axiom/ axiom-dxm/ > wonderful-feature-dxm.patch
> 
>  5. send wonderful-feature-dxm.patch to Tim and axiom-developer@.
> 
> Best wishes,
> d.

\start
Date: Wed, 19 Apr 2006 12:16:29 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: re: [AxiomDownload]
Cc: David Mentre

> Thanks David,
> 
> But haven't I read in the tla documentation that directories are a 
> problem. With the procedure you give one cannot rename directories. Am I 
> wrong?
> 
> The good think is that the procedure is independent of an SCM. ;-)
> 
> Ralf
> 
> On 04/19/2006 05:54 PM, David MENTRE wrote:
> > Hello Ralf,
> > 
> > 2006/4/19, Ralf Hemmecke:
> >> Now it tells me only, how to send patches of single files to you.
> >> What would be the procedure if my modification involves several files?
> >> Remember people even might forget which files they actually modified. So
> >> how do they find out about all the different files. Would you use a
> >> 'tla' command to create the patch? Maybe 'tla changeset'?
> > 
> > Procedure that works for any Source Code Management system:
> > 
> >  1. you have your own modified Axiom in axiom-dxm/ (with relevant pamphlets)
> > 
> >  2. 'make clean' into axiom-dxm/
> > 
> >  3. checkout latest fresh cvs into axiom/, next to axiom-dxm/
> > 
> >  4. diff -Naur axiom/ axiom-dxm/ > wonderful-feature-dxm.patch
> > 
> >  5. send wonderful-feature-dxm.patch to Tim and axiom-developer@.
> > 
> > Best wishes,
> > d.

David's process will work fine. I'll accept whole files of patches
or individual file patches provided they 
 (a) are in -Naur format
 (b) are reasonably well documented
 (c) are against the latest tla version
 (d) fit into the system

Since I hand review and apply every change it might happen that your
patch gets rewritten to work in a different fashion. The -Naur file
format gives me enough information to find every individual change.

\start
Date: Wed, 19 Apr 2006 18:24:20 +0200
From: David Mentre
To: Ralf Hemmecke
Subject: re: [AxiomDownload]

Ralf,

2006/4/19, Ralf Hemmecke:
> But haven't I read in the tla documentation that directories are a
> problem. With the procedure you give one cannot rename directories. Am I
> wrong?

You right. Or, more exactly, the renaming won't appear as such but as
a new file(s):

$ mkdir orig
$ mkdir orig/a
$ cat > orig/a/f
foo
$ cp -a orig modified
$ mv modified/a/ modified/b
$ diff -Naur orig modified/
diff -Naur orig/a/f modified/a/f
--- orig/a/f    2006-04-19 18:17:49.000000000 +0200
+++ modified/a/f        1970-01-01 01:00:00.000000000 +0100
@@ -1 +0,0 @@
-foo
diff -Naur orig/b/f modified/b/f
--- orig/b/f    1970-01-01 01:00:00.000000000 +0100
+++ modified/b/f        2006-04-19 18:17:49.000000000 +0200
@@ -0,0 +1 @@
+foo



> The good think is that the procedure is independent of an SCM. ;-)

I'm for peace in SCM war. ;-)

\start
Date: Wed, 19 Apr 2006 12:18:51 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: "Please add new attributes" message when building aldor interface

> I hope this all goes away soon. I have already started to move the Java 
> code to Aldor. Unfortunately, I have not made progress since several 
> weeks. :-(

I think we all agree that It would be good to have this as aldor code.

> Anyway, part of the code of Peter Broadbery is included in the Axiom 
> distribution. I actually don't understand why src_aldor2 is not in 
> axiom--main--1. There is no need to connect it with the MAKE of axiom. 
> But if people have installed JAVA and have installed Aldor, they would 
> just need to say 'make aldor-interface' or something the like. And the 
> JAVA process would start to produce the dependency graph and then run 
> aldor to produce libaxiom.al. That would be much simpler.

make it work. send patch files.

> Once we have that more people would try to use Aldor and of course we 
> would try to remove any dependency on JAVA in a future release.
> 
> So what do you think about including (an extracted) src_aldor2.tgz in 
> --patch-50? If you want you can explicitly state that this part is to 
> use at one's own risk. But it would be a bit simpler than the current 
> steps at http://wiki.axiom-developer.org/AldorForAxiom

make it work. send patch files.

\start
Date: Wed, 19 Apr 2006 10:38:50 -0700
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Axiom bibliography

C Y [Cliff Yapp] wrote:
> The problem of making a bibtex file into a pamphlet file is going to be
> a big one, primarily because in order to make some sense of the one
> (large) file it would be advisable to keep it ordered by date, author,
> or some other key.  But the only way I know of which might be able to
> achieve this would be to use some tool for the management of
> bibliographies.  JabRef would be far and away my preference - it is the
> leading open source solution that I am aware of, and I'm hoping its
> Groups feature could be used somehow to manage things:
>
> http://jabref.sourceforge.net/
> http://jabref.sourceforge.net/images/Jabref-ScreenShot-MainWindow.png
>
> but if we do use such a tool we have the problem of its being designed
> to work with bibtex, not bibtex in pamphlet :-/.

I'm working on a system for physicists which will require an extensive
reference database (at least all of the arXiv plus all of SPIRES) and
furthermore, I want wiki pages to actually link to the bibliography.

For physics anyway, search engines already exist to find papers and even
entire bibtex entries (via arXiv, SPIRES, and NASA ADS).  For math see
the Front here at UC-Davis which also provides bibtex:
http://front.math.ucdavis.edu/  AND these systems all provide a concise
identifier for each paper.  (e.g. math.AC/0604301)  Historic papers are
often more of a problem.

I have discussed this project a bit with Bill privately, but would
welcome more widespread development in this direction.

Right now I have an experimental Plone site (because of the existence of
the Bibliography Archetype -- same as Axiom Portal:
    http://portal.axiom-developer.org/bibliography_view
).  Maybe I have missed it but I do not see a way to search the
bibliography.  Furthermore when viewing a bibliography entry it does not
give you a concise identifier for each paper that you can \cite{},
unless you go export to bibtex, then examine the output. 

I would like to add search and \cite{} capability from wiki pages.  This
would allow discussion of papers, and even back-references on the wiki!
It would be super-sweet if the search could be done in a sidebar, next
to the edit window, using AJAX, so that you could retrieve the
identifier for \cite{} without having to open a new browser window.

> Has anyone any particular ideas on this?  For me the issue will become
> rapidly more concrete as I work on the Unit and Emacs pamphlets, both
> of which (units especially) are likely to have a healthy bibliography
> by the time they are "done".  Since this is a core design issue for the
> Axiom literate document system it needs discussion and consideration by
> all interested parties.  There are a LOT of papers to include even if
> you just take the ones on Axiom itself - when you branch out to other
> types of relevant programs (proof checkers, etc.) and then pure math in
> general we're talking THOUSANDS of papers which might (should) wind up
> being cited by Axiom.  Each pamphlet will include the specific papers
> it references of course, but the Bibliography as a whole would probably
> constitute a volume all by itself.  We'll need intelligent ways to
> merge, sort, and manage this process.  I guess I would propose this as
> a rough draft:
>
> 1.  Create and maintain a central bibliography, starting with the
> Nelson Beebe axiom.bib file as a beginning.  Pamphlet authors would be
> encouraged to use the citations already present if they want to cite an
> existing paper.
>
> 2.  Each new pamphlet will undoubtedly cite papers and other works not
> included in the main axiom.bib file.  They will most likely either
> append these new entries on to the end of axiom.bib or maintain a
> separate file.  When a new pamphlet is submitted to Axiom, part of the
> inclusion process will be incorporating the new bibliography entries
> into the main axiom.bib file.  This can be done either via a diff
> (preferably of an altered axiom.bib which has been sorted by whatever
> criteria we decide to organize the main file) or the inclusion of a bib
> file which contains all the new references.  In the latter case,
> someone with the correct tools can merge the new references into the
> main file.

I have been thinking to write a back-end which will interrogate other
search engines for bibtex, if someone enters something unknown.  For
instance, SPIRES references are easy to recognize by syntax (e.g.
McElrath:2005bp) same for arXiv (e.g. hep-ph/0506151) so the wiki system
can know which database to import from if it doesn't have the
bibliography entry already.

> 3.  We need some way to identify categories of paper within the main
> bib file - maybe some kind of agreed upon keywords for each category of
> paper.  This will evolve somewhat but most major categories should be
> agreed upon in advance.  This will allow someone looking for a
> particular paper to cite to quickly identify the relevant subset of the
> bib file.  This will require jabref or some similar tool to handle
> properly, but that is going to be unavoidable in such a large file.

Rather than explicitly identify categories, why not just use
backreferences?  e.g. a wiki page called CommutativeRings has a number
of references.  If you viewed one of those entires in the bibliography,
it would show "pages that cite this paper" including your
CommutativeRings.

> 4.  If things get too large, we might have to consider "group" based
> bib files - I don't know what the size limits are for bibtex but it
> must have some.

I say one huge database.  I know of no size limits.  If one wants to
process with latex one could always extract the subset of bibtex entries
=66rom the database.

> 5.  IIRC there is some way to process bib files as TeX documents?  If
> so we can make the bibliography file available on the wiki like any
> regular pamphlet file.  I'll have to check that.

What do you mean here?  Have you seen the Axiom Portal bibliography that
I'm talking about?

If you're interested in working on this, please do!  For the near term
I'm trying to get an XHTML+XML plone site working, and developing a new
wiki syntax that is faux-latex and generates XHTML+MathML.  I have not
started on the bibliography stuff yet, but I will need some kind of
interface to query the bibliography.  e.g. "give me a formatted citation
or URL for the identifier McElrath:2005bp".  If you want to write that,
or look into it, please do!

For now the software I'm building on is the CMF Bibliography Archetype:
    http://plone.org/events/sprints/paderborn/BibliographyTeam

\start
Date: Wed, 19 Apr 2006 12:04:33 -0700 (PDT)
From: Cliff Yapp
To: Bob McElrath
Subject: Re: Axiom bibliography

> C Y [Cliff Yapp] wrote:
> > JabRef would be far and away my
> > preference - it is the leading open source solution that I am
> > aware of, and I'm hoping its Groups feature could be used somehow
> > to manage things:
> > 
> > http://jabref.sourceforge.net/
> >
> http://jabref.sourceforge.net/images/Jabref-ScreenShot-MainWindow.png
> > 
> > but if we do use such a tool we have the problem of its being
> > designed to work with bibtex, not bibtex in pamphlet :-/.
> 
> I'm working on a system for physicists which will require an
> extensive reference database (at least all of the arXiv plus all of
> SPIRES) and furthermore, I want wiki pages to actually link to the
> bibliography.
> 
> For physics anyway, search engines already exist to find papers and
> even entire bibtex entries (via arXiv, SPIRES, and NASA ADS).  For
> math see the Front here at UC-Davis which also provides bibtex:
> http://front.math.ucdavis.edu/  AND these systems all provide a
> concise identifier for each paper.  (e.g. math.AC/0604301)  Historic
> papers are often more of a problem.

Isn't that a bit different from the problem of how to handle axiom.bib?
 Web interfacing and updating of it (with convenience links to online
archives) would definitely be a Good Thing but for the pamphlets we
need a bib file.  And for us non-web-editing fogies we need some
desktop tools to handle it as well.  Getting all of these worlds to
speak to each other cleanly seems to be as yet something of an unsolved
problem.

> I have discussed this project a bit with Bill privately, but would
> welcome more widespread development in this direction.

I think I haven't wrapped my brain all the way around this one, but I'm
going to keep trying to do so because it is extremely important to a
literate programming project such as this one.

> Right now I have an experimental Plone site (because of the existence
> of the Bibliography Archetype -- same as Axiom Portal:
>     http://portal.axiom-developer.org/bibliography_view
> ).  Maybe I have missed it but I do not see a way to search the
> bibliography.  Furthermore when viewing a bibliography entry it does
> no give you a concise identifier for each paper that you can \cite{},
> unless you go export to bibtex, then examine the output.  

Agreed.  OK, so you are looking at a web interface that parses the
axiom.bib file, allows searching of it, and provides convenient
citing-via-web abilities as well as links to actual papers (when
available?)  Presumably entries could be added too, although the manner
in which they are added needs careful thought.

> I would like to add search and \cite{} capability from wiki pages. 
> This would allow discussion of papers, and even back-references on
> the wiki! It would be super-sweet if the search could be done in a
> sidebar, next to the edit window, using AJAX, so that you could
> retrieve the identifier for \cite{} without having to open a new
> browser window.

OK, I think I'm beginning to follow you.  Yes, that would indeed be
nice!
 
> > 1.  Create and maintain a central bibliography, starting with the
> > Nelson Beebe axiom.bib file as a beginning.  Pamphlet authors would
> > be encouraged to use the citations already present if they want to
> > cite an existing paper.
> > 
> > 2.  Each new pamphlet will undoubtedly cite papers and other works
> > not included in the main axiom.bib file.  They will most likely
> > either append these new entries on to the end of axiom.bib or
> > maintain a separate file.  When a new pamphlet is submitted to
> > Axiom, part of the inclusion process will be incorporating the new
> > bibliography entries into the main axiom.bib file.  This can be
> > done either via a diff (preferably of an altered axiom.bib which
> > has been sorted by whatever criteria we decide to organize the
> > main file) or the inclusion of a bib file which contains all the
> > new references.  In the latter case, someone with the correct
> > tools can merge the new references into the main file.
> 
> I have been thinking to write a back-end which will interrogate other
> search engines for bibtex, if someone enters something unknown.  For
> instance, SPIRES references are easy to recognize by syntax (e.g.
> McElrath:2005bp) same for arXiv (e.g. hep-ph/0506151) so the wiki
> system can know which database to import from if it doesn't have the
> bibliography entry already.

Two concerns there.  The first one is how we ensure quality and
avoidance of duplications (suppose a slightly different bibtex entry
already exists for that paper - how do we spot it?) but I think the
online archives are reasonably good quality so I'm not too worried. 
The second is copyright - if we just snatch bibtex references for
papers off the various sites and incorporate them into axiom.bib, is
that OK?  I can't imagine why it would be a problem since the whole
idea of bibtex entries is to use them in papers but the question needs
to be asked.

> > 3.  We need some way to identify categories of paper within the
> > main bib file - maybe some kind of agreed upon keywords for each
> > category of paper.  This will evolve somewhat but most major
> > categories should be agreed upon in advance.  This will allow
> > someone looking for a particular paper to cite to quickly identify
> > the relevant subset of the bib file.  This will require jabref or
> > some similar tool to handle properly, but that is going to be
> > unavoidable in such a large file.
> 
> Rather than explicitly identify categories, why not just use
> backreferences?  e.g. a wiki page called CommutativeRings has a
> number of references.  If you viewed one of those entires in the
> bibliography, it would show "pages that cite this paper" including
> your CommutativeRings.

That would work for the web, but what about "stand alone" authors
working in (say) emacs?  Or what about a case where someone says "how
extensive is Axiom's research on topic X" and they then want to check
the bibliography for all papers pertaining to X? Or "have any papers on
topic Y from the last Z years been considered by Axiom?" 

> > 4.  If things get too large, we might have to consider "group"
> > based bib files - I don't know what the size limits are for bibtex
> > but it must have some.
> 
> I say one huge database.  I know of no size limits.  If one wants to
> process with latex one could always extract the subset of bibtex
> entries from the database.

OK.  Will we adopt the policy that all entries in the axiom.bib file
must be cited by some pamphlet?  Otherwise we will have references
which will never appear in any pamphlet but still exist in the
database.  There are some cases in the past where I have wanted a
reference in my bibliography even though I didn't cite it in a
particular paper because it could be relevant to later work - is this
bad practice?

> > 5.  IIRC there is some way to process bib files as TeX documents? 
> > If so we can make the bibliography file available on the wiki like
> > any regular pamphlet file.  I'll have to check that.
> 
> What do you mean here?  Have you seen the Axiom Portal bibliography
> that I'm talking about?

Yes - I was thinking about whether we want to make an Axiom volume out
of the comprehensive axiom.bib contents or not. Probably not, so never
mind. 

> If you're interested in working on this, please do!  For the near
> term I'm trying to get an XHTML+XML plone site working, and 
> developing a new wiki syntax that is faux-latex and generates
> XHTML+MathML.  I have not started on the bibliography stuff yet, but
> I will need some kind of interface to query the bibliography.  
> e.g. "give me a formatted citation or URL for the identifier
> McElrath:2005bp".  If you want to write that, or look into it, 
> please do!

Unfortunately, I'm thinking more about axiom.bib itself than the web
interface at the moment - I do my editing offline so a web environment
is less useful in the short term.  Eventually all the various
environments, text, jabref, and web alike, will have to funnel down
into one axiom.bib file, so I was more concerned as to what that file
should look like.

You raise a very important point - for a large number of papers the
identifier (and probably bibtex file) should conform to what is
commonly used online. I guess I will need to search for all my
references in the common online archives.  citeseer I'm familiar with,
and xxx.lanl to some extent, but we should have a policy of "check for
auto-generated bibtex entries from these archives before creating your
own."  We should also decide on one convention for identifiers (and
quality standards) on papers where we need to create our own bibtex
entry - the pamphlet files themselves being an obvious example.

\start
Date: Wed, 19 Apr 2006 15:14:01 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Axiom bibliography

> > 5.  IIRC there is some way to process bib files as TeX documents? 
> > > If so we can make the bibliography file available on the wiki like
> > > any regular pamphlet file.  I'll have to check that.
> > 
> > What do you mean here?  Have you seen the Axiom Portal bibliography
> > that I'm talking about?
> 
> Yes - I was thinking about whether we want to make an Axiom volume out
> of the comprehensive axiom.bib contents or not. Probably not, so never
> mind. 

I'm a big fan of annotated bibliographies. We could create a bib volume
that would generate the bibtex file as well as a document that contains
the annotations. Annotations are a great way to collect wisdom about
various papers from previous readers so you can decide if the reference
is related to your effort.

\start
Date: Wed, 19 Apr 2006 21:30:05 +0200
From: David Mentre
To: Tim Daly
Subject: Re: Axiom bibliography

Hello Tim,

Tim Daly writes:

> I'm a big fan of annotated bibliographies. We could create a bib volume
> that would generate the bibtex file as well as a document that contains
> the annotations.

Wouldn't it be simpler to write a latex/pamphlet file with needed
\cite{} and comments? Something like:


\cite{paper1} : good paper on algorithm foo, related to \cite{paperx}.

\cite{paper2} : PhD giving ...


As an added bonus, such a pamphlet file could be used on the Axiom web
site through Bill's machinery.

\start
Date: Wed, 19 Apr 2006 15:30:29 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Axiom bibliography

excellent point. --t

\start
Date: Wed, 19 Apr 2006 12:43:00 -0700 (PDT)
From: Cliff Yapp
To: David Mentre, Tim Daly
Subject: Re: Axiom bibliography

--- David Mentre wrote:

> Hello Tim,
> 
> Tim Daly writes:
> 
> > I'm a big fan of annotated bibliographies. We could create a bib
> volume
> > that would generate the bibtex file as well as a document that
> contains
> > the annotations.
> 
> Wouldn't it be simpler to write a latex/pamphlet file with needed
> \cite{} and comments? Something like:
> 
> 
> \cite{paper1} : good paper on algorithm foo, related to
> \cite{paperx}.
> 
> \cite{paper2} : PhD giving ...

Perfect.  That way we can use all the available goodies for the bibtex
part, the annotated paper would update itself automatically to conform
to the bibtex file, and we can annotate however we need to.  Beautiful.

> As an added bonus, such a pamphlet file could be used on the Axiom
> web site through Bill's machinery.

With hyperref, the pdf should even be clickable.  Nice, nice solution. 
I was too focused on trying to shoehorn the annotations into the bibtex
file itself.

\start
Date: Wed, 19 Apr 2006 22:35:20 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Axiom bibliography

Did you know that BibTeX does not impose a restriction on the fields 
names that are used inside a bibentry? Everything is decided by the 
corresponding bibstyle (.bst) file (which is more like a program).

Unfortunately, I cannot give a reference, but there should be bibstyles 
around that can be used to produce annotated bibliographies from .bib 
files (no pamphlet). The annotation would be in the field "annotate".
And you can use any latex inside this field.

I am not sure whether I would like writing annotations that way (I 
usually have a field "abstract", though), but it is somehow is closer to 
the latex philosophy that the style decides about the look of the data.

I think the most important point is that the data is available in a 
format than can be processed automatically.

And yes, it is a pity that people have not thought about it from the 
beginning: any paper/book/... should have a uniqe string (the bibkey) 
that identifies the item **worldwide**. At the moment every person uses 
his/her own identifiers and it is not easy to merge two overlapping 
bibliography databases.

Ralf

On 04/19/2006 09:14 PM, root wrote:
> I'm a big fan of annotated bibliographies. We could create a bib volume
> that would generate the bibtex file as well as a document that contains
> the annotations. Annotations are a great way to collect wisdom about
> various papers from previous readers so you can decide if the reference
> is related to your effort.

\start
Date: Wed, 19 Apr 2006 16:47:50 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Axiom bibliography

On Wednesday, April 19, 2006 1:39 PM Bob McElrath wrote:
> ...
> Right now I have an experimental Plone site (because of
> the existence of the Bibliography Archetype -- same as
> Axiom Portal:
>     http://portal.axiom-developer.org/bibliography_view
> ).  Maybe I have missed it but I do not see a way to search the
> bibliography.

All items in the bibliography are automatically searched when
you do any search on the portal (search box in upper right
corner). You can control this if you click the 'Search' tab.

http://portal.axiom-developer.org/search_form

This "Advanced search" allows to search for only specific
content. All of the bibliography reference types appear as
separate 'portal types' - all having the word "reference"
in the type name.

It is easy to generate a URL that does a search of all
bibliograph entries. For example the following search finds
all entries containing the word "polynomial":

http://portal.axiom-developer.org/search?SearchableText=polynomial&port=
a
l_type%3Alist=ArticleReference&portal_type%3Alist=BookReference&porta=
l_t
ype%3Alist=BookletReference&portal_type%3Alist=InbookReference&portal=
_ty
pe%3Alist=IncollectionReference&portal_type%3Alist=InproceedingsRefer=
enc
e&portal_type%3Alist=ManualReference&portal_type%3Alist=Mastersthesis=
Ref
erence&portal_type%3Alist=MiscReference&portal_type%3Alist=PhdthesisR=
efe
rence&portal_type%3Alist=PreprintReference&portal_type%3Alist=Proceed=
ing
sReference&portal_type%3Alist=TechreportReference&portal_type%3Alist==
Unp
ublishedReference&portal_type%3Alist=WebpublishedReference&Creator=&s=
ubm
it=Search

Note: The above is all one long URL. Most email programs will
split this into multiple lines that must be re-joined before
use in a browser.

> Furthermore when viewing a bibliography entry it does not
> give you a concise identifier for each paper that you can \cite{},
> unless you go export to bibtex, then examine the output.

The page returned above has links formatted as follows:

http://portal.axiom-developer.org/refs/axiombib/Duval1992EPS

"Duval1992EPS" is the bibtex identifier assigned by Nelson Beebe.

The URL

http://portal.axiom-developer.org/refs/axiombib/Duval1992EPS/downloadFor
m

will provide the full bibtex entry.

>
> I would like to add search and \cite{} capability from wiki
> pages.  This would allow discussion of papers, and even
> back-references on the wiki! It would be super-sweet if the
> search could be done in a sidebar, next to the edit window,
> using AJAX, so that you could retrieve the identifier for
> \cite{} without having to open a new browser window.

So is this what you have in mind?

--------

Supposed in an Axiom wiki page I write:

   Blah, blah. Polynomial\cite{axiombib/Duval1992EPS} are
   treated ...

In this case what will we see rendered on the page?

             1
   Polynomial  are treated ...

with the 1 hyperlinked to a brief formatted reference at the
bottom of the page?

  ..1 D Duval and F Jung  (1992)
  Examples of problem solving using computer algebra

which in turn is hyperlinked to full reference at

http://portal.axiom-developer.org/refs/axiombib/Duval1992EPS

\start
Date: Wed, 19 Apr 2006 22:49:50 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Axiom bibliography

>> \cite{paper1} : good paper on algorithm foo, related to
>> \cite{paperx}.
>>
>> \cite{paper2} : PhD giving ...

I think

@article{paper1,
    author = {...},
    ...
    annotate = {good paper on algorithm foo, related to \cite{paper2}}
}

@phdthesis{paper2,
   author = {...},
   ...
   annotate = {PhD giving ... }
}

Is perfectly possible. The problem is the bibstyle that makes a document 
out of it.

Well yes, if hyperref is included then also that should be clickable, 
but it would probably be more like an annotated bibliography than the 
example David gave.

Would you like to see

[AB79] good paper on algorithm foo related to [Sch99]
[Sch99] PhD giving ...

??? Probably not.

Google for "annotated bibliography bibtex".

\start
Date: Wed, 19 Apr 2006 16:55:46 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Axiom bibliography

On Wednesday, April 19, 2006 4:48 PM I should have written:
> ...
> The URL
>

http://portal.axiom-developer.org/refs/axiombib/Duval1992EPS/download

>
> will provide the full bibtex entry.
>

\start
Date: Wed, 19 Apr 2006 14:52:27 -0700
From: Bob McElrath
To: Ralf Hemmecke
Subject: Re: Axiom bibliography


Ralf Hemmecke [Ralf Hemmecke] wrote:
> Well yes, if hyperref is included then also that should be clickable, 
> but it would probably be more like an annotated bibliography than the 
> example David gave.
> 
> Would you like to see
> 
> [AB79] good paper on algorithm foo related to [Sch99]
> [Sch99] PhD giving ...
> 
> ??? Probably not.
> 
> Google for "annotated bibliography bibtex".

If you can click on [AB79] and [Sch99], then who cares?

Actually I've been thinking to use the usual latex annotations.  (e.g.
$\ ^1$ good paper on algorithm foo related to $\ ^2$) where the
wiki/pamphlet system would put a formatted reference with author and
title at the bottom of the page as a footnote.

Perhaps also the citation should have a line: "Mentioned in:" with a
list of other wiki pages/pamphlets.

But formatting of the footnote is a detail that can be customized, and
argued in the future when it works.

\start
Date: Wed, 19 Apr 2006 14:58:49 -0700
From: Bob McElrath
To: Ralf Hemmecke
Subject: Re: Axiom bibliography

Ralf Hemmecke [Ralf Hemmecke] wrote:
> Did you know that BibTeX does not impose a restriction on the fields 
> names that are used inside a bibentry? Everything is decided by the 
> corresponding bibstyle (.bst) file (which is more like a program).

Yes, the format is:
@ARTICLE{identifier,
    key1 = value1,
    key2 = value2,
    etc...
}

you can put anything in there you want.  Wheter your .bst uses it or not
is another matter.  Some odd keys in my bibtex files include "adsurl",
"doi", "abstract", "SLACcitation", and comments from me via "bobnote".
;)

> And yes, it is a pity that people have not thought about it from the 
> beginning: any paper/book/... should have a uniqe string (the bibkey) 
> that identifies the item **worldwide**. At the moment every person uses 
> his/her own identifiers and it is not easy to merge two overlapping 
> bibliography databases.

That is the intent behind the Digital Object Identifier (DOI) system:
    http://www.doi.org/
A doi looks like: 10.1126/science.1066687

The problem is not that no strings exist, the problem is that many
people have chosen different and incompatible ways to do it.  But on the
other hand their databases are generally open, so one can interrogate a
server when you get an identifier that isn't in your .bib.

\start
Date: Wed, 19 Apr 2006 17:59:56 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Axiom bibliography

On Wednesday, April 19, 2006 4:48 PM I wrote:
> ...
> It is easy to generate a URL that does a search of all
> bibliograph entries. For example the following search finds
> all entries containing the word "polynomial":
> ...

It might be easier to use the 'path' option on the search
instead of listing all of the bibiography types since only
bibliography entries will be present in the 'axiombib' folder.
E.g. This query returns a list of Axiom references that have
'Buchberger' in the title:

http://portal.axiom-developer.org/search?Title=Buchberger&path=/Plone=
/re
fs/axiombib&submit=Search

Similarly you can search only for Reduce references:

http://portal.axiom-developer.org/search?Title=Buchberger&path=/Plone=
/re
fs/redbib&submit=Search

\start
Date: Wed, 19 Apr 2006 15:14:05 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: Axiom bibliography

Page, Bill [Bill Page] wrote:
> > I would like to add search and \cite{} capability from wiki 
> > pages.  This would allow discussion of papers, and even
> > back-references on the wiki! It would be super-sweet if the
> > search could be done in a sidebar, next to the edit window,
> > using AJAX, so that you could retrieve the identifier for
> > \cite{} without having to open a new browser window.
> 
> So is this what you have in mind?

Yes, right now I intend to use the CMF Bibliography Archetype as a base
(same as you are using on the Axiom Portal)...but I think it leaves some
things to be desired, and I'd like to enhance it.  Improving searching
would be one.

My goal in doing a search is to find the unique ID to reference a paper
by, so I can type \cite{foo} on my wiki page.  Or I'm looking to
download the paper.  Neither of which are possible/easy with the CMF
Bibliography Archetype, as it stands.

> --------
> 
> Supposed in an Axiom wiki page I write:
> 
>    Blah, blah. Polynomial\cite{axiombib/Duval1992EPS} are
>    treated ...
> 
> In this case what will we see rendered on the page? 
> 
>              1
>    Polynomial  are treated ...
> 
> with the 1 hyperlinked to a brief formatted reference at the
> bottom of the page?
> 
>   ..1 D Duval and F Jung  (1992)
>   Examples of problem solving using computer algebra
> 
> which in turn is hyperlinked to full reference at
> 
> http://portal.axiom-developer.org/refs/axiombib/Duval1992EPS
> 
> ----------

That is exactly what I have in mind.  But furthermore the page displayed
at:
    http://portal.axiom-developer.org/refs/axiombib/Duval1992EPS
is almost useless because it does not provide any link to any on-line
database which would let me download the paper.  It has only a cryptic
journal citation.  I think one would have to be an expert in the field
to decode j-IFIP-TRANS-A <#j-IFIP-TRANS-A> A-2:133\u2013141, 143.

For the \cite{} I would rather have one huge bibliography, with every
paper on the planet.  The contents of the \cite{} should identify the
paper, rather than the local bibliography ('axiombib') to look in.  For
instance, \cite{arXiv:hep-ph/01234567} or
\cite{ADS:2001Sci...294.1320M}, where I assume that the 'arXiv:' and
'ADS:' can be dropped because the text string itself is sufficently
unique to figure out which database to look in.

The difference is that I assume NO ONE will add any entry to the bibtex.
Rather the server will keep a database and update it automatically when
you type \cite{hep-ph/0123457}.  Keep the users away from database
maintainence.  It's hard enough just to find the paper in the first
place.  

If you want to process a pamphlet in latex it's easy enough to extract
the bibtex entries used and export them.

\start
Date: Wed, 19 Apr 2006 18:46:57 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Axiom bibliography

> ... But furthermore the page displayed at:
>     http://portal.axiom-developer.org/refs/axiombib/Duval1992EPS
> is almost useless because it does not provide any link to any on-line
> database which would let me download the paper.  It has only a cryptic
> journal citation.  I think one would have to be an expert in the field
> to decode j-IFIP-TRANS-A <#j-IFIP-TRANS-A> A-2:133\u2013141, 143.
>

As you know the contents of a bibtex entry is up to whoever wrote
the entry. In this case Nelson Beebe has a particular "standard
abbreviation" for referring to journal articles. To decode this
you would need to refer to his web site:

http://www.math.utah.edu/pub/tex/bib/axiom.html
http://www.math.utah.edu/~beebe/bibliographies.html
http://www.math.utah.edu/~beebe

All of this stuff pre-dates the current concern for more appropriate
and general standards on the web.

In the case of the bibliography product on Plone, whether a link
is provided depends on whether a URL is present in the bibtex
entry. For an example of an entry containing a link see:

http://portal.axiom-developer.org/refs/axiombib/webpublishedreference.20
05-01-18.1190226284

(I am sure there are some others in /Plone/refs/axiombib.

> For the \cite{} I would rather have one huge bibliography, with
> every paper on the planet...

Google? ;)

\start
Date: Wed, 19 Apr 2006 20:03:32 -0700 (PDT)
From: Cliff Yapp
To: Bob McElrath, Bill Page
Subject: Re: Axiom bibliography

--- Bob McElrath wrote:

> That is exactly what I have in mind.  But furthermore the page
> displayed at:
>     http://portal.axiom-developer.org/refs/axiombib/Duval1992EPS
> is almost useless because it does not provide any link to any on-line
> database which would let me download the paper.

Well, in quite a number of cases (especially older papers) they simply
aren't online.  I agree however that if they are available they should
be linked to.  We could just include a URL in the bibtex entry itself,
which could then presumably be parsed by the web display.

> It has only a cryptic journal citation.  I think one would have to
> be an expert in the field to decode j-IFIP-TRANS-A <#j-IFIP-TRANS-A>
> A-2:133\u2013141, 143.

I agree we want to be clearer than this, and Bill mentioned that those
abbreviations might not be designed in a way that matches our purposes.
 So let's establish a standard that does fit our needs, and use it.  A
URL to the paper is the best way, but when that's not available we have
to do the best we can.
 
> For the \cite{} I would rather have one huge bibliography, with every
> paper on the planet.

Amen :-).  Too bad we don't have that.  Although axiombib might get
close given enough time and effort ;-).

> The contents of the \cite{} should identify the
> paper, rather than the local bibliography ('axiombib') to look in. 

Well... I would prefer it that cite references axiombib first and gets
the URL from that, and if it is not present there goes elsewhere.

> For instance, \cite{arXiv:hep-ph/01234567} or
> \cite{ADS:2001Sci...294.1320M}, where I assume that the 'arXiv:' and
> 'ADS:' can be dropped because the text string itself is sufficently
> unique to figure out which database to look in.

Or, what about this - if the arXiv: or ADS: notation is included, link
directly to the main site.  If it is not included, look first to the
local axiombib for the URL and then try to identify a site.  If our
bibtex files are annotated it might be more beneficial to a user to
start there, but the option of arXiv: allows the author to be direct if
desired.  hep-ph/01234567 might have some useful local comments defined
in axiom.bib, for example.

> The difference is that I assume NO ONE will add any entry to the
> bibtex.
> Rather the server will keep a database and update it automatically
> when you type \cite{hep-ph/0123457}.  Keep the users away from
> database maintainence.  It's hard enough just to find the paper in
> the first place.  

What about papers that are not listed in any of the major online
references?  I think we have to allow for an updated axiom.bib, but I
agree automating as much of it as possible through connections with
servers is a Good Thing.

> If you want to process a pamphlet in latex it's easy enough to
> extract the bibtex entries used and export them.

Maybe, but what if an online archive changes their format and decides
not to allow simple automation of bibtex entry downloads?  How will we
store annotations?  I think a local solution that is refreshed and
updated periodically will be the best compromise - we always have
something that works locally (also for offline editing, which does
happen), but it is kept current with developments elsewhere.

\start
Date: Thu, 20 Apr 2006 09:16:34 +0200
From: David Mentre
To: Gabriel Dos Reis
Subject: Re: [Axiom-mail] Axiom and linux distros
Cc: Benjamin Kosnik

Hello Gaby,

07 Apr 2006 12:54:36 +0200, Gabriel Dos Reis=
:
> Benjamin pointed out that a minimal requirement would be for Axiom to
> support cross-compilation

Could you detail this point? By "cross-compilation", do you really
mean like compiling on architecture i386 for arch ppc64? Why?

That might be an issue, as Lisp images are generated by executing the
lisp machine, and machine specific C and object files are generated at
that time. Maybe Camm could comment on this point, as GCL guru. ;-)

However, Axiom can be compiled on various architecture (tested archs
are alpha amd64 arm hppa i386 ia64 mips mipsel powerpc s390 sparc).

> "easy" packaging, etc.

Axiom is already packaged for the Debian system[1]. I don't know if
the packaging is "easy" enough though.

Best wishes,
d.

[1] http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&=
version=all&exact=1&keywords=axiom

\start
Date: Thu, 20 Apr 2006 00:27:08 -0700
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Axiom bibliography

C Y [Cliff Yapp] wrote:
> > The contents of the \cite{} should identify the
> > paper, rather than the local bibliography ('axiombib') to look in. 
> 
> Well... I would prefer it that cite references axiombib first and gets
> the URL from that, and if it is not present there goes elsewhere.

The local database would still be kept, and periodically updated from
external database queries.  Sorry for the confusion -- I always intended
that.  Solely external lookups would be slow and error prone.  So all
lookups would look in the local database first, then go to arXiv/ADS/etc
if the requested entry isn't already in the local database.

I was thinking this afternoon that the footnote could be "This citation
is not in the database.  Reload to see it."  Where in between the server
would be interrogating arXiv (etc) servers.  Or "This citation could not
be found in any databases.  Click here to enter it manually."

> What about papers that are not listed in any of the major online
> references?  I think we have to allow for an updated axiom.bib, but I
> agree automating as much of it as possible through connections with
> servers is a Good Thing.

Of course manual entry would be possible, but I hope that it would be
rare.

> > If you want to process a pamphlet in latex it's easy enough to
> > extract the bibtex entries used and export them.
> 
> Maybe, but what if an online archive changes their format and decides
> not to allow simple automation of bibtex entry downloads?  How will we
> store annotations?  I think a local solution that is refreshed and
> updated periodically will be the best compromise - we always have
> something that works locally (also for offline editing, which does
> happen), but it is kept current with developments elsewhere.

Well that's an unfortunate possibility that would have to be dealt with.
Fortunately, the number of databases is large.  But yes, the loss of a
database would suck.

If that happened though we'd still have the local database of references
*used* on the site.  We just wouldn't be able to obtain new ones.

\start
Date: 20 Apr 2006 11:36:25 +0200
From: Martin Rubey
To: Martin Rubey
Subject: [ANN] Axiom Workshop 2006 -- Final Announcement

Dear all,

this is the final announcement of the Axiom Workshop 2006 at the RISC in
Hagenberg.

Please note that it is not at all a prerequesite to be familiar with the
computer algebra system axiom. In particular, the talks will address issues
inherent to symbolic computation in general, and not any particular system.

The schedule is as follows:

Thursday, April 27

10:00 M. Rubey           Opening and Introduction to Axiom
11:00 C. Schneider       Sigma - A package for multi-summation
12:00 Lunch
14:00 N. Thiery          Implementing Algebraic Combinatorics - some
                         experiences with MuPAD-Combinat
15:00 R. Hemmecke        Introduction to Aldor I
16:00                    Workshop I


Friday, April 28

10:00 P. Hlineny         MACEK - real structural computations with
                         matroids
11:00 B. Gittenberger    Extended admissible functions
12:00 Lunch
15:00 R. Hemmecke        Introduction to Aldor II
16:00                    Workshop II


Saturday, April 29

09:00 M. Rubey           Guessing formulas for sequences
10:00 A. Hersen          Implementing a hierarchy of Recurrences
11:00                    Workshop III: Presentation of Results

I hope to see you soon,

Martin Rubey


-------------------------------------------------------------------------------
                                    _
                                   (_)
                          __ ___  ___  ___  _ __ ___
                         / _` \ \/ / |/ _ \| '_ ` _ \
                        | (_| |>  <| | (_) | | | | | |
                         \__,_/_/\_\_|\___/|_| |_| |_|
                                    _
                                   (_)

         __          ______  _____  _  __ _____ _    _  ____  _____
         \ \        / / __ \|  __ \| |/ // ____| |  | |/ __ \|  __ \
          \ \  /\  / / |  | | |__) | ' /| (___ | |__| | |  | | |__) |
           \ \/  \/ /| |  | |  _  /|  <  \___ \|  __  | |  | |  ___/
            \  /\  / | |__| | | \ \| . \ ____) | |  | | |__| | |
             \/  \/   \____/|_|  \_\_|\_\_____/|_|  |_|\____/|_|

                            ___   ___   ___    __
                           |__ \ / _ \ / _ \  / /
                              ) | | | | | | |/ /_
                             / /| | | | | | | '_ \
                            / /_| |_| | |_| | (_) |
                           |____|\___/ \___/ \___/



                Domain Specific Packages and their Mathematics


with a special focus on


                             Discrete Mathematics


It will take place at the Research Institute for Symbolic Computation

  http://www.risc.uni-linz.ac.at

in Hagenberg, Austria

  http://www.risc.uni-linz.ac.at/about/map

from Thursday, April 27, 10 am, to Saturday, April 29, noon.

-------------------------------------------------------------------------------

Axiom is a Computer Algebra System with a long tradition.  It recently became
free software. See http://www.axiom-developer.org for more details.


The workshop aims at a cooperation of Axiom developers with developers of
packages written for other Computer Algebra Systems or developers of
stand-alone packages.  Furthermore, the workshop wants to make the potential of
Axiom and Aldor more widely known in order to attract new users and new
developers.


If you would like to attend the workshop, please send a message to
Martin Rubey.


There is no conference fee, but it is expected that participants pay
accommodation and meals themselves.  There is a limited number of rooms
available in Hagenberg for approximately 26 EUR/night.  Contact
Martin Rubey for details.

-------------------------------------------------------------------------------


Organisers: Ralf Hemmecke
            Martin Rubey

Email: Martin Rubey

Homepage: http://axiom-developer.org/workshop

\start
Date: Thu, 20 Apr 2006 06:38:19 -0700 (PDT)
From: Cliff Yapp
To: Bob McElrath
Subject: Re: Axiom bibliography

--- Bob McElrath wrote:

> C Y [Cliff Yapp] wrote:
> > > The contents of the \cite{} should identify the
> > > paper, rather than the local bibliography ('axiombib') to look
> > > in. 
> > 
> > Well... I would prefer it that cite references axiombib first and
> > gets the URL from that, and if it is not present there goes 
> > elsewhere.
> 
> The local database would still be kept, and periodically updated from
> external database queries.  Sorry for the confusion -- I always
> intended that.  Solely external lookups would be slow and error 
> prone.  So all lookups would look in the local database first, then
> go to arXiv/ADS/etc if the requested entry isn't already in the 
> local database.

Cool!  In that case, it gets my vote!

> I was thinking this afternoon that the footnote could be "This
> citation is not in the database.  Reload to see it."  Where in
> between the server would be interrogating arXiv (etc) servers. 
> Or "This citation could not be found in any databases.  Click here
> to enter it manually."

I'm not sure what the limits of web browser interfacing would be, but I
imagine something like the travelocity site would be nice:

1.  If search local is successful, return immediately.
2.  If not, flash a "Reference not in local database, searching online
archives..." page while the search is going on.  Some kind of running
progress line like "Searching arXiv..."  "Searching ADS..."  etc. would
be nice but probably even more work.
3.  If search succeeds, return "Reference located, added to Axiom
database."  If it fails, return "Reference not found, please enter."

I take it we aren't going to worry too much about a particular paper
being "on topic?"  I guess in Axiom's case it would be hard to say with
certainty any particular paper couldn't be relevant.

I'm intrigued by the idea of a DOI number - something like that could
potentially be quite useful - but do arXiv papers, for example, have
DOI numbers assigned?  Also, I think DOI numbers might be inconvenient
and unintuitive for a \cite{} entry - I guess the best thing to do is
record a DOI number in the bibtex file if it exists, but don't use it
for the identity tag.

Maybe we should establish a pattern for choosing the tag for a paper. 
Something like the following:

1.  If available, use the tag from arXiv, ADS, or other database since
this will match others using those databases.  In the case of
duplication of a paper in differrent databases, we will need to
establish a priority.  I'm not familiar with all the options - can
someone suggest a logical a->b->c search priority for the various
databases out there?  Alternatively, we might use OAI conformance or
some other such criteria.

2.  If that the paper does not exist in any archive, we must have some
rule for creating a tag name that makes sense.  This will take a little
thought.  CiteSeer seems to like the work done by these folks:  Open
Archives Initiative http://www.openarchives.org/  I would suggest we
adopt whatever open conventions have been developed - maybe even create
a "Bibliography Howto" for inclusion in Axiom?  Also, if the OAI is
doing quality work that is relevant to our needs we can define priority
for database searches based on an archive's use of OAI-PMH standards -
check the OAI compliant databases first, then check other ones.

> > What about papers that are not listed in any of the major online
> > references?  I think we have to allow for an updated axiom.bib,
> > but I agree automating as much of it as possible through
> > connections with servers is a Good Thing.
> 
> Of course manual entry would be possible, but I hope that it would be
> rare.

Agreed :-).

> > > If you want to process a pamphlet in latex it's easy enough to
> > > extract the bibtex entries used and export them.
> > 
> > Maybe, but what if an online archive changes their format and
> > decides not to allow simple automation of bibtex entry downloads?
> > How will we store annotations?  I think a local solution that is
> > refreshed and updated periodically will be the best compromise -
> > we always have something that works locally (also for offline
> > editing, which does happen), but it is kept current with 
> > developments elsewhere.
> 
> Well that's an unfortunate possibility that would have to be dealt
> with. Fortunately, the number of databases is large.  But yes, the
> loss of a database would suck.

Is there some sort of automated way to check URLs included in bibtex
entries, in order to spot dead links?

> If that happened though we'd still have the local database of
> references *used* on the site.  We just wouldn't be able to obtain
> new ones.

OK, I get it now.  Sounds great!

\start
Date: Thu, 20 Apr 2006 06:43:28 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, list
Subject: Re: [ANN] Axiom Workshop 2006 -- Final Announcement

--- Martin Rubey wrote:

> Dear all,
> 
> this is the final announcement of the Axiom Workshop 2006 at the RISC
> in Hagenberg.

I suppose it's a tad late to mention this, but is there any chance
someone with a video-camera could record the talks and post them on the
Axiom website?  I saw this done with one of Richard Stallman's lectures
once and despite the large file size I found it a really interesting
video and well worth the download time.  I don't know if anyone is able
to do that (or if the Axiom server can even handle hosting it) but it
would be a great resource for those of us who can't afford to travel to
Europe.

\start
Date: Thu, 20 Apr 2006 11:54:10 -0500
From: Benjamin Kosnik
To: David Mentre
Subject: Re: [Axiom-mail] Axiom and linux distros

> Could you detail this point? By "cross-compilation", do you really
> mean like compiling on architecture i386 for arch ppc64? Why?

often times ppc64 hardware is unavailable, or slow.

This is a pretty common requirement.

\start
Date: Thu, 20 Apr 2006 10:49:10 -0700
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Axiom bibliography

C Y [Cliff Yapp] wrote:
> I take it we aren't going to worry too much about a particular paper
> being "on topic?"  I guess in Axiom's case it would be hard to say with
> certainty any particular paper couldn't be relevant.

That's a job we have to leave to the author of the page. ;)

> I'm intrigued by the idea of a DOI number - something like that could
> potentially be quite useful - but do arXiv papers, for example, have
> DOI numbers assigned?  Also, I think DOI numbers might be inconvenient
> and unintuitive for a \cite{} entry - I guess the best thing to do is
> record a DOI number in the bibtex file if it exists, but don't use it
> for the identity tag.

It seems *finding* doi's is hard and not-free:
    http://www.crossref.org/01company/pr/press021406.htm
(or, not-available-yet).  I seem to run into them a lot through the APS
Journals though.

As far as I know, arXiv papers do not have DOI identifiers until they
appear in a journal (at which point the same paper exists in many
databases -- journal, arXiv, SPIRES, etc).

As far as DOI being inconveninent and unintuitive -- all "unique
identifiers" are inconveninent and unintuitive.  My philosophy is that
it doesn't matter what kind of line noise the user has to cut/paste as
an ID, as long as it is short (<~ 15 characters) and the user can FIND
what he should type from something intuitive like the author's name.
(This is done via external search engines)

> Maybe we should establish a pattern for choosing the tag for a paper. 
> Something like the following:
> 
> 1.  If available, use the tag from arXiv, ADS, or other database since
> this will match others using those databases.  In the case of
> duplication of a paper in differrent databases, we will need to
> establish a priority.  I'm not familiar with all the options - can
> someone suggest a logical a->b->c search priority for the various
> databases out there?  Alternatively, we might use OAI conformance or
> some other such criteria.

Since bibtex entries can have any data at all, it should have multiple
entries if it is in multiple databases:
    doi = "10.1103/PhysRevLett.75.3969",
    eprint    = "hep-ph/0506151",
    url = "http://stacks.iop.org/0370-1328/73/912",
    adsbibcode = "1995Sci...269..198A",
    SLACcitation = "%%CITATION = PRPLC,117,75;%%",
    SPIRESbibcode = "McElrath:2005bp"
just to name a few.  Then the user can use \cite{hep-ph/0506151} or
\cite{1995Sci...269..198A} or \cite{10.1103/PhysRevLett.75.3969} and
they should all find the same article.  (Note the above examples do not
all refer to the same paper)

Then of course we have to worry about merging entries that were
retrieved from different sources, but refer to the same paper.

> 2.  If that the paper does not exist in any archive, we must have some
> rule for creating a tag name that makes sense.  This will take a little
> thought.  CiteSeer seems to like the work done by these folks:  Open
> Archives Initiative http://www.openarchives.org/  I would suggest we
> adopt whatever open conventions have been developed - maybe even create
> a "Bibliography Howto" for inclusion in Axiom?  Also, if the OAI is
> doing quality work that is relevant to our needs we can define priority
> for database searches based on an archive's use of OAI-PMH standards -
> check the OAI compliant databases first, then check other ones.

I'd just generate something random.  local:4748224 or some such.  who
cares what that string is?  You always have to do a search for the paper
anyway since no one memorizes things even as simple as "McElrath:2005bp"
anyway.

\start
Date: Thu, 20 Apr 2006 20:15:26 +0100
From: Peter Broadbery
To: Ralf Hemmecke
Subject: Re: "Please add new attributes" message when building aldor interface

On Wed, 2006-04-19 at 17:57 +0200, Ralf Hemmecke wrote:
>  > So it seems that my version of ATTREG.spad
> > was more recent than attrib.as.head. Humm it's strange since I did not
> > modify ATTREG.spad and I decompressed src_ador2.tgz after the full build
> > of Axiom.
> 
> I hope this all goes away soon. I have already started to move the Java 
> code to Aldor. Unfortunately, I have not made progress since several 
> weeks. :-(
> 

I've also started looking at this again - also not got very far, as time
seems to be a bit limited at the moment.  Feel free to ask questions
though.

Apologies for the ATTREG rule - a better method would be to generate the
list of attributes from the .spad file, but I didn't get round to doing
this.

>From memory, integrating it into the build (providing that one's allowed
to ignore details like bugs in older versions of make) should just be a
case of adding stanzas in src/Makefile for ${SRC}/aldor/Makefile and
aldordir - the algebra ones provide a reasonable model. 


\start
Date: Fri, 21 Apr 2006 00:44:55 -0400
From: Tim Daly
To: list
Subject: size issue with noweb

The noweb code is beginning to show a weakness.

I'm building a literate program for work. It now has 51785 lines
which format out to 1276 pages.

Every 10 lines of changes or so I save the program, and run a 
makefile that 
  1) extracts the latex
  2) latex the tex file
  3) latex the tex file again (for cross-ref)
  4) extracts the program
  5) compiles the program
  6) extracts the test cases
  7) runs the program on the test cases.

The process takes 20 seconds on a 3.2Ghz processor.
16 of those seconds (80% of the total time) involve noweb.

My program will eventually be a factor of 10 larger
(about 500k lines, 12k pages).

I'm not sure that noweb is up to the task. It clearly cannot scale.
Latex, a MUCH more complex program, swallows my document in one second.
I think it might be time to explore a noweb rewrite.

In particular, I'm beginning to think that we could use latex
syntax for chunks as in:

<<chunkname>>=
  foo
@

becomes

\begin{chunk}[chunkname]
  foo
\end{chunk}

and 

<<chunkname>>

becomes

\chunk{chunkname}

Code could still be extracted with a preprocessor but the 
latex piece would become native latex and could be formatted
by standard latex with only a .sty file. This completely 
eliminates the need for noweave.

\start
Date: Fri, 21 Apr 2006 12:07:00 +0700 (NOVST)
From: Andrey G. Grozin
To: Tim Daly
Subject: Re: size issue with noweb

On Fri, 21 Apr 2006, root wrote:
> In particular, I'm beginning to think that we could use latex
> syntax for chunks as in:
>
> <<chunkname>>=
>  foo
> @
>
> becomes
>
> \begin{chunk}[chunkname]
>  foo
> \end{chunk}
>
> and
>
> <<chunkname>>
>
> becomes
>
> \chunk{chunkname}
>
> Code could still be extracted with a preprocessor but the
> latex piece would become native latex and could be formatted
> by standard latex with only a .sty file. This completely
> eliminates the need for noweave.
I think this is a very good idea. I'd only propose to use

\begin{chunk}{chunkname}

because the parameter is not optional.

\start
Date: Fri, 21 Apr 2006 01:06:16 -0400
From: Tim Daly
To: Andrey G. Grozin
Subject: Re: size issue with noweb

excellent point.

this would be a two-pass process similar to the handling of \cite{}

\start
Date: 21 Apr 2006 08:25:22 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: [ANN] Axiom Workshop 2006 -- Final Announcement

Tim Daly writes:

> Martin,
> 
> Are there any plans to record the talks?

no. At least not from my part.

> Will papers be available?

Most of them are already:

I will post mine ("extended rate, more gfun") to the arxiv in mai and I
submitted it also to MathInfo 06, but it may well be rejected, of course.
A preliminary version is already on MathAction.

Bernhard Gittenberger's paper "extended admissible functions" is available on
his homepage http://dmg.tuwien.ac.at/geom/bibtexing/bgitten.html

Petr Hlineny, Nicolas Thiery and Carsten Schneider have all provided links at
MathAction.

Ralf Hemmecke's work is available through his homepage.

Antoine Hersen will do so after the workshop, I suppose.

\start
Date: Fri, 21 Apr 2006 09:24:26 +0200
From: David Mentre
To: Tim Daly
Subject: Re: size issue with noweb

Hello Tim,

2006/4/21, Tim Daly:
> The process takes 20 seconds on a 3.2Ghz processor.
> 16 of those seconds (80% of the total time) involve noweb.

Which part of noweb takes so much time? noweave? notangle? Both of them?

> My program will eventually be a factor of 10 larger
> (about 500k lines, 12k pages).

Would it be possible to have your program, or at least a document
having the same noweb structure, for tests?

Would it be possible to write a dummy program of the size of the final
one (10 times larger) but with expected noweb structure?

> I'm not sure that noweb is up to the task. It clearly cannot scale.
> Latex, a MUCH more complex program, swallows my document in one second.
> I think it might be time to explore a noweb rewrite.

Before a rewrite, we should understand where is exactly the congestion
point. From your message, I don't understand exactly what is going
wrong.

I can do some profiling but I need a test document.

> In particular, I'm beginning to think that we could use latex syntax for =
chunks

While I'm not against changing the syntax, I don't understand how a
syntax change would improve performance. Or do you assume that the
performance penalty is syntax related (ok, I've just understood that
this syntax change would eliminate the noweave processing)?


> <<chunkname>>=
>   foo
> @
>
> becomes
>
> \begin{chunk}[chunkname]
>   foo
> \end{chunk}
>
> and
>
> <<chunkname>>
>
> becomes
>
> \chunk{chunkname}
>
> Code could still be extracted with a preprocessor but the
> latex piece would become native latex and could be formatted
> by standard latex with only a .sty file. This completely
> eliminates the need for noweave.

This seems a reasonable idea to me. It should be easy to write some
Python or Perl to apply automatically this transformation.

Just one point: does noweave apply a specific treatment to "[[  ]]"
marks or is it handled by latex macros?

\start
Date: Fri, 21 Apr 2006 04:29:59 -0400
From: Tim Daly
To: David Mentre
Subject: Re: size issue with noweb

the idea is that we could eliminate noweave as a function
by using latex markup to specify the syntax. that eliminates
one half of the noweb functionality. this also has the feature
that pamphlets are simply latex documents with a special style
file and can be processed without noweb.

the [[ ]] syntax would need an "inline verbatim" kind of quoting
similar to what happens now (since [[]] gets replaced by latex code.
so 
  a sentence with [[quote me]] 
becomes
  a sentence with \iquote{quote me}

the notangle step is just a preprocessor step and can accept any
syntax. we could even unify this approach with Bill's 
\axiom and \reduce processing. 

i could write a lisp program to do the notangle step and
i believe it could be made MUCH faster.

unfortunately i cannot send you my current program as it is not
(yet?) open source. i'd have to get permission from work.

my best guess about the processing costs is the byte-by-byte 
pipelining in noweb. my program is written in common lisp and
used to also do read-char (byte at a time). now i do a read-sequence
and reduced the i/o costs below measurable values. noweb uses a lot
of awk-sed processing rather than a single C program and i think the
process does not scale.

\start
Date: Fri, 21 Apr 2006 17:40:54 +0900
From: Jean-Christophe Helary
To: Tim Daly
Subject: Re: size issue with noweb
Cc: David Mentre

Tim,

On a related note, I was wondering if such self documenting processes  
would not make the translation/localization a order of magnitude more  
difficult ?

I have not quit the idea of helping with localizing Axiom to French  
and I have been looking for ways to do that cleanly, but, just like  
for emacs I found the highest barrier to localization is the fact  
that the code and the documentation are pretty much one and the same  
in literate programming. Or Am I misunderstanding something ?

On 2006/04/21, at 17:29, root wrote:

> the idea is that we could eliminate noweave as a function
> by using latex markup to specify the syntax. that eliminates
> one half of the noweb functionality. this also has the feature
> that pamphlets are simply latex documents with a special style
> file and can be processed without noweb.

\start
Date: Fri, 21 Apr 2006 04:52:40 -0400
From: Tim Daly
To: Jean-Christophe Helary
Subject: Re: size issue with noweb
Cc: David Mentre

> 
> On a related note, I was wondering if such self documenting processes  
> would not make the translation/localization a order of magnitude more  
> difficult ?
> 
> I have not quit the idea of helping with localizing Axiom to French  
> and I have been looking for ways to do that cleanly, but, just like  
> for emacs I found the highest barrier to localization is the fact  
> that the code and the documentation are pretty much one and the same  
> in literate programming. Or Am I misunderstanding something ?

it depends on what level of localization you want to claim.

translating the axiom tutorial book is a static task of known size.

if you want the algebra read-eval-print loop to speak french 
you only need to change the internal messages, most of which
are collected in the s2-us.msgs file. some still need to be
collected.

if you want the hypertex browser to speak french then there is
an additional task of translating the browser pages. this is a
rather larger but not overwhelming task. this information is static.

if you want all of axiom to be translated into french this is
likely a huge, ongoing task. the system is slowly being converted
to self-documented code. this is a dynamic task.

so there are at least 4 different levels of translation that
would need to occur. personally i'd take them in the order listed
as that moves from the largest audience down to the smallest.

\start
Date: Fri, 21 Apr 2006 11:02:14 +0200
From: Frederic Lehobey
To: list
Subject: Re: size issue with noweb

Hi,

On Fri, Apr 21, 2006 at 05:40:54PM +0900, Jean-Christophe Helary wrote:

> On a related note, I was wondering if such self documenting processes 
> would not make the translation/localization a order of magnitude more 
> difficult ?

Actually, getting rid of noweb and replacing it with regular latex
syntax would make axiom books much easier to translate with tools like
po4a (see
http://lehobey-rennes.dyndns.org/dokuwiki/doku.php?id=doc:axiom:traduct=
ion#utiliser_po4a
from my message of Tue, 7 Mar 2006, Message-ID:
<20060307175300.GB7310@melusine>).

Books are not the whole story though.

\start
Date: Fri, 21 Apr 2006 18:13:20 +0900
From: Jean-Christophe Helary
To: list
Subject: Re: size issue with noweb

Thanks for the links Frederic.

Jean-Christophe

On 2006/04/21, at 18:02, Frederic Lehobey wrote:

> Hi,
>
> On Fri, Apr 21, 2006 at 05:40:54PM +0900, Jean-Christophe Helary 
> wrote:
>
>> On a related note, I was wondering if such self documenting processes
>> would not make the translation/localization a order of magnitude more
>> difficult ?
>
> Actually, getting rid of noweb and replacing it with regular latex
> syntax would make axiom books much easier to translate with tools like
> po4a (see
> http://lehobey-rennes.dyndns.org/dokuwiki/doku.php?
> id=doc:axiom:traduction#utiliser_po4a
> from my message of Tue, 7 Mar 2006, Message-ID:
> <20060307175300.GB7310@melusine>).
>
> Books are not the whole story though.

\start
Date: Fri, 21 Apr 2006 11:29:19 +0200
From: David Mentre
To: Tim Daly
Subject: Re: size issue with noweb

Tim,

2006/4/21, Tim Daly:
> the idea is that we could eliminate noweave as a function
> by using latex markup to specify the syntax. that eliminates
> one half of the noweb functionality.

I think this is a good idea.

Another point that worries me: for numbering of the code chunks and
their cross-indexing, noweb uses a lot of LaTeX machinery. I don't
know which part is comming from noweb.sty (which could be re-used
as-is) and which parts is generated by noweave.

> the [[ ]] syntax would need an "inline verbatim" kind of quoting
> similar to what happens now (since [[]] gets replaced by latex code.
> so
>   a sentence with [[quote me]]
> becomes
>   a sentence with \iquote{quote me}

ok. Writting the program doing this transformation might be a bit
tricky (the "[[[a][i]]]" case).

> unfortunately i cannot send you my current program as it is not
> (yet?) open source. i'd have to get permission from work.

If I find time, I'll try to make an obfuscation tool that keep the
noweb structure but replace content with meaningless one.

> my best guess about the processing costs is the byte-by-byte
> pipelining in noweb. my program is written in common lisp and
> used to also do read-char (byte at a time). now i do a read-sequence
> and reduced the i/o costs below measurable values. noweb uses a lot
> of awk-sed processing rather than a single C program and i think the
> process does not scale.

Using OProfile on a linux system would let you know exactly where the
time is spent. Of course, while not difficult, it takes a little time
to set up and doing the experiments. DTrace on a Solaris system would
also give useful info (if not better), however I've never used it. I
think DTrace has been recently ported to Linux.

In practical terms, beside just comments, do you need help on the
code? I could give a try to a notangle in Common Lisp but you would be
probably much more efficient than me (and the code would probably be
cleaner :-) . However, I could try to write a noweb->new-latex-syntax
filter in Python. What do you think of it?

\start
Date: Fri, 21 Apr 2006 08:55:25 -0500
From: Jay Belanger
To: Tim Daly
Subject: Re: size issue with noweb

Tim Daly writes:
...
> In particular, I'm beginning to think that we could use latex
> syntax for chunks as in:
>
> <<chunkname>>=
>   foo
> @
>
> becomes
>
> \begin{chunk}[chunkname]
>   foo
> \end{chunk}
>
> and
>
> <<chunkname>>
>
> becomes
>
> \chunk{chunkname}
>
> Code could still be extracted with a preprocessor but the
> latex piece would become native latex and could be formatted
> by standard latex with only a .sty file. This completely
> eliminates the need for noweave.
>
> Comments?

A while back, Dan Dill wrote TeX/Mathematica
(ftp://chem.bu.edu/pub/tex-mathematica-2.0), which does something
similar.  (I later hacked that into EMaxima.)  <<chunkname>> was still
<<chunkname>>, though.  I like \chunk{chunkname} better. 
The notangle part of TeX/Mathematica was written in Elisp, though.

\start
Date: Fri, 21 Apr 2006 11:42:03 -0400
From: Tim Daly
To: David Mentre
Subject: Re: size issue with noweb

> In practical terms, beside just comments, do you need help on the
> code? I could give a try to a notangle in Common Lisp but you would be
> probably much more efficient than me (and the code would probably be
> cleaner :-) . However, I could try to write a noweb->new-latex-syntax 
> filter in Python. What do you think of it?

until this massive project settles down i don't have the time to
undertake the project. at some point the little slices of noweb time
are eating away at my code-compile-check (CCC) loop. since this is the
main workday loop every second counts. at some point, probably when my
CCC loop hits 1 minute per change, it makes sense to stop real work,
code the lisp version of noweb, and then continue. since my
productivity is inversely related to the CCC time i need my CCC loop
to be instantaneous.

there is nothing like a large project to foster tool development :-)

\start
Date: Fri, 21 Apr 2006 14:11:22 -0400
From: Bill Page
To: list
Subject: RE: size issue with noweb
Cc: David Mentre

On April 21, 2006 11:42 AM Tim Daly (root) wrote:
> 
> David Mentre wrote: 
> > In practical terms, beside just comments, do you need help on
> > the code? I could give a try to a notangle in Common Lisp but 
> > you would be probably much more efficient than me (and the code
> > would probably be cleaner :-) . However, I could try to write a 
> > noweb->new-latex-syntax filter in Python. What do you think of
> > it?

Knuth's "web" syntax involving << ... >>, @ and [[ ... ]] is
certainly arcane, especially when compared to the TeX syntax
invented by the same author, but I think simply replacing one
with the other is not much of a gain. In fact I presume that
is why no one has bothered to do this before now.

When it comes down to it, "web" and noweb are pretty old
literate programming technology. Although literate programming
still is not very popular, there have been a few improvements
in the tools since the early days. I think if we are going to
change the literate programming tools used in Axiom, we would
be better off adopting a newer approach rather than re-inventing
old methods.

I think one such tool that such be seriously considered is
Leo.

http://webpages.charter.net/edreamleo/front.html

Leo even has tools for some noweb conversions.

> 
> until this massive project settles down i don't have the time to
> undertake the project. at some point the little slices of noweb
> time are eating away at my code-compile-check (CCC) loop. since
> this is the main workday loop every second counts. at some point,
> probably when my CCC loop hits 1 minute per change, it makes
> sense to stop real work, code the lisp version of noweb, and then
> continue. since my productivity is inversely related to the CCC
> time i need my CCC loop to be instantaneous.

Surely this way of programming must be extremely foreign to a
lisp programmer! Working with one large document and repeatedly
reprocessing the whole thing and recreating the program each
time you want to test something is certainly not the way most
people use lisp. Even when programming in less "dynamic"
languages like Python or even C, one usually modifies only a
small part of the program and does the minimum amount of
*incremental* work required to test it.

This is one of the problems with the traditional literate
programming tools. This was solved by the invention of 'untangle' -
the opposite of 'tangle' - which allows you to edit and work
with individual code chunks (or small sets of such chunks) and
to automatically maintain and update the larger literate
document of which these chunks form only a part. For example
Leo has this capability.

> 
> there is nothing like a large project to foster tool
> development :-)
> 

I think it would be a big mistake to waste time writing yet
another literate programming tool as part of the Axiom project.
But if even one other person here is interested in helping,
then I think I have finally got to the point where I want
to invest the time in putting the Axiom source in the Leo
environment. I don't expect that this will necessarily appeal
to everyone (There are some people here who are simply
fanatical about their choice of editor and programming
language :), but Leo's "directed acyclic graph" outline
seems almost tailor made for Axiom's highly interrelated
code - especially at the level of the Axiom library SPAD
and Aldor code.

Recently Simon Michael, the author of the ZWiki software on
which the Axiom Wiki is based, has experimentally moved the
source for ZWiki to Leo

http://leo.zwiki.org/FrontPage

This is a much smaller project than Axiom but I think working
with ZWiki's python code in this way is a good way to used
to Leo's approach to organizing a large project in the form
of an "outline"

http://en.wikipedia.org/wiki/Leo_%28editor%29

\start
Date: Fri, 21 Apr 2006 15:24:55 -0400
From: Tim Daly
To: Bill Page
Subject: Re: size issue with noweb
Cc: Douglas Troeger, David Mentre

> > until this massive project settles down i don't have the time to
> > undertake the project. at some point the little slices of noweb
> > time are eating away at my code-compile-check (CCC) loop. since
> > this is the main workday loop every second counts. at some point,
> > probably when my CCC loop hits 1 minute per change, it makes
> > sense to stop real work, code the lisp version of noweb, and then
> > continue. since my productivity is inversely related to the CCC
> > time i need my CCC loop to be instantaneous.

> Surely this way of programming must be extremely foreign to a
> lisp programmer! Working with one large document and repeatedly
> reprocessing the whole thing and recreating the program each
> time you want to test something is certainly not the way most
> people use lisp. Even when programming in less "dynamic"
> languages like Python or even C, one usually modifies only a
> small part of the program and does the minimum amount of
> *incremental* work required to test it.

Multiple files per program came about historically because
computers were limited in what they could process. Unix on
my pdp 11/40 couldn't handle large files. In fact, the unix
editor on the pdp 11/40 would die if a file exceeded 1/2
of available core memory (minus the editor/opsys/etc)
which effectively limited my files to about 8K bytes including
comments. 

These limitations generated linker overlays (thankfully 
unused), segment addressing (still bothering us in the x86),
#include noise, preprocessors, obscure library structures,
byte-by-byte file processing, sand-grain sized source files,
linker file formats, makefiles, and all manner of now-useless
tools and technologies.

If you work on a large program you need to be able to 
keep the organization in your head. If you use 1K C files as
your tool you end up grepping all over the place to find the
right include file or the C source file. Worse yet is the 
include hell (which is the key reason why axiom is not yet
running on a mac) where each opsys changes the order of these
tiny include files.

My program is currently over 50k lines and 1200 pages and
I don't feel any strain at all while writing it. I estimate
it will be finished at about 500k lines and 12k pages. If
I did all that in the C or Java style of tiny files I'd have
a dozen directories (really just virtual chapter/sections)
and hundreds of files with associated makefiles, include
files, test cases, and, oh yes, maybe some documentation.

My head is a very small place and I need to optimize it.

My monolithic file style has evolved over the years into an
extremely productive environment. At any time I know that my
program has up to date documentation, test cases, and code.
I know it works because I just completely rebuilt it a minute
ago and any change I've made to the system happened in the
last minute. I can send you the single file and know that
it works and is fully documented and tested. And I can do
this at any moment of the day. Since I rarely change more
than 10 lines before completely rebuilding, testing, and
checking the document output I know what just broke (since
the test case is in there), when and how I broke it, and the
broken source is still in front of me.

Furthermore, since the file is a document I'm constantly
reminded that I'm writing for people, not the machine. The
combination of emacs, a shell buffer, latex, and xdvi keeps
me aware of the structure of the problem as well as the
structure of the program. There is nothing quite like a
Chapter/Section organization to help organize a program
as well as my thinking. The literate programming tecnology
allows me to reorganize the document and the program at will.
Thus I can break out a pile of code into a new section if it
becomes rich enough in function to warrent its own place.

Tools affect the way you think about a problem and even
what you can think about. We need to stop living with the
historical limitations of tools from my childhood and start
working with real, industrial strength tools. We'll shortly
have a 1THz processor with 1TByte of memory. Why limit our
thinking to 1960s technology?

\start
Date: Fri, 21 Apr 2006 23:30:41 +0200
From: David Mentre
To: Tim Daly
Subject: Re: size issue with noweb

Tim,

David Mentre writes:

>> unfortunately i cannot send you my current program as it is not
>> (yet?) open source. i'd have to get permission from work.
>
> If I find time, I'll try to make an obfuscation tool that keep the
> noweb structure but replace content with meaningless one.

I hacked a little noweb obfuscation tool in Python, attached to this
email.

It removes all code, while keeping the noweb structure (code chunk names
are MD5 of original names) and initial size. Regarding latex comments,
it is more difficult to obfuscate properly without writing a latex
parser (which I don't want to write :-). So I obfuscate all individuals
words. That should not mess to much latex commands and remove enough
meaning.

Could you try it on your file:
  ./noweb-obfuscation.py file.pamphlet

If you find the result safe enough, could you send it to me?

Best wishes,
d.
-- 
David Mentre -- http://wiki.axiom-developer.org/FrontPage


--=-=-=

#!/usr/bin/python

import md5
import sys
import re

chunk_re = re.compile("^(<<.+?>>=.*?\n@\s*)$", re.MULTILINE | re.DOTALL)
chunk_components_re = re.compile("^<<(.+?)>>=(.*?\n)@\s*$",
                                 re.MULTILINE | re.DOTALL)

chunk_call_re = re.compile("(<<.+?>>)")
chunk_call_name_re = re.compile("<<(.+?)>>")

word_re = re.compile(r'[\s./][a-zA-Z0-9]+?[\s./]')

def log(txt):
    sys.stderr.write(txt)

def md5_str(str):
    h = md5.new()
    h.update(str)
    return h.hexdigest()

def obfuscate_code_string(str):
    s = ""
    for i in range(0, len(str)):
        if str[i] != '\n':
            s += 'a'
        else:
            s += '\n'
    return s

def obfuscate_code(text):
    calls = re.split(chunk_call_re, text)
    for s in calls:
        m = re.match(chunk_call_name_re, s)
        if m != None:
            print "<<%s>>" % md5_str(m.group(1)),
        else:
            print obfuscate_code_string(s),
        
def obfuscate_comment(text):
    def word_repl(match_obj):
        return obfuscate_code_string(match_obj.group(0))
    t = re.sub(word_re, word_repl, text)
    print t,

def obfuscate_file(filename):
    f = open(filename, 'r')
    file_content = f.read()
    f.close()

    splitted = re.split(chunk_re, file_content)
    for part in splitted:
        m = re.match(chunk_components_re, part)
        if m != None:
            chunk_name = m.group(1)
            # a code chunk
            if chunk_name != "*":
                print "<<%s>>=\n" % md5_str(m.group(1)),
            else:
                print "<<*>>=\n",
            obfuscate_code(m.group(2))
            print "@\n",
        else:
            # some comment
            obfuscate_comment(part)

obfuscate_file(sys.argv[1])


\start
Date: Fri, 21 Apr 2006 18:48:00 -0400
From: Tim Daly
To: David Mentre
Subject: Re: size issue with noweb

umm, that would probably be unwise in the extreme.  you and i know
that it's obfuscated but that's a detail that would be overlooked by
human resources.

try consing together a few dozen axiom files. that should be large
enough to show the effect. and it is valid input.

\start
Date: Sat, 22 Apr 2006 01:17:56 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Status of bugs on IssueTracker

Hi Tim,

Can you look at the following issues when time permits ?

Some of them can probably be closed.

# old (?) pending status
===========================================================

#109 hyperdoc uncompress failed
http://wiki.axiom-developer.org/109HyperdocUncompressFailed

#153 make install does not install a needed libdb.text for HyperDoc
http://wiki.axiom-developer.org/153MakeInstallDoesNotInstallANeededLibdbTextForHyperDoc


# can probably be closed
===========================================================

#105 integrate(z^3000, z=0..1)
http://wiki.axiom-developer.org/105IntegrateZ3000Z01

#190 Compile fail on Fedora Core 4
http://wiki.axiom-developer.org/190CompileFailOnFedoraCore4

#127 Building axiom from source fails on my Fedora Core 3
http://wiki.axiom-developer.org/127BuildingAxiomFromSourceFailsOnMyFedoraCore3

#266 Axiom binary for Fedora Core 4 does not start properly
http://wiki.axiom-developer.org/266AxiomBinaryForFedoraCore4DoesNotStartProperly

#33 GCL fails to compile on Fedora Core 3
http://wiki.axiom-developer.org/33GCLFailsToCompileOnFedoraCore3

#28 GCL 2.6.5 on FC3
http://wiki.axiom-developer.org/28GCL265OnFC3

#30 make install: no such file or directory
http://wiki.axiom-developer.org/30MakeInstallNoSuchFileOrDirectory

#46 termio vs ptermio (in src/clef/edible.c)
http://wiki.axiom-developer.org/46TermioVsPtermioInSrcClefEdibleC

#129 patch-32 fails to display 3D graphics
http://wiki.axiom-developer.org/129Patch32FailsToDisplay3DGraphics

#126 /bin/sh vs /bin/bash scripting inconsistancy
http://wiki.axiom-developer.org/126BinShVsBinBashScriptingInconsistancy


# Humm, the next ones, I don't know
----------------------------------------------------------

#57 Databases are not copied back
http://wiki.axiom-developer.org/57DatabasesAreNotCopiedBack

#62 make GCL= does not override properly
http://wiki.axiom-developer.org/62MakeGCLDoesNotOverrideProperly

#80 Semantic Errors when building algebra
http://wiki.axiom-developer.org/80SemanticErrorsWhenBuildingAlgebra

# does not crash with #196 ')set functions compile on' fixed 
# but does not work. Is the code correct?
#156 Axiom crashes when compiling simple Taylor code
http://wiki.axiom-developer.org/156AxiomCrashesWhenCompilingSimpleTaylorCode

# AXIOM variable probably not set
#147 axiom-Apr2005-src.tgz fails on fedora 3
http://wiki.axiom-developer.org/147AxiomApr2005SrcTgzFailsOnFedora3
                         and
#151 Environment variable AXIOM
http://wiki.axiom-developer.org/151EnvironmentVariableAXIOM


#277 Patches for GCL on Linux
http://wiki.axiom-developer.org/277PatchesForGCLOnLinux

\start
Date: 22 Apr 2006 08:14:09 +0200
From: Martin Rubey
To: Gregory Vanuxem
Subject: Re: Status of bugs on IssueTracker

Dear "greg",

I just wanted to tell you that I highly value your work of updating the
issues. I noticed this already some time ago, but I didn't get round to say

MERCI BEAUCOUP !

yet.

Martin

Vanuxem Gr=E9gory Gregory Vanuxem writes:

> Hi Tim,
>
> Can you look at the following issues when time permits ?
>
> Some of them can probably be closed.
>
> Cheers,
>
> Greg
>
> # old (?) pending status
> =========================
==========================
==========
>
> #109 hyperdoc uncompress failed
> http://wiki.axiom-developer.org/109HyperdocUncompressFailed
>
> #153 make install does not install a needed libdb.text for HyperDoc
> http://wiki.axiom-developer.org/153MakeInstallDoesNotInstallANeededLibdbT=
extForHyperDoc
>
>
> # can probably be closed
> =========================
==========================
==========
>
> #105 integrate(z^3000, z=0..1)
> http://wiki.axiom-developer.org/105IntegrateZ3000Z01
>
> #190 Compile fail on Fedora Core 4
> http://wiki.axiom-developer.org/190CompileFailOnFedoraCore4
>
> #127 Building axiom from source fails on my Fedora Core 3
> http://wiki.axiom-developer.org/127BuildingAxiomFromSourceFailsOnMyFedora=
Core3
>
> #266 Axiom binary for Fedora Core 4 does not start properly
> http://wiki.axiom-developer.org/266AxiomBinaryForFedoraCore4DoesNotStartP=
roperly
>
> #33 GCL fails to compile on Fedora Core 3
> http://wiki.axiom-developer.org/33GCLFailsToCompileOnFedoraCore3
>
> #28 GCL 2.6.5 on FC3
> http://wiki.axiom-developer.org/28GCL265OnFC3
>
> #30 make install: no such file or directory
> http://wiki.axiom-developer.org/30MakeInstallNoSuchFileOrDirectory
>
> #46 termio vs ptermio (in src/clef/edible.c)
> http://wiki.axiom-developer.org/46TermioVsPtermioInSrcClefEdibleC
>
> #129 patch-32 fails to display 3D graphics
> http://wiki.axiom-developer.org/129Patch32FailsToDisplay3DGraphics
>
> #126 /bin/sh vs /bin/bash scripting inconsistancy
> http://wiki.axiom-developer.org/126BinShVsBinBashScriptingInconsistancy
>
>
> # Humm, the next ones, I don't know
> ----------------------------------------------------------
>
> #57 Databases are not copied back
> http://wiki.axiom-developer.org/57DatabasesAreNotCopiedBack
>
> #62 make GCL= does not override properly
> http://wiki.axiom-developer.org/62MakeGCLDoesNotOverrideProperly
>
> #80 Semantic Errors when building algebra
> http://wiki.axiom-developer.org/80SemanticErrorsWhenBuildingAlgebra
>
> # does not crash with #196 ')set functions compile on' fixed
> # but does not work. Is the code correct?
> #156 Axiom crashes when compiling simple Taylor code
> http://wiki.axiom-developer.org/156AxiomCrashesWhenCompilingSimpleTaylorC=
ode
>
> # AXIOM variable probably not set
> #147 axiom-Apr2005-src.tgz fails on fedora 3
> http://wiki.axiom-developer.org/147AxiomApr2005SrcTgzFailsOnFedora3
>                          and
> #151 Environment variable AXIOM
> http://wiki.axiom-developer.org/151EnvironmentVariableAXIOM
>
>
> #277 Patches for GCL on Linux
> http://wiki.axiom-developer.org/277PatchesForGCLOnLinux

\start
Date: Sat, 22 Apr 2006 09:52:46 +0200
From: David Mentre
To: Tim Daly
Subject: Re: size issue with noweb

Hello Tim,

Tim Daly writes:

> umm, that would probably be unwise in the extreme.  you and i know
> that it's obfuscated but that's a detail that would be overlooked by
> human resources.

Yep. I thought at this issue afterwards. Never underestimate the human
factor. :)

> try consing together a few dozen axiom files. that should be large
> enough to show the effect. and it is valid input.

Yes. As usual, I ran for the complicated solution while a simpler one
existed.


Anyway, you have now some Python code that is able to parse noweb
files. :)

\start
Date: Sat, 22 Apr 2006 22:16:04 -0400
From: Alfredo Portes
To: Bill Page
Subject: Latest Release

The latest build for Doyen has been released and uploaded to
axiom-developer. The docs have been tested and have been used to
successfully reproduced doyen on two separate machines. Please feel free to
test the latest iso and the build procedure for the Live-CD.

http://alfredo.axiom-developer.org/doyen/doyen-42206.iso

best regards,

Wilken

--
Jose Alfredo Perez

\start
Date: 23 Apr 2006 09:26:20 +0200
From: Martin Rubey
To: list
Subject: What Axiom is really good at in comparison with other CAS

Dear all,

I suppose that one of the questions I will have to answer at the Axiom Workshop
is, what Axiom is really good at in comparison with other CAS:

Mathematically and Developmentwise.

I have created an appropriate page. PLEASE visit and enter your thoughts with
short commentary -- especially with respect to discrete mathematics.

http://wiki.axiom-developer.org/SandBoxAxiomStrenghts

Note that I'm well aware of the fact that some abilities may be
contoversial. Thus, for presentation, I will pick the most uncontroversial
thoughts, of course.

\start
Date: Sun, 23 Apr 2006 13:25:23 -0400
From: Tim Daly
To: list
Subject: Summer of Code application
Cc: Heow Eide-Goodman, Bill Page

I would like to submit Axiom as a Summer of Code project for 2006.

We successfully participated last year as a subproject of the LispNYC group.

This year, in preparation for participation in the Summer of Code program,
we have collected and published a series of possible projects at

  http://wiki.axiom-developer.org/SummerOfCode

Axiom is a large, general purpose computer algebra system. It used to 
be a commercial competitor to Mathematica and Maple. It is now free and
open source (Modified BSD). It has been active since 2001 and is hosted
at both Sourceforge and Savannah (FSF site). See

  http://wiki.axiom-developer.org
  http://savannah.nongnu.org/projects/axiom
  http://sourceforge.net/projects/axiom

Since Axiom is a large project we have a wide range of possible areas
of contribution from documentation all the way to algebra code. There
are projects for user interface, literate programming, graphics, etc.

We are able to review student proposals as well as direct projects
selected from our proposal list. We have recently established a 
connection to RISC-Linz (Research in Symbolic Computation in Austria),
a department at the University of Linz. In addition we have had an
ongoing student collaboration with the City College of New York's
CAISS laboratory working on promoting Axiom as a science platform.
See 

  http://daly.axiom-developer.org/doyen

but we could make much faster project if we could find funding for
student participation.

We have tried to create an Axiom Foundation to pay for work on supported
projects but that has not been successful. Open source funding is always
a challenge.

\start
Date: Mon, 24 Apr 2006 09:53:00 -0400
From: Tim Daly
To: list
Subject: axiom opportunity

http://video.google.com/videoplay?docid=9203462148706105599

It appears that China has introduced a debian-based $146 (U.S. dollar)
computer called "Municator". 

Axiom has been shown to run on Yellow Dog, which is a chinese 
language version of linux.

I think we need to start positioning ourselves to be the computer
algebra system for these linux systems. Which implies we spend
some time trying to get axiom working in conjunction with things
like Open Office.

Open Office has a component that creates mathematical equations
but does little else. We could use this component as a front end
and overtake its current use by adding a combination of tools
under the math component.

We could combine open office math with the lex editor (for literate
programs) and axiom. Someone could study the various components and
do a high level design document that would coordinate combining the
components. Are there any 'software designers' in on the mailing list?

A widespread adoption of an axiom/OO math tool would also raise the
issue of B-natural rather quickly since people will certainly 
complain about user interaction issues.

Trying to work with open office as a front-end will certainly
force axiom's user interface to mature rapidly.

Comments?

\start
Date: Mon, 24 Apr 2006 10:13:43 -0400
From: Tim Daly
To: list
Subject: axiom opportunity

http://www.japancorp.net/Article.Asp?ART_ID=9507

Another article on the axiom opportunity

\start
Date: Mon, 24 Apr 2006 10:52:24 -0400
From: Tim Daly
To: list
Subject: issac 2006

Is anyone else on this list planning to attend either
ISSAC 2006 or the Manuel Bronstein conference?

\start
Date: Mon, 24 Apr 2006 14:44:34 -0400
From: Bill Page
To: Tim Daly
Subject: RE: issac 2006

On Monday, April 24, 2006 10:52 AM Tim Daly (root) wrote:
>
> Is anyone else on this list planning to attend either
> ISSAC 2006 or the Manuel Bronstein conference?
>

For me it is a definite *maybe* for both. :)

\start
Date: Mon, 24 Apr 2006 15:43:52 -0400
From: William Sit
To: Tim Daly
Subject: Re: issac 2006

root wrote:

> Is anyone else on this list planning to attend either
> ISSAC 2006 or the Manuel Bronstein conference?

For me, yes to both.

\start
Date: Tue, 25 Apr 2006 09:17:58 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: issac 2006

I'll be at the Bronstein conference.

Ralf

On 04/24/2006 04:52 PM, root wrote:
> Is anyone else on this list planning to attend either
> ISSAC 2006 or the Manuel Bronstein conference?
> 
> Tim

\start
Date: Tue, 25 Apr 2006 04:19:15 -0700
From: Antoine Hersen
To: Tim Daly
Subject: Re: axiom opportunity

------=_Part_12791_15778870.1145963955158

>
> Axiom has been shown to run on Yellow Dog, which is a chinese
> language version of linux.


Yellow Dog is PPC version of RedHat :
http://www.terrasoftsolutions.com/products/ydl/

Red Flag is what we perceived as the Chinese Linux :
http://www.redflag-linux.com/eindex.html

I think we need to start positioning ourselves to be the computer
> algebra system for these linux systems. Which implies we spend
> some time trying to get axiom working in conjunction with things
> like Open Office.


We should try to have Axiom in is current form available as a package for
all the popular distribution from there respective official repository. Tha=
t
is according to http://distrowatch.com/ in order :

Rank Distribution H.P.D*  1 Ubuntu <http://distrowatch.com/ubuntu> 2659[ima=
ge:
>]  2 SUSE <http://distrowatch.com/suse> 1770[image: =]  3
Fedora<http://distrowatch.com/fedora>
1383[image: >]  4 Mandriva <http://distrowatch.com/mandriva> 1330[image: <]
5 MEPIS <http://distrowatch.com/mepis> 974[image: >]  6 Damn
Small<http://distrowatch.com/damnsmall>
915[image: >]  7 Debian <http://distrowatch.com/debian> 810[image: >]  8
KNOPPIX <http://distrowatch.com/knoppix> 695[image: =]  9
Gentoo<http://distrowatch.com/gentoo>
679[image: >]  10 PCLinuxOS <http://distrowatch.com/pclinuxos> 655[image: >=
]
11 Slackware <http://distrowatch.com/slackware> 593[image: >]  12
FreeBSD<http://distrowatch.com/freebsd>
560
I think it is only the case for Debian right know.

Open Office has a component that creates mathematical equations
> but does little else.


Koffice has one too, that might be easier to extract than  touching
OpenOffice.

QT/KDE could also be a good choice for a cross platform UI has open source
version are available for Linux/Win/Mac


We could use this component as a front end
> and overtake its current use by adding a combination of tools
> under the math component.
>
> We could combine open office math with the lex editor (for literate
> programs) and axiom.


I did not have success for googling for "lex editor" can you post a url
please ?


Someone could study the various components and
> do a high level design document that would coordinate combining the
> components. Are there any 'software designers' in on the mailing list?


Kind of. But did we decided on a set of desired capability ?

A widespread adoption of an axiom/OO math tool would also raise the
> issue of B-natural rather quickly since people will certainly
> complain about user interaction issues.


Axiom/OO sound strange, I think there is a plugin to use Mupad with Ms
Office anybody has used this system ?

Trying to work with open office as a front-end will certainly
> force axiom's user interface to mature rapidly.


There will be the problem of  Latex, that might be a lot of works to male O=
O
parse Latex.

\start
Date: Tue, 25 Apr 2006 14:31:38 +0200
From: David Mentre
To: Antoine Hersen
Subject: Re: axiom opportunity

Hello,

2006/4/25, Antoine Hersen:
> > Trying to work with open office as a front-end will certainly
> > force axiom's user interface to mature rapidly.
>
> There will be the problem of  Latex, that might be a lot of works to male=
 OO parse Latex.

On that side, a reasonable approach would be to add a new Axiom output
format suitable for computer parsing (for example as sexp). One could
use a standardized format, like MathML, but I am affraid of its
complexity (that's said, that does not prevent us to look at how
MathML has defined its building blocks).

Regarding initial Tim question: OOo has a documented API but might not
be suited to create new User Interface components. Moreover, its
output is quite awful[1]. For the 30 years horizon, I would much
prefer invest my time in an easily deployable interface (i.e.
HTML/Javascript) and/or a innovative and good looking interface (i.e.
a combination of TeXmacs and the one Tim is always giving as example,
with drag&drop). OOo is not one of them.

[1] http://www.openoffice.org/product/pix/math-big.png

\start
Date: 25 Apr 2006 14:51:26 +0200
From: Martin Rubey
To: David Mentre
Subject: Re: axiom opportunity

I think tex4ht can also do openoffice:

http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn3.html#QQ1-3-10

\start
Date: Tue, 25 Apr 2006 06:45:07 -0700 (PDT)
From: Cliff Yapp
To: Antoine Hersen, Tim Daly
Subject: Re: axiom opportunity

> > I think we need to start positioning ourselves to be the computer
> > algebra system for these linux systems. Which implies we spend
> > some time trying to get axiom working in conjunction with things
> > like Open Office.

Tim, do you mean have Axiom available as a "plug-in" to OpenOffice, or
use the OpenOffice mathematical editing environment in our own
interface?

> > Open Office has a component that creates mathematical equations
> > but does little else.
> 
> Koffice has one too, that might be easier to extract than  touching
> OpenOffice.

I doubt we want to extract components from these setups for a
stand-alone interface, although perhaps they are more modular than I
think.
 
> QT/KDE could also be a good choice for a cross platform UI has open
> source version are available for Linux/Win/Mac

If we want to take the shortest target to a good looking cross platform
Math GUI I would agree QT is a logical choice, and in that case Koffice
might indeed have useful code for our purposes once they port to QT4. 
(QT3 is not free on Windows, and apparently has some problems with
printing on Linux.)  The thing to keep in mind is that KOffice, by
design, builds off of the KDE enviornment.  I doubt we want to depend
on that for a working GUI, although I certainly have no objections to
taking advantage of it if it is available.  We might be able to use the
display and IO components of the math editing though.

For the record, there exists a (very) basic set of bindings for QT/Lisp
using CFFI:  http://members.aon.at/lispolos/  Of course GCL doesn't yet
support CFFI so this isn't of immediate use, but it might be a
worthwhile direction to pursue down the road.  I would love to see an
expansion of this work be a SoC project.

Camm, if you're listening, how much work is involved with getting CFFI
functional on GCL?  Would it need ANSI mode?

Anyway, I agree that we need to first define what we want an interface
to do/be.  Also, if I do a little crystal ball gazing, I think what
will eventually happen is that one or more open source CASs will sprout
a wide variety of interfaces integrating them into office suites,
editors, science/educational programs, etc.  EMaxima was in effect an
integration of Maxima into LaTeX documents, and I found that quite
useful, so I suspect we will see many of these types of things develop
gradually over time.

> > We could use this component as a front end
> > and overtake its current use by adding a combination of tools
> > under the math component.
> >
> > We could combine open office math with the lex editor (for literate
> > programs) and axiom.

Uh - do you mean the Leo editor?

> I did not have success for googling for "lex editor" can you post a
> url please ?
> 
> > Someone could study the various components and
> > do a high level design document that would coordinate combining the
> > components. Are there any 'software designers' in on the mailing
> > list?
>  
> Kind of. But did we decided on a set of desired capability ?

I would argue we're just at the beginning of that process.  Also, there
are some things I would worry about - for example, how does one do
interactive plotting in OpenOffice?  What about automatic line
breaking?  We still have no truly robust solution for line breaking (it
is a Hard Problem in general) and while we have a variety of ways that
work for most common cases I'm not sure how to use even those in
OpenOffice.

> > A widespread adoption of an axiom/OO math tool would also raise the
> > issue of B-natural rather quickly since people will certainly
> > complain about user interaction issues.

Very true.  But don't we need an open Aldor in order to be able to push
B-natural forward?  I thought we had reached the decision that a
language improvement was needed to do B-natural correctly? 
 
> Axiom/OO sound strange, I think there is a plugin to use Mupad with
> Ms Office anybody has used this system ?

Can't say that I have - I take it you're thinking of this? 
http://www.sciface.com/main.php?menu=2&ID=66760

It certainly looks interesting.

> > Trying to work with open office as a front-end will certainly
> > force axiom's user interface to mature rapidly.
> 
> There will be the problem of  Latex, that might be a lot of works
> to male OO parse Latex.

Maxima had someone who did work on this - it looks like the better way
is to teach Axiom to output OpenOffice math expressions.  I have no
idea how much work this would be.

\start
Date: Tue, 25 Apr 2006 11:05:09 -0400
From: Bill Page
To: David Mentre
Subject: RE: axiom opportunity

On Tuesday, April 25, 2006 8:32 AM David MENTRE wrote:
> [Open Office ...]
> On that side, a reasonable approach would be to add a new Axiom
> output format suitable for computer parsing (for example as sexp).
> One could use a standardized format, like MathML, but I am afraid
> of its complexity (that's said, that does not prevent us to look
> at how MathML has defined its building blocks).
>

I think jsMath as an alternative to MathML has continued to
evolve and mature very rapidly:

http://www.math.union.edu/~dpvc/jsMath/changes.html

It uses just a subset of LaTeX embedded in HTML.

For use in a graphical user interface based on web browser
technology I still consider jsMath quite superior to MathML
in ease of use, compatibility and even performance.

> Regarding initial Tim question: OOo has a documented API but
> might not be suited to create new User Interface components.
> Moreover, its output is quite awful[1].

OpenOffice is a very good alternative to Microsoft Office and
I think that is really about as far as it goes... :( At work I
make this recommendation to everyone who comes to me with a
problem invoving Microsoft Word. But I think serious authors
who use a lot of mathematics expect more than what OpenOffice
and Word can provide. So at most I think, we should try only
to make it relatively easy for someone to import a document
containing mathematics generated by Axiom into OpenOffice. I
really can not imagine actually using OpenOffice as the primary
user interface.

> For the 30 years horizon, I would much prefer invest my time
> in an easily deployable interface (i.e. HTML/Javascript) and/or
> a innovative and good looking interface (i.e. a combination of
> TeXmacs and the one Tim is always giving as example, with
> drag&drop). OOo is not one of them.
>

I agree. TeXmacs is a very interesting platform that has a
lot of potential but it needs more work done on the Axiom side
to really exploit it fully. TeXmacs is a bit slow and it's user
interface is a little weird (especially compared to what Microsoft
Windows users are used to), I think it can be acceptable for
a lot of potential users of Axiom. Plus it has interfaces for
many other open source (and even some commercial) math packages.
But one trouble with TeXmacs is that the developer base is very
small and it's source code is quite idiosyncratic - which makes
it hard for new developers to make even simple changes.

I personally still like the HTML/Javascript option the best.
One reason it is attractive to me is because it scales well
from desktop to online collaborative web environments. In 30
years time I am convinced that more and more research and
development will be done using online collaborative tools.
It is just not possible for individuals to build tools more
complex than Axiom is right now using the tools developed
30 years ago. It most be possible for people to work together,
fluently share and pool their work. They need new and more
powerful tools that they trust which will hopefully grow out
of the work on source code version control systems today.

Which reminds me to mention:

  https://launchpad.net

Take a look at:

  https://launchpad.net/products/?text=axiom

and

  https://launchpad.net/distros/ubuntu/dapper/+source/axiom

This system has some important features that Savannah and
SourceForge do not have (yet). See for example the online
support for translation, "new generation" revision control
system, specification tracking system and bounty incentives.

\start
Date: Tue, 25 Apr 2006 09:49:54 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: axiom opportunity
Cc: David Mentre

Page, Bill [Bill Page] wrote:
> On Tuesday, April 25, 2006 8:32 AM David MENTRE wrote:
> > [Open Office ...]
> > On that side, a reasonable approach would be to add a new Axiom
> > output format suitable for computer parsing (for example as sexp).
> > One could use a standardized format, like MathML, but I am afraid
> > of its complexity (that's said, that does not prevent us to look
> > at how MathML has defined its building blocks).

The most basic building blocks of MathML can be added fairly easily.
You need a character table, and know how to do fractions, roots, and
sub/superscripts.  I would think this would be a day or two of work, but
would be a big step in allowing evolution to start.  Once it "basically"
works, others can add pieces that are missing, and think about whether a
more well-thought-out design is required.

I've written a TeX->MathML converter (in python) in the last few weeks,
and been surprised that it's not nearly as hard as I thought.  The basic
rules are easy.  Mark it as experimental and let it go.
./src/algebra/tex.spad.pamphlet is only 709 lines.

> I think jsMath as an alternative to MathML has continued to
> evolve and mature very rapidly:
> 
> http://www.math.union.edu/~dpvc/jsMath/changes.html
> 
> It uses just a subset of LaTeX embedded in HTML.
> 
> For use in a graphical user interface based on web browser
> technology I still consider jsMath quite superior to MathML
> in ease of use, compatibility and even performance.

Uh...Bill..."performance"?  I've done quite a few benchmarks and jsMath
is a dog when it comes to speed.  Davide and I have been discussing ways
to cache jsMath output to improve speed.  (He sent me an experimental
cache a few days ago that I haven't had a chance to look at yet...)
jsMath requires the browser to draw each sub-component of an expression
in a hidden <div> so that it can measure its metrics.  This is very slow
compared to just reading the metrics from the font.

jsMath is a good transition tool, and Davide hopes to evolve it to have
a MathML output mode, but it is by no means fast.

In the long term the solution to math on the web is MathML.  I think the
sooner we (and the world) embrace this fact, and stop spending all our
efforts on stop-gap solutions, the better we will be and the quicker we
can advance.  Furthermore mathematics needs huge character sets.  Moving
to unicode (implied by the move to MathML) will be a huge boon to math
since we can use all kinds of characters and operators outside of ASCII.

The Really Big Problem with MathML is fonts.  FYI the STIX fonts project
plans a beta release in the next few weeks: http://www.stixfonts.org/.
The addition of this font, and its distribution with browsers will
remove most of the problems with MathML, and it will begin to take off
since every Firefox/Mozilla user will be able to "see" MathML without
jumping trough the extra hoops of installing fonts, as is currently
required.  Axiom should jump on this opportunity.

\start
Date: Tue, 25 Apr 2006 13:25:40 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: axiom opportunity
Cc: David Mentre

On Tuesday, April 25, 2006 12:50 PM Bob McElrath wrote:
> ...
> Bill Page wrote:
> > I think jsMath as an alternative to MathML has continued to
> > evolve and mature very rapidly:
> >
> > http://www.math.union.edu/~dpvc/jsMath/changes.html
> >
> > It uses just a subset of LaTeX embedded in HTML.
> >
> > For use in a graphical user interface based on web browser
> > technology I still consider jsMath quite superior to MathML
> > in ease of use, compatibility and even performance.
>
> Uh...Bill..."performance"?  I've done quite a few benchmarks
> and jsMath is a dog when it comes to speed.

Could you point me to some examples of these benchmarks?
Identical pages rendered as MathML and jsMath? Are there
some cases that are especially bad? Worse case?

I have not done any rigorous tests but my experiments using
FireFox 1.5.0.2 on Windows makes me feel jsMath has the lead -
although both seem likely "fast enough" for the kinds of uses
I have in mind, e.g. rendering a single "page" of HTML online -
either from a web site or from a local copy of Axiom. Such a
"page" might contain say at most 10 equations and maybe 20
embedded symbols.

When working with the MathML output of tex4ht I was astounded
by the enourmous size of the MathML pages generated for quite
simple Axiom output. It seems to me that much of the performance
is dominated by the network and (perhaps) XML parsing.

> Davide and I have been discussing ways to cache jsMath output
> to improve speed.  (He sent me an experimental cache a few
> days ago that I haven't had a chance to look at yet...)
> jsMath requires the browser to draw each sub-component of an
> expression in a hidden <div> so that it can measure its metrics.
> This is very slow compared to just reading the metrics from the
> font.
>

Doing what you can to cache this information makes sense to
me. Even sending jsMath itself down the line takes a serious
amount of time and we should be careful to make sure the
browser is caching it.

> jsMath is a good transition tool, and Davide hopes to evolve
> it to have a MathML output mode, but it is by no means fast.
>

Actually in the most recent "future work" he has mentioned
doing the opposite - MathML input with jsMath rendering. Even
this makes sense to me.

> In the long term the solution to math on the web is MathML.

In spite of all the effort, I remain sceptical.

> I think the sooner we (and the world) embrace this fact, and
> stop spending all our efforts on stop-gap solutions, the better
> we will be and the quicker we can advance.

What we need now to advance is considerably simpler - just
a reliable, simple and compatible way of rendering LaTeX
equations and symbols in HTML. Even rendering LaTeX as graphics
on the server, embedding them in HTML and caching the result
is "nearly good enough".

> Furthermore mathematics needs huge character sets.  Moving
> to unicode (implied by the move to MathML) will be a huge boon
> to math since we can use all kinds of characters and operators
> outside of ASCII.
>
> The Really Big Problem with MathML is fonts.  FYI the STIX
> fonts project plans a beta release in the next few weeks:
> http://www.stixfonts.org/. The addition of this font, and its
> distribution with browsers will remove most of the problems
> with MathML, and it will begin to take off since every
> Firefox/Mozilla user will be able to "see" MathML without
> jumping through the extra hoops of installing fonts, as is
> currently required.

I am not going to hold my breath! :)

Anyway what prevents jsMath also from benefiting from these
new fonts?

> Axiom should jump on this opportunity.
>

On the contrary, I think Axiom should continue to make use of
the most expedient solution available now. Axiom needs a better
user interface now. I think a possibly (much?) better interface
in the future (even the relatively near future, say 2 years) is
likely to be too late.

\start
Date: Tue, 25 Apr 2006 13:37:32 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: [MathML] 

Bob,

Because of the way edits are sent to Axiom Wiki subscribers
you have sent many edit emails like the following.

Might I suggest that you either take advantage of "Preview"
button or just create a page named, e.g. SandBoxMathML and
then your edits are silent and then rename it when you think
it is ready? :)

> -----Original Message-----
> From: Bob McElrath [mailto:mathaction-bounces@axiom-developer.org]
> Sent: Tuesday, April 25, 2006 1:24 PM
> To: MathAction
> Subject: [MathML]
>
> Changes http://wiki.axiom-developer.org/MathML/diff
> --
>
> 
> ++added:
> +    Rep := Record(prolog : L S, MathML : L S, epilog : L S)
> +
>      precondition:   E -> E
>
> --removed:
> 
> -    Rep := Record(prolog : L S, MathML : L S, epilog : L S)
> 
>
> --
> forwarded from
> http://wiki.axiom-developer.org/MathML#msg20060425122417-0500@
wiki.axiom-developer.org
>

\start
Date: Tue, 25 Apr 2006 10:45:17 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: axiom opportunity
Cc: David Mentre

Page, Bill [Bill Page] wrote:
> Could you point me to some examples of these benchmarks?
> Identical pages rendered as MathML and jsMath? Are there
> some cases that are especially bad? Worse case?

I've never written down any numbers because jsMath pages take many
seconds, while MathML is always unnoticably fast.

Attached is one of my test pages, to be compared with:
    http://www.math.union.edu/~dpvc/jsMath/examples/TeXbook16.html

> I have not done any rigorous tests but my experiments using
> FireFox 1.5.0.2 on Windows makes me feel jsMath has the lead -
> although both seem likely "fast enough" for the kinds of uses
> I have in mind, e.g. rendering a single "page" of HTML online -
> either from a web site or from a local copy of Axiom. Such a
> "page" might contain say at most 10 equations and maybe 20
> embedded symbols.

I find this statement very difficult to believe.  On the above example
page I can watch it render each expression.  It takes ~4s to render the
whole page.  The MathML version (attached) has the Firefox cursor in the
"busy" state for ~0.5s.  I think most of that time is spent loading the
file and parsing it.  It's about 0.5s for much much larger pages too.

jsMath is at least an order of magnatude slower.  I don't understand how
you haven't noticed this...  On my TiddlyWiki I have many wiki nodes
that take several seconds just to render the math...

I ran a profiler on jsMath a while back in an attempt to speed it up.
It's performance is fundamentally related to the function BBoxFor which
has to get the browser to render an expression so it can be measured.
This function is extremely expensive at ~0.1s per invocation.

> > In the long term the solution to math on the web is MathML.
> 
> In spite of all the effort, I remain sceptical.

Why?

> Anyway what prevents jsMath also from benefiting from these
> new fonts?

jsMath benefits too.

> > Axiom should jump on this opportunity.
> 
> On the contrary, I think Axiom should continue to make use of
> the most expedient solution available now. Axiom needs a better
> user interface now. I think a possibly (much?) better interface
> in the future (even the relatively near future, say 2 years) is
> likely to be too late.

A better user interface needs a fast, standardized way to render math.
MathML is that solution.

Rendering images or jsMath will never allow:
    1) subexpression interactivity
    2) cut and paste
    3) graphical equation editing
which one wangs for a UI.

\start
Date: Tue, 25 Apr 2006 10:46:34 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: [MathML]

Sorry.

Editing in the browser is painful.  I'm editing in an external editor,
which doesn't allow preview... :(

Page, Bill [Bill Page] wrote:
> Bob,
> 
> Because of the way edits are sent to Axiom Wiki subscribers
> you have sent many edit emails like the following.
> 
> Might I suggest that you either take advantage of "Preview"
> button or just create a page named, e.g. SandBoxMathML and
> then your edits are silent and then rename it when you think
> it is ready? :)
> 
> Regards,
> Bill Page.
> 
> > -----Original Message-----
> > 
> >  
> > +    Rep := Record(prolog : L S, MathML : L S, epilog : L S)
> > +
> >      precondition:   E -> E


\start
Date: Tue, 25 Apr 2006 19:55:43 +0200
From: Gregory Vanuxem
To: Timothy Daly Tim Daly
Subject: Typo in DeveloperNotes.pamphlet

Hi,

The following patch fixes a typo in DeveloperNotes.pamphlet

===============================================================
--- src/doc/DeveloperNotes.pamphlet.old
+++ src/doc/DeveloperNotes.pamphlet
@@ -1686,7 +1686,7 @@
 Axiom can generate TeX output by typing:
 \begin{verbatim}
 )set output tex on
-)end{verbatim}
+\end{verbatim}
 
 Here we give an example of TeX output that contains a bug:
 \begin{verbatim}
================================================================

\start
Date: Tue, 25 Apr 2006 14:03:40 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: [MathML]

Bob,

On Tuesday, April 25, 2006 1:47 PM you wrote:
>
> Sorry.
>
> Editing in the browser is painful.  I'm editing in an external
> editor, which doesn't allow preview... :(

External editing in the SandBox works well for this case.

No problem. I am glad you are working on the MathML issue!

Regards,
Bill Page.

>
> Page, Bill [Bill Page] wrote:
> > Bob,
> >
> > Because of the way edits are sent to Axiom Wiki subscribers
> > you have sent many edit emails like the following.
> >
> > Might I suggest that you either take advantage of "Preview"
> > button or just create a page named, e.g. SandBoxMathML and
> > then your edits are silent and then rename it when you think
> > it is ready? :)
> >

\start
Date: Tue, 25 Apr 2006 11:09:03 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: [MathML]

Page, Bill [Bill Page] wrote:
> Bob,
> 
> On Tuesday, April 25, 2006 1:47 PM you wrote:
> > 
> > Sorry.
> > 
> > Editing in the browser is painful.  I'm editing in an external
> > editor, which doesn't allow preview... :(
> 
> External editing in the SandBox works well for this case.
> 
> No problem. I am glad you are working on the MathML issue!

Could you take a look at http://wiki.axiom-developer.org/SandBoxMathML ?

I think I have copied all the relevant bits from tex.spad.pamphlet but
it still tells me it can't coerce to my new domain.

\start
Date: Tue, 25 Apr 2006 20:57:32 +0200
From: Gregory Vanuxem
To: Bob McElrath
Subject: re: [MathML]

Hi,

Le mardi 25 avril 2006 =E0 11:09 -0700, Bob McElrath a =E9crit :
> Page, Bill [Bill Page] wrote:
> > Bob,
> >
> > On Tuesday, April 25, 2006 1:47 PM you wrote:
> > >
> > > Sorry.
> > >
> > > Editing in the browser is painful.  I'm editing in an external
> > > editor, which doesn't allow preview... :(
> >
> > External editing in the SandBox works well for this case.
> >
> > No problem. I am glad you are working on the MathML issue!
>
> Could you take a look at http://wiki.axiom-developer.org/SandBoxMathML =
?
>
> I think I have copied all the relevant bits from tex.spad.pamphlet but
> it still tells me it can't coerce to my new domain.

Since this package is not implemented:

)abbrev package MML1 MathMLFormat1
MathMLFormat1(S : SetCategory): public == private where
  public  ==  with
    coerce: S -> MathMLFormat()
  private == add
    import MathMLFormat()

    coerce(s : S): MathMLFormat ==
      coerce(s :: OutputForm)$MathMLFormat


You have to use for example 1::OutputForm::MML.

And since the function coerce($):OutputFrom is not implemented the
result cannot be printed ("The function coerce with signature hashcode
is missing from domain MathMLFormat").

So can only use

\begin{axiom}
1::OutputForm::MML;
\end{axiom}

\start
Date: Tue, 25 Apr 2006 15:07:40 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: axiom opportunity
Cc: David Mentre

Bob,

On Tuesday, April 25, 2006 1:45 PM you wrote:
>
> Bill Page wrote:
> > Could you point me to some examples of these benchmarks?
> > Identical pages rendered as MathML and jsMath? Are there
> > some cases that are especially bad? Worse case?
>
> I've never written down any numbers because jsMath pages take
> many seconds, while MathML is always unnoticably fast.
>
> Attached is one of my test pages, to be compared with:
>     http://www.math.union.edu/~dpvc/jsMath/examples/TeXbook16.html

Thanks. Here are the same pages loaded on axiom-developer for
easier comparison:

jsMath (2529 bytes) ->
http://page.axiom-developer.org/TeXbook16.html

MathML (5861 bytes) ->
http://page.axiom-developer.org/texbookch16.xhtml

Of course the actual number of bytes transferred in the case
of jsMath can be quite a bit higher because of sending the
font information.

>
> > I have not done any rigorous tests but my experiments using
> > FireFox 1.5.0.2 on Windows makes me feel jsMath has the lead -
> > although both seem likely "fast enough" for the kinds of uses
> > I have in mind, e.g. rendering a single "page" of HTML online -
> > either from a web site or from a local copy of Axiom. Such a
> > "page" might contain say at most 10 equations and maybe 20
> > embedded symbols.
>
> I find this statement very difficult to believe.  On the above
> example page I can watch it render each expression.  It takes
> ~4s to render the whole page.  The MathML version (attached)
> has the Firefox cursor in the "busy" state for ~0.5s.  I think
> most of that time is spent loading the file and parsing it.
> It's about 0.5s for much much larger pages too.
>

Measuring this case more carefully, I have to admit that I agree
with your estimates. These times can be considerable improved
(about 1s to render jsMath) by making sure that you have the Tex
Fonts installed on your system and clicking the "don't show page
until complete" option.

Even so, if these examples were generated from the result of
an Axiom calculation I believe I might still judge the result
"adequate". I suppose that just goes to show that performance
is to some extent subjective - it's what you get used to ...

> jsMath is at least an order of magnatude slower.  I don't
> understand how you haven't noticed this...  On my TiddlyWiki
> I have many wiki nodes that take several seconds just to
> render the math...

But the math and the pages themselves are very pretty. :)

>
> ...
> > > In the long term the solution to math on the web is
> > > MathML.
> >
> > In spite of all the effort, I remain sceptical.
>
> Why?

Because we have LaTeX now and it works now. As hardware gets
faster, software remains just as difficult to write as ever.

>
> > > Axiom should jump on this opportunity.
> >
> > On the contrary, I think Axiom should continue to make use
> > of the most expedient solution available now. Axiom needs a
> > better user interface now. I think a possibly (much?) better
> > interface in the future (even the relatively near future,
> > say 2 years) is likely to be too late.
>
> A better user interface needs a fast, standardized way to
> render math. MathML is that solution.
>

I can agree at least that it probably will be. :)

> Rendering images or jsMath will never allow:
>     1) subexpression interactivity
>     2) cut and paste
>     3) graphical equation editing
> which one wangs for a UI.
>

Hmmm... I have been testing this kind of thing using the new
java-based Maple graphical user interface for almost two years
now and the limitations of the current Maple implementation
notwithstanding, I am even more convinced than I was before
this "gui devolution" of Maple that this sort of user interface
has little real value for users with even moderate experience.
It just doesn't really have much to do with the "mathematics"
that one actually does with these tools (at least what I do
with them).

\start
Date: 25 Apr 2006 21:40:01 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: axiom opportunity

Tim Daly writes:

[...]

| I think we need to start positioning ourselves to be the computer
| algebra system for these linux systems.

We should aim at getting Axiom 'easily' installable on all major linux
systems -- not just Debian.  
[ I'm not saying that because I'm a SuSE Linux user :-) ]

We should be at a point where Axiom is included in linux distros --
just like I can have singular with my SuSE distro.

\start
Date: Tue, 25 Apr 2006 16:55:18 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: Typo in DeveloperNotes.pamphlet

patch applied. fixed in the next release --t

\start
Date: Tue, 25 Apr 2006 14:30:33 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: axiom opportunity
Cc: David Mentre

Page, Bill [Bill Page] wrote:
> Bob, 
> 
> On Tuesday, April 25, 2006 1:45 PM you wrote:
> > 
> > Bill Page wrote:
> > > Could you point me to some examples of these benchmarks?
> > > Identical pages rendered as MathML and jsMath? Are there
> > > some cases that are especially bad? Worse case?
> > 
> > I've never written down any numbers because jsMath pages take
> > many seconds, while MathML is always unnoticably fast.
> > 
> > Attached is one of my test pages, to be compared with:
> >     http://www.math.union.edu/~dpvc/jsMath/examples/TeXbook16.html
> 
> Thanks. Here are the same pages loaded on axiom-developer for
> easier comparison:
> 
> jsMath (2529 bytes) ->
> http://page.axiom-developer.org/TeXbook16.html
> 
> MathML (5861 bytes) ->
> http://page.axiom-developer.org/texbookch16.xhtml
> 
> Of course the actual number of bytes transferred in the case
> of jsMath can be quite a bit higher because of sending the
> font information.

Don't forget 100K for jsMath itself!

And, I am using the truetype tex fonts.

Given the propensity of computer algebra systems to generate truly
gigantic expressions, I think anything less than "blazingly fast" at
drawing the math is unacceptable.

Just for kicks I just put an expression I'm currently working with into
my TiddlyWiki+jsMath.  It's derived in Maple and about 4 pages long (a
polynomial).  It takes about 30s to render.  Maple is able to draw it on
the screen in an unnoticable fraction of a second.

If I type 'solve(a*x^4+b*x^3+c*x^2+d*x+e, x);' (just to name a
"reasonable" very long expression) and it takes 0.01s to give me the
roots of a quartic, and 30s to draw them on the screen, that is
unnaceptable.

> Hmmm... I have been testing this kind of thing using the new
> java-based Maple graphical user interface for almost two years
> now and the limitations of the current Maple implementation
> notwithstanding, I am even more convinced than I was before
> this "gui devolution" of Maple that this sort of user interface
> has little real value for users with even moderate experience.
> It just doesn't really have much to do with the "mathematics"
> that one actually does with these tools (at least what I do
> with them).

I agree.  In fact I always use the 'classic' worksheet because the java
one is such crap.

Just because a good interface hasn't been written yet doesn't mean that
one is impossible.  I still hold out hope.

\start
Date: 25 Apr 2006 23:34:34 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Typo in DeveloperNotes.pamphlet

Tim Daly writes:

| patch applied. fixed in the next release --t

is this also in the SVN repository?

\start
Date: Tue, 25 Apr 2006 17:43:40 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: Typo in DeveloperNotes.pamphlet

> | patch applied. fixed in the next release --t
> 
> is this also in the SVN repository?

no. i cannot yet reach the svn repositories.

\start
Date: Wed, 26 Apr 2006 00:07:15 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: re: Typo in DeveloperNotes.pamphlet

Hi Gaby,

Le mardi 25 avril 2006 =E0 23:34 +0200, Gabriel Dos Reis a =E9crit :
> Tim Daly writes:
>
> | patch applied. fixed in the next release --t
>
> is this also in the SVN repository?

Sorry I forgot to CC you... I'll not forget the next time.

\start
Date: Tue, 25 Apr 2006 21:54:58 -0400
From: Tim Daly
To: list
Subject: Summer of Code application]

------- Start of forwarded message -------
From: Leslie Hawthorn
Subject: Re: [Soc2006support] Summer of Code application

Hello Tim,

Thank you for your application and your interest in Summer of Code 2006. 
  Unfortunately, we cannot offer Axiom admission to the program at this 
time.  Best of luck to you and your colleagues with your project and all 
your future endeavors.

Kind regards,
LH

root wrote:
> I would like to submit Axiom as a Summer of Code project for 2006.
> 
> We successfully participated last year as a subproject of the LispNYC group.
> 
> This year, in preparation for participation in the Summer of Code program,
> we have collected and published a series of possible projects at
> 
>   http://wiki.axiom-developer.org/SummerOfCode
> 
> Axiom is a large, general purpose computer algebra system. It used to 
> be a commercial competitor to Mathematica and Maple. It is now free and
> open source (Modified BSD). It has been active since 2001 and is hosted
> at both Sourceforge and Savannah (FSF site). See
> 
>   http://wiki.axiom-developer.org
>   http://savannah.nongnu.org/projects/axiom
>   http://sourceforge.net/projects/axiom
> 
> Since Axiom is a large project we have a wide range of possible areas
> of contribution from documentation all the way to algebra code. There
> are projects for user interface, literate programming, graphics, etc.
> 
> We are able to review student proposals as well as direct projects
> selected from our proposal list. We have recently established a 
> connection to RISC-Linz (Research in Symbolic Computation in Austria),
> a department at the University of Linz. In addition we have had an
> ongoing student collaboration with the City College of New York's
> CAISS laboratory working on promoting Axiom as a science platform.
> See 
> 
>   http://daly.axiom-developer.org/doyen
> 
> but we could make much faster progress if we could find funding for
> student participation.
> 
> We have tried to create an Axiom Foundation to pay for work on supported
> projects but that has not been successful. Open source funding is always
> a challenge.
> 
> Tim Daly
> Axiom Lead Developer.
> Tim Daly
> 
> _______________________________________________
> Soc2006support mailing list
> Soc2006support@google.com
> https://mailman.corp.google.com/mailman/listinfo/soc2006support

Leslie Hawthorn
Open Source Program Coordinator

\start
Date: Wed, 26 Apr 2006 17:48:00 +0200
From: David Mentre
To: Gabriel Dos Reis
Subject: Re: axiom opportunity

Hello,

25 Apr 2006 21:40:01 +0200, Gabriel Dos Reis=
:
> We should aim at getting Axiom 'easily' installable on all major linux
> systems -- not just Debian.
> [ I'm not saying that because I'm a SuSE Linux user :-) ]

So why don't you package Axiom for SuSE ?

\start
Date: 26 Apr 2006 18:06:33 +0200
From: Gabriel Dos Reis
To: David Mentre
Subject: Re: axiom opportunity

David Mentre writes:

| Hello,
| 
| 25 Apr 2006 21:40:01 +0200, Gabriel Dos Reis:
| > We should aim at getting Axiom 'easily' installable on all major linux
| > systems -- not just Debian.
| > [ I'm not saying that because I'm a SuSE Linux user :-) ]
| 
| So why don't you package Axiom for SuSE ?

Because I don't want to package it just for SuSE -- I might switch to or
acquire a new Unix variant in the future.  Furthermore, I consider
that approach a rathole[1]: which version of SuSE?  I certanly don't have
a standard SuSE installation and my working version is probably too
old by many standards.  I want to have Axiom in a form where I could
just type "./configure; make; make install" and be done with it.  See the
Autoconf suggestion in a different thread.  But I would
like Axiom to be better than that; that is the reason why I talked to
Benjamin Kosnik about distribution when we met two-three weeks ago.  See the
"cross compilation issue" in another thread.  I also briefly discussed
the issue with Paolo Carlini,  fellow libstdc++ maintainer, working
for SUSE.  

Best,

[1] I had had a version of Maple working well till two years ago I
upgraded to a newer linux version that was using a new version of
glibc.  My copy of Maple stopped working.

\start
Date: Wed, 26 Apr 2006 18:10:06 +0200
From: Frederic Lehobey
To: list
Subject: Re: axiom opportunity

Hi,

On Wed, Apr 26, 2006 at 05:48:00PM +0200, David MENTRE wrote:
> 25 Apr 2006 21:40:01 +0200, Gabriel Dos Reis <gdr@integrable-solutions.=
net>:
> > We should aim at getting Axiom 'easily' installable on all major linu=
x
> > systems -- not just Debian.
> > [ I'm not saying that because I'm a SuSE Linux user :-) ]
>
> So why don't you package Axiom for SuSE ?

Have you tried to run alien on Camm Maguire Debian packages? (I have
not.)

  http://www.die.net/doc/linux/man/man1/alien.1.html

\start
Date: Wed, 26 Apr 2006 12:12:16 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: axiom opportunity
Cc: David Mentre

Axiom should build on any linux system without error.
If you know of a system where you set the AXIOM shell variable
properly and the build fails please 
  (a) post a console log
  (b) try to figure out what failed and generate a patch.

As far as I'm aware Axiom should build on SUSE.

\start
Date: 26 Apr 2006 18:25:58 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: axiom opportunity
Cc: David Mentre

Tim Daly writes:

| Axiom should build on any linux system without error.
| If you know of a system where you set the AXIOM shell variable
| properly and the build fails please 
|   (a) post a console log
|   (b) try to figure out what failed and generate a patch.
| 
| As far as I'm aware Axiom should build on SUSE.

Axiom builds on my linux box; but it does not support
cross-compilation.  Cross-compilation is not an issue when one has
access to the native machine with all the tool there.  It, however, is
an issue when packaging for systems; if we don't have that it would be
difficult to have Axiom come out of the box with major linux distros.

Axiom currently builds on the linux boxes I have access to (RH, SuSE,
Unbuntu) but it installs in non-"standard" locations; that is "easy"
to correct with a minimal Autoconf support. 

\start
Date: Wed, 26 Apr 2006 18:29:11 +0200
From: David Mentre
To: Gabriel Dos Reis
Subject: Re: axiom opportunity

26 Apr 2006 18:06:33 +0200, Gabriel Dos Reis=
:
> Because I don't want to package it just for SuSE -- I might switch to or
> acquire a new Unix variant in the future.  Furthermore, I consider
> that approach a rathole[1]: which version of SuSE?  I certanly don't have
> a standard SuSE installation and my working version is probably too
> old by many standards.

The SuSE package (or RedHat or whatever) won't appear by chance.
Packaging a software is a lot of *work*. If you don't do it, nobody
will do it for you. Don't forget this is Free Software.

> I want to have Axiom in a form where I could
> just type "./configure; make; make install" and be done with it.  See the
> Autoconf suggestion in a different thread.

See the guy who said that he would provide a first a configure.ac. ;-)

>  But I would
> like Axiom to be better than that; that is the reason why I talked to
> Benjamin Kosnik about distribution when we met two-three weeks ago.  See =
the
> "cross compilation issue" in another thread.

RedHat *requires* cross-compilation capabilities. I'm not sure Axiom
is able to do that.

> I also briefly discussed
> the issue with Paolo Carlini,  fellow libstdc++ maintainer, working
> for SUSE.

So?


> [1] I had had a version of Maple working well till two years ago I
> upgraded to a newer linux version that was using a new version of
> glibc.  My copy of Maple stopped working.

Yes. This the reason that we are all working on Free Software and not
proprietary one. But this has nothing to do with packaging issues.
When the system evolves, one needs to provide the necessary work to
make the program working in the new environment. Tim is doing that
work. Bill also. We need more people coding and less talks (like what
I'm doing ;-).

\start
Date: Wed, 26 Apr 2006 12:33:53 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: axiom opportunity
Cc: David Mentre

Axiom can be installed at any location (defaults to /usr/local)
by adding an option on the command line (see Makefile.dvi)

  make INSTALL=/yourabsolutepath

In general, Axiom is designed to be built from source.
I provide binaries for the systems I can access but they are not
guaranteed to run.

\start
Date: Wed, 26 Apr 2006 12:36:56 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: axiom opportunity
Cc: David Mentre

>>  But I would
>> like Axiom to be better than that; that is the reason why I talked to
>> Benjamin Kosnik about distribution when we met two-three weeks ago.  See the
>> "cross compilation issue" in another thread.
> 
> RedHat *requires* cross-compilation capabilities. I'm not sure Axiom
> is able to do that.

Cross compilation? Axiom builds on all of the 12 (?) debian systems.
It is even rumored to have built on the Zaurus 6700 (a PDA).

All of that effort is due to Camm. Unfortunately his tarball of 
patches are all undocumented so I have no idea why those changes
are necessary. I'm reluctant to make changes without understanding.

\start
Date: Wed, 26 Apr 2006 13:27:06 -0400
From: Bill Page
To: Frederic Lehobey
Subject: RE: axiom opportunity

On April 26, 2006 12:10 PM Frederic Lehobey wrote:
> 
> On Wed, Apr 26, 2006 at 05:48:00PM +0200, David MENTRE wrote:
> > 25 Apr 2006 21:40:01 +0200, Gabriel Dos Reis wrote:
> > > We should aim at getting Axiom 'easily' installable on 
> > > all major linux systems -- not just Debian.
> > > [ I'm not saying that because I'm a SuSE Linux user :-) ]
> > 
> > So why don't you package Axiom for SuSE ?
> 
> Have you tried to run alien on Camm Maguire Debian packages?
> (I have not.)
> 
>   http://www.die.net/doc/linux/man/man1/alien.1.html
> 

The RPM's at:

http://wiki.axiom-developer.org/AxiomDownload

where prepared using alien from the Debian distribution as
described there. I have successfully installed these on both
SuSE and RedHat systems.

\start
Date: 26 Apr 2006 19:57:53 +0200
From: Gabriel Dos Reis
To: David Mentre
Subject: Re: axiom opportunity

David Mentre writes:

| Gaby,
| 
| 26 Apr 2006 18:06:33 +0200, Gabriel Dos Reis:
| > Because I don't want to package it just for SuSE -- I might switch to or
| > acquire a new Unix variant in the future.  Furthermore, I consider
| > that approach a rathole[1]: which version of SuSE?  I certanly don't have
| > a standard SuSE installation and my working version is probably too
| > old by many standards.
| 
| The SuSE package (or RedHat or whatever) won't appear by chance.

Wasn't that obvious? :-)
However, it is possible to talk the packaging people into doing half
of the work when most of all they need is already there (i.e. provided
by us).

| Packaging a software is a lot of *work*. If you don't do it, nobody
| will do it for you. Don't forget this is Free Software.

that might not be obvious, but yes, I have an idea and practice of
free software -- it is not just do it by yoruself or talk other people
into doing it for you.  *In practice*, it is something in between.  
For example, I don't package GCC; I just build the release tarball;
someone else package it because the necessary bits are already there.

I'm not saying you should not try to SuSE/Red Hat package.  I'm saying 

| > I want to have Axiom in a form where I could
| > just type "./configure; make; make install" and be done with it.  See the
| > Autoconf suggestion in a different thread.
| 
| See the guy who said that he would provide a first a configure.ac. ;-)
| 
| >  But I would
| > like Axiom to be better than that; that is the reason why I talked to
| > Benjamin Kosnik about distribution when we met two-three weeks ago.  See the
| > "cross compilation issue" in another thread.
| 
| RedHat *requires* cross-compilation capabilities. I'm not sure Axiom
| is able to do that.

The issue not whether Axiom can do that it its current form -- last
time, I tried, it can't.  But, whether it can be made to do that.

| > I also briefly discussed
| > the issue with Paolo Carlini,  fellow libstdc++ maintainer, working
| > for SUSE.
| 
| So?

so, the executive summary is like for Red Hat.

| > [1] I had had a version of Maple working well till two years ago I
| > upgraded to a newer linux version that was using a new version of
| > glibc.  My copy of Maple stopped working.
| 
| Yes. This the reason that we are all working on Free Software and not
| proprietary one. But this has nothing to do with packaging issues.

It does: the root issue is *dependency*.  It has little to do with
proprietary versus non-propriatry.

\start
Date: 26 Apr 2006 20:05:27 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: axiom opportunity
Cc: David Mentre

Tim Daly writes:

| >>  But I would
| >> like Axiom to be better than that; that is the reason why I talked to
| >> Benjamin Kosnik about distribution when we met two-three weeks ago.  See the
| >> "cross compilation issue" in another thread.
| > 
| > RedHat *requires* cross-compilation capabilities. I'm not sure Axiom
| > is able to do that.
| 
| Cross compilation? 

yes; for many reasons, people cross-compile programs/packages from one
system to another one. 

| Axiom builds on all of the 12 (?) debian systems.
| It is even rumored to have built on the Zaurus 6700 (a PDA).

yes, still that is not the same as cross-compiling.  As you know,
building natively assumes that one has access to the system and all
required tools ate already there.  That is nto always the case for
distribution and packaging people.

The issue is whether we find it important to have Axiom included in
major linux distributions or whether we should tell people "just
compile it by yourself"?  My opinion is that we should work on Axiom
to get into the first option -- but that requires agreement from all
of us before investing time in it.  That is not abstract talk (David ! :-)

| All of that effort is due to Camm. Unfortunately his tarball of 
| patches are all undocumented so I have no idea why those changes
| are necessary. I'm reluctant to make changes without understanding.

Do you have link to those patches?

\start
Date: Wed, 26 Apr 2006 14:30:02 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: axiom opportunity
Cc: David Mentre

> | All of that effort is due to Camm. Unfortunately his tarball of 
> | patches are all undocumented so I have no idea why those changes
> | are necessary. I'm reluctant to make changes without understanding.
> 
> Do you have link to those patches?

wget daly.axiom-developer.org/axiom_20050901-6.diff

\start
Date: 26 Apr 2006 20:49:47 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: axiom opportunity
Cc: David Mentre

Tim Daly writes:

| > | All of that effort is due to Camm. Unfortunately his tarball of 
| > | patches are all undocumented so I have no idea why those changes
| > | are necessary. I'm reluctant to make changes without understanding.
| > 
| > Do you have link to those patches?
| 
| wget daly.axiom-developer.org/axiom_20050901-6.diff

BTW, I sent an email to axiom-math yesterday, it is still awaiting
moderator review I believe :-)

\start
Date: Wed, 26 Apr 2006 15:34:06 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: axiom opportunity
Cc: David Mentre

Gaby,

On April 26, 2006 2:50 PM you wrote:
> | > 
> | > Do you have link to those patches?
> | 

All Debian patches are available with the official Debian
sources. For Axiom see:

http://packages.debian.org/stable/math/axiom-source

That is probably were Tim got his copy?

> | wget daly.axiom-developer.org/axiom_20050901-6.diff
> 
> Thanks!
> 
> BTW, I sent an email to axiom-math yesterday, it is still
> awaiting moderator review I believe :-)
>

None of the Axiom mailing lists are moderated but they do
require member registration. Without the registration
requirement these lists would be impossible since we currently
get 20 to 30 spam emails per day posted to these lists. These
need to be periodically reviewed and deleted. There is always
the risk that a posting by someone really interested in Axiom
might get dinged.

Your posting was held because it was classed as a:

  "Post by non-member to a members-only list"

(As you probably know by the bouce message that you should
have received from the email list software.)

I have just passed it but you really should register. See:

http://wiki.axiom-developer.org/AxiomCommunity

\start
Date: 26 Apr 2006 22:08:06 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: axiom opportunity
Cc: David Mentre

Bill Page writes:

[...]

| > BTW, I sent an email to axiom-math yesterday, it is still
| > awaiting moderator review I believe :-)
| >
| 
| None of the Axiom mailing lists are moderated but they do
| require member registration. Without the registration
| requirement these lists would be impossible since we currently
| get 20 to 30 spam emails per day posted to these lists. These
| need to be periodically reviewed and deleted. There is always
| the risk that a posting by someone really interested in Axiom
| might get dinged.
| 
| Your posting was held because it was classed as a:
| 
|   "Post by non-member to a members-only list"
| 
| (As you probably know by the bouce message that you should
| have received from the email list software.)
| 
| I have just passed it but you really should register. See:
| 
| http://wiki.axiom-developer.org/AxiomCommunity

Thanks for taking care of that mail.
Yes, when I got the bounce message, I was surprised because I do
receive emails sent to all Axiom lists, in particular to
axiom-math. So I did not investigate further, how I could be receiving
mails from that list if I was not subscribed (i.e. I took the
subscription for granted).  Now, it might be that I registered with a
different address where posting with another address (which while not
impossible, will surprise me).

\start
Date: Thu, 27 Apr 2006 02:21:10 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: sourceforge cvs

Hi,

I have downloaded axiom from sourceforge cvs without success. It seems
that the sourceforge cvs has a old version of axiom. When I download
axiom from sourceforge cvs with:

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/axiom login 
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/axiom co -P
axiom

The Makefile contains :

#GCLVERSION=gcl-2.4.1
#GCLVERSION=gcl-2.5
#GCLVERSION=gcl-2.5.2
#GCLVERSION=gcl-2.6.1
#GCLVERSION=gcl-2.6.2
#GCLVERSION=gcl-2.6.2a
#GCLVERSION=gcl-2.6.3
#GCLVERSION=gcl-2.6.5
#GCLVERSION=gcl-2.6.6
#GCLVERSION=gcl-2.6.7pre
GCLVERSION=gcl-2.6.7

So it seems that the version I donwloaded is a old version (a correct
version has to contain GCLVERSION=2.6.8pre)

I can be wrong, thought ...In fact I have lost more than one hours to
find if this was a filesystem problem or a cvs one (I downloaded axion
on a experimental filesystem).

PS: Please tell me that it's a cvs problem and not a filesystem
problem... ;-)

\start
Date: Wed, 26 Apr 2006 21:51:02 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: sourceforge cvs

checking....

\start
Date: Wed, 26 Apr 2006 22:01:18 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: sourceforge cvs

These are the first few lines of the Makefile for the latest version
just checked out from the sourceforge cvs. Notice that it uses 
gcl-2.6.8pre. The policy is to distribute the latest tarball of
GCL and the previously working tarball (just in case I make a 
mistake and we need to back up a version). So only gcl-2.6.8pre.tgz
and gcl-2.6.7.tgz exist in the zips directory. All other versions
have been erased.

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

VERSION="Axiom (April 2006)"
SPD=$(shell pwd)
SYS=$(notdir $(AXIOM))
SPAD=${SPD}/mnt/${SYS}
LSP=${SPD}/lsp
#GCLVERSION=gcl-2.4.1
#GCLVERSION=gcl-2.5
#GCLVERSION=gcl-2.5.2
#GCLVERSION=gcl-2.6.1
#GCLVERSION=gcl-2.6.2
#GCLVERSION=gcl-2.6.2a
#GCLVERSION=gcl-2.6.3
#GCLVERSION=gcl-2.6.5
#GCLVERSION=gcl-2.6.6
#GCLVERSION=gcl-2.6.7pre
#GCLVERSION=gcl-2.6.7
GCLVERSION=gcl-2.6.8pre

\start
Date: Thu, 27 Apr 2006 04:38:40 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: sourceforge cvs

Hi,

Le mercredi 26 avril 2006 =E0 22:01 -0400, root a =E9crit :
> These are the first few lines of the Makefile for the latest version
> just checked out from the sourceforge cvs.

Checked out another time on a reiserfs partition without success (always
the Axiom (December 2005) version). So it seems that I'm alone with this
problem, another thing that I don't understand today. The "Browse CVS
Repository" service don't work too for me...

Sorry for the inconvenience.

\start
Date: 27 Apr 2006 21:26:36 +0200
From: Gabriel Dos Reis
To: list
Subject: Axiom trunk failure

Hi,

  I checked out a fresh copy from SVN axiom/trunk.  The build failed
for me while patching GCL-2.6.7:

[...]

11 applying tail-recursive noise patch
patching file gcl_cmpflet.lsp
Hunk #1 FAILED at 390.
1 out of 1 hunk FAILED -- saving rejects to file gcl_cmpflet.lsp.rej


The rejected hunk is:

***************
*** 390,397 ****
            (wt-label *exit*))
      (unwind-no-exit 'tail-recursion-mark)
      (wt-nl "goto TTL;")
-     (cmpnote "Tail-recursive call of ~s was replaced by iteration."
-              (fun-name (car fd))))
     (t (push-args args)
        (wt-nl (c-function-name "L" (fun-cfun (car fd)) (fun-name (car fd))) "(")
        (dotimes** (n (fun-level (car fd))) (wt "base" n ","))
--- 390,399 ----
            (wt-label *exit*))
      (unwind-no-exit 'tail-recursion-mark)
      (wt-nl "goto TTL;")
+ ; 20031022000 tpd we don't need to know this
+ ;    (cmpnote "Tail-recursive call of ~s was replaced by iteration."
+ ;             (fun-name (car fd)))
+     )
     (t (push-args args)
        (wt-nl (c-function-name "L" (fun-cfun (car fd)) (fun-name (car fd))) "(")
        (dotimes** (n (fun-level (car fd))) (wt "base" n ","))
 


Does this ring bell to anyone?

\start
Date: Thu, 27 Apr 2006 15:37:01 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Axiom trunk failure

yep. it turns off the "tail recursion" noise. bill schelter and i
worked on creating tail recursion in AKCL. This was just a debugging
message at the time. For some reason it outlived its useful life and
continues in the current code base. the message "exposes" lisp to 
the user of the axiom interpreter so i removed it.

it should patch correctly. i suspect there is a mismatch between
the GCL version you are using and the patch level you are using.

in the zips subdirectory all patches are named by the .tgz file
to which they apply. the name also includes the directory path
to the file and the name of the file. so 

zips/gcl-2.6.7

has patches like

gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch

which lives in lsp/gcl-2.6.7/cmpnew/gcl_cmpflet.lsp

\start
Date: 28 Apr 2006 00:12:32 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: Axiom trunk failure

Tim Daly writes:

| yep. it turns off the "tail recursion" noise. bill schelter and i
| worked on creating tail recursion in AKCL. This was just a debugging
| message at the time. For some reason it outlived its useful life and
| continues in the current code base. the message "exposes" lisp to 
| the user of the axiom interpreter so i removed it.
| 
| it should patch correctly. i suspect there is a mismatch between
| the GCL version you are using and the patch level you are using.
| 
| in the zips subdirectory all patches are named by the .tgz file
| to which they apply. the name also includes the directory path
| to the file and the name of the file. so 
| 
| zips/gcl-2.6.7
| 
| has patches like
| 
| gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch
| 
| which lives in lsp/gcl-2.6.7/cmpnew/gcl_cmpflet.lsp

All that is fine.

After some investigation, I nailed down the problem.  
The file lsp/gcl-2.6.7/cmpnew/gcl_cmpflet.lsp (unlike any other files
that are subject to patches) has DOS-style newlines which is not
reflected in the patch being applied.  I don't know how that comes
into existence.  Therefore the failure to match. 

I manually removed those DOS-style newlines and applied the patch, it
just work fine.

\start
Date: 28 Apr 2006 01:08:16 +0200
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: Axiom trunk failure

Gabriel Dos Reis writes:

| After some investigation, I nailed down the problem.  
| The file lsp/gcl-2.6.7/cmpnew/gcl_cmpflet.lsp (unlike any other files
| that are subject to patches) has DOS-style newlines which is not
| reflected in the patch being applied.  I don't know how that comes
| into existence.

I checked that the original release of GCL-2.6.7

  ftp://ftp.gnu.org/pub/gnu/gcl/

has those curiosities.  So the explanation must be somewhere between
the editor Tim used to produce the patch and the the actual patch
being stored in the SVN repository.

\start
Date: 28 Apr 2006 09:47:56 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: GCL-2.6.7 and GCC-4.2.0

Hi Camm,

  Building GCL-2.6.7 (either pristine release or as part of Axiom)
with GCC-4.2.0 (development source code) on an x86 fails with the
following:

[...]

gcc -o raw_gcl  \
        -L.  -Wl,-Map raw_gcl_map   -lgcl -lm  -lgmp /usr/lib/libbfd.a /home/gdr/lib/libiberty.a -lreadline -lncurses -lc -lgclp ./libgcl.a(sys_gcl.o)(.text+0x480f): In function `gcl_init_system':
sys_gcl.c: undefined reference to `init_gcl_cmptop'
collect2: ld returned 1 exit status

\start
Date: 28 Apr 2006 11:46:07 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Gabriel Dos Reis writes:

| Hi Camm,
| 
|   Building GCL-2.6.7 (either pristine release or as part of Axiom)
| with GCC-4.2.0 (development source code) on an x86 fails with the
| following:
| 
| [...]
| 
| gcc -o raw_gcl  \
|         -L.  -Wl,-Map raw_gcl_map   -lgcl -lm  -lgmp /usr/lib/libbfd.a /home/gdr/lib/libiberty.a -lreadline -lncurses -lc -lgclp ./libgcl.a(sys_gcl.o)(.text+0x480f): In function `gcl_init_system':
| sys_gcl.c: undefined reference to `init_gcl_cmptop'
| collect2: ld returned 1 exit status

Additional information:  
 
   I don't know whether that helps or not [obviously, I'm not familiar
with GCL build machinery :-)].  From the build directory, all .o files
in cmpnew/ are usual .o files, except gcl_cmptop.o which is identical 
to gcl_cmptop.data; I suppose that is key to the misbehaviour? 


soliton[5:16]% file cmpnew/*.o                                ~/build/gcl-2.6.7
cmpnew/gcl_cmpbind.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpblock.o:   ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpcall.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpcatch.o:   ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpenv.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpeval.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpflet.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpfun.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpif.o:      ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpinline.o:  ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmplabel.o:   ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmplam.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmplet.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmploc.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpmap.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpmulti.o:   ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpspecial.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmptag.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmptop.o:     ASCII English text, with very long lines
cmpnew/gcl_cmptype.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmputil.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpvar.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpvs.o:      ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
cmpnew/gcl_cmpwt.o:      ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
soliton[5:17]% diff cmpnew/gcl_cmptop.o cmpnew/gcl_cmptop.data
soliton[5:17]%                                                ~/build/gcl-2.6.7


\start
Date: 28 Apr 2006 08:52:40 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Greetings!  Yes, if you could please post the output from the
compilation of gcl_cmptop.lsp, that would be great!  Or simply the
whole thing.

Take care,

Gabriel Dos Reis writes:

> Gabriel Dos Reis writes:
> 
> | Hi Camm,
> | 
> |   Building GCL-2.6.7 (either pristine release or as part of Axiom)
> | with GCC-4.2.0 (development source code) on an x86 fails with the
> | following:
> | 
> | [...]
> | 
> | gcc -o raw_gcl  \
> |         -L.  -Wl,-Map raw_gcl_map   -lgcl -lm  -lgmp /usr/lib/libbfd.a /home/gdr/lib/libiberty.a -lreadline -lncurses -lc -lgclp ./libgcl.a(sys_gcl.o)(.text+0x480f): In function `gcl_init_system':
> | sys_gcl.c: undefined reference to `init_gcl_cmptop'
> | collect2: ld returned 1 exit status
> 
> Additional information:  
>  
>    I don't know whether that helps or not [obviously, I'm not familiar
> with GCL build machinery :-)].  From the build directory, all .o files
> in cmpnew/ are usual .o files, except gcl_cmptop.o which is identical 
> to gcl_cmptop.data; I suppose that is key to the misbehaviour? 
> 
> 
> soliton[5:16]% file cmpnew/*.o                                ~/build/gcl-2.6.7
> cmpnew/gcl_cmpbind.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpblock.o:   ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpcall.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpcatch.o:   ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpenv.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpeval.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpflet.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpfun.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpif.o:      ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpinline.o:  ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmplabel.o:   ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmplam.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmplet.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmploc.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpmap.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpmulti.o:   ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpspecial.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmptag.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmptop.o:     ASCII English text, with very long lines
> cmpnew/gcl_cmptype.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmputil.o:    ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpvar.o:     ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpvs.o:      ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> cmpnew/gcl_cmpwt.o:      ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
> soliton[5:17]% diff cmpnew/gcl_cmptop.o cmpnew/gcl_cmptop.data
> soliton[5:17]%                                                ~/build/gcl-2.6.7

\start
Date: 28 Apr 2006 16:00:19 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Camm Maguire writes:

| Greetings!  Yes, if you could please post the output from the
| compilation of gcl_cmptop.lsp, that would be great!  Or simply the
| whole thing.

OK.

soliton[10:01]% file gcl_cmptop.o                      ~/build/gcl-2.6.7/cmpnew
gcl_cmptop.o: ASCII English text, with very long lines

Content of the file attached to this message.

\start
Date: 28 Apr 2006 10:35:06 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Greetings!  My apologies -- not the .o file, the log from the
compilation posted to the screen.  Or, if you prefer, your entire
configure and make build log.

Take care,


Gabriel Dos Reis writes:

> Camm Maguire writes:
> 
> | Greetings!  Yes, if you could please post the output from the
> | compilation of gcl_cmptop.lsp, that would be great!  Or simply the
> | whole thing.
> 
> OK.
> 
> soliton[10:01]% file gcl_cmptop.o                      ~/build/gcl-2.6.7/cmpnew
> gcl_cmptop.o: ASCII English text, with very long lines
> 
> Content of the file attached to this message.

\start
Date: Fri, 28 Apr 2006 11:25:20 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: GCL-2.6.7 and GCC-4.2.0

you guys might find it more efficient to cooperate using 
accounts on axiom-developer.org. let me know.

\start
Date: 28 Apr 2006 11:35:24 -0400
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Greetings!

Here is your problem:

gcl_cmptop.c: In function 'LI29':
gcl_cmptop.c:2547: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

i.e. this gcc development snapshot ran into an internal bug when
compiling the gcl_cmptop.c file.  You might try working around the
problem by configuring gcl with --enable-debug for the time being, but
this really should be reported to the gcc people and their bug tracker
as explained in the instructions referred to above.

Take care, 


Gabriel Dos Reis writes:

> Camm Maguire writes:
> 
> | Greetings!  My apologies -- not the .o file, the log from the
> | compilation posted to the screen.  Or, if you prefer, your entire
> | configure and make build log.
> 
> sorry for having misparsed what you said; here is the
> (gzip-compressed) log for cnofigure and make.  Hope, it is better this
> time.   
> 
> For my curiosity: is it expected that the .o coming from compiling a
> .lsp actually is NOT a "usual" .o file?
> 

No, usually the .data file is appended to the .o output by gcc, but
here the latter is empty.

\start
Date: 28 Apr 2006 17:11:44 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Camm Maguire writes:

| Greetings!  My apologies -- not the .o file, the log from the
| compilation posted to the screen.  Or, if you prefer, your entire
| configure and make build log.

sorry for having misparsed what you said; here is the
(gzip-compressed) log for cnofigure and make.  Hope, it is better this
time.   

For my curiosity: is it expected that the .o coming from compiling a
.lsp actually is NOT a "usual" .o file?

\start
Date: 28 Apr 2006 17:50:04 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Camm Maguire writes:

| Greetings!
| 
| Here is your problem:
| 
| gcl_cmptop.c: In function 'LI29':
| gcl_cmptop.c:2547: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See <URL:http://gcc.gnu.org/bugs.html> for instructions.

Woaw!  I suppose I should have paid more attention to the build log.
[ Gaby washing his red face. ]

Is it possible to alter GCL's build system so that it halts with no
ambiguous message when compilation does not complete for a given
module instead of continuing as if everything was OK?

| i.e. this gcc development snapshot ran into an internal bug when
| compiling the gcl_cmptop.c file.  You might try working around the
| problem by configuring gcl with --enable-debug for the time being, but
| this really should be reported to the gcc people and their bug tracker
| as explained in the instructions referred to above.

I'm taking care of that part since it turns out to be a GCC problem. 
*Shrug*.

\start
Date: 29 Apr 2006 19:28:40 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Camm Maguire writes:

[...]

| > For my curiosity: is it expected that the .o coming from compiling a
| > .lsp actually is NOT a "usual" .o file?
| > 
| 
| No, usually the .data file is appended to the .o output by gcc, but
| here the latter is empty.

\start
Date: 29 Apr 2006 19:31:18 +0200
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCL-2.6.7 and GCC-4.2.0

Camm Maguire writes:

[...]

| but this really should be reported to the gcc people and their bug tracker
| as explained in the instructions referred to above.

The issue is now fixed in the current working development version of GCC
[gcc version 4.2.0 20060428 (experimental)].  

I can report a successful build for both GCL and Axiom.

\start
Date: Sat, 29 Apr 2006 15:16:55 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: re: sourceforge cvs

On April 26, 2006 10:39 PM Vanuxem Gr=E9gory wrote:
>
> On 26 avril 2006 =E0 22:01 -0400, Tim Daly (root) wrote:
> ...
> > These are the first few lines of the Makefile for the latest
> > version just checked out from the sourceforge cvs.
> ...
> > #GCLVERSION=gcl-2.6.7
> > GCLVERSION=gcl-2.6.8pre
> ...
>
> Checked out another time on a reiserfs partition without success
> (always the Axiom (December 2005) version). So it seems that I'm
> alone with this problem, another thing that I don't understand today.
> The "Browse CVS Repository" service don't work too for me...
>
> Sorry for the inconvenience.
>

There is definitely a strange problem with the CVS at SourceForge.

The CVS browse now shows everything as atleast 3 months old:

http://cvs.sourceforge.net/viewcvs.py/axiom/axiom/

(December 2005) and

http://cvs.sourceforge.net/viewcvs.py/axiom/axiom/Makefile?view=markup

shows the old version of the Makefile without gcl-2.6.8pre

But that is very odd! Because two days ago I did a 'cvs update'
from SourceForge and I did obtain the correct new version.

And further more the Savannah CVS browse is also up to date:

http://cvs.savannah.nongnu.org/viewcvs/axiom/?root=axiom

(patch-49)

I don't understand it.

\start
Date: Sat, 29 Apr 2006 15:21:46 -0400
From: Bill Page
To: Tim Daly
Subject: Re: Typo in DeveloperNotes.pamphlet

On April 25, 2006 5:44 PM Tim Daly (root) wrote:
> 
> > | patch applied. fixed in the next release --t
> >
> > Gaby asked:
> > 
> > is this also in the SVN repository?
> 
> no. i cannot yet reach the svn repositories.
> 

Tim, maybe that was because you were not actually registered at
SourceForge to allow access to SVN? :) I have just updated your
admin rights at SourceForge so you should now have full access
the same as Gaby.

\start
Date: Sat, 29 Apr 2006 15:29:38 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: axiom opportunity

On April 26, 2006 2:50 PM Gabriel Dos Reis wrote:
>
> Tim Daly (root) writes:
>
> | All of that effort is due to Camm. Unfortunately his tarball of
> | patches are all undocumented so I have no idea why those changes
> | are necessary. I'm reluctant to make changes without understanding.
> | >
> | > Do you have link to those patches?
> |
> | wget daly.axiom-developer.org/axiom_20050901-6.diff
>
> Thanks!
>

Concerning documentation of the Debian patches for Axiom recall
that:

http://lists.gnu.org/archive/html/gcl-devel/2005-12/msg00052.html

On December 14, 2005 8:50 PM Camm Maguire wrote:

Greetings!

OK, for accuracy, here is the full patch I am using for
axiom_20050901-4.  This is debian/patch.merge in the Debian source
package.   It is far more complex than it looks, as it supports as
well the platforms on which native object relocation is not yet
implemented (2.6.x hppa ia64 mips alpha, 2.7.0 hppa ia64).  For the
ubiquitous x86, we just need the #+native-reloc code.

I'll be happy to try to explain this again as time permits, but for
now let me say that the purpose of

the first patch is to load gcl_collectfn, turn sgc on, and link in
cfuns-c.o, sock-io.o, and libspad.a,

the second and third patches is to avoid making the databases when
native object relocation is not available, and to use prebuilt copies
supplied under debian instead, as on such machines one cannot have
more than 1024 open file descriptors, which likewise bounds the number
of binary loads.

the fourth patch is to link $(OBJS1) into the image.  This might now
be made obsolete by the first patch, or vice versa.

the fifth and sixth patches are only to support machines without
native object relocation.  They use the same compiler::link mechanism
to link in all the compiled lisp objects which normally would be
achieved via a load and a si::save-system.  I'm hoping 2.7.0 will be
the end of this requirement.

Take care,
==========================
==========================
==========================
=
=
--- ./lsp/Makefile.pamphlet.~1.5.~	2005-09-05 18:50:31.000000000 +0000
+++ ./lsp/Makefile.pamphlet	2005-09-20 21:20:10.000000000 +0000
@@ -1012,14 +1012,7 @@
 	@echo 1 building ${LSP} ${GCLVERSION}

 gcldir:
-	@echo 2 building ${GCLVERSION}
-	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
-<<gcl-2.6.7.socket.patch>>
-<<gcl-2.6.7.libspad.patch>>
-<<gcl-2.6.7.toploop.patch>>
-<<gcl-2.6.7.tail-recursive.patch>>
-<<gcl-2.6.7.collectfn.fix>>
-<<gclConfigureMake>>
+	echo '(compiler::link nil "${OUT}/lisp" (format nil "(progn (let
((*load-path* (cons ~S *load-path*))(si::*load-types* ~S))
(compiler::emit-fn t))(when (fboundp (quote si::sgc-on)) (si::sgc-on
t))#-native-reloc(setq compiler::*default-system-p* t))"
si::*system-directory* (quote (list #+native-reloc".o" ".lsp")))
"${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o
${OBJ}/${SYS}/lib/libspad.a")' | gcl
 	@echo 13 finished system build on `date` | tee >gcldir

 ccldir: ${LSP}/ccl/Makefile
--- ./src/algebra/Lattice.pamphlet.orig	2005-01-04 23:45:59.000000000 =
+0000
+++ ./src/algebra/Lattice.pamphlet	2005-02-14 18:45:10.000000000 +0000
@@ -39620,13 +39620,14 @@
 	@ cp -p ${SRC}/doc/gloss.text ${LIB}
 	@ cp -p ${SRC}/doc/topics.data ${MID}
 	@ echo rebuilding daase files
-	@ (cd ${MID} ; \
-	   echo ')set out le 200' >/tmp/tmp.input ; \
-	   echo ')fin' >>/tmp/tmp.input ; \
-	   echo '(make-databases "" (QUOTE ("unix")))' >>/tmp/tmp.input ; \
-	   echo '(bye)' >>/tmp/tmp.input ; \
-	   cat /tmp/tmp.input | ${INTERPSYS} ; \
-	   rm -f /tmp/tmp.input )
+	@ (cd ${MID} ; \
+	   echo ')set out le 200' >/tmp/tmp.input ; \
+	   echo ')fin' >>/tmp/tmp.input ; \
+	   echo "#+native-reloc(make-databases \"\" (QUOTE
(\"unix\")))#-native-reloc(system \"cp ${SRC}/../debian/*.daase =
${MID}\")"
>>/tmp/tmp.input ; \
+	   echo '(bye)' >>/tmp/tmp.input ; \
+	   cat /tmp/tmp.input | ${INTERPSYS} ; \
+	   rm -f /tmp/tmp.input )
+#	@ (cp ${SRC}/../debian/*.daase ${MID})
 	@ echo If all went well, go-ahead Mike and do a db-install as well !

 db-install:
@@ -39758,7 +39759,8 @@
 	@ echo rebuilding databases...
 	@ cp ${SRC}/doc/gloss.text ${MID}
 	@ cp ${SRC}/doc/topics.data ${MID}
-	@ (cd ${MID} ; echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
+	@ (cd ${MID} ; echo ")lisp (progn #+native-reloc(make-databases \"\"
nil)#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MID}\"))" |
${INTERPSYS} )
+#	@ (cp ${SRC}/../debian/*.daase ${MID})

 check:
 	@ echo Checking that INTERP.EXPOSED and NRLIBs are consistent
--- ./src/etc/Makefile.pamphlet.orig	2005-01-30 12:03:12.000000000 +0000
+++ ./src/etc/Makefile.pamphlet	2005-02-14 18:47:16.000000000 +0000
@@ -33,9 +33,10 @@
 	@ cp ${SRC}/doc/gloss.text ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
-	@ (cd ${INT}/algebra ; \
-           echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
-	@ cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
+	@ (cd ${INT}/algebra ; \
+           echo ")lisp (progn #+native-reloc(progn (make-databases \"\"
nil)(system \"cp ${INT}/algebra/*.daase
${MNT}/${SYS}/algebra\"))#-native-reloc(system \"cp =
${SRC}/../debian/*.daase
${MNT}/${SYS}/algebra\"))" | ${INTERPSYS} )
+#	@ cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
+#	@ (cp ${SRC}/../debian/*.daase ${MNT}/${SYS}/algebra)

 @
 \section{summary}
--- ./src/boot/Makefile.pamphlet.orig	2005-06-05 03:23:35.000000000 =
+0000
+++ ./src/boot/Makefile.pamphlet	2005-09-20 21:36:15.000000000 +0000
@@ -1173,7 +1173,8 @@

 Until this is fixed we need to continue to use the old scheme.
 <<environment>>=
-CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote =
(${OBJS1})))
(system::save-system "${SAVESYS}"))
+#CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote =
(${OBJS1})))
(system::save-system "${SAVESYS}"))
+CMD0=	(if (member :native-reloc *features*) (progn (mapcar (function
(lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system
"${SAVESYS}")) (compiler::link (quote (${OBJS1})) "${SAVESYS}" (format =
nil
"(let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S))
(compiler::emit-fn t)) (when (fboundp (quote si::sgc-on)) (si::sgc-on =
t))
(setq compiler::*default-system-p* t)" si::*system-directory* (quote  =
(list
".lsp")))))
 
 @
 \subsection{boothdr.lisp \cite{1}}
--- ./src/interp/Makefile.pamphlet.orig	2005-09-20 21:48:56.000000000 =
+0000
+++ ./src/interp/Makefile.pamphlet	2005-09-20 21:49:14.000000000 +0000
@@ -576,7 +576,28 @@
 \begin{verbatim}
 <<save depsys image>>=
 	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp") (spad-save
"${DEPSYS}"))' | ${LISPSYS})
+	   echo '#+native-reloc(progn (load "${OUT}/makedep.lisp")
(spad-save "${DEPSYS}"))#-native-reloc(progn \
+			(setq si::*collect-binary-modules* t) \
+			(load "${OUT}/makedep.lisp") \
+			(compiler::link \
+				(remove-duplicates si::*binary-modules*
:test (quote equal)) \
+				"$(DEPSYS)" \
+				(format nil "\
+					(setq si::*collect-binary-modules*
t) \
+					(let ((si::*load-path* (cons ~S
si::*load-path*))\
+	                                     (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					(load \"$(OUT)/makedep.lisp\")\
+					(gbc t)\
+					(when si::*binary-modules* \
+						(error
si::*binary-modules*))\
+					(setq si::collect-binary-modules*
nil si::*binary-modules* nil)\
+					(gbc t)\
+					(when (fboundp (quote si::sgc-on))
(si::sgc-on t))\
+					(setq compiler::*default-system-p*
t)\
+				" si::*system-directory* (quote (list
".lsp")))\
+				"" \
+				nil))' | ${LISPSYS})
 @
 \end{verbatim}

@@ -880,8 +901,36 @@
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >>
${OUT}/makeint.lisp
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' >>
${OUT}/makeint.lisp
+#	@ (cd ${OBJ}/${SYS}/bin ; \
+#	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t)
(user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
 	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t)
(user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	  echo '#+native-reloc(progn (gbc t) (setq x
si::*system-directory*)(load "${OUT}/makeint.lisp") (setq
si::*system-directory* x) (unintern (quote x))(gbc t)(user::spad-save
"${SAVESYS}"))#-native-reloc(progn \
+			(setq si::*collect-binary-modules* t)\
+			(setq x si::*system-directory*)\
+			(load "${OUT}/makeint.lisp")\
+			(setq si::*system-directory* x)\
+			(unintern (quote x))\
+			(compiler::link \
+				(remove-duplicates si::*binary-modules*
:test (quote equal))\
+				"$(SAVESYS)" \
+				(format nil "\
+					(let ((si::*load-path* (cons ~S
si::*load-path*))\
+                                             (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					 (setq si::*collect-binary-modules*
t)\
+					 (setq x si::*system-directory*)\
+					 (load \"$(OUT)/makeint.lisp\")\
+					 (setq si::*system-directory* x)\
+					 (unintern (quote x))\
+					 (when si::*binary-modules* \
+						(error
si::*binary-modules*))\
+					(setq si::collect-binary-modules*
nil si::*binary-modules* nil)\
+					(gbc t)\
+					(when (fboundp (quote si::sgc-on))
(si::sgc-on t))\
+					(setq compiler::*default-system-p*
t)\
+				" si::*system-directory* (quote (list
".lsp")))\
+			"$(OBJ)/$(SYS)/lib/sockio-c.o
$(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" \
+			nil))' | $(LISPSYS))
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
==========================
==========================
==========================
=
=


Tim Daly writes:

> > > also, how do we handle the fact that users can build gcl
> > > using the -ansi switch. that means that their local copy
> > > of gcl cannot be used by axiom (yet).
> > >
> >
> > The Debian prerequiste for Axiom is the non-ansi version of
> > gcl. If the non-ansi version is not installed on the system
> > then 'apt-get install axiom' will also install it.
>
> true but not everyone uses debian.
> how do we solve the redhat9 issue?
>

Note that the rpms created by alien from the debian binaries
work on redhad9.

\start
Date: 29 Apr 2006 21:38:40 +0200
From: Martin Rubey
To: Ralf Hemmecke, Nicolas M. Thiery
Subject: A{ld,xi}o{r,m}-Combinat


Dear all,

attached you find a screenshot from some code and its output that has emerged
from the Axiom Workshop 2006. I hope you like it. Note that the two lines in
the upper frame define TreeClass completely as a domain, given the domain Atom
and the functors CrossClass and UnionClass...

The code is mainly from Ralf Hemmecke in collaboration with Nicolas Thiery. I
am extremely grateful and amazed what these two guy accomplished in such a
short time. (Antoine and I added some pretty printing for fun...)

FREE ALDOR!

The Axiom-Aldor Workshop 2007 is going to happen next year at the RISC in
Hagenberg, near Linz, Austria. The topic will be "Computer Algebra meets ???"
where ??? might be one of Graph Theory, Algebra or Analysis. Date to be
fixed. Send abstracts of talks, requirements for the date, fields you are
interested in to Martin Rubey :-)

I believe that we can say that in terms of produced code the workshop was a
tremendous success. Even more, the talks were of extremely high quality. Thanks
again to all the speakers! 

Here I would also like to say "thank you" to the RISC team, to provide such
excellent conditions.

Finally I would like to say a big "thank you" to Ralf Hemmecke! 

FREE ALDOR!

\start
Date: Sat, 29 Apr 2006 17:01:18 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: A{ld,xi}o{r,m}-Combinat
Cc: Nicolas M. Thiery

Martin,

On April 29, 2006 3:39 PM you wrote:
> 
> attached you find a screenshot from some code and its output 
> that has emerged from the Axiom Workshop 2006. I hope you like
> it. Note that the two lines in the upper frame define TreeClass
> completely as a domain, given the domain Atom and the functors
> CrossClass and UnionClass...

Cool. Of course I am very curious about the latter two functors. :) 

> 
> The code is mainly from Ralf Hemmecke in collaboration with 
> Nicolas Thiery. I am extremely grateful and amazed what these
> two guys accomplished in such a short time. (Antoine and I
> added some pretty printing for fun...)

I am sure that the entire "team" is very talented but I am
inclined to want to underline the word "collaboration". What
perhaps is most amazing is how powerful Axiom/Aldor is when
one actually learns to use it right. :) And working together as
a small team makes it very productive. I hope we somehow find
it possible to arrange more (and more frequent) such "sprints"
on all sorts of Axiom subjects.

> 
> FREE ALDOR!
>

Indeed. I was pleased to note today the Bob Sutor, one of the
creators of Axiom, added his name and "good luck" wish to the
FreeAldor page on Axiom Wiki. :)

> The Axiom-Aldor Workshop 2007 is going to happen next year at 
> the RISC in Hagenberg, near Linz, Austria. The topic will be
> "Computer Algebra meets ???" where ??? might be one of Graph
> Theory, Algebra or Analysis.

Glad to hear it. Perhaps with this much notice I can make it
there next year. :)

> Date to be fixed. Send abstracts of talks, requirements for
> the date, fields you are interested in to Martin Rubey :-)

Graph theory sounds nice but my "wish" is really that the topic
could be "Computer Algebra meets category theory" ... in my
opinion the potential for category theory in computer algebra
has not even begun to be tapped and Axiom is in a particularly
good position to take the lead.

> 
> I believe that we can say that in terms of produced code the 
> workshop was a tremendous success. Even more, the talks were
> of extremely high quality. Thanks again to all the speakers! 
> 

Thanks for the quick report. I am glad to hear that it turned
out so well. Perhaps we will hear also from some of the other
participants? Any pictures?

\start
Date: Sat, 29 Apr 2006 15:01:17 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Martin Rubey
Subject: RE: A{ld,xi}o{r,m}-Combinat
Cc: Nicolas M. Thiery

--- Bill Page wrote:

> Martin,
> 
> On April 29, 2006 3:39 PM you wrote:
> > 
> > attached you find a screenshot from some code and its output 
> > that has emerged from the Axiom Workshop 2006. I hope you like
> > it. Note that the two lines in the upper frame define TreeClass
> > completely as a domain, given the domain Atom and the functors
> > CrossClass and UnionClass...

Neat!  Oh, inquiring minds want to know - which Emacs mode was that?

> > The code is mainly from Ralf Hemmecke in collaboration with 
> > Nicolas Thiery. I am extremely grateful and amazed what these
> > two guys accomplished in such a short time. (Antoine and I
> > added some pretty printing for fun...)
> 
> I am sure that the entire "team" is very talented but I am
> inclined to want to underline the word "collaboration". What
> perhaps is most amazing is how powerful Axiom/Aldor is when
> one actually learns to use it right. :) And working together as
> a small team makes it very productive. I hope we somehow find
> it possible to arrange more (and more frequent) such "sprints"
> on all sorts of Axiom subjects.

Maybe we should add a "geographic location" map for axiom developers -
I'm in the US (VA) and since Axiom is only a hobby for me I can't
really afford going to Europe :-(.  I really regret missing the one in
NY now :-/.  Not that I had anything particularly interesting to show
at that point...

> > FREE ALDOR!
> >
> 
> Indeed. I was pleased to note today the Bob Sutor, one of the
> creators of Axiom, added his name and "good luck" wish to the
> FreeAldor page on Axiom Wiki. :)
> 
> > The Axiom-Aldor Workshop 2007 is going to happen next year at 
> > the RISC in Hagenberg, near Linz, Austria. The topic will be
> > "Computer Algebra meets ???" where ??? might be one of Graph
> > Theory, Algebra or Analysis.
> 
> Glad to hear it. Perhaps with this much notice I can make it
> there next year. :)

RISC would be a neat place to visit - lots of good work has come out of
there.
 
> > Date to be fixed. Send abstracts of talks, requirements for
> > the date, fields you are interested in to Martin Rubey :-)
> 
> Graph theory sounds nice but my "wish" is really that the topic
> could be "Computer Algebra meets category theory" ... in my
> opinion the potential for category theory in computer algebra
> has not even begun to be tapped and Axiom is in a particularly
> good position to take the lead.

Gotta agree with that one!  Reminds me, I need to bite the bullet and
buy a couple of those category theory books someone recommended...

> > I believe that we can say that in terms of produced code the 
> > workshop was a tremendous success. Even more, the talks were
> > of extremely high quality. Thanks again to all the speakers! 
> > 
> 
> Thanks for the quick report. I am glad to hear that it turned
> out so well. Perhaps we will hear also from some of the other
> participants? Any pictures?

Next year maybe we could chip in a few bucks and someone could rent a
video camera to record the talks (provided the speakers agree, of
course.)  This was done for at least one of the Blender conferences and
I found it a very interesting resource.

\start
Date: Sat, 29 Apr 2006 16:03:32 -0700 (PDT)
From: Cliff Yapp
To: Jay Belanger
Subject: Emacs mode in Windows

Well, it doesn't work out of the box, but after some tweaking I managed
to get it to run.  The primary problem seems to be that the prompt
work-arounds needed for the patch-49 version aren't required for the
(older) Windows binary.  It's not clear to me why, although I do recall
earlier discussions about this "double prompt" behavior on Windows.

Anyway, for those who absolutely can't wait to have something better
than the dos window, this might help.  I don't know how to "special
case" Windows cleanly in Emacs yet, so this version is a one-off from
the sandbox pamphlet for now.  I loaded it by opening the file in
Emacs, doing the byte-compile-and-load menu option, switching to
scratch, and then typing M-x axiom-mode.  Something cleaner is probably
possible but that's how I normally test this so I haven't figured out
the clean way yet.

\start
Date: Sun, 30 Apr 2006 01:17:34 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: A{ld,xi}o{r,m}-Combinat
Cc: Nicolas M. Thiery

Hello,

On 04/29/2006 11:01 PM, Bill Page wrote:
> Martin,
> 
> On April 29, 2006 3:39 PM you wrote:
>> attached you find a screenshot from some code and its output 
>> that has emerged from the Axiom Workshop 2006. I hope you like
>> it. Note that the two lines in the upper frame define TreeClass
>> completely as a domain, given the domain Atom and the functors
>> CrossClass and UnionClass...
> 
> Cool. Of course I am very curious about the latter two functors. :)

You find the code below. But let me add a few words. The code is 
probably not identical to the one Martin actually used in his screen 
shot, but it is the first working version of that code.

I guess, most of you might now say: well, it looks completely trivial 
and natural. Yes, that is the point! Aldor allows this. The hard thing 
actually was, to understand the MuPAD-combinat design (in particular to 
understand what a "combinatorial class" is and then to translate it into 
an appropriate design for Aldor.

Actually, I must thank Nicolas quite a bit. He showed in his talks how 
useful recursion is. And how this is currently done in MuPAD. Basically, 
in MuPAD-combinat it is of importance that one should be able to define 
combinatorial classes via a grammer. MuPAD-combinat then computes a 
fixed point for this grammar in order to get the combinatorial classes. 
And as I understood Nicolas, that code is quite huge and complicated.

The amazing thing now is that the Aldor compiler computes the fixpoint. 
That makes the code below so short.

> I hope we somehow find it possible to arrange more (and more frequent)
 > such "sprints" on all sorts of Axiom subjects.

I'm all for it. We had lot's of fun, too. ;-)

> Indeed. I was pleased to note today the Bob Sutor, one of the
> creators of Axiom, added his name and "good luck" wish to the
> FreeAldor page on Axiom Wiki. :)

I very much hope that the Aldor sources can be opened. But that is only 
the first step. There needs to be a lot of teaching, too, in order to 
show people the beauty of Aldor. It is not always easy to handle such a 
powerful language, since translating the design of a project written in 
some other language to Aldor is a nontrivial task.

>> The Axiom-Aldor Workshop 2007 is going to happen next year at 
>> the RISC in Hagenberg, near Linz, Austria. The topic will be
>> "Computer Algebra meets ???" where ??? might be one of Graph
>> Theory, Algebra or Analysis.

> Graph theory sounds nice but my "wish" is really that the topic
> could be "Computer Algebra meets category theory" ... in my
> opinion the potential for category theory in computer algebra
> has not even begun to be tapped and Axiom is in a particularly
> good position to take the lead.

Oh, though I have not worked much in category theory (I only know the 
basics), I would love that. Maybe until then we could even have some 
computations in category theory implemented in Axiom...
My fear is only that there are perhaps not so many people who would want 
to come. Other opinions?

>> I believe that we can say that in terms of produced code the 
>> workshop was a tremendous success.

I would say, it was of equal importance that we spread the idea...
Nicolas, am I wrong if I say that you and perhaps your "team" now more 
seriously consider Aldor/Axiom as an option? Of course, that all depends 
on the availablility of Aldor.

> Thanks for the quick report. I am glad to hear that it turned
> out so well. Perhaps we will hear also from some of the other
> participants? Any pictures?

Yes. But I need some rest. I had a light flu that started right before 
the workshop. Now I can hardly speak anymore. :-(

All the best and also a big thanks to Martin who first came up with the 
idea to have such a workshop at RISC and who worked quite a lot for it.

\start
Date: Sun, 30 Apr 2006 08:20:39 +0900
From: Jean-Christophe Helary
To: list
Subject: re: sourceforge cvs

> There is definitely a strange problem with the CVS at SourceForge.

I have not been following the thread closely but SF has locked  
anonymous checkout because they had problems with it.

I work on a project where the latest we can get is a March 9th update  
when the developer keeps adding stuff everyday.

There is a note somewhere on SF about that.

\start
Date: Sun, 30 Apr 2006 01:25:16 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Emacs mode in Windows

Hello Cliff,

thanks for your work on axiommode.el, but I really really wonder, why 
that is not a pamphlet file. Or is it and I just don't know?

Always think of those poor guys who come after you and had to modify 
your stuff.

\start
Date: Sun, 30 Apr 2006 01:31:18 +0200
From: Ralf Hemmecke
To: Bill Page,
Subject: Re: A{ld,xi}o{r,m}-Combinat

Oooop, no it was not intentional that I forgot the code in my last mail 
on this thread. Sorry.

-------------------------------------------------------------------
----
---- CombClass
---- Copyright (C) Ralf Hemmecke (Ralf Hemmecke)
---- http://www.hemmecke.de/aldor
----
-------------------------------------------------------------------

#include "aldor"
macro CCC == CombinatorialClassCategory;
import from Integer;

CombinatorialClassCategory: Category == with {
	count: Integer -> Integer;
}

Primitive(T: Type, n: Integer): CombinatorialClassCategory == add {
         Rep == T;
         count(i: Integer): Integer == if i=n then 1 else 0;
}
Epsilon(T: Type): CombinatorialClassCategory == Primitive(T, 0) add;
Atom(T: Type): CombinatorialClassCategory == Primitive(T, 1) add;

UnionClass(T: Type, S1: CCC, S2: CCC): CCC == add {
         Rep == Record(t1: T, t2: T);
	count(i: Integer): Integer == count(i)$S1 + count(i)$S2;
}

CrossClass(T: Type, S1: CCC, S2: CCC): with {
         CombinatorialClassCategory
} == add {
         Rep == Record(t1: T, t2: T);

	count(i: Integer): Integer == {
--		c := count(0)$S1;
--		result := if zero? c then 0 else c * count(i)$S2;
		result := 0;
		for k in 1 .. i-1 repeat {
			result := result + count(k)$S1 * count(i-k)$S2;
		}
--		c := count(0)$S2;
--		result + (if zero? c then 0 else count(i)$S1) * c;
		result;
	}
}

TreeClass: CombinatorialClassCategory == UnionClass(Integer,
     Atom Integer,
     CrossClass(Integer, TreeClass, TreeClass)
) add;
--rhx: THIS "add" MUST BE HERE. Otherwise the code segfaults.
--rhx: The "reason": with "add" the compiler does a fix point
--rhx: computation.
--rhx: My guess: Without the "add" it is a simple constant
--rhx: assignment, and when the domain is the constant assignment
--rhx: takes place at runtime, the right hand side is evaluated
--rhx: completely before it gets assigned to the lefthand side.
--rhx: Well, but there then clearly is unevaluatable code on the
--rhx: righthand side.
--rhx: In my eyes, it's a but that the compiler does not complain
--rhx: if there is recursion and no "add".

combinat(args: Array String): () == {
         import from TreeClass;
         import from TextWriter, String, Character, Integer;
         stdout << "count 0 = " << count(0) << newline;
         stdout << "count 1 = " << count(1) << newline;
         stdout << "count 2 = " << count(2) << newline;
         stdout << "count 3 = " << count(3) << newline;
         stdout << "count 4 = " << count(4) << newline;
         stdout << "count 5 = " << count(5) << newline;
         stdout << "count 6 = " << count(6) << newline;
         stdout << "ENDE" << newline;
};

combinat(arguments$CommandLine);


#if COMMANDLINE
aldor -fx -laldor combclass.as
combclass
count 0 = 0
count 1 = 1
count 2 = 1
count 3 = 2
count 4 = 5
count 5 = 14
count 6 = 42
ENDE
#endif

\start
Date: 30 Apr 2006 01:33:24 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: axiom opportunity

Bill Page writes:

| On April 26, 2006 2:50 PM Gabriel Dos Reis wrote:
| > 
| > Tim Daly (root) writes:
| > 
| > | All of that effort is due to Camm. Unfortunately his tarball of 
| > | patches are all undocumented so I have no idea why those changes
| > | are necessary. I'm reluctant to make changes without understanding.
| > | > 
| > | > Do you have link to those patches?
| > | 
| > | wget daly.axiom-developer.org/axiom_20050901-6.diff
| > 
| > Thanks!
| > 
| 
| Concerning documentation of the Debian patches for Axiom recall
| that:
| 
| http://lists.gnu.org/archive/html/gcl-devel/2005-12/msg00052.html

Many thanks.  I'll go over this later when time permits.

\start
Date: Sat, 29 Apr 2006 18:52:56 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Emacs mode in Windows

--- Ralf Hemmecke wrote:

> Hello Cliff,
> 
> thanks for your work on axiommode.el, but I really really wonder, why
> that is not a pamphlet file. Or is it and I just don't know?

Sort of.  Sorry, I should have been clearer.  The pamphlet version is
here:

http://wiki.axiom-developer.org/SandBoxAxiomEmacsMode

and should work fine on Linux.  But that version (e.g., the one
generated directly from that pamphlet) will not run on Windows for two,
possibly three reasons:

1.  The "axiom" command used on Linux is not the one that works on
Windows - I needed C:/Program Files/axiom/mnt/window/AxiomSYS.exe or
something like that.

2.  I took out the -noht and -noclef options.  I might not have had to
do that - this is the one I'm not sure about - but they don't seem to
be needed here.

3.  The code I use to clean up the double (1) -> prompt on Linux causes
a hang on Windows, because the version of Axiom in the Windows binary
doesn't produce the double (1) ->.  So I had to comment that out.  I
might be able to conditionalize it for Window vs. Linux if Emacs can
tell me where I'm running, but that's a temporary measure at best.  I'm
not quite sure how to handle it - does anyone know why the Linux
version produces that initial double prompt?  If that could go away
things would be simpler.
 
> Always think of those poor guys who come after you and had to modify 
> your stuff.

I pity them either way ;-).  But there does exist a pamphlet version,
which is the "main" version and the one where all future work will take
place.  This is partially to preserve the changes it took to make it
work on Windows, partially to announce that it CAN work on Windows at
all, and partially taking pity on those stuck with a DOS window ;-). 
It may be that the other mode on AxiomonEmacs (axiom-smallest or some
such) works and works better for now, but since this one has been
demonstrated to work (on WinXP anyway) I wanted to let folks know.

I think this mode will have to stay in the Sandbox for quite a while -
there are many changes and features to come before it can claim to be a
really serious asset to users or developers.

\start
Date: Sat, 29 Apr 2006 22:41:37 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Emacs mode in Windows
Cc: Ralf Hemmecke

On April 29, 2006 9:53 PM C Y wrote:
> ...
> The pamphlet version is here:
> 
> http://wiki.axiom-developer.org/SandBoxAxiomEmacsMode
> 
> and should work fine on Linux.

I think your emacs mode project using pamphlet files on
Axiom Wiki is a great demonstration of how to do this kind
of collaboration on line. Good work Cliff and Jay!

> But that version (e.g., the one generated directly from
> that pamphlet) will not run on Windows for two, possibly
> three reasons:

If it proves necessary, you might consider including an
alternate <<windows-main>>= chunk that would allow one to
tangle a windows version of the code from the same source
document. You can select this chunk in the drop down box
next to the 'tangle' button. Then clicking 'tangle' would
generate a windows version of your code.

> 
> 1.  The "axiom" command used on Linux is not the one that
> works on Windows - I needed
> C:/Program Files/axiom/mnt/window/AxiomSYS.exe
> or something like that.

Actually just 'AXIOMsys' should work fine if the Windows
version of Axiom was installed by the automatic installer
or if the AXIOMsys.exe binary is in the PATH (as set by
the installer).

> 
> 2.  I took out the -noht and -noclef options.  I might
> not have had to do that - this is the one I'm not sure
> about - but they don't seem to be needed here.

They are not needed and would probably be ignored if passed
to AXIOMsys.

> 
> 3.  The code I use to clean up the double (1) -> prompt on 
> Linux causes a hang on Windows, because the version of Axiom
> in the Windows binary doesn't produce the double (1) ->.  So
> I had to comment that out.  I might be able to conditionalize
> it for Window vs. Linux if Emacs can tell me where I'm running,
> but that's a temporary measure at best.  I'm not quite sure
> how to handle it - does anyone know why the Linux version
> produces that initial double prompt?  If that could go away
> things would be simpler.

The reason for this difference is that there is no 'sman'
program on Windows - at least not yet - because we do not
have Axiom graphics and hyperdoc on Windows.

On linux the 'axiom' command does not start Axiom directly,
instead it calls the 'sman' program which then starts the
Axiom main process 'AXIOMsys', the Axiom graphics process,
the hyperdoc process and sets up the communication between
these processes. The option -noht tells sman not to start the
hyperdoc process. The option -noclef tells sman not to use
Axiom's line input filter process to replace 'readline'.
(Windows DOS window has similar built-in functionality.)

One side-effect of starting Axiom through sman is the double
prompt which is caused because sman asks Axiom to create a
new "frame". Another side effect is the larger number of
processes running.

On linux it is also possible to call AXIOMsys directly just
like on Windows. In that case you will only see a single
prompt on both Windows and linux. In fact it is probably a
good idea to call AXIOMsys directly like this *unless* you
really do need to use Axiom graphics in your emacs session.

> ...  This [email] is partially to preserve the changes it
> took to make it work on Windows, partially to announce that
> it CAN work on Windows at all, and partially taking pity on
> those stuck with a DOS window ;-).

I think it would be a good idea to include this sort of design
information somewhere in the SandBoxAxiomEmacsMode pamphlet
file maybe associated with the <<windows-main>>= chunk I
suggested above?

> It may be that the other mode on AxiomonEmacs (axiom-smallest
> or some such) works and works better for now, but since this
> one has been demonstrated to work (on WinXP anyway) I wanted
> to let folks know.

I think that's great news. I think you might be surprised to
learn how many people actually use xemacs on windows and how
many people install the Windows version of Axiom as their first
contact with Axiom. We badly need to build a new Windows binary
distribution real-soon-now and I think we should definitely
should include an emacs mode and maybe even the option of
installing xemacs itself with this mode pre-installed. We
already do this for the TeXmacs interface. (Windows users expect
everything to be done for them! :) The last Windows binary was
created from the Windows source distribution more than a year
ago and the Windows source distribution itself is not up to
date with the linux sources.

> 
> I think this mode will have to stay in the Sandbox for quite
> a while - there are many changes and features to come before
> it can claim to be a really serious asset to users or
> developers.
> 

\start
Date: Sat, 29 Apr 2006 20:38:53 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Emacs mode in Windows
Cc: Ralf Hemmecke

--- Bill Page wrote:

> On April 29, 2006 9:53 PM C Y wrote:
> > ...
> > The pamphlet version is here:
> > 
> > http://wiki.axiom-developer.org/SandBoxAxiomEmacsMode
> > 
> > and should work fine on Linux.
> 
> I think your emacs mode project using pamphlet files on
> Axiom Wiki is a great demonstration of how to do this kind
> of collaboration on line. Good work Cliff and Jay!

Thanks!

> > But that version (e.g., the one generated directly from
> > that pamphlet) will not run on Windows for two, possibly
> > three reasons:
> 
> If it proves necessary, you might consider including an
> alternate <<windows-main>>= chunk that would allow one to
> tangle a windows version of the code from the same source
> document. You can select this chunk in the drop down box
> next to the 'tangle' button. Then clicking 'tangle' would
> generate a windows version of your code.

That's a great idea, but it looks like you might have hit on the
solution, at least for the short term.  AXIOMsys should solve almost
everything.

> > 1.  The "axiom" command used on Linux is not the one that
> > works on Windows - I needed
> > C:/Program Files/axiom/mnt/window/AxiomSYS.exe
> > or something like that.
> 
> Actually just 'AXIOMsys' should work fine if the Windows
> version of Axiom was installed by the automatic installer
> or if the AXIOMsys.exe binary is in the PATH (as set by
> the installer).

Tested and confirmed.

> > 2.  I took out the -noht and -noclef options.  I might
> > not have had to do that - this is the one I'm not sure
> > about - but they don't seem to be needed here.
> 
> They are not needed and would probably be ignored if passed
> to AXIOMsys.

I think this is also the case.  Initial test seems to indicate it.

> > 3.  The code I use to clean up the double (1) -> prompt on 
> > Linux causes a hang on Windows, because the version of Axiom
> > in the Windows binary doesn't produce the double (1) ->.  So
> > I had to comment that out.  I might be able to conditionalize
> > it for Window vs. Linux if Emacs can tell me where I'm running,
> > but that's a temporary measure at best.  I'm not quite sure
> > how to handle it - does anyone know why the Linux version
> > produces that initial double prompt?  If that could go away
> > things would be simpler.
> 
> The reason for this difference is that there is no 'sman'
> program on Windows - at least not yet - because we do not
> have Axiom graphics and hyperdoc on Windows.

Ah!

> On linux the 'axiom' command does not start Axiom directly,
> instead it calls the 'sman' program which then starts the
> Axiom main process 'AXIOMsys', the Axiom graphics process,
> the hyperdoc process and sets up the communication between
> these processes. The option -noht tells sman not to start the
> hyperdoc process. The option -noclef tells sman not to use
> Axiom's line input filter process to replace 'readline'.
> (Windows DOS window has similar built-in functionality.)

OK.  As long as AXIOMsys ignores options, we can have our cake and eat
it too, from the looks of it.  I may be able to fake up a way to try
first for axiom, then for AXIOMsys.

> One side-effect of starting Axiom through sman is the double
> prompt which is caused because sman asks Axiom to create a
> new "frame". Another side effect is the larger number of
> processes running.

Hmm.  On Linux that may be OK - I'll have to see how graphics commands
work inside Emacs.

> On linux it is also possible to call AXIOMsys directly just
> like on Windows. In that case you will only see a single
> prompt on both Windows and linux. In fact it is probably a
> good idea to call AXIOMsys directly like this *unless* you
> really do need to use Axiom graphics in your emacs session.

I think we would want to enable graphics if possible... I don't know if
there is a way to "check" for the presence of a command without running
it in a cross platform manner, but I can try to find out.

> > ...  This [email] is partially to preserve the changes it
> > took to make it work on Windows, partially to announce that
> > it CAN work on Windows at all, and partially taking pity on
> > those stuck with a DOS window ;-).
> 
> I think it would be a good idea to include this sort of design
> information somewhere in the SandBoxAxiomEmacsMode pamphlet
> file maybe associated with the <<windows-main>>= chunk I
> suggested above?

Can do, once I get home to my own machine.  Of course, then I can't
test on Windows any more...

> > It may be that the other mode on AxiomonEmacs (axiom-smallest
> > or some such) works and works better for now, but since this
> > one has been demonstrated to work (on WinXP anyway) I wanted
> > to let folks know.
> 
> I think that's great news. I think you might be surprised to
> learn how many people actually use xemacs on windows and how
> many people install the Windows version of Axiom as their first
> contact with Axiom. 

Any of them interested in occasional alpha testing?

> We badly need to build a new Windows binary
> distribution real-soon-now and I think we should definitely
> should include an emacs mode and maybe even the option of
> installing xemacs itself with this mode pre-installed. We
> already do this for the TeXmacs interface. (Windows users expect
> everything to be done for them! :)

I was wondering about that - given the abysmal usability of the dos
prompt solution, maybe we could stuff Emacs in there configured to act
as the default terminal?  I know it would be large but it would be in
keeping with Tim's "make it work" approach and would probably appeal to
casual downloaders more.

Of course, that's assuming it actually gets enhanced to a really usable
point...  (if (is-before-cart (get-current-horse)) (backpedal-quickly))

> The last Windows binary was
> created from the Windows source distribution more than a year
> ago and the Windows source distribution itself is not up to
> date with the linux sources.

Does anybody remember how that was created?  I know it's some kind of
mix of the Nullsoft installer, mingw/msys, lots of patience and
sacrificing  six liters of Jolt by the light of a full moon...

If ever a literate document was needed for Axiom, it would be some kind
of "build a Windows install.exe file" scripts and procedure.

> > I think this mode will have to stay in the Sandbox for quite
> > a while - there are many changes and features to come before
> > it can claim to be a really serious asset to users or
> > developers.
> 
> Keep up the good work!

Thanks!  Will do (or try anyway.)  Pretty soon I'm going to have to
face mmm-mode, and that's probably where things are going to get hairy.


User feedback (assuming users exist, of course) would be useful - I'm
sort of making up the feature set as I go here.  On the immediate todo
list:

1.  Figure out some sort of way to flag the case where an old input is
modified but not re-evaluated - this ensures input and output blocks
match up or are flagged as not matching for the user.
2.  Figure out how to completely restart Axiom while leaving the
previous document in place.  As a side note, load an older Axiom
session and start Axiom up behind it.
3.  Save a session as a latex document.  That one will be tricky.
4.  Syntax highlighting.

I've got more ideas, but that should be enough to keep me out of
trouble for a while.

\start
Date: Sun, 30 Apr 2006 11:35:48 -0400
From: Bill Page
To: Alfredo Portes, Wilken Rivera
Subject: RE: Doyen @ ASEE Mid-Atlantic Spring Conference 2006
Cc: Douglas Troeger, Yegor Bryukhov, Gilbert Baumslag, Bernice Rogowitz

On April 30, 2006 10:43 AM Alfredo Portes wrote:

> Attached to this email there are some pictures of the ASEE poster
> presentation at City Tech.
>
> This is the website of the conference:
http://websupport1.citytech.cuny.edu/Faculty/hli/asee/asee/default.asp 

Great work guys! Your poster looks very interesting.

I have downloaded and tested your most recent version of the
Doyen CD from

http://wiki.axiom-developer.org/DoyenCD

and I think it is looking very good. It booted and ran Axiom and
the local Doyen-Wiki web interface for Axiom just fine.  It would
be nice to have a similar web interface for Magnus and a few other
open source computer algebra packages.

I think what you need now is some useful content in the Doyen-Wiki
to help users get started.

What you have here will be very useful for promoting Axiom and
other computer algebra systems by distributing this CD at
conferences and via non-profit channels such as CafePress and
Lulu.

Would you be willing to add some of the materials from your poster
to the Axiom Wiki? I suggest creating a link under 'Axiom Meetings'
at

http://wiki.axiom-developer.org/AxiomCommunity

Could you include some of your photos? Maybe something like this:

http://wiki.axiom-developer.org/AxiomMeeting2005

\start
Date: Sun, 30 Apr 2006 09:23:39 -0700
From: Bob McElrath
To: Gregory Vanuxem
Subject: re: [MathML]

Gregory Vanuxem wrote:
> > Could you take a look at http://wiki.axiom-developer.org/SandBoxMathML ?
> > 
> > I think I have copied all the relevant bits from tex.spad.pamphlet but
> > it still tells me it can't coerce to my new domain.
> 
> Since this package is not implemented:
> 
> )abbrev package MML1 MathMLFormat1
> MathMLFormat1(S : SetCategory): public == private where
>   public  ==  with
>     coerce: S -> MathMLFormat()
>   private == add
>     import MathMLFormat()
> 
>     coerce(s : S): MathMLFormat ==
>       coerce(s :: OutputForm)$MathMLFormat
> 
> 
> You have to use for example 1::OutputForm::MML.
> 
> And since the function coerce($):OutputFrom is not implemented the
> result cannot be printed ("The function coerce with signature hashcode
> is missing from domain MathMLFormat").
> 
> So can only use
> 
> \begin{axiom}
> 1::OutputForm::MML;
> \end{axiom}

Thanks for the hint but it still doesn't work.  If I read teh above
correctly, it should be used like:

    x::MathMLFormat1(OutputForm)

    Cannot convert from type Variable x to MathMLFormat1 OutputForm for
    value x

So then I try manually converting to OutputForm first:

    x::OutputForm::MathMLFormat1(OutputForm)

    Cannot convert from type OutputForm to MathMLFormat1 OutputForm for
    value x

what am I doing wrong?

\start
Date: Sun, 30 Apr 2006 19:20:34 +0200
From: Gregory Vanuxem
To: Bob McElrath
Subject: re: [MathML]

[...]

> Thanks for the hint but it still doesn't work.  If I read teh above
> correctly, it should be used like:
>
>     x::MathMLFormat1(OutputForm)
>
>     Cannot convert from type Variable x to MathMLFormat1 OutputForm for
>     value x

No, MathMLFormat1 is a package and not a domain. It's usage is to coerce
elements that inherit from SetCategory to MathMLFormat (SetCategory
exports the function 'coerce : % -> OutputForm' so this coercion can be
used in this package)

So its usage is (for example):

coerce(x)$MathMLFormat1(POLY INT);


> So then I try manually converting to OutputForm first:
>
>     x::OutputForm::MathMLFormat1(OutputForm)
>
>     Cannot convert from type OutputForm to MathMLFormat1 OutputForm for
>     value x
>
> what am I doing wrong?

To coerce any element to MathMLFormat without the MathMLFormat1 package
you have to coerce the element to OupuForm first since the coerce
function in MathMLFormat is of the form 'coerce:   OuptutForm -> $':

x::OutputForm::MathMLFormat;

The MathMLFormat1 package is just an utility package to avoid to coerce
element to OutputForm first (the interpreter will directly use this
package).

So now you can use:

x::MathMLFormat;

But note that there is always a semicolon at the end of the command
(sorry I forgot to insist on this point). If you remove the semicolon
you'll get the error message:

The function coerce with signature hashcode is missing from domain
MathMLFormat

The interpreter here try to coerce the MathMLFormat element to
OutputForm (to print it on the screen) so you have to implement the
function 'coerce: $ -> OutputForm' in the MathMLFormat domain.

\start
Date: Sun, 30 Apr 2006 13:56:29 -0400
From: Tim Daly
To: list
Subject: Re: Doyen @ ASEE Mid-Atlantic Spring Conference 2006

you guys have done an excellent job! this is going to mean so
much more than just coursework on your resumes. anybody can take
courses but few people build a science platform using open source.
Consider writing up the work and submitting it to an external
conference. The more exposure you get the better your opportunities.

interesting to see the pictures. i don't recognize the hall.

it could also be packaged into a VMWare virtual machine. VMWare
now makes a freeware virtual machine player. this would mean that
anyone could have a Doyen science platform running on any opsys.
i really think that this is going to have a long term impact.

perhaps we can figure out a way to show it at ISSAC 2007.
i'll certainly be showing examples of it at ISSAC 2006.

the wiki integration is a nice step.
i've been working on rewriting the axiom browser pages into javascript.
that would allow the wiki to replace the axiom browser.
i should probably send you a few examples so you can try them
and give some feedback.

\start
Date: 01 May 2006 03:39:27 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Editing wiki frontpage

Bill Page writes:

| Gaby,
| 
| On April 7, 2006 9:54 AM you wrote:
| > 
| > How does one edit the wiki front-page?  What I'm interested 
| > is to put a link from the front-page to a separate page that
| > documents the SVN source code is organized and how to do check
| > outs and check ins.
| > 
| 
| Editing the FrontPage (and a few other "special" pages on
| the Axiom Wiki) requires a Zope user id. Right now, only me,
| Rubey Martin, and Ralf Hemmecke have this sort of user id.
| If you are interested in sharing responsibility for the
| content of these pages, I have no problem providing you
| with similar access.
| 
| On the other hand, if all you would like is a link on the
| FrontPage, then just let me know the page name you want and
| I will add the link for you.

Hi Bill,

I would like to have the following information linked from the
FrontPage, probably under the name "Axiom silver branch".  I will add
more information later.  Suggestions for improvements are welcome.
Many thanks!

-- Gaby

Obtaining a working copy from the Sourceforge SVN repository
============================================================

* SVN requirements:

  You need a working SVN command that supports the HTTP protocol.  
  You can get a copy from

        http://subversion.tigris.org/


  Here is an excellent online book on version control with Subversion

        http://svnbook.red-bean.com/


* read-only access:

   Check out the silver branch of Axiom source code with

     svn co https://svn.sourceforge.net/svnroot/axiom/trunk axiom.silver

  That command will create a directory, named axiom.silver, to
  hold checked out copy of the Axiom source code.  Please, feel free to
  replace "axiom.silver" with any name that suits your taste.

  If you are only interested in a particular development branch, say
  build-improvement, you may say

   svn co https://svn.sourceforge.net/svnroot/axiom/branch/build-improvement \
                axiom.build-improvement


* read and write access:

  You need to have a Sourceforge user id, and be registered as a developer.

  To obtain a working copy with write privilege to the sourceforge
  repository you might want to append "--username=<sf-user-id>" to the
  above commands, where <sf-user-id> is your sourceforge user id.  


* "Core" developers:  

   Some developers might prefer to have a working copy of the "whole"
   axiom repository, in that case they might want to issue

     svn co https://svn.sourceforge.net/svnroot/axiom axiom

   That will check out the Axiom main repository into a local
   directory named axiom. It should contain the following
   subdirectories: 

        branches/
        tags/
        trunk/

   that are self-explanatory.


Building Axiom from the development source
==========================================

The Axiom build machinery is very complex, stratified in many
layers.  At the moment the build system is known to support only
native build-in-source.  This means Axiom is known to build for a
large set of target platforms where

   * the configure and make commands are issued from the directory
     containing the Axiom source codes, and the build happens in that
     directory;
   
   * no cross-compilation is involved.


You might find it convenient, especially if you are working with
repository files (either from SVN or CVS), to have the build happens
in a different directory than the one containing Axiom pristine
sources.  To that end, you can create a build directory that mirrors
the source directory as follows:

   # create a directory for building axiom
   $ mkdir axiom-build-dir

   # mirror the source directory structure with lndir
   $ cd axiom-build-dir && lndir /path/to/axiom.silver

Here the lndir command creates a shadow directory of symbolic links
to the Axiom source directory (here axiom.silver).  Once that is done,
you can 

   # configure the source directory
   $ ./configure
   
Follow the instructions displayed after the configuration step.


At the moment, Axiom does not support the standard GNU-style configure
command switches.  Work is being done to remedy that situation.


Preparing and submitting patches
================================

When contributing a patch for consideration in the silver branch,
please send a message to the mailing list

    axiom-dev@axiom-developer.org
   
that contains the patch in Naur format (e.g. as produced by diff -Naur), 
and a ChangeLog entry briefly explaining the changes.  Please remember
that your modifications must follow the pamphlet style where required,
be properly documented.  Also, remember that patches for inclusion in
the silver branch must be prepared against the current "trunk" of the
SVN repository.  To that end, you might first want to update your
working copy with

   $ svn update

before producing the patch that you will submit.  We assume that
before sending your patch, you have built and tested axiom as per your
modification.  Be sure to indicate on which plateforms you have tested
your changes. 



