\start
Date: 01 Apr 2007 08:38:38 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: SymPy on Axiom Wiki

Gabriel Dos Reis writes:

> Bill Page writes:
> 
> [...]
> 
> | I would like to discuss this more with other active Axiom
> | developers.
> 
> Why should InputForm be preferable over Expression T?

These two domains serve two entirely different purposes, and I would warn you
not to abuse INFORM, since the idea behind it is very clever indeed, and I
definitively will use it in the future.

\start
Date: Sun, 1 Apr 2007 03:03:38 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: symbolic manipulation of expressions in Axiom (was: SymPy on Axiom Wiki)

On March 31, 2007 7:10 PM Gaby wrote:
> 
> Bill Page writes:
> 
> > [...]

Since I am changing the subject line, let me also re-insert
a little more context from my previous email:

> | I think it would be much better if the coercion to
> | OutputForm from InputForm looked more (or even exactly)
> | like the syntax of input to the Axiom interpreter. Then
> | we could add symbolic manipulations such as are done in
> | SymPy directly to Axiom. In fact this would be very easy
> | to do and the fact that it has not yet been done in Axiom
> | can only related to the pre-occupation of the original
> | Axiom developers with what Stephen Watt calls "computer
> | algebra" as opposed to the much simpler problem of symbolic
> | computation. But I think symbolic computation has an
> | important place in Axiom.
> |
> | I would like to discuss this more with other active Axiom
> | developers.
> 
> Why should InputForm be preferable over Expression T?
> 

I'm glad you asked. :-)

I presume that by "Expression T" you mean such domains as
'Expression Integer' and 'Expression Float' etc.

For me to answer your question it is important to understand
what Expression in Axiom really is. One way to do that is to
look at the internal representation.

  Rep:=Fraction SparseMultivariatePolynomial(T, Kernel %)

So Expression is a mathematical domain of rational functions
(ratio of two polymonials) where the polynomial variables
are extended to kernels including various special functions.
It is of course a very general so many symbolic expressions
can be evaluated as operations on members of this domain.
But the members of this domain are *not* general symbolic
expressions! They are quite literally things represented as
the ratio of two polynomials, which in turn are represented
by however ratios and polynomials are represented, etc. And
the OutputForm for the members of this domain correspond to
a much reduced set of symbolic expressions.

That is the reason why when you enter something like this:

(1) -> 1/sin(x)+y

Axiom responds with:

        y sin(x) + 1
   (1)  ------------
           sin(x)
                                 Type: Expression Integer

Even though perhaps it looks like it, Axiom is not performing
some kind of arbitrary "simplification" of symbolic expressions.
Instead what is happening is that Axiom is interpreting the
symbols in the input expression as operations performed in
some domain and evaluating those operations *algebraically*
to ultimately create a member of that domain - in this case
Expression Integer. Then the Axiom interpreter displays this
member using the coercion to OutputForm defined by the
domain.

In contrast the members of the domain InputForm represent
exactly the symbolic expression that is the *input* to the
interpreter. Manipulating members of this domain amounts to
directly manipulating the expressions.

\start
Date: Sun, 1 Apr 2007 03:05:29 -0400
From: Bill Page
To: Martin Rubey, Gabriel Dos Reis
Subject: re: SymPy on Axiom Wiki

On April 1, 2007 2:39 AM Martin Rubey wrote:
> 
> Gabriel Dos Reis writes:
> 
> > Bill Page writes:
> > 
> > [...]
> > 
> > | I would like to discuss this more with other active Axiom
> > | developers.
> > 
> > Why should InputForm be preferable over Expression T?
> 
> These two domains serve two entirely different purposes, and 
> I would warn you not to abuse INFORM, since the idea behind
> it is very clever indeed, and I definitively will use it in
> the future.
> 

What do you mean by "abuse" it? Certainly we use it all the
time in Axiom!

\start
Date: Sun, 01 Apr 2007 04:45:02 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: symbolic manipulation of expressions in Axiom (was: SymPy on Axiom Wiki)

>> Why should InputForm be preferable over Expression T?
>>
>
> I'm glad you asked. :-)
>
> I presume that by "Expression T" you mean such domains as
> 'Expression Integer' and 'Expression Float' etc.
>

Yes.

> For me to answer your question it is important to understand
> what Expression in Axiom really is. One way to do that is to
> look at the internal representation.
>
>  Rep:=Fraction SparseMultivariatePolynomial(T, Kernel %)
>
> So Expression is a mathematical domain of rational functions
> (ratio of two polymonials) where the polynomial variables
> are extended to kernels including various special functions.

Sorry, I don't think I'm satisfied with an answer that has to
look at the internal representation before explaining why I
should not believe the interface.

> It is of course a very general so many symbolic expressions
> can be evaluated as operations on members of this domain.
> But the members of this domain are *not* general symbolic
> expressions! They are quite literally things represented as
> the ratio of two polynomials, which in turn are represented
> by however ratios and polynomials are represented, etc. And
> the OutputForm for the members of this domain correspond to
> a much reduced set of symbolic expressions.
>
> That is the reason why when you enter something like this:
>
> (1) -> 1/sin(x)+y
>
> Axiom responds with:
>
>        y sin(x) + 1
>   (1)  ------------
>           sin(x)
>                                 Type: Expression Integer
>
> Even though perhaps it looks like it, Axiom is not performing
> some kind of arbitrary "simplification" of symbolic expressions.
> Instead what is happening is that Axiom is interpreting the
> symbols in the input expression as operations performed in
> some domain and evaluating those operations *algebraically*
> to ultimately create a member of that domain - in this case
> Expression Integer. Then the Axiom interpreter displays this
> member using the coercion to OutputForm defined by the
> domain.
>
> In contrast the members of the domain InputForm represent
> exactly the symbolic expression that is the *input* to the
> interpreter. Manipulating members of this domain amounts to
> directly manipulating the expressions.

\start
Date: 01 Apr 2007 18:57:44 +0200
From: Francois Maltey
To: list
Subject: evaluate a polynom for a matrix.

Hello,

Let P in Ring[X] and M in SquareMatrix(Ring)

The mathematics evaluate P(M) 
   by sum (ak*M^k, k=0..deg P) in SquareMatrix(Ring)
where P = sum (ak*X^k, k=0..deg P)

How can I do this in axiom.

Maple fails in the subs command of a*M^2 + b*M + c 
because (a*M^2 + b*M) is a matrix, and c is a number.

Mupad could do it.

How can I do it with axiom ?

I have the beginning of the Caley-Hamilton theorem :
Now I must compute P(M) and find the zero matrix for n=1,2,3,4,5.

--
-- Create a generic matrix  
--

matriceN1 := n +-> _
  matrix [[("a".(i::String).(j::String))::Symbol for j in 1..n] for i in 1..n]
matriceN2 n ==
  matrix [[("a".(i::String).(j::String))::Symbol for j in 1..n] for i in 1..n]
M4 := matriceN2 4
 
--
-- Create an identity matrix 
--

(matrice N1 4)^0

zeroOrOne := b +-> if b then 1 else 0 
matriceId1 := n +-> _
  matrix [[zeroOrOne ((i=j)::Boolean) for j in 1..n] for i in 1..n]
matriceId1 4

matriceId2 := n +-> diagonalMatrix [1 for k in 1..n] 
matriceId2 5 

coeff := (i, j) +-> if i=j then 1 else 0 
matriceId3 := n +-> matrix [[coeff (i,j) for i in 1..n] for j in 1..n]
matriceId3 4 

--
-- Computes determinant (M - x*Id) where M is the previous generic matrix
--

polCar := M +-> determinant (M - x * matriceId2 ncols M)
polCarN := n +-> polCar matriceN1 n
polCarN 2
P4 := polCarN 4

--
-- Now evaluate P4(M4). We might find the (0)_4 matrix.
--

\start
Date: Sun, 1 Apr 2007 12:22:07 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: conferences

I plan to attend ECCAD in Delaware and ISSAC in Canada. --Tim

\start
Date: 01 Apr 2007 12:57:53 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: conferences

Tim Daly writes:

| I plan to attend ECCAD in Delaware and ISSAC in Canada. --Tim

I'll miss ECCAD as I'll be "on the road" in Europe -- ISO C++ committee
meeting.  See you at ISSAC.

\start
Date: 01 Apr 2007 20:39:19 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: evaluate a polynom for a matrix.

Please direct questions of this kind to axiom-math@nongnu.org.

Francois Maltey writes:

> Hello,
> 
> Let P in Ring[X] and M in SquareMatrix(Ring)
> 
> The mathematics evaluate P(M) 
>    by sum (ak*M^k, k=0..deg P) in SquareMatrix(Ring)
> where P = sum (ak*X^k, k=0..deg P)
> 
> How can I do this in axiom.

-- work in SquareMatrix(n, FRAC POLY INT)

n := 4;

SM ==> SquareMatrix(n, FRAC POLY INT)

--
-- Create a generic matrix
--

M: SM := matrix [[a[i,j] for j in 1..n] for i in 1..n]

-- Create an identity matrix

I: SM := 1;

-- Computes determinant (M - x*Id) where M is the previous generic matrix.
-- note that characteristicPolynomial would do this for youm however, for some
-- strange reason, it accepts an element of Matrix R instead of SquareMatrix R.

P := determinant (M - x * I)

-- Now evaluate P(M). We find the (0)_4 matrix.  Note that you can coerce only
-- to a univariate polynomial, since matrix multiplication is not
-- commutative...

(P::UP(x, SM))(M)

\start
Date: Sun, 1 Apr 2007 14:47:15 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: symbolic manipulation of expressions in Axiom

On April 1, 2007 5:45 AM Gaby wrote:
> 
> >> Why should InputForm be preferable over Expression T?
> >>
> ... 
> > For me to answer your question it is important to understand
> > what Expression in Axiom really is. One way to do that is to
> > look at the internal representation.
> >
> >  Rep:=Fraction SparseMultivariatePolynomial(T, Kernel %)
> >
> > So Expression is a mathematical domain of rational functions
> > (ratio of two polymonials) where the polynomial variables
> > are extended to kernels including various special functions.
> 
> Sorry, I don't think I'm satisfied with an answer that has to
> look at the internal representation before explaining why I
> should not believe the interface.
>

Of course you should believe the interface! There is no need to
look at the internal representation. I just thought it might be
easier since we are developers and are able to take a "white box"
view. But if you prefer that I express this only in terms of the
interface, please review the following Axiom session.

Consider the three strings:

(1) ->   a1:="(a/x)+(a/y)"

   (1)  "(a/x)+(a/y)"
                                                     Type: String

(2) ->   a2:="(a/x) + (a/y)"

   (2)  "(a/x) + (a/y)"
                                                     Type: String

(3) ->   a3:="(a*x+a*y)/(x*y)"

   (3)  "(a*x+a*y)/(x*y)"
                                                     Type: String

Of course as members of the Domain String these are all different.

(4) -> (a1=a2)::Boolean

   (4)  false
                                                     Type: Boolean

(5) -> (a1=a3)::Boolean

   (5)  false
                                                     Type: Boolean

(6) -> (a2=a3)::Boolean

   (6)  false
                                                     Type: Boolean

While as members of the Domain Expression Integer these are equal.

(7) -> interpretString(a1."=".a2)::Boolean

   (7)  true
                                                     Type: Boolean

(8) -> interpretString(a1."=".a3)::Boolean

   (8)  true
                                                     Type: Boolean

(9) -> interpretString(a2."=".a3)::Boolean

   (9)  true
                                                     Type: Boolean

But when we evaluate them as symbolic expressions in the domain
InputForm:

(10) -> x:INFORM:=x

   (10)  x
                                                   Type: InputForm

(11) -> y:INFORM:=y

   (11)  y
                                                   Type: InputForm

(12) -> a:INFORM:=a

   (12)  a
                                                   Type: InputForm

The first two are equal but the third is something different!

(13) -> interpretString(a1."=".a2)::Boolean

   (13)  true
                                                     Type: Boolean

(14) -> interpretString(a1."=".a3)::Boolean

   (14)  false
                                                     Type: Boolean

(15) -> interpretString(a2."=".a3)::Boolean

   (15)  false
                                                     Type: Boolean

So equality of these "algebraic" objects in Expression Integer
is not the same as equality in a purely symbolic domain like
InputForm.

In fact, after completing this exercise I realized that the
original Axiom developers actually did already anticipate the
need for an OutputForm for InputForm that is equivalent the
actual input to the Axiom interpreter. The function that I was
looking for is called 'expr' in the domain InputForm.

(16) -> map(expr,map(interpretString,a1=a2)::Equation(INFORM))

         a   a  a   a
   (16)  - + -= - + -
         x   y  x   y
                                      Type: Equation OutputForm

(17) -> map(expr,map(interpretString,a2=a3)::Equation(INFORM))

         a   a  a x + a y
   (17)  - + -= ---------
         x   y     x y
                                      Type: Equation OutputForm

(18) -> map(expr,map(interpretString,a1=a3)::Equation(INFORM))

         a   a  a x + a y
   (18)  - + -= ---------
         x   y     x y
                                      Type: Equation OutputForm

So once again as Tim Daly has said main times, the problem is just
that :( as usual ): there is not enough documentation.

\start
Date: 01 Apr 2007 14:31:22 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: symbolic manipulation of expressions in Axiom

Bill Page writes:

| On April 1, 2007 5:45 AM Gaby wrote:
| > 
| > >> Why should InputForm be preferable over Expression T?
| > >>
| > ... 
| > > For me to answer your question it is important to understand
| > > what Expression in Axiom really is. One way to do that is to
| > > look at the internal representation.
| > >
| > >  Rep:=Fraction SparseMultivariatePolynomial(T, Kernel %)
| > >
| > > So Expression is a mathematical domain of rational functions
| > > (ratio of two polymonials) where the polynomial variables
| > > are extended to kernels including various special functions.
| > 
| > Sorry, I don't think I'm satisfied with an answer that has to
| > look at the internal representation before explaining why I
| > should not believe the interface.
| >
| 
| Of course you should believe the interface! There is no need to
| look at the internal representation.


I very much prefer an answer in terms of interfaces than that of
internal representation (where possible).  Because interfaces are what
explains the thingies to us -- even as developers.

| I just thought it might be
| easier since we are developers and are able to take a "white box"
| view.

I regret to say, but I'm a big fan of encapsulation (where useful) and
prefer to see interfaces even if I'm spending all my time tweaking in
the innards.  Thanks for the illustation. 

The difference, as I see it comes from the larger number of supported
mathematical operations for Expression T, than there are for InputForm.
Augment InputForm with all useful mathematical operations working on
InputForm and you'll see very little difference from Expression T.
Hence, Martin's warning.

Also, be aware than the Axiom designers, in many places, thought of
Expression as the general domain for symbolic manipulation and have
appropriate hardwired type inference rules in the interpreter.

\start
Date: Sun, 1 Apr 2007 14:34:38 -0500
From: Tim Daly
To: Bill Page
Subject: regression testing

Bill,

Sweet! Nice hack using InputForm.
I'll make this example into an input file for regression

As part of the effort to build a regression test suite
I've been rewriting the input files into pamphlet format.

I also picked up a book this yesterday to update my understanding
of limits and to get some idea of the range of limits that axiom
can and cannot do currently (as part of looking at the Gruntz 
limit algorithm). I've been writing these examples into input files
so we can capture the results permanently. 

It would be great if everyone could capture their testing examples
with an explanation.  The current input files are fairly sparse in
their text but they do show some interesting tricks I'd forgotten
Axiom can do.


\start
Date: Sun, 1 Apr 2007 14:38:45 -0500
From: Tim Daly
To: Bill Page
Subject: unit testing

Bill,

A slightly higher level of design goal can be seen in the ffrac.spad
domain that I just sent out. You'll notice that it has unit tests
embedded before each operation. These will serve a couple purposes,
both unit test and regression tests. That way we can document what
works and we can check when something breaks.

Of course, the inline comments are not really the "right" way
to construct and document these tests. They will eventually be
extractable chunks so we can run unit and regression tests on them.

It would be useful when constructing new domains if examples of
operations were embedded in the pamphlet files in a standard style
so we could achieve these goals.

\start
Date: 01 Apr 2007 21:42:16 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Waldek Hebisch writes:

> Bill Page wrote:
> > You are right that I did not state this properly. Of course we can
> > evaluate expressions (including functions) that return domains
> > and categories. What I was trying to say is that domains in Spad
> > and Aldor are immutable during run-time. Once constructed their
> > "value" is constant and can not be changed. For example we
> > can not insert or remove anything in the list of exports or even
> > replace one exported function with another during the execution
> > of the program. This is possible in Python.
> > 
> > Note: I am not talking about the post facto library extension feature
> > in Aldor. 'extend' is a compile-time operation.
> 
> I want comment about Alder, but in current Axiom runtime domains are
> mutable.  In fact I think that ability to redefine domain at runtime
> was an important design goal (otherwise a sigificant part of Axiom
> runtime activities would be useless).
> 
> I think that biggest problem in impementing 'extend' is to provide
> sane behaviour during redefinition.

although Domains may be mutable in some sense in SPAD and Aldor (since we can
access and modify their "state") I think that "the way things are meant to be
done in Axiom/SPAD/Aldor" is to create new domains, instead of modifying old
ones. Since we have "dependent types", this can be done in an extremely
flexible manner, as the example "Interpret" shows, which takes a string and
yields a domain.

\start
Date: Sun, 1 Apr 2007 15:00:19 -0500
From: Tim Daly
To: Bill Page
Subject: CATS (Computer Algebra Test Suite)

Bill,

At an even higher level of design goal it would be useful to construct
a Computer Algebra Test Suite, a project I've referred to as CATS.

There are several converging ideas driving CATS.

First, there are very few people in the field and it would be good to
leverage expertise across more than one CAS. This is probably of more
interest to the SAGE people but Axiom can be a driving force.

Second, there is a NIST classification system for numeric algorithms.
Such a standard does not exist for algebraic algorithms. But it would
be useful to have a classification so we could show which parts of the
standard Axiom currently computes and which parts need work.

Third, there needs to be some way to organize the documentation
within Axiom so that it follows some kind of logical outline.
One possibility is to follow book outlines for particular domains
but Axiom covers a large range which isn't found in any one book.

Fourth, we've tried to organize the algebra graph within Axiom
without success. I think there is a lot to learn about both Axiom's
algebra graph and computational mathematics from a good organization.

So the CATS effort is an attempt to drag these observations into one
pile and create a first draft of a "standard" computational mathematics
layout. This would allow us to place algorithms in context, place 
carefully audited, universally accepted results in context, standardize
the abilities expected in CA systems, document algorithms and results
in some standardized format, organize research tracks, etc.

This might end up being in a Abramowitz and Stegun style, like
their Handbook of Mathematical Functions, crossed with books like
Geddes. (It's unfortunate that copyright will keep these prior works
from being directly useful.)

The job is large but the 30 year horizon benefits are enormous.




Within the Axiom project we could start almost anywhere by just
dragging topics together at random and then classifying categories,
domains, algorithms, and example files against this arbitrary
set. Eventually I expect that the topics will self-organize (not
likely as a hierarchy but more as a graph).

This project overlays all of the computational mathematics field
so no one vendor will take it on as a project. It properly belongs
in NIST, INRIA, or some other country-wide funding organization but
I'm not optimistic about that happening.

Anyway, that's enough hasty-generalization...back to regression testing.

\start
Date: Sun, 1 Apr 2007 16:02:33 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: symbolic manipulation of expressions in Axiom

On April 1, 2007 3:31 PM Gaby wrote:
> ...
> I regret to say, but I'm a big fan of encapsulation (where useful)
> and prefer to see interfaces even if I'm spending all my time
> tweaking in the innards.  Thanks for the illustation. 
> 

No problem.

> The difference, as I see it comes from the larger number of
> supported mathematical operations for Expression T, than there
> are for InputForm.

There are *no* mathematical (algebraic) operations in InputForm!
That is the whole point of the discussion.

> Augment InputForm with all useful mathematical operations
> working on InputForm and you'll see very little difference
> from Expression T.

That is completely wrong. There is still a huge difference
as I have now explained at least two different ways. :-(
The operations in InputForm are purely symbolic. They could
be written in simple Lisp or Python just as easily. That is
definitely not true of Expression. Expression requires a very
large portion of Axiom's library.

> Hence, Martin's warning.

I do not understand Martin's warning. I think it under the
wrong impression (just as you are) about what I am saying.

> 
> Also, be aware than the Axiom designers, in many places,
> thought of Expression as the general domain for symbolic
> manipulation and have appropriate hardwired type inference
> rules in the interpreter.
> 

Of course that is no problem. If you are able to read and
understand Stephen Watt's paper on this subject, I am sure
that this would be clear to you.

\start
Date: 01 Apr 2007 15:19:53 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: symbolic manipulation of expressions in Axiom

[...]

| > The difference, as I see it comes from the larger number of
| > supported mathematical operations for Expression T, than there
| > are for InputForm.
| 
| There are *no* mathematical (algebraic) operations in InputForm!

and I'm saying that once you've added them, as for Expression T,
you'll see no difference.  Adding them is precisely what people do
when they start "symbolic computation" and "simplification".

[...]

| > Also, be aware than the Axiom designers, in many places,
| > thought of Expression as the general domain for symbolic
| > manipulation and have appropriate hardwired type inference
| > rules in the interpreter.
| > 
| 
| Of course that is no problem. If you are able to read and
| understand Stephen Watt's paper on this subject, I am sure
| that this would be clear to you.

That has nothing to do with what I'm saying. 

BTW, it is possible to read Watt's paper and not agreeing with him.
And it is possible to agree with him and not reading his paper.
But again, what he said in his paper has nothing to do with the
distinction between Expression T and InputForm I'm concerned with.

\start
Date: Sun, 01 Apr 2007 18:37:56 -0400
From: Cliff Yapp
To: Tim Daly
Subject: Re: CATS (Computer Algebra Test Suite)

Tim Daly wrote:

> Third, there needs to be some way to organize the documentation
> within Axiom so that it follows some kind of logical outline.
> One possibility is to follow book outlines for particular domains
> but Axiom covers a large range which isn't found in any one book.
> 
> Fourth, we've tried to organize the algebra graph within Axiom
> without success. I think there is a lot to learn about both Axiom's
> algebra graph and computational mathematics from a good organization.

Tim, what about using MSC2000 as a top level starting point for the
algebra portion of the classification?  Even that is probably not of
sufficiently broad scope (many pamphlets in Axiom will be related to
more mundane issues such as programming language definition, user
interface APIs, etc) but for mathematics I doubt it would be possible to
find something more useful.

A while back I did some work with the MSC2000 system in order to design
a top level bibliography system for Axiom, and actually did get
something working.  I don't think there was much response to the
original effort and I didn't pursue it further, but I believe the code
is still available.

Is that subject classification not quite what is needed for this effort?
 If not, perhaps something could be begun based on category theory?

\start
Date: Sun, 1 Apr 2007 18:43:12 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: symbolic manipulation of expressions in Axiom

On April 1, 2007 4:20 PM Gaby wrote:
> ...
> Bill Page wrote:
> | 
> | There are *no* mathematical (algebraic) operations in InputForm!
> 
> and I'm saying that once you've added them, as for Expression T,
> you'll see no difference.  Adding them is precisely what people
> do when they start "symbolic computation" and "simplification".

No. I disagree at a deep level. I think what is done in the
Axiom library is completely different. What Axiom is doing is
fundamentally *algebraic*. Simplification of symbolic expressions
does not any algebra. For example to simplify an expression it
is not necessary to instantiate an object which directly represents
a polynomial in the way polynomials are represented in Axiom.
All that you need to do is to apply a set of re-write rules that
accomplish (or not) your desired goal.

On the other hand creating a polynomial *object* (and some other
algebraic objects) is exactly what Axiom does in the Expression
domain.

> 
> [...]
> 
> | > Also, be aware than the Axiom designers, in many places,
> | > thought of Expression as the general domain for symbolic
> | > manipulation and have appropriate hardwired type inference
> | > rules in the interpreter.
> | > 
> | 
> | Of course that is no problem. If you are able to read and
> | understand Stephen Watt's paper on this subject, I am sure
> | that this would be clear to you.
> 
> That has nothing to do with what I'm saying. 
>

??? But that is exactly what I am saying.
 
> BTW, it is possible to read Watt's paper and not agreeing with
> him. And it is possible to agree with him and not reading his
> paper.

Certainly. In fact I agreed with him before I read his paper.

> But again, what he said in his paper has nothing to do with
> the distinction between Expression T and InputForm I'm
> concerned with.
> 

It is possible that I do not understand "the distinction between
Expression T and InputForm that you are concerned with", but I
did think that my concern in this regard was the same as yours.
If that is the case then I strongly disagree with your conclusion.
I also feel strongly that understanding this distinction is
critical to understanding what is different about Axiom as a
computer algebra system, so I have a lot of motivation to continue
this discussion until we can find some agreement.

How shall we proceed?

Would it help if I try to described more formally my understanding
of exactly how Axiom captures matematical semantics in terms of
the representation of objects and how that differs from more
syntactical things like term re-writing? Or do continue to insist
that we not talk about representation?

\start
Date: 01 Apr 2007 18:02:19 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: symbolic manipulation of expressions in Axiom

Bill Page writes:

| On April 1, 2007 4:20 PM Gaby wrote:
| > ...
| > Bill Page wrote:
| > | 
| > | There are *no* mathematical (algebraic) operations in InputForm!
| > 
| > and I'm saying that once you've added them, as for Expression T,
| > you'll see no difference.  Adding them is precisely what people
| > do when they start "symbolic computation" and "simplification".
| 
| No. I disagree at a deep level. I think what is done in the
| Axiom library is completely different. What Axiom is doing is
| fundamentally *algebraic*. Simplification of symbolic expressions
| does not any algebra.

Well, I do disagree there.  If you don't do any algebra, you cannot
manage your symbolic expressions. 

For a symbolic expression, you first need to chose on a "standard form"
(or "normal form", depending on your religion).

The fundamental reason why "simplify" is so ill-defined for symbolic
expressions is precisely that whatever they have to do is profoundly
influenced by the algebra of the standard form structures.


For example, when you see something like

     x^2 * 3 * x^(-4) * 5/89

you have to come up with algebraic computations for the "constant"
parts, and for the exponent parts -- many symbolic manipulation
systems assume tht "*" is commutative.

| For example to simplify an expression it
| is not necessary to instantiate an object which directly represents
| a polynomial in the way polynomials are represented in Axiom.

But, you do need to come up with standard form that requires you do
define algebra rules on the objects.  In particular, you do need to
make alegbraic assumptions regarding the polynomials.

| All that you need to do is to apply a set of re-write rules that
| accomplish (or not) your desired goal.

But, the rewrite rules do embody algebraic semantics.

| On the other hand creating a polynomial *object* (and some other
| algebraic objects) is exactly what Axiom does in the Expression
| domain.

        simplify(differentiate (sin(x) + x, x)^2 + (sin(x) + x)^2)


| > [...]
| > 
| > | > Also, be aware than the Axiom designers, in many places,
| > | > thought of Expression as the general domain for symbolic
| > | > manipulation and have appropriate hardwired type inference
| > | > rules in the interpreter.
| > | > 
| > | 
| > | Of course that is no problem. If you are able to read and
| > | understand Stephen Watt's paper on this subject, I am sure
| > | that this would be clear to you.
| > 
| > That has nothing to do with what I'm saying. 
| >
| 
| ??? But that is exactly what I am saying.

"that is exactly" what?

| > BTW, it is possible to read Watt's paper and not agreeing with
| > him. And it is possible to agree with him and not reading his
| > paper.
| 
| Certainly. In fact I agreed with him before I read his paper.
| 
| > But again, what he said in his paper has nothing to do with
| > the distinction between Expression T and InputForm I'm
| > concerned with.
| > 
| 
| It is possible that I do not understand "the distinction between
| Expression T and InputForm that you are concerned with", but I
| did think that my concern in this regard was the same as yours.
| If that is the case then I strongly disagree with your conclusion.
| I also feel strongly that understanding this distinction is
| critical to understanding what is different about Axiom as a
| computer algebra system, so I have a lot of motivation to continue
| this discussion until we can find some agreement.

I believe I understand what makes the difference between Axiom and
other CASes, but I think both you and me seem to profoundly between
the outcome of InputForm augmented with all that is necessary to mimic
other CASes and Expression T.  Consequently I do not see the link

 # understanding this distinction is critical to understanding what is
 # different about Axiom as a computer algebra system.

| How shall we proceed?

Definitely.

| Would it help if I try to described more formally my understanding
| of exactly how Axiom captures matematical semantics in terms of
| the representation of objects and how that differs from more
| syntactical things like term re-writing? Or do continue to insist
| that we not talk about representation?

I believe the distinction must be explained through interfaces.  If we
must resort to internal representations, then the distinction is
artificial, not fundamental; therefore, we can ignore it as being
merely non-fundamental artefacts.

\start
Date: Sun, 1 Apr 2007 19:34:57 -0500
From: Tim Daly
To: list
Subject: regression testing

I'm working my way back from the latest version thru the various
versions in arch. I've come across a difference that can't be
explained by any change I've made. Can someone please test this
on their platform and send me the results?

Attached is a portion of the regression test file. It consists of
tests delimited by --S (start) and --E (end)... The --R lines show the
"expected" results, that is, the results in silver. The --G result
show what comes from gold. The embedded lines are the computed
lines. They should be identical and clearly they are not. Please let
me know what your results are so I can guess where this bug might be.

You should just be able to clip the rest of this file into an input
file, say foo.input and the start axiom and do 
 )spool result
 )read foo
 )spool 

and send me the resulting file along with some idea of what
source tree you used to build it.


Thanks
Tim


cut here
=======================================================================



)version

---------------------------------------------------------------------
--This is test 15. It sets x for test 18.
---------------------------------------------------------------------
--S 15 of 50
x := 0.7::DoubleFloat
--G 
--G
--G   (15)  0.69999999999999996
--G                                                            Type: DoubleFloat
--R 
--R
--R   (15)  0.69999999999999996
--R                                                            Type: DoubleFloat
--E 15


---------------------------------------------------------------------
-- This is test 18. Clearly cos(acos(x)) differs.
---------------------------------------------------------------------
--S 18 of 50
[sin asin x,  cos acos x,  tan atan x,  cot acot x]
--G 
--G
--G   (18)
--G   [0.69999999999999996, 0.69999999999999996, 0.69999999999999996,
--G    0.69999999999999996]
--G                                                       Type: List DoubleFloat
--R 
--R
--R   (18)
--R   [0.69999999999999996, 0.70000000000000007, 0.69999999999999996,
--R    0.69999999999999996]
--R                                                       Type: List DoubleFloat
--E 18

--MISMATCH
--expected:"   [0.69999999999999996, 0.70000000000000007, 0.69999999999999996,"
--     got:"   [0.69999999999999996, 0.69999999999999996, 0.69999999999999996,"
--FAILED elemnum  18 of 50














---------------------------------------------------------------------
This is test 22. It sets the value of variable x for later testing
---------------------------------------------------------------------

--S 22 of 50
x := 1.1::DoubleFloat
--G 
--G
--G   (22)  1.1000000000000001
--G                                                            Type: DoubleFloat
--R 
--R
--R   (22)  1.1000000000000001
--R                                                            Type: DoubleFloat
--E 22

---------------------------------------------------------------------
This is test 26. asin(sin(x)) is different.
---------------------------------------------------------------------
--S 26 of 50
[asin sin x,  acos cos x,  atan tan x,  acot cot x, acsc csc x,   asec sec x  ]
--G 
--G
--G   (26)
--G   [1.1000000000000001, 1.1000000000000001, 1.1000000000000001,
--G    1.1000000000000001, 1.0999999999999999, 1.1000000000000001]
--G                                                       Type: List DoubleFloat
--R 
--R
--R   (26)
--R   [1.1000000000000003, 1.1000000000000001, 1.1000000000000001,
--R    1.1000000000000001, 1.0999999999999999, 1.1000000000000001]
--R                                                       Type: List DoubleFloat
--E 26


--MISMATCH
--expected:"   [1.1000000000000003, 1.1000000000000001, 1.1000000000000001,"
--     got:"   [1.1000000000000001, 1.1000000000000001, 1.1000000000000001,"
--FAILED elemnum  26 of 50












---------------------------------------------------------------------
This is test 29. It constructs the function used in later tests.
---------------------------------------------------------------------

--S 29 of 50
qtest(a,b,n) ==
   m1 := if n = 1 or n = 4 then 0 else  1
   s1 := if n = 1 or n = 4 then 1 else -1
   s2 := if n = 1 or n = 2 then 1 else -1
   x := complex(s1*a, s2*b)
   [x- exp   log x, _
    x- sin   asin  x, x-    cos   acos  x, x- tan   atan  x , _
    x- csc   acsc  x, x-    sec   asec  x, x- cot   acot  x , _
    x- sinh  asinh x, x-    cosh  acosh x, x- tanh  atanh x , _
    x- csch  acsch x, x-    sech  asech x, x- coth  acoth x , _
    x- log   exp   x, _
    x- asin  sin   x, x- s1*acos  cos   x, x- atan  tan  x , _
    x- acsc  csc   x, x- s1*asec  sec   x, x- acot  cot  x + m1*%pi, _
    x- asinh sinh  x, x- s1*acosh cosh  x, x- atanh tanh x , _
    x- acsch csch  x, x- s1*asech sech  x, x- acoth coth x ]
--G 
--G                                                                   Type: Void
--R 
--R                                                                   Type: Void
--E 29


---------------------------------------------------------------------
This is test 31 that sets the variable sa used below.
---------------------------------------------------------------------

--S 31 of 50
sa := 0.7::DoubleFloat
--G 
--G
--G   (31)  0.69999999999999996
--G                                                            Type: DoubleFloat
--R 
--R
--R   (31)  0.69999999999999996
--R                                                            Type: DoubleFloat
--E 31

---------------------------------------------------------------------
This is test 32 that sets the variable sb used below.
---------------------------------------------------------------------
--S 32 of 50
sb := 1.1::DoubleFloat
--G 
--G
--G   (32)  1.1000000000000001
--G                                                            Type: DoubleFloat
--R 
--R
--R   (32)  1.1000000000000001
--R                                                            Type: DoubleFloat
--E 32



---------------------------------------------------------------------
This is test 35. There are various mismatches that follow.
---------------------------------------------------------------------

--S 35 of 50
qtest(sa, sb, 1)
--G 
--G   Compiling function qtest with type (DoubleFloat,DoubleFloat,
--G      PositiveInteger) -> List Complex DoubleFloat 
--G
--G   (35)
--G   [1.1102230246251565E-16,
--G    2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--G    1.1102230246251565E-16,
--G    -4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--G    4.4408920985006262E-16 + 2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--G    3.3306690738754696E-16 + -2.2204460492503131E-16 %i, 0.,
--G    -6.6613381477509392E-16 %i, -1.1102230246251565E-16,
--G    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
--G    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--G    -2.2204460492503131E-16,
--G    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
--G    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--G    -5.5511151231257827E-16, -2.2204460492503131E-16, -1.1102230246251565E-16,
--G    1.1102230246251565E-16, 0., -1.1102230246251565E-16,
--G    -1.1102230246251565E-16]
--G                                               Type: List Complex DoubleFloat
--R 
--R   Compiling function qtest with type (DoubleFloat,DoubleFloat,
--R      PositiveInteger) -> List Complex DoubleFloat 
--R
--R   (35)
--R   [1.1102230246251565E-16,
--R    2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--R    -2.2204460492503131E-16,
--R    -4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--R    4.4408920985006262E-16, -1.1102230246251565E-16,
--R    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    1.1102230246251565E-16,
--R    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--R    1.1102230246251565E-16 + -2.2204460492503131E-16 %i, 0.,
--R    -6.6613381477509392E-16 %i, -1.1102230246251565E-16,
--R    -4.4408920985006262E-16 + -4.4408920985006262E-16 %i,
--R    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--R    -3.3306690738754696E-16,
--R    -4.4408920985006262E-16 + -4.4408920985006262E-16 %i,
--R    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--R    -5.5511151231257827E-16, -2.2204460492503131E-16, -1.1102230246251565E-16,
--R    1.1102230246251565E-16, 0., -1.1102230246251565E-16,
--R    -1.1102230246251565E-16]
--R                                               Type: List Complex DoubleFloat
--E 35

--MISMATCH
--expected:"    -4.4408920985006262E-16 + -4.4408920985006262E-16 %i,"
--     got:"    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    -3.3306690738754696E-16,"
--     got:"    -2.2204460492503131E-16,"
--MISMATCH
--expected:"    -4.4408920985006262E-16 + -4.4408920985006262E-16 %i,"
--     got:"    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    1.1102230246251565E-16 + -2.2204460492503131E-16 %i, 0.,"
--     got:"    3.3306690738754696E-16 + -2.2204460492503131E-16 %i, 0.,"
--MISMATCH
--expected:"    4.4408920985006262E-16, -1.1102230246251565E-16,"
--     got:"    -1.1102230246251565E-16,"
--MISMATCH
--expected:"    -4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--     got:"    4.4408920985006262E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -2.2204460492503131E-16,"
--     got:"    -4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--     got:"    1.1102230246251565E-16,"
--MISMATCH
--expected:"   [1.1102230246251565E-16,"
--     got:"    2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"   (35)"
--     got:"   [1.1102230246251565E-16,"
--MISMATCH
--expected:""
--     got:"   (35)"
--MISMATCH
--expected:"      PositiveInteger) -> List Complex DoubleFloat "
--     got:""
--MISMATCH
--expected:"   Compiling function qtest with type (DoubleFloat,DoubleFloat,"
--     got:"      PositiveInteger) -> List Complex DoubleFloat "
--MISMATCH
--expected:" "
--     got:"   Compiling function qtest with type (DoubleFloat,DoubleFloat,"
--FAILED elemnum  35 of 50

















---------------------------------------------------------------------
This is test 39. It fails in various ways. Check the attached mismatches
---------------------------------------------------------------------

--S 39 of 50
qtest(sa, sb, 2)
--G 
--G
--G   (39)
--G   [-1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--G    -3.3306690738754696E-16,
--G    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--G    -4.4408920985006262E-16 + 2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--G    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--G    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + -2.2204460492503131E-16 %i, 0.,
--G    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
--G    -1.1102230246251565E-16, 2.2204460492503131E-16,
--G    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
--G    -1.1102230246251565E-16, 8.8817841970012523E-16, 2.2204460492503131E-16,
--G    1.1102230246251565E-16, 3.3306690738754696E-16,
--G    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i,
--G    1.1102230246251565E-16,
--G    2.2204460492503131E-16 + -2.2204460492503131E-16 %i]
--G                                               Type: List Complex DoubleFloat
--R 
--R
--R   (39)
--R   [-1.1102230246251565E-16,
--R    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--R    -3.3306690738754696E-16,
--R    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--R    -4.4408920985006262E-16,
--R    1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--R    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--R    -1.1102230246251565E-16,
--R    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--R    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + -2.2204460492503131E-16 %i, 0.,
--R    4.4408920985006262E-16 + -4.4408920985006262E-16 %i, 0.,
--R    3.3306690738754696E-16,
--R    4.4408920985006262E-16 + -4.4408920985006262E-16 %i, 0.,
--R    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,
--R    3.3306690738754696E-16, -1.1102230246251565E-16, 1.1102230246251565E-16,
--R    2.2204460492503131E-16 + -2.2204460492503131E-16 %i]
--R                                               Type: List Complex DoubleFloat
--E 39

--MISMATCH
--expected:"    3.3306690738754696E-16, -1.1102230246251565E-16, 1.1102230246251565E-16,"
--     got:"    1.1102230246251565E-16,"
--MISMATCH
--expected:"    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,"
--     got:"    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + -4.4408920985006262E-16 %i, 0.,"
--     got:"    1.1102230246251565E-16, 3.3306690738754696E-16,"
--MISMATCH
--expected:"    3.3306690738754696E-16,"
--     got:"    -1.1102230246251565E-16, 8.8817841970012523E-16, 2.2204460492503131E-16,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + -4.4408920985006262E-16 %i, 0.,"
--     got:"    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i, 0.,"
--     got:"    -1.1102230246251565E-16, 2.2204460492503131E-16,"
--MISMATCH
--expected:"    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--     got:"    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--     got:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i, 0.,"
--MISMATCH
--expected:"    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,"
--     got:"    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--     got:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -1.1102230246251565E-16,"
--     got:"    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,"
--     got:"    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--     got:"    -1.1102230246251565E-16,"
--MISMATCH
--expected:"    -4.4408920985006262E-16,"
--     got:"    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--     got:"    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -3.3306690738754696E-16,"
--     got:"    -4.4408920985006262E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--     got:"    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"   [-1.1102230246251565E-16,"
--     got:"    -3.3306690738754696E-16,"
--MISMATCH
--expected:"   (39)"
--     got:"    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:""
--     got:"   [-1.1102230246251565E-16,"
--MISMATCH
--expected:" "
--     got:"   (39)"
--FAILED elemnum  39 of 50
--





---------------------------------------------------------------------
This is test 43 which fails. See the mismatch report attached.
---------------------------------------------------------------------
--S 43 of 50
qtest(sa, sb, 3)
--G 
--G
--G   (43)
--G   [-1.1102230246251565E-16, 0.,
--G    -2.2204460492503131E-16 + 4.4408920985006262E-16 %i,
--G    -2.2204460492503131E-16, 0., -4.4408920985006262E-16,
--G    -1.1102230246251565E-16, -1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + 4.4408920985006262E-16 %i,
--G    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 0., 0.,
--G    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16, 0.,
--G    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,
--G    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,
--G    3.3306690738754696E-16,
--G    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--G    1.1102230246251565E-16, 2.2204460492503131E-16 + 2.2204460492503131E-16 %i]
--G                                               Type: List Complex DoubleFloat
--R 
--R
--R   (43)
--R   [-1.1102230246251565E-16, 0.,
--R    -2.2204460492503131E-16 + 4.4408920985006262E-16 %i,
--R    -2.2204460492503131E-16, 1.1102230246251565E-16, -4.4408920985006262E-16,
--R    -1.1102230246251565E-16, -1.1102230246251565E-16,
--R    4.4408920985006262E-16 + 2.2204460492503131E-16 %i,
--R    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--R    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 0., 0.,
--R    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 %i, 0.,
--R    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,
--R    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,
--R    3.3306690738754696E-16, -1.1102230246251565E-16, 1.1102230246251565E-16,
--R    2.2204460492503131E-16 + 2.2204460492503131E-16 %i]
--R                                               Type: List Complex DoubleFloat
--E 43

--MISMATCH
--expected:"    2.2204460492503131E-16 + 2.2204460492503131E-16 %i]"
--     got:"    1.1102230246251565E-16, 2.2204460492503131E-16 + 2.2204460492503131E-16 %i]"
--MISMATCH
--expected:"    3.3306690738754696E-16, -1.1102230246251565E-16, 1.1102230246251565E-16,"
--     got:"    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,"
--     got:"    3.3306690738754696E-16,"
--MISMATCH
--expected:"    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,"
--     got:"    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,"
--MISMATCH
--expected:"    2.2204460492503131E-16 %i, 0.,"
--     got:"    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,"
--     got:"    -1.1102230246251565E-16, 0.,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 0., 0.,"
--     got:"    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i,"
--     got:"    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 0., 0.,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,"
--     got:"    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--     got:"    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + 2.2204460492503131E-16 %i,"
--     got:"    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -1.1102230246251565E-16, -1.1102230246251565E-16,"
--     got:"    -2.2204460492503131E-16 + 4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    -2.2204460492503131E-16, 1.1102230246251565E-16, -4.4408920985006262E-16,"
--     got:"    -1.1102230246251565E-16, -1.1102230246251565E-16,"
--MISMATCH
--expected:"    -2.2204460492503131E-16 + 4.4408920985006262E-16 %i,"
--     got:"    -2.2204460492503131E-16, 0., -4.4408920985006262E-16,"
--MISMATCH
--expected:"   [-1.1102230246251565E-16, 0.,"
--     got:"    -2.2204460492503131E-16 + 4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"   (43)"
--     got:"   [-1.1102230246251565E-16, 0.,"
--MISMATCH
--expected:""
--     got:"   (43)"
--MISMATCH
--expected:" "
--     got:""
--FAILED elemnum  43 of 50













---------------------------------------------------------------------
Test 31 sets the variable sa and it echos properly
---------------------------------------------------------------------
--S 31 of 50
sa := 0.7::DoubleFloat
--G 
--G
--G   (31)  0.69999999999999996
--G                                                            Type: DoubleFloat
--R 
--R
--R   (31)  0.69999999999999996
--R                                                            Type: DoubleFloat
--E 31

---------------------------------------------------------------------
Test 32 sets the variable sb and it echos properly
---------------------------------------------------------------------

--S 32 of 50
sb := 1.1::DoubleFloat
--G 
--G
--G   (32)  1.1000000000000001
--G                                                            Type: DoubleFloat
--R 
--R
--R   (32)  1.1000000000000001
--R                                                            Type: DoubleFloat
--E 32

---------------------------------------------------------------------
But test 47 fails (see the mismatches reported below).
---------------------------------------------------------------------

--S 47 of 50
qtest(sa, sb, 4)
--G 
--G
--G   (47)
--G   [1.1102230246251565E-16, 0.,
--G    3.3306690738754696E-16 + 4.4408920985006262E-16 %i, 2.2204460492503131E-16,
--G    0., 2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    3.3306690738754696E-16 + 2.2204460492503131E-16 %i, 0.,
--G    6.6613381477509392E-16 %i, -1.1102230246251565E-16, 0.,
--G    1.1102230246251565E-16, 1.1102230246251565E-16, 0., 1.1102230246251565E-16,
--G    -6.6613381477509392E-16, -2.2204460492503131E-16, -1.1102230246251565E-16,
--G    1.1102230246251565E-16, 0., -1.1102230246251565E-16,
--G    -1.1102230246251565E-16]
--G                                               Type: List Complex DoubleFloat
--R 
--R
--R   (47)
--R   [1.1102230246251565E-16, 0.,
--R    3.3306690738754696E-16 + 4.4408920985006262E-16 %i, 2.2204460492503131E-16,
--R    -1.1102230246251565E-16,
--R    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 1.1102230246251565E-16,
--R    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    1.1102230246251565E-16 + 2.2204460492503131E-16 %i, 0.,
--R    6.6613381477509392E-16 %i, -1.1102230246251565E-16, 0., 0.,
--R    2.2204460492503131E-16 %i, 0., 0., -6.6613381477509392E-16,
--R    -2.2204460492503131E-16, -1.1102230246251565E-16, 1.1102230246251565E-16,
--R    0., -1.1102230246251565E-16, -1.1102230246251565E-16]
--R                                               Type: List Complex DoubleFloat
--E 47

--MISMATCH
--expected:"    0., -1.1102230246251565E-16, -1.1102230246251565E-16]"
--     got:"    -1.1102230246251565E-16]"
--MISMATCH
--expected:"    -2.2204460492503131E-16, -1.1102230246251565E-16, 1.1102230246251565E-16,"
--     got:"    1.1102230246251565E-16, 0., -1.1102230246251565E-16,"
--MISMATCH
--expected:"    2.2204460492503131E-16 %i, 0., 0., -6.6613381477509392E-16,"
--     got:"    -6.6613381477509392E-16, -2.2204460492503131E-16, -1.1102230246251565E-16,"
--MISMATCH
--expected:"    6.6613381477509392E-16 %i, -1.1102230246251565E-16, 0., 0.,"
--     got:"    1.1102230246251565E-16, 1.1102230246251565E-16, 0., 1.1102230246251565E-16,"
--MISMATCH
--expected:"    1.1102230246251565E-16 + 2.2204460492503131E-16 %i, 0.,"
--     got:"    6.6613381477509392E-16 %i, -1.1102230246251565E-16, 0.,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--     got:"    3.3306690738754696E-16 + 2.2204460492503131E-16 %i, 0.,"
--MISMATCH
--expected:"    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,"
--     got:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 1.1102230246251565E-16,"
--     got:"    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--     got:"    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 1.1102230246251565E-16,"
--MISMATCH
--expected:"    -1.1102230246251565E-16,"
--     got:"    0., 2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--FAILED elemnum  47 of 50
--
--

\start
Date: 01 Apr 2007 20:07:25 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: regression testing

Tim Daly writes:

| I'm working my way back from the latest version thru the various
| versions in arch. I've come across a difference that can't be
| explained by any change I've made. Can someone please test this
| on their platform and send me the results?
| 
| Attached is a portion of the regression test file. It consists of
| tests delimited by --S (start) and --E (end)... The --R lines show the
| "expected" results, that is, the results in silver. The --G result
| show what comes from gold. The embedded lines are the computed
| lines. They should be identical and clearly they are not. Please let
| me know what your results are so I can guess where this bug might be.
| 
| You should just be able to clip the rest of this file into an input
| file, say foo.input and the start axiom and do 
|  )spool result
|  )read foo
|  )spool 
| 
| and send me the resulting file along with some idea of what
| source tree you used to build it.

It will help me if you can say more about exactly what is being
tested.  I see DoubleFloat computations, from what I discussed two or
three days ago, the underlying representation is Lisp' long-float --
which I think is bogus.  That representation tends to differ from
platform to platform along with the accuracy.  I believe double-float
is more portable with predictable accuracy across platforms.  Also,
there are platform-dependent libm variations to factor in (plus
C compiler optimizations).  Those remarks may or may not be relevant,
but it would help me to understand yoru issue if you could elaborate a
bit.   See below, results with build-improvements, on an
i686-suse-linux.

   % rpm -q glibc
   glibc-2.5-25

-- Gaby

Starts dribbling to foo.txt (2007/4/1, 19:0:47).
(1) -> )r td


)version
 
Value = "Monday March 5, 2007 at 17:21:39 "

---------------------------------------------------------------------
--This is test 15. It sets x for test 18.
---------------------------------------------------------------------
--S 15 of 50
x := 0.7::DoubleFloat
 
   Loading /usr/local/lib/axiom/target/i686-suse-linux/algebra/FLOAT.o 
      for domain Float 

   Loading /usr/local/lib/axiom/target/i686-suse-linux/algebra/DFLOAT.o
      for domain DoubleFloat 
   (1)  0.69999999999999996
                                                            Type: DoubleFloat
--G 
--G
--G   (15)  0.69999999999999996
--G                                                            Type: DoubleFloat
--R 
--R
--R   (15)  0.69999999999999996
--R                                                            Type: DoubleFloat
--E 15


---------------------------------------------------------------------
-- This is test 18. Clearly cos(acos(x)) differs.
---------------------------------------------------------------------
--S 18 of 50
[sin asin x,  cos acos x,  tan atan x,  cot acot x]
 

   (2)
   [0.69999999999999996, 0.70000000000000007, 0.69999999999999996,
    0.69999999999999996]
                                                       Type: List DoubleFloat
--G 
--G
--G   (18)
--G   [0.69999999999999996, 0.69999999999999996, 0.69999999999999996,
--G    0.69999999999999996]
--G                                                       Type: List DoubleFloat
--R 
--R
--R   (18)
--R   [0.69999999999999996, 0.70000000000000007, 0.69999999999999996,
--R    0.69999999999999996]
--R                                                       Type: List DoubleFloat
--E 18

--MISMATCH
--expected:"   [0.69999999999999996, 0.70000000000000007, 0.69999999999999996,"
--     got:"   [0.69999999999999996, 0.69999999999999996, 0.69999999999999996,"
--FAILED elemnum  18 of 50














---------------------------------------------------------------------
-- This is test 22. It sets the value of variable x for later testing
---------------------------------------------------------------------

--S 22 of 50
x := 1.1::DoubleFloat
 

   (3)  1.0999999999999999
                                                            Type: DoubleFloat
--G 
--G
--G   (22)  1.1000000000000001
--G                                                            Type: DoubleFloat
--R 
--R
--R   (22)  1.1000000000000001
--R                                                            Type: DoubleFloat
--E 22

---------------------------------------------------------------------
-- This is test 26. asin(sin(x)) is different.
---------------------------------------------------------------------
--S 26 of 50
[asin sin x,  acos cos x,  atan tan x,  acot cot x, acsc csc x,   asec sec x  ]
 

   (4)
   [1.0999999999999999, 1.0999999999999999, 1.0999999999999999,
    1.0999999999999999, 1.0999999999999999, 1.0999999999999999]
                                                       Type: List DoubleFloat
--G 
--G
--G   (26)
--G   [1.1000000000000001, 1.1000000000000001, 1.1000000000000001,
--G    1.1000000000000001, 1.0999999999999999, 1.1000000000000001]
--G                                                       Type: List DoubleFloat
--R 
--R
--R   (26)
--R   [1.1000000000000003, 1.1000000000000001, 1.1000000000000001,
--R    1.1000000000000001, 1.0999999999999999, 1.1000000000000001]
--R                                                       Type: List DoubleFloat
--E 26


--MISMATCH
--expected:"   [1.1000000000000003, 1.1000000000000001, 1.1000000000000001,"
--     got:"   [1.1000000000000001, 1.1000000000000001, 1.1000000000000001,"
--FAILED elemnum  26 of 50












---------------------------------------------------------------------
-- This is test 29. It constructs the function used in later tests.
---------------------------------------------------------------------

--S 29 of 50
qtest(a,b,n) ==
   m1 := if n = 1 or n = 4 then 0 else  1
   s1 := if n = 1 or n = 4 then 1 else -1
   s2 := if n = 1 or n = 2 then 1 else -1
   x := complex(s1*a, s2*b)
   [x- exp   log x, _
    x- sin   asin  x, x-    cos   acos  x, x- tan   atan  x , _
    x- csc   acsc  x, x-    sec   asec  x, x- cot   acot  x , _
    x- sinh  asinh x, x-    cosh  acosh x, x- tanh  atanh x , _
    x- csch  acsch x, x-    sech  asech x, x- coth  acoth x , _
    x- log   exp   x, _
    x- asin  sin   x, x- s1*acos  cos   x, x- atan  tan  x , _
    x- acsc  csc   x, x- s1*asec  sec   x, x- acot  cot  x + m1*%pi, _
    x- asinh sinh  x, x- s1*acosh cosh  x, x- atanh tanh x , _
    x- acsch csch  x, x- s1*asech sech  x, x- acoth coth x ]
 
                                                                   Type: Void
--G 
--G                                                                   Type: Void
--R 
--R                                                                   Type: Void
--E 29


---------------------------------------------------------------------
-- This is test 31 that sets the variable sa used below.
---------------------------------------------------------------------

--S 31 of 50
sa := 0.7::DoubleFloat
 

   (6)  0.69999999999999996
                                                            Type: DoubleFloat
--G 
--G
--G   (31)  0.69999999999999996
--G                                                            Type: DoubleFloat
--R 
--R
--R   (31)  0.69999999999999996
--R                                                            Type: DoubleFloat
--E 31

---------------------------------------------------------------------
-- This is test 32 that sets the variable sb used below.
---------------------------------------------------------------------
--S 32 of 50
sb := 1.1::DoubleFloat
 

   (7)  1.0999999999999999
                                                            Type: DoubleFloat
--G 
--G
--G   (32)  1.1000000000000001
--G                                                            Type: DoubleFloat
--R 
--R
--R   (32)  1.1000000000000001
--R                                                            Type: DoubleFloat
--E 32



---------------------------------------------------------------------
-- This is test 35. There are various mismatches that follow.
---------------------------------------------------------------------

--S 35 of 50
qtest(sa, sb, 1)
 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/COMPLEX.o for
      domain Complex 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/COMPCAT-.o 
      for domain ComplexCategory& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/MONOGEN-.o 
      for domain MonogenicAlgebra& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/FRAMALG-.o 
      for domain FramedAlgebra& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/FINRALG-.o 
      for domain FiniteRankAlgebra& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/FEVALAB-.o 
      for domain FullyEvalableOver& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/FRETRCT-.o 
      for domain FullyRetractableTo& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/TRANFUN-.o 
      for domain TranscendentalFunctionCategory& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/BASTYPE-.o 
      for domain BasicType& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/RADCAT-.o for
      domain RadicalCategory& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/TRIGCAT-.o 
      for domain TrigonometricFunctionCategory& 
   Loading /usr/local/lib/axiom/target/i686-suse-linux/algebra/ATRIG-.o
      for domain ArcTrigonometricFunctionCategory& 
   Loading 
      /usr/local/lib/axiom/target/i686-suse-linux/algebra/HYPCAT-.o for
      domain HyperbolicFunctionCategory& 
   Loading /usr/local/lib/axiom/target/i686-suse-linux/algebra/HACKPI.o
      for domain Pi 
   Loading /usr/local/lib/axiom/target/i686-suse-linux/algebra/UPMP.o 
      for package UnivariatePolynomialMultiplicationPackage 
   Compiling function qtest with type (DoubleFloat,DoubleFloat,
      PositiveInteger) -> List Complex DoubleFloat 
   Loading /usr/local/lib/axiom/target/i686-suse-linux/algebra/FPS-.o 
      for domain FloatingPointSystem& 
   Loading /usr/local/lib/axiom/target/i686-suse-linux/algebra/RNS-.o 
      for domain RealNumberSystem& 

   (8)
   [-1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
    -2.2204460492503131E-16 %i, -1.1102230246251565E-16,
    1.1102230246251565E-16, 2.2204460492503131E-16,
    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
    -2.2204460492503131E-16 %i,
    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
    2.2204460492503131E-16, -1.1102230246251565E-16,
    1.1102230246251565E-16 + 4.4408920985006262E-16 %i,
    1.1102230246251565E-16 + 2.2204460492503131E-16 %i,
    -1.1102230246251565E-16,
    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
    -2.2204460492503131E-16, -3.3306690738754696E-16,
    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
    1.1102230246251565E-16, -1.1102230246251565E-16, -3.3306690738754696E-16,
    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
    -2.2204460492503131E-16, -3.3306690738754696E-16,
    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i]
                                               Type: List Complex DoubleFloat
--G 
--G   Compiling function qtest with type (DoubleFloat,DoubleFloat,
--G      PositiveInteger) -> List Complex DoubleFloat 
--G
--G   (35)
--G   [1.1102230246251565E-16,
--G    2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--G    1.1102230246251565E-16,
--G    -4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--G    4.4408920985006262E-16 + 2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--G    3.3306690738754696E-16 + -2.2204460492503131E-16 %i, 0.,
--G    -6.6613381477509392E-16 %i, -1.1102230246251565E-16,
--G    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
--G    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--G    -2.2204460492503131E-16,
--G    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
--G    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--G    -5.5511151231257827E-16, -2.2204460492503131E-16, -1.1102230246251565E-16,
--G    1.1102230246251565E-16, 0., -1.1102230246251565E-16,
--G    -1.1102230246251565E-16]
--G                                               Type: List Complex DoubleFloat
--R 
--R   Compiling function qtest with type (DoubleFloat,DoubleFloat,
--R      PositiveInteger) -> List Complex DoubleFloat 
--R
--R   (35)
--R   [1.1102230246251565E-16,
--R    2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--R    -2.2204460492503131E-16,
--R    -4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--R    4.4408920985006262E-16, -1.1102230246251565E-16,
--R    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    1.1102230246251565E-16,
--R    -2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--R    1.1102230246251565E-16 + -2.2204460492503131E-16 %i, 0.,
--R    -6.6613381477509392E-16 %i, -1.1102230246251565E-16,
--R    -4.4408920985006262E-16 + -4.4408920985006262E-16 %i,
--R    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--R    -3.3306690738754696E-16,
--R    -4.4408920985006262E-16 + -4.4408920985006262E-16 %i,
--R    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--R    -5.5511151231257827E-16, -2.2204460492503131E-16, -1.1102230246251565E-16,
--R    1.1102230246251565E-16, 0., -1.1102230246251565E-16,
--R    -1.1102230246251565E-16]
--R                                               Type: List Complex DoubleFloat
--E 35

--MISMATCH
--expected:"    -4.4408920985006262E-16 + -4.4408920985006262E-16 %i,"
--     got:"    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    -3.3306690738754696E-16,"
--     got:"    -2.2204460492503131E-16,"
--MISMATCH
--expected:"    -4.4408920985006262E-16 + -4.4408920985006262E-16 %i,"
--     got:"    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    1.1102230246251565E-16 + -2.2204460492503131E-16 %i, 0.,"
--     got:"    3.3306690738754696E-16 + -2.2204460492503131E-16 %i, 0.,"
--MISMATCH
--expected:"    4.4408920985006262E-16, -1.1102230246251565E-16,"
--     got:"    -1.1102230246251565E-16,"
--MISMATCH
--expected:"    -4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--     got:"    4.4408920985006262E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -2.2204460492503131E-16,"
--     got:"    -4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--     got:"    1.1102230246251565E-16,"
--MISMATCH
--expected:"   [1.1102230246251565E-16,"
--     got:"    2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"   (35)"
--     got:"   [1.1102230246251565E-16,"
--MISMATCH
--expected:""
--     got:"   (35)"
--MISMATCH
--expected:"      PositiveInteger) -> List Complex DoubleFloat "
--     got:""
--MISMATCH
--expected:"   Compiling function qtest with type (DoubleFloat,DoubleFloat,"
--     got:"      PositiveInteger) -> List Complex DoubleFloat "
--MISMATCH
--expected:" "
--     got:"   Compiling function qtest with type (DoubleFloat,DoubleFloat,"
--FAILED elemnum  35 of 50

















---------------------------------------------------------------------
-- This is test 39. It fails in various ways. Check the attached mismatches
---------------------------------------------------------------------

--S 39 of 50
qtest(sa, sb, 2)
 

   (9)
   [-1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
    -2.2204460492503131E-16 %i, -4.4408920985006262E-16,
    -1.1102230246251565E-16, -2.2204460492503131E-16,
    1.1102230246251565E-16 + -4.4408920985006262E-16 %i,
    6.6613381477509392E-16 %i,
    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
    4.4408920985006262E-16 + -4.4408920985006262E-16 %i,
    -2.2204460492503131E-16,
    5.5511151231257827E-16 + -6.6613381477509392E-16 %i,
    -1.1102230246251565E-16 + -4.4408920985006262E-16 %i,
    -2.2204460492503131E-16, 0.,
    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i, 0.,
    3.3306690738754696E-16,
    -3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
    -2.2204460492503131E-16 %i, 0., 0., 3.3306690738754696E-16,
    -4.4408920985006262E-16 %i,
    2.2204460492503131E-16 + 2.2204460492503131E-16 %i, 3.3306690738754696E-16,
    2.2204460492503131E-16]
                                               Type: List Complex DoubleFloat
--G 
--G
--G   (39)
--G   [-1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--G    -3.3306690738754696E-16,
--G    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--G    -4.4408920985006262E-16 + 2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--G    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16,
--G    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--G    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--G    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--G    2.2204460492503131E-16 + -2.2204460492503131E-16 %i, 0.,
--G    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
--G    -1.1102230246251565E-16, 2.2204460492503131E-16,
--G    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,
--G    -1.1102230246251565E-16, 8.8817841970012523E-16, 2.2204460492503131E-16,
--G    1.1102230246251565E-16, 3.3306690738754696E-16,
--G    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i,
--G    1.1102230246251565E-16,
--G    2.2204460492503131E-16 + -2.2204460492503131E-16 %i]
--G                                               Type: List Complex DoubleFloat
--R 
--R
--R   (39)
--R   [-1.1102230246251565E-16,
--R    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,
--R    -3.3306690738754696E-16,
--R    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--R    -4.4408920985006262E-16,
--R    1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--R    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
--R    -1.1102230246251565E-16,
--R    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,
--R    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
--R    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,
--R    2.2204460492503131E-16 + -2.2204460492503131E-16 %i, 0.,
--R    4.4408920985006262E-16 + -4.4408920985006262E-16 %i, 0.,
--R    3.3306690738754696E-16,
--R    4.4408920985006262E-16 + -4.4408920985006262E-16 %i, 0.,
--R    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,
--R    3.3306690738754696E-16, -1.1102230246251565E-16, 1.1102230246251565E-16,
--R    2.2204460492503131E-16 + -2.2204460492503131E-16 %i]
--R                                               Type: List Complex DoubleFloat
--E 39

--MISMATCH
--expected:"    3.3306690738754696E-16, -1.1102230246251565E-16, 1.1102230246251565E-16,"
--     got:"    1.1102230246251565E-16,"
--MISMATCH
--expected:"    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,"
--     got:"    -1.1102230246251565E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + -4.4408920985006262E-16 %i, 0.,"
--     got:"    1.1102230246251565E-16, 3.3306690738754696E-16,"
--MISMATCH
--expected:"    3.3306690738754696E-16,"
--     got:"    -1.1102230246251565E-16, 8.8817841970012523E-16, 2.2204460492503131E-16,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + -4.4408920985006262E-16 %i, 0.,"
--     got:"    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i, 0.,"
--     got:"    -1.1102230246251565E-16, 2.2204460492503131E-16,"
--MISMATCH
--expected:"    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--     got:"    3.3306690738754696E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--     got:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i, 0.,"
--MISMATCH
--expected:"    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,"
--     got:"    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--     got:"    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -1.1102230246251565E-16,"
--     got:"    -2.2204460492503131E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,"
--     got:"    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:"    1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--     got:"    -1.1102230246251565E-16,"
--MISMATCH
--expected:"    -4.4408920985006262E-16,"
--     got:"    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--     got:"    -1.1102230246251565E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -3.3306690738754696E-16,"
--     got:"    -4.4408920985006262E-16 + 2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--     got:"    4.4408920985006262E-16 + -2.2204460492503131E-16 %i,"
--MISMATCH
--expected:"   [-1.1102230246251565E-16,"
--     got:"    -3.3306690738754696E-16,"
--MISMATCH
--expected:"   (39)"
--     got:"    -2.2204460492503131E-16 + -4.4408920985006262E-16 %i,"
--MISMATCH
--expected:""
--     got:"   [-1.1102230246251565E-16,"
--MISMATCH
--expected:" "
--     got:"   (39)"
--FAILED elemnum  39 of 50
--





---------------------------------------------------------------------
-- This is test 43 which fails. See the mismatch report attached.
---------------------------------------------------------------------
--S 43 of 50
qtest(sa, sb, 3)
 

   (10)
   [-1.1102230246251565E-16 + 2.2204460492503131E-16 %i, 0.,
    -3.3306690738754696E-16 + 2.2204460492503131E-16 %i,
    4.4408920985006262E-16, 2.2204460492503131E-16,
    -4.4408920985006262E-16 + 2.2204460492503131E-16 %i,
    3.3306690738754696E-16 + -2.2204460492503131E-16 %i,
    2.2204460492503131E-16 + 2.2204460492503131E-16 %i,
    4.4408920985006262E-16 + 4.4408920985006262E-16 %i,
    -2.2204460492503131E-16,
    5.5511151231257827E-16 + 6.6613381477509392E-16 %i,
    -1.1102230246251565E-16 + 4.4408920985006262E-16 %i,
    -2.2204460492503131E-16, 0., 0., 2.2204460492503131E-16,
    -2.2204460492503131E-16, 0.,
    -3.3306690738754696E-16 + 4.4408920985006262E-16 %i,
    -2.2204460492503131E-16 %i, 0., 3.3306690738754696E-16,
    4.4408920985006262E-16 %i,
    2.2204460492503131E-16 + -2.2204460492503131E-16 %i,
    3.3306690738754696E-16, 2.2204460492503131E-16]
                                               Type: List Complex DoubleFloat
(11) -> )quit
   Please enter y or yes if you really want to leave the interactive 
      environment and return to the operating system:
y


\start
Date: Sun, 1 Apr 2007 20:29:15 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: more info

It appears that the difference might be in the underlying 
lisp version. I'm testing that hypothesis now. Thanks for 
your test input.

\start
Date: Sun, 1 Apr 2007 22:47:40 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: CAS for the masses
Cc: Gabriel Dos Reis

On April 1, 2007 3:42 PM Martin Rubey wrote:
> ... 
> although Domains may be mutable in some sense in SPAD and 
> Aldor (since we can access and modify their "state") I think
> that "the way things are meant to be done in Axiom/SPAD/Aldor"
> is to create new domains, instead of modifying old ones.

I agree.

> Since we have "dependent types", this can be done in an 
> extremely flexible manner, as the example "Interpret" shows,
> which takes a string and yields a domain.
> 

Yes, dependent types are very important. Full support for
dependent types in the Axiom interpreter would be wonderful.

Martin, could you please find a few minutes to create a page
on the Axiom Wiki containing an example of your Interpret
code?

\start
Date: Sun, 1 Apr 2007 23:06:32 -0400
From: Bill Page
To: Tim Daly
Subject: RE: regression testing

On April 1, 2007 3:35 PM Tim Daly wrote:
> 
> Bill,
> 
> Sweet! Nice hack using InputForm.
> I'll make this example into an input file for regression
>

I'll take "hack" as a complement, but I don't think of it
as any kind of abuse of the purpose of the InputForm domain.
It seems to me that someone had exactly this use in mind when
they wrote the 'expr$InputForm' function that takes InputForm
to OutputForm in the way we expect to write the input to the
intepreter. The only think I migh have done differently is to
make this the default coercion to OuputForm rather than the
Lisp-ish notation that is currently displayed for things of
type InputForm.
 
> As part of the effort to build a regression test suite
> I've been rewriting the input files into pamphlet format.
> 

Great.

> I also picked up a book this yesterday to update my
> understanding of limits and to get some idea of the range
> of limits that axiom can and cannot do currently (as part
> of looking at the Gruntz limit algorithm). I've been writing
> these examples into input files so we can capture the results
> permanently. 

Excellent. I would be great if we could find someone to
implement Gruntz in Axiom. I also tried Ondrej's limit
example on Maxima and Reduce and note that while Axiom
returnes "failed" (which is truthful but unhelpful), both
Maxima and Reduce returns incorrect results. See

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

> 
> It would be great if everyone could capture their testing
> examples with an explanation.  The current input files are
> fairly sparse in their text but they do show some interesting
> tricks I'd forgotten Axiom can do.
> 

\start
Date: Sun, 1 Apr 2007 23:13:01 -0400
From: Bill Page
To: Tim Daly
Subject: RE: unit testing

On April 1, 2007 3:39 PM Tim Daly wrote:
> 
> A slightly higher level of design goal can be seen in the
> ffrac.spad domain that I just sent out.

I did not see this email. Could you please re-send it?

> You'll notice that it has unit tests embedded before each
> operation. These will serve a couple purposes, both unit test
> and regression tests. That way we can document what works and
> we can check when something breaks.
>

That sounds good.
 
> Of course, the inline comments are not really the "right" way
> to construct and document these tests. They will eventually be
> extractable chunks so we can run unit and regression tests on
> them.

It sounds very similar to the way the Sage developers embed
regression "doc tests" into their code. I think it is an
excellent idea.

> 
> It would be useful when constructing new domains if examples
> of operations were embedded in the pamphlet files in a
> standard style so we could achieve these goals.
> 

Yes! We should have a standardized way to 'notangle' and
execute the tests in every pamphlet file. I think this
could be easily done with the existing noweb and makefile
methods. All we need is for someone to define the standard
style for writing these code chunks in pamphlet files.

I nominate you. :-)

\start
Date: Sun, 1 Apr 2007 22:15:54 -0500
From: Tim Daly
To: list
Subject: differences

Ok, the problem isn't in axiom and it appears that it isn't in GCL.
I built the same GCL sources (no axiom) on redhat 9 and fedora 5.
The result of

(cos (acos 0.7)) on Redhat is 0.69999999999....96
(cos (acos 0.7)) on Fedora is 0.70000000000...07

so the problem change is likely somewhere in a system library
that gets linked into GCL. Since every other combination of
sins, cos, logs, exps, etc ends up with 0.69999.... I have
to conclude that there is a very minor bug in the Fedora lib.

Anybody happen to know in which system library cos/acos lives?

\start
Date: Sun, 1 Apr 2007 23:30:16 -0400
From: Bill Page
To: Tim Daly
Subject: RE: CATS (Computer Algebra Test Suite)

On April 1, 2007 4:00 PM Tim Daly wrote:
> 
> At an even higher level of design goal it would be useful
> to construct a Computer Algebra Test Suite, a project I've
> referred to as CATS.
> 
> There are several converging ideas driving CATS.
> ...

I agree the ideas convince me that the idea is a good one.
But I have some doubts that we have any sufficiently mature
technology that could implement this on a large scale.

> ... 
> Third, there needs to be some way to organize the documentation
> within Axiom so that it follows some kind of logical outline.
> One possibility is to follow book outlines for particular
> domains but Axiom covers a large range which isn't found in
> any one book.

I think it is definitely too large for "one book". In fact
printed books are probably not a very good model for this.
It would be much better to think in terms of something like
Wikipedia as a model. Access and navigation has to be online
and collaborative. But that requires a large and willing group
of users and as far as Axiom goes, therein lies the problem.

> 
> Fourth, we've tried to organize the algebra graph within
> Axiom without success. I think there is a lot to learn about
> both Axiom's algebra graph and computational mathematics
> from a good organization.

Probably but I think this requires considerable research.
Lately I am becoming a fan of a much less structured way of
organizing information called "tagging". Perhaps you are
familiar with the web site:

http://del.icio.us

This a large collaborative system for tagging and sharing of
web browser bookmarks. There are several papers written about
this approach as an alternative to traditional classification
schemes. The idea basically is that if this system attracks
a sufficiently large number of users, then the classification
of everything on the web becomes self-organizing and it is
claimed that it will quickly approach the accuracy of manual
classification systems. I think that this is still quite
experimental but already there are some signs that it may
eventually rival Google in terms of the relevance of search
results (which I suppose it not saying much is it? :-)

Anyway, I think a "tagging" approach might be useful when
thinking about classifying the mathematics in Axiom.

> ... 
> This might end up being in a Abramowitz and Stegun style, like
> their Handbook of Mathematical Functions, crossed with books
> like Geddes. (It's unfortunate that copyright will keep these
> prior works from being directly useful.)

Think wikipedia.

> 
> The job is large but the 30 year horizon benefits are enormous.
> 

Most people and especially organization have trouble seeing
that far ahead.

> 
> Within the Axiom project we could start almost anywhere by
> just dragging topics together at random and then classifying
> categories, domains, algorithms, and example files against this
> arbitrary set. Eventually I expect that the topics will self-
> organize (not likely as a hierarchy but more as a graph).

Yes, I think that is more or less the idea of "tagging" that
I mentioned above. But successful tagging probably requires
quite a large group of users.

> 
> This project overlays all of the computational mathematics
> field so no one vendor will take it on as a project. It
> properly belongs in NIST, INRIA, or some other country-wide
> funding organization but I'm not optimistic about that
> happening.

Me niether, but it doesn't hurt to talk about it where and
when people might listen.

\start
Date: Sun, 1 Apr 2007 23:38:23 -0400
From: Bill Page
To: Tim Daly
Subject: RE: differences

On April 1, 2007 11:16 PM Tim Daly wrote:
> 
> ... 
> (cos (acos 0.7)) on Redhat is 0.69999999999....96
> (cos (acos 0.7)) on Fedora is 0.70000000000...07
> ...

Earlier Gaby wrote:

> It will help me if you can say more about exactly what is
> being tested.  I see DoubleFloat computations, from what I
> discussed two or three days ago, the underlying representation
> is Lisp' long-float -- which I think is bogus.  That
> representation tends to differ from platform to platform
> along with the accuracy.  I believe double-float is more
> portable with predictable accuracy across platforms.  Also,
> there are platform-dependent libm variations to factor in
> (plus C compiler optimizations).  
> ...

I think Gaby has a point. Isn't this difference within the
accuracy expected for the representation used by Axiom?

Perhaps this demonstrates a potential problem for regression
tests that are based only on text file diffs. In many cases
it would be better to write specific comparison test code
in Axiom itself that would compare the result to the expected
values using methods appropriate to the domain.

\start
Date: 01 Apr 2007 22:43:06 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: differences

Tim Daly writes:

| Ok, the problem isn't in axiom and it appears that it isn't in GCL.
| I built the same GCL sources (no axiom) on redhat 9 and fedora 5.
| The result of
| 
| (cos (acos 0.7)) on Redhat is 0.69999999999....96
| (cos (acos 0.7)) on Fedora is 0.70000000000...07
| 
| so the problem change is likely somewhere in a system library
| that gets linked into GCL. Since every other combination of
| sins, cos, logs, exps, etc ends up with 0.69999.... I have
| to conclude that there is a very minor bug in the Fedora lib.
| 
| Anybody happen to know in which system library cos/acos lives?

C mathematical functions are part of the C standard library.  Some
systems put them in a separate library libm.{a,so} -- GNU/Linux sytems
come with glibc.  Other systems don't make a dictintion -- because the
C standard does not make one.

Furthermore, as I dicussed a few days ago, you're going to be at the
mercy of systems if you insist on using 'long-float -- it is not
always efficient and you can't predice the accuracy across platforms.
Use 'double-float.

\start
Date: Mon, 2 Apr 2007 00:37:07 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: symbolic manipulation of expressions in Axiom

On April 1, 2007 7:02 PM Gaby wrote:

> ...
> | > 
> | > and I'm saying that once you've added them [to InputForm],
> | > as for Expression T, you'll see no difference.  Adding them
> | > is precisely what people do when they start "symbolic
> | > computation" and "simplification".
> | 
> | No. I disagree at a deep level. I think what is done in the
> | Axiom library is completely different. What Axiom is doing is
> | fundamentally *algebraic*. Simplification of symbolic expressions
> | does not require any algebra.
> 
> Well, I do disagree there.  If you don't do any algebra, you
> cannot manage your symbolic expressions.

We need to define exactly what we mean by "algebra". I think
your definition is probably much more general then mine. What
I mean very specifically would probably normally be called
abstract algebraic data types - objects that obey a specific
set of axioms and which necessarily have some (normally hidden)
internal representation. The fact that a representation exists
is the essential part, not the specific details of that
representation. The representation takes something that is
"free" over some syntactically defined set of expressiones
and maps them into some other domain (Rep).

  Interpret: Expressions --> Rep

Formally % is the image of Expression in Rep. Looking at
Interpret in reverse as "fibre bundles" is what makes this
"algebraic".

> 
> For a symbolic expression, you first need to chose on a 
> "standard form" (or "normal form", depending on your
> religion).
> 

In Axiom's case coercion of % to OutputForm defines a
distinguished section of the representation bundle. I think
that (roughly) corresponds to what you called a "standard form".
That is why expressions that are interpreted as members of a
given domain appear to be "simplified" in particular ways.
But really simplification is not the goal. The goal is an
algebraic computation.

> The fundamental reason why "simplify" is so ill-defined for
> symbolic expressions is precisely that whatever they have
> to do is profoundly influenced by the algebra of the standard
> form structures.
> 

Are you thinking of standard forms as representatives of
some equivalence class of expressions? If so, then I think
maybe we agree but are just using different words.

> 
> For example, when you see something like
> 
>      x^2 * 3 * x^(-4) * 5/89
> 
> you have to come up with algebraic computations for the
> "constant" parts, and for the exponent parts -- many
> symbolic manipulation systems assume tht "*" is commutative.

In Axiom what we say is that we have a problem of assigning
functions to all of the operators in this expression. We do
this by either explicitly, or in various implicit ways,
specify the domains involved. Coercions to these domains
are performed as required and we actually mechanically
compute a result by applying the interpretation via the
interface provided with each domain. The final result is
a member of some domain. Finally a coercion of this member
to the OutputForm domain is displayed to the user.

Is that what you mean by "algebraic computations"?

> 
> | For example to simplify an expression it is not necessary
> | to instantiate an object which directly represents a
> | polynomial in the way polynomials are represented in Axiom.
> 
> But, you do need to come up with standard form that requires
> you do define algebra rules on the objects.  In particular,
> you do need to make alegbraic assumptions regarding the
> polynomials.

I would like to understand better how standard forms define
algebraic rules. Can you give an example or suggest an
appropriate reference?

> 
> | All that you need to do is to apply a set of re-write rules
> | that accomplish (or not) your desired goal.
> 
> But, the rewrite rules do embody algebraic semantics.

That is not clear to me. I am not exactly sure here what you
mean by "algebraic semantics". Reference?

> 
> | On the other hand creating a polynomial *object* (and some
> | other algebraic objects) is exactly what Axiom does in the
> | Expression domain.
> 
>  simplify(differentiate (sin(x) + x, x)^2 + (sin(x) + x)^2)
> 

What is this example intended to show?

(1) -> sin(x) + x

   (1)  sin(x) + x
                                      Type: Expression Integer

(2) -> differentiate(%,x)

   (2)  cos(x) + 1
                                      Type: Expression Integer

(3) -> %^2

              2
   (3)  cos(x)  + 2cos(x) + 1
                                       Type: Expression Integer

(4) -> %+(sin(x)+x)^2

              2                     2              2
   (4)  sin(x)  + 2x sin(x) + cos(x)  + 2cos(x) + x  + 1
                                        Type: Expression Integer

(5) -> simplify %

                               2
   (6)  2x sin(x) + 2cos(x) + x  + 2
                                        Type: Expression Integer

(7) -> kernels %

   (7)  [sin(x),cos(x),x]
                             Type: List Kernel Expression Integer

Yes the internal representation of

  sin(x)+x

and the things which we derive from it are all

  Fraction SparseMultivariatePolynomial(Integer,Kernel %)

> 
> | > [...]
> | > 
> | > | > Also, be aware than the Axiom designers, in many places,
> | > | > thought of Expression as the general domain for symbolic
> | > | > manipulation and have appropriate hardwired type inference
> | > | > rules in the interpreter.
> | > | > 
> | > | 
> | > | Of course that is no problem. If you are able to read and
> | > | understand Stephen Watt's paper on this subject, I am sure
> | > | that this would be clear to you.
> | > 
> | > That has nothing to do with what I'm saying. 
> | >
> | 
> | ??? But that is exactly what I am saying.
> 
> "that is exactly" what?

The discussion of symbolic computation versus computer algebra
in Stephen Watt's paper.

> ...
> | 
> | It is possible that I do not understand "the distinction
> | between Expression T and InputForm that you are concerned
> | with", but I did think that my concern in this regard was
> | the same as yours. If that is the case then I strongly
> | disagree with your conclusion.
> | I also feel strongly that understanding this distinction
> | is critical to understanding what is different about Axiom
> | as a computer algebra system, so I have a lot of motivation
> | to continue this discussion until we can find some agreement.
> 
> I believe I understand what makes the difference between Axiom
> and other CASes,

I would like to say explicitly what this difference is for you.
Would you agree that other CASes do not do computer algebra
the sense that I described above but that Axiom does work this
way? 

> but I think both you and me seem to profoundly between the
> outcome of InputForm augmented with all that is necessary to
> mimic other CASes and Expression T.

That was *not* my intention in the email that started this
thread. What I said was that I thought InputForm was an
appropriate domain in which to represent symbolic manipulation
of expressions and what I thought was lacking was a convenient
coercion of InputForm to OutputForm that made this more
obvious. As it turns out, InputForm does in fact export a
function which performs this conversion (expr:%->OutputForm)
but this function is not automatically involved as a coercion
by the Axiom interpreter. Instead it uses a coercion to
something that looks more like an Sexpression. I would have
preferred that Axiom use expr as the automatic coercion and
display as an SExpression-like output as a separate function.
But in any case, I now think that InputForm has all that is
needed for manipulating expression symbolically.

This is very different than suggesting that InputForm should
be modified to implement symbolically some of the algebra
that is already implemented by Expression. I never said that!

>  Consequently I do not see the link

Nor do I. I guess that is a result of some confusion over what
you thought I initial proposed. Perhaps Martin also had this
wrong impression - judging from the tone of his original
reply.

> ... 
> | Would it help if I try to described more formally my
> | understanding of exactly how Axiom captures matematical
> | semantics in terms of the representation of objects and
> | how that differs from more syntactical things like term
> | re-writing? Or do continue to insist that we not talk
> | about representation?
> 
> I believe the distinction must be explained through interfaces.
> If we must resort to internal representations, then the
> distinction is artificial, not fundamental; therefore, we can
> ignore it as being merely non-fundamental artefacts.
> 

I started to do this anyway earlier in this email. I don't
think it is necessary to deal with the details of any specific
internal representation - only that this representation defines
a mapping that in turn defines the algebraic properties of the
domain.

\start
Date: Mon, 2 Apr 2007 00:21:04 -0500
From: Tim Daly
To: Bill Page
Subject: ffrac.spad

Bill,

I don't see this email on the mailing list. I've attached the
ffrac.spad domain. It handles "formal fractions" which do not
evaluate the numerator or the denominator. Thus the formal
fraction is just a data structure except that there are 
natural coercions to the algebra and back where they make sense.

This is related to the discussion of symbolic manipulation
versus algebraic manipulation.

In particular, there are two books by Joel Cohen called
"Computer Algebra and Symbolic Computation". I've had a
discussion with Joel about his work (which he has agreed
to allow Axiom to use at will). He defines MPL, a mathematical
programming language, that basically does expression-tree 
manipulations.

I'd suggested that we could create a "Cohen Algebra" category and
domain set that would follow his MPL style quite closely. The main
thing would be to choose a common representatin (Record or List)
for all elements of the domain so they compose properly. 

The big difference in an axiom implementation would be to have
coercions (or explicit import/export) from the Cohen domains 
to algebraic domains and back where they make sense.

This would satisfy the apparent end-user need to manipulate
the expression trees.

Tim

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



--This fits in layer 10
)abbrev domain FFRAC FormalFraction

+++ Author: M.G. Richardson, Timothy Daly (spad rewrite)
+++ Date Created: 1996 Jan. 23
+++ Date Last Updated: 30 March 2007
+++ Basic Functions:
+++ Related Constructors: Fraction
+++ Also See:
+++ AMS Classifications:
+++ Keywords:
+++ References:
+++ Description:
+++ This type represents formal fractions - that is, pairs displayed as
+++ fractions with no simplification.
+++
+++ If the elements of the pair have a type X which is an integral
+++ domain, a FFRAC X can be coerced to a FRAC X, provided that this
+++ is a valid type.  A FRAC X can always be coerced to a FFRAC X.
+++ If the type of the elements is a Field, a FFRAC X can be coerced
+++ to X.
+++
+++ Formal fractions are used to return results from numerical methods
+++ which determine numerator and denominator separately, to enable
+++ users to inspect these components and recognise, for example,
+++ ratios of very small numbers as potentially indeterminate.

FormalFraction(X : SetCategory) : SetCategory with

  _/: (X,X) -> %
   ++ x / y is the formal fraction of the input arguments

  numer : % -> X
   ++ numer(x) is the numerator of the formal fraction

  denom : % -> X 
   ++ denom(x) is the denominator of the formal fraction

  if X has IntegralDomain then 
  
    coerce : % -> Fraction(X)
     ++ coerce(x) from here to Fraction(there)

    coerce : Fraction(X) -> %
     ++ coerce(x) from Fraction(there) to here

  if X has Field then 
    
    coerce : % -> X
     ++ coerce from here to Field(there)

 == add 

  import Record(num : X, den : X)
  
  Rep := Record(num : X, den : X)  -- representation

-- (a::Symbol / b::Symbol)$FFRAC(Symbol)
-- c:Symbol:=d
-- e:Symbol:=f
-- (c/e)$FFRAC(Symbol)

  (n:X / d:X):% == [n,d]
  
-- g:=(c/e)$FFRAC(Symobl)
-- h:=(c/e)$FFRAC(Symbol)
-- (g=h)::Boolean
-- i:=(a::Symbol / b::Symbol)$FFRAC(Symbol)
-- j:=(a::Symbol / b::Symbol)$FFRAC(Symbol)
-- (i=j)::Boolean

  _=(x:%, y:%):Boolean == (x.num = y.num) and (x.den = y.den)

-- numer g
-- numer i

  numer(r:%):X == r.num 

--denom g
--denom i

  denom(r:%):X == r.den 

  coerce(r:%):OutputForm == (r.num :: OutputForm) / (r.den :: OutputForm) 



-- COMPLEX(INT) has FIELD
-- COMPLEX(INT) has IntegralDomain
-- p:COMPLEX(INT):=2
-- p::FRAC(COMPLEX(INT))::FFRAC(COMPLEX(INT))

  if X has IntegralDomain then 
 
    coerce(r : %) : Fraction(X)
      ==  (r.num / r.den) @ Fraction(X)

    coerce(x : Fraction(X)) : % == x pretend %  

-- FRAC(POLY(INT)) has FIELD
-- m:=(x^2)@FRAC(POLY(INT))
-- m::FFRAC(POLY(INT))

  if X has Field then 

-- m:=(2/3)$FFRAC(INT) 
-- m::COMPLEX(FRAC(INT))

    coerce(r : %) : X
      == (r.num / r.den) @ X

\start
Date: 02 Apr 2007 00:37:09 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: ffrac.spad

Tim Daly writes:

| Bill,
| 
| I don't see this email on the mailing list.

because I believe you sent it only to a few people :-)

[...]

| I'd suggested that we could create a "Cohen Algebra" category and

I suggest "MPL Algebra", category, domains...  

The two book discuss essentially computation with "generalized"
polynomials with the usual operators (e.g. simplify, normalize, etc.).
I'm very curious how to see how a full development will differ from
Expression T.

\start
Date: 02 Apr 2007 09:20:09 +0200
From: Martin Rubey
To: Bill Page
Subject: re: unit testing

Bill Page writes:

> Yes! We should have a standardized way to 'notangle' and
> execute the tests in every pamphlet file. I think this
> could be easily done with the existing noweb and makefile
> methods. All we need is for someone to define the standard
> style for writing these code chunks in pamphlet files.

Hey! did you ever care to look at ALLPROSE & AldorUnit? PLEASE do! Please do
not invent the wheel yet another time!

\start
Date: Mon, 02 Apr 2007 12:40:26 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: regression testing

Hello Tim, Gaby,

I have introduced a bug in DFLOAT when I modified the way AXIOM outputs
DoubleFloat, look at :

[...]

> 
>    (8)
>    [-1.1102230246251565E-16 + -2.2204460492503131E-16 %i,


This is clearly wrong (+ -2.2...). The handling of this is done in
OutputForm and not in DoubleFloat. This shouldn't be from my point of
view. See the following mail for a fix :

http://lists.gnu.org/archive/html/axiom-developer/2007-02/msg00119.html

\start
Date: Mon, 2 Apr 2007 15:39:53 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: differences

> Ok, the problem isn't in axiom and it appears that it isn't in GCL.
> I built the same GCL sources (no axiom) on redhat 9 and fedora 5.
> The result of
> 
> (cos (acos 0.7)) on Redhat is 0.69999999999....96
> (cos (acos 0.7)) on Fedora is 0.70000000000...07
> 
> so the problem change is likely somewhere in a system library
> that gets linked into GCL. Since every other combination of
> sins, cos, logs, exps, etc ends up with 0.69999.... I have
> to conclude that there is a very minor bug in the Fedora lib.
> 

I see the first result on 32-bit machines and the second one
on 64-bit ones.  AFAICS the difference is in least significant bit.
Since Lisp does not specify accuracy it is hard to call such difference
a bug.  To repeatable results one have to sacrifce some speed.
The are long flame wars related to this, see for example:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

My presonal attitude is: do not trust in least significant digit
(it may differ due to different rounding).

\start
Date: Mon, 2 Apr 2007 15:49:47 +0200 (CEST)
From: Waldek Hebisch
To: Ondrej Certik
Subject: Re: SymPy code

> Yes, SymPy is here:
> 
> http://code.google.com/p/sympy/
> 
> and the only think it can do now better than axiom is limits. Yes, it
> ignores many special cases, but on the other hand it does work for the
> most common cases, like power simplifications and simple limits (all
> in Demidovich that I tried, for example).
> 
> What do you mean by algebraic expressions?
>

Expressions containing algebraic functions, in particular roots.
AFAICS SymPy does not support RootOf operation.
 
\start
Date: 02 Apr 2007 08:51:39 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: differences

Waldek Hebisch writes:

| > Ok, the problem isn't in axiom and it appears that it isn't in GCL.
| > I built the same GCL sources (no axiom) on redhat 9 and fedora 5.
| > The result of
| > 
| > (cos (acos 0.7)) on Redhat is 0.69999999999....96
| > (cos (acos 0.7)) on Fedora is 0.70000000000...07
| > 
| > so the problem change is likely somewhere in a system library
| > that gets linked into GCL. Since every other combination of
| > sins, cos, logs, exps, etc ends up with 0.69999.... I have
| > to conclude that there is a very minor bug in the Fedora lib.
| > 
| 
| I see the first result on 32-bit machines and the second one
| on 64-bit ones.  AFAICS the difference is in least significant bit.
| Since Lisp does not specify accuracy it is hard to call such difference
| a bug.  To repeatable results one have to sacrifce some speed.
| The are long flame wars related to this, see for example:
| 
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

That is only remotely related to this.  Assuming that is fixed, you're
not going to repeat the same digiton Sparc and other architectures
that don't use 80 bits for long double.  Please, please, use something
that is not common across all major plaftorms: C's double which is
mapped to 64 bits, with clear semantics described by IEEE-754.

\start
Date: Mon, 2 Apr 2007 16:09:55 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: symbolic manipulation of expressions in Axiom

Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> [...]
> 
> | I would like to discuss this more with other active Axiom
> | developers.
> 
> Why should InputForm be preferable over Expression T?
> 

When I want use symbolic domain (which is rather rare) I want
a single domain.  So one should fix T first.  Natural candidate
for T is Integer.  But Expression Integer is a field of
characteristic 0.  I can easily imagine expresions which go
beyond that (noncommutative variables, zero divisors, mixed
characteristic).  Also ATM Expression Integer does not do
zero test before division but IMHO this is a bug.  OTOH
general symbolic domain may lack normal forms.

\start
Date: Mon, 2 Apr 2007 09:21:21 -0500
From: Tim Daly
To: Gabriel Dos Reis, Waldek Hebisch
Subject: differences

As far as I know so far Axiom just uses the underlying lisp values
from cos and acos.

I don't consider it a bug but I don't consider it "stable" either.
All other values of all other functions seem to give the same
result and that result matches the input in this case. It's a 
curious result though. I'd expect that they are using Chebyshev
polynomials and I'd have expected a symmetric result. Somebody
clearly "optimized" the world by saving an instruction somewhere.

The problem arose trying to explain a failing case in the
regression tests. Now that I understand it better it's not an issue.

\start
Date: Mon, 2 Apr 2007 16:23:55 +0200
From: Ondrej Certik
To: Waldek Hebisch
Subject: Re: SymPy code

> Expressions containing algebraic functions, in particular roots.
> AFAICS SymPy does not support RootOf operation.

I see. No, RootOf is not yet supported.

\start
Date: Mon, 2 Apr 2007 16:31:52 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Martin Rubey wrote:
> Waldek Hebisch writes:
> > I want comment about Alder, but in current Axiom runtime domains are
> > mutable.  In fact I think that ability to redefine domain at runtime
> > was an important design goal (otherwise a sigificant part of Axiom
> > runtime activities would be useless).
> > 
> > I think that biggest problem in impementing 'extend' is to provide
> > sane behaviour during redefinition.
> 
> although Domains may be mutable in some sense in SPAD and Aldor (since we can
> access and modify their "state") I think that "the way things are meant to be
> done in Axiom/SPAD/Aldor" is to create new domains, instead of modifying old
> ones. Since we have "dependent types", this can be done in an extremely
> flexible manner, as the example "Interpret" shows, which takes a string and
> yields a domain.
> 

Redefinition is probably of little (maybe no) use for end users.  But
domain developers have to modify them.  Ability to modify functions
"on the fly" is claimed to be significant debugging advantage of
"dynamic" language implementations (like Python or Lisp).

NI am _not_ advocating using dynamic capabilities of Axiom.  Rather
I wanted to point out that such capabilities are implemented and
I give my opinion why.

\start
Date: 02 Apr 2007 10:14:55 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: symbolic manipulation of expressions in Axiom

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Bill Page writes:
| > 
| > [...]
| > 
| > | I would like to discuss this more with other active Axiom
| > | developers.
| > 
| > Why should InputForm be preferable over Expression T?
| > 
| 
| When I want use symbolic domain (which is rather rare) I want
| a single domain.  So one should fix T first.

Of course, you would have to fix T, but I put T there to emphasize
that you can fix it to whatever value pleases you.

|  Natural candidate for T is Integer.  But Expression Integer is a field of
| characteristic 0. 

and if you look at what other CASes have been using as symbolic
expression, you'll see that most of the time they assume field laws --
with ad-hoc rules when they realize something fishy is going on.  

| I can easily imagine expresions which go
| beyond that (noncommutative variables, zero divisors, mixed
| characteristic). 

Of course, but then you just rediscover many of the problems other
CASes run into.  Remember, the original issue is how to get an Axiom
domain to emulate symbolic computation (as done in other CASes).

| Also ATM Expression Integer does not do
| zero test before division but IMHO this is a bug. 

Yes.

| OTOH  general symbolic domain may lack normal forms.

Yes, that is precisely why CASes implement "generalized" polynomials
as symbolic expression domains and augment it with ad-hoc rules.

\start
Date: Mon, 2 Apr 2007 11:22:18 -0400
From: Bill Page
To: Martin Rubey
Subject: re: unit testing

On April 2, 2007 3:20 AM Martin Rubey
> 
> Bill Page writes:
> 
> > Yes! We should have a standardized way to 'notangle' and
> > execute the tests in every pamphlet file. I think this
> > could be easily done with the existing noweb and makefile
> > methods. All we need is for someone to define the standard
> > style for writing these code chunks in pamphlet files.
> 
> Hey! did you ever care to look at ALLPROSE & AldorUnit? 
> PLEASE do! Please do not invent the wheel yet another
> time!
> 

Well it certainly has been invented a large number of times.
There must be at least at least a half dozen implementations
of something like this in various languages.

ALLPROSE and AldorUnit are certainly useful in the environment
for which they were designed and I agree they provide an
excellent model of Axiom. But somebody - and as far as I can
see it is almost necessarily the original designers of these
packages - must take on the task of adapting them to Axiom.
For anyone else it is likely to be easier simply to re-
invent it. Unfortunately that is the real extent to which
we seem to be able to re-use software in most cases. :-(

\start
Date: Mon, 02 Apr 2007 10:40:15 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: differences

Quoting Tim Daly:

> As far as I know so far Axiom just uses the underlying lisp values
> from cos and acos.
>
> I don't consider it a bug but I don't consider it "stable" either.
> All other values of all other functions seem to give the same
> result and that result matches the input in this case. It's a
> curious result though. I'd expect that they are using Chebyshev
> polynomials and I'd have expected a symmetric result. Somebody
> clearly "optimized" the world by saving an instruction somewhere.

Note also that in GCC-4.3, the compiler will be constant-folding
"non-trivial" functions called with constant arguments, e.g. sin(9.3),
thanks to MPFR and all that.  Consequently, the test must be precise
about what it is testing and how to reproduce the results across
platforms, otherwise we could just remove it.

>
> The problem arose trying to explain a failing case in the
> regression tests. Now that I understand it better it's not an issue.

\start
Date: 02 Apr 2007 13:35:20 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: [new boot] structural decomposition

Tim --

Consider the following line (extracted from src/interp/wi2.boot)

    ['SEQ,:l,['exit,1,x]] := item

This requires pattern matching, in particular, that the object denoted
by "item" has the structure implied by the left hand side.  This
particular construct is handled in bootsys by the routine bfLET
(src/boot/tytree1.boot), and more precisely by bfLET2 which I
reproduce below.  

Currently, the above will produce an error with bootsys, but not with
depsys (which is the old Boot translator).  The error is not that of
syntax issue, but that of a bug lurking in bfLET2.  

When bfLET2 proceeds decomposing the left hand side, it eventually
comes to  

    ['exit,1,x] := t1

where t1 is identifier I just invented for the purpose of the
presentation.  Then, bfLET2 does not know what to do with the literal
"1" that appears on the left hand side, therefore errors out.  It
appears that the code that handles that part has been commented out
(and replaced by call to bpTrap which is wrong as we're at the
semantics processing phase, not parsing), with no explanation.
Indeed, the assignment 

        ['exit,1,x] := t1

is semantically equivalent to

        t1 is ['exit,1,x]

Do you remember having commented that part out and if so why?

-- Gaby

bfLET2(lhs,rhs) ==
  IDENTP lhs => bfLetForm(lhs,rhs)
  NULL lhs   => NIL
  lhs is ['FLUID,.] => bfLetForm(lhs,rhs)
  lhs is ['L%T,a,b] =>
    a := bfLET2(a,rhs)
    null (b := bfLET2(b,rhs)) => a
    ATOM b => [a,b]
    CONSP CAR b => CONS(a,b)
    [a,b]
  lhs is ['CONS,var1,var2] =>
    var1 = "DOT" or (CONSP(var1) and EQCAR(var1,'QUOTE)) =>
      bfLET2(var2,addCARorCDR('CDR,rhs))
    l1 := bfLET2(var1,addCARorCDR('CAR,rhs))
    null var2 or EQ(var2,"DOT") =>l1
    if CONSP l1 and ATOM CAR l1 then l1 := cons(l1,nil)
    IDENTP var2 =>
      [:l1,bfLetForm(var2,addCARorCDR('CDR,rhs))]
    l2 := bfLET2(var2,addCARorCDR('CDR,rhs))
    if CONSP l2 and ATOM CAR l2 then l2 := cons(l2,nil)
    APPEND(l1,l2)
  lhs is ['APPEND,var1,var2] =>
    patrev := bfISReverse(var2,var1)
    rev := ['REVERSE,rhs]
    g := INTERN CONCAT('"LETTMP#", STRINGIMAGE $letGenVarCounter)
    $letGenVarCounter := $letGenVarCounter + 1
    l2 := bfLET2(patrev,g)
    if CONSP l2 and ATOM CAR l2 then l2 := cons(l2,nil)
    var1 = "DOT" => [['L%T,g,rev],:l2]
    last l2 is ['L%T, =var1, val1] =>
      [['L%T,g,rev],:REVERSE CDR REVERSE l2,
       bfLetForm(var1,['NREVERSE,val1])]
    [['L%T,g,rev],:l2,bfLetForm(var1,['NREVERSE,var1])]
  lhs is ["EQUAL",var1] =>
    ['COND,[["EQUAL",var1,rhs],var1]]
  bpSpecificErrorHere '"unexpected  LET code is generated in this line"
  REALLYPRETTYPRINT lhs
  bpTrap()

--  -- let the IS code take over from here
--  REALLYPRETTYPRINT lhs
--  isPred :=
--    $inDefIS => bfIS1(rhs,lhs)
--    bfIS(rhs,lhs)
--  REALLYPRETTYPRINT ['COND,[isPred,rhs]]
--  ['COND,[isPred,rhs]]

\start
Date: Mon, 2 Apr 2007 13:52:35 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: structural decomposition

The whole boot/shoe parser was a complete black box delivered whole
by Bill Burge so I don't know the details.

It looks like

['SEQ, :l, ['exit,1,x]] := item

tries to take a lisp s-expression and decompose it to extract
the "l", inner list construct. The axiom SEQ seems to expect
an (exit ....) s-expression as the last expression in the seq.

It may be that the convention changed and SEQ no longer required
the last s-expression to be an exit call but I don't know for sure.
The "1" might have been an error code? The s-expression this expects
seems to look like:

  (exit 1 x)

so maybe it was intended as an error code? If you can find the
runtime implementation of exit that might give you a clue.

You'll often see this kind of code (from SF.NRLIB/code.lsp)

(defun |DFLOAT;manexp (|x| $) (prog .....[snip]....
  (return (seq (exit (cond ((zerop |x| ...[snip]....

\start
Date: Mon, 02 Apr 2007 14:03:09 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: structural decomposition

Quoting Tim Daly:

> The whole boot/shoe parser was a complete black box delivered whole
> by Bill Burge so I don't know the details.

OK.  I assumed you did some editing there; that turns out to be
an erroneous assumption.

>
> It looks like
>
> ['SEQ, :l, ['exit,1,x]] := item
>
> tries to take a lisp s-expression and decompose it to extract
> the "l", inner list construct. The axiom SEQ seems to expect
> an (exit ....) s-expression as the last expression in the seq.

Yes, I understand what the code means, and how it should be
handled by bootsys.  My analysis led me do bfLET2 which
was not doing the right thing because the code that should
handle it was commented out and replaced by bpTrap() -- which
is not OK, as bpTrap() concerns itself only with syntactic
issues.

> It may be that the convention changed and SEQ no longer required
> the last s-expression to be an exit call but I don't know for sure.
> The "1" might have been an error code? The s-expression this expects
> seems to look like:
>
>  (exit 1 x)
>
> so maybe it was intended as an error code? If you can find the
> runtime implementation of exit that might give you a clue.

The problem is not that of exit.  The problem is that of a
literal appearing in the pattern and bfLET2 being confused.
You can see that in the bfLET2 code, or you can test with
something like this:

% cat t.boot && bootsys -batch -eval '(boottran::boottoclc "t.boot")'
foo t ==
   ['BAR, 2, x] := t
   x
ERROR IN LINE 2
   ['BAR, 2, x] := t
...................|
unexpected  LET code is generated in this line
2
ERROR IN LINE 2
   ['BAR, 2, x] := t
...................|
syntax error
ignored from line 2
   ['BAR, 2, x] := t
...|
ignored through line 2
   ['BAR, 2, x] := t
...................|


I've changed bfLET2 to handle allow literals in
the patterns, currently algebra layer 13 is being
built.  I'll report when the build finishes.

\start
Date: 02 Apr 2007 20:09:03 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: structural decomposition

Gabriel Dos Reis writes:

[...]

| I've changed bfLET2 to handle allow literals in
| the patterns, currently algebra layer 13 is being
| built.  I'll report when the build finishes.

It went OK.

-- Gaby
*** src/boot/ChangeLog.build-improvements	(revision 19373)
--- src/boot/ChangeLog.build-improvements	(local)
***************
*** 1,3 ****
--- 1,8 ----
+ 2007-04-02  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* tytree1.boot.pamphlet (bfLET2): Handle literals in patterns.
+ 	Update cached Lisp translation.
+ 
  2007-03-24  Gabriel Dos Reis  Gabriel Dos Reis
  
  	* Makefile.pamphlet: Fix typos.
*** src/boot/tytree1.boot.pamphlet	(revision 19373)
--- src/boot/tytree1.boot.pamphlet	(local)
*************** bfLET2(lhs,rhs) ==
*** 460,476 ****
      [['L%T,g,rev],:l2,bfLetForm(var1,['NREVERSE,var1])]
    lhs is ["EQUAL",var1] =>
      ['COND,[["EQUAL",var1,rhs],var1]]
!   bpSpecificErrorHere '"unexpected  LET code is generated in this line"
!   REALLYPRETTYPRINT lhs
!   bpTrap()
   
- --  -- let the IS code take over from here
- --  REALLYPRETTYPRINT lhs
- --  isPred :=
- --    $inDefIS => bfIS1(rhs,lhs)
- --    bfIS(rhs,lhs)
- --  REALLYPRETTYPRINT ['COND,[isPred,rhs]]
- --  ['COND,[isPred,rhs]]
   
  bfLET(lhs,rhs) ==
    $letGenVarCounter : local := 1
--- 460,477 ----
      [['L%T,g,rev],:l2,bfLetForm(var1,['NREVERSE,var1])]
    lhs is ["EQUAL",var1] =>
      ['COND,[["EQUAL",var1,rhs],var1]]
!   -- The original expression may be one that involves literals as 
!   -- sub-patterns, e.g.
!   --      ['SEQ, :l, ['exit, 1, x]] := item
!   -- We continue the processing as if that expression had been written
!   --      item is ['SEQ, :l, ['exit, 1, x]]
!   -- and generate appropriate codes.
!   --                  -- gdr/2007-04-02.
!   isPred :=
!     $inDefIS => bfIS1(rhs,lhs)
!     bfIS(rhs,lhs)
!   ['COND,[isPred,rhs]]
   
   
  bfLET(lhs,rhs) ==
    $letGenVarCounter : local := 1
*************** bfDs n== if n=0 then '"" else CONCAT('"D
*** 1613,1621 ****
               (|bfCONTAINED| |x| (CDR |y|))))))))
  
  (DEFUN |bfLET2| (|lhs| |rhs|)
!   (PROG (|val1| |ISTMP#3| |g| |rev| |patrev| |l2| |l1| |var2| |var1|
!                 |b| |ISTMP#2| |a| |ISTMP#1|)
!     (DECLARE (SPECIAL |$letGenVarCounter|))
      (RETURN
        (COND
          ((IDENTP |lhs|) (|bfLetForm| |lhs| |rhs|))
--- 1614,1622 ----
               (|bfCONTAINED| |x| (CDR |y|))))))))
  
  (DEFUN |bfLET2| (|lhs| |rhs|)
!   (PROG (|isPred| |val1| |ISTMP#3| |g| |rev| |patrev| |l2| |l1| |var2|
!             |var1| |b| |ISTMP#2| |a| |ISTMP#1|)
!     (DECLARE (SPECIAL |$inDefIS| |$letGenVarCounter|))
      (RETURN
        (COND
          ((IDENTP |lhs|) (|bfLetForm| |lhs| |rhs|))
*************** bfDs n== if n=0 then '"" else CONCAT('"D
*** 1734,1743 ****
           (LIST 'COND (LIST (LIST 'EQUAL |var1| |rhs|) |var1|)))
          (#1#
           (PROGN
-            (|bpSpecificErrorHere|
-                "unexpected  LET code is generated in this line")
             (REALLYPRETTYPRINT |lhs|)
!            (|bpTrap|)))))))
  
  (DEFUN |bfLET| (|lhs| |rhs|)
    (PROG (|$letGenVarCounter|)
--- 1735,1747 ----
           (LIST 'COND (LIST (LIST 'EQUAL |var1| |rhs|) |var1|)))
          (#1#
           (PROGN
             (REALLYPRETTYPRINT |lhs|)
!            (SETQ |isPred|
!                  (COND
!                    (|$inDefIS| (|bfIS1| |rhs| |lhs|))
!                    (#1# (|bfIS| |rhs| |lhs|))))
!            (REALLYPRETTYPRINT (LIST 'COND (LIST |isPred| |rhs|)))
!            (LIST 'COND (LIST |isPred| |rhs|))))))))
  
  (DEFUN |bfLET| (|lhs| |rhs|)
    (PROG (|$letGenVarCounter|)
*** src/interp/ChangeLog.build-improvements	(revision 19373)
--- src/interp/ChangeLog.build-improvements	(local)
***************
*** 1,5 ****
--- 1,18 ----
  2007-04-02  Gabriel Dos Reis  Gabriel Dos Reis
  
+ 	* Makefile.pamphlet (<<applu.clisp>>): Remove.
+ 	(<<hashcode.clisp>>): Likewise.
+ 	(<<interop.clisp>>): Likewise.
+ 	(<<xrun.clisp>>): Likewise.
+ 	(<<wi1.clisp>>): Likewise.
+ 	(<<wi2.clisp>>): Likewise.
+ 	(<<pspad1.clisp>>): Likewise.
+ 	(<<pspad2.clisp>>): Likewise.
+ 	(<<mark.clisp>>): Likewise.
+ 	* Makefile.in: Regenerate.
+ 
+ 2007-04-02  Gabriel Dos Reis  Gabriel Dos Reis
+ 
  	* setvars.boot.pamphlet: Push into package "BOOT".
  	Remove cached Lisp translation.
  	* Makefile.pamphlet (<<newaux.lisp (OUT from MID)>>): Remove
*** src/interp/Makefile.in	(revision 19373)
--- src/interp/Makefile.in	(local)
*************** ${AUTO}/apply.$(FASLEXT): apply.$(FASLEX
*** 437,450 ****
  	@ echo 9 making ${AUTO}/apply.$(FASLEXT) from apply.$(FASLEXT)
  	@ cp apply.$(FASLEXT) ${AUTO}
  
- apply.clisp: apply.boot
- 	@ echo 11 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "apply.boot"))' | ${DEPSYS} ; \
- 	   else \
- 	   echo '(progn (boottran::boottocl "apply.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
-            fi ;
- 
  
  as.clisp: as.boot
  	@ echo 417 making $@ from $<
--- 437,442 ----
*************** g-timer.clisp: g-timer.boot
*** 829,843 ****
  	  fi
  
  
- hashcode.clisp: hashcode.boot
- 	@ echo 584 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "hashcode.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "hashcode.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- 
  ${AUTO}/htcheck.$(FASLEXT): htcheck.$(FASLEXT)
  	@ echo 453 making ${AUTO}/htcheck.$(FASLEXT) from htcheck.$(FASLEXT)
  	@ cp htcheck.$(FASLEXT) ${AUTO}
--- 821,826 ----
*************** i-intern.clisp: i-intern.boot
*** 966,980 ****
  	  fi
  
  
- interop.clisp: interop.boot
- 	@ echo 587 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "interop.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "interop.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- 
  i-map.clisp: i-map.boot
  	@ echo 304 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 949,954 ----
*************** lisplib.clisp: lisplib.boot
*** 1085,1098 ****
  ${AUTO}/mark.$(FASLEXT): mark.$(FASLEXT)
  	@ cp $< $@
  
- mark.clisp: mark.boot
- 	@ echo 605 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "mark.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "mark.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  
  match.clisp: match.boot
  	@ echo 339 making $@ from $<
--- 1059,1064 ----
*************** profile.clisp: profile.boot
*** 1473,1499 ****
  ${AUTO}/pspad1.$(FASLEXT):  pspad1.$(FASLEXT)
  	@ cp $< $@
  
- pspad1.clisp: pspad1.boot
- 	@ echo 599 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "pspad1.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "pspad1.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- 
  ${AUTO}/pspad2.$(FASLEXT):  pspad2.$(FASLEXT)
  	@ cp $< $@
  
- pspad2.clisp: pspad2.boot
- 	@ echo 602 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "pspad2.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "pspad2.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi 
- 
- 
  record.clisp: record.boot
  	@ echo 447 making $@ $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1439,1447 ----
*************** trace.clisp: trace.boot
*** 1591,1614 ****
  
  ${AUTO}/wi1.$(FASLEXT): wi1.$(FASLEXT) 
  	@ cp $< $@
- wi1.clisp: wi1.boot
- 	@ echo 593 making $@ from $<
- 	@ echo '(progn (boottran::boottocl "wi1.boot"))' | ${DEPSYS}
  
  ${AUTO}/wi2.$(FASLEXT):  wi2.$(FASLEXT)
  	@ cp $< $@
- wi2.clisp: wi2.boot
- 	@ echo 596 making $@ from $<
- 	@ echo '(progn (boottran::boottocl "wi2.boot"))' | ${DEPSYS}
- 
- xrun.clisp: xrun.boot
- 	@ echo 590 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "xrun.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "xrun.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  
  ${AUTO}/xruncomp.$(FASLEXT): xruncomp.$(FASLEXT)
  	@ echo 457 making ${AUTO}/xruncomp.$(FASLEXT) from xruncomp.$(FASLEXT)
--- 1539,1547 ----
*** src/interp/Makefile.pamphlet	(revision 19373)
--- src/interp/Makefile.pamphlet	(local)
*************** ${AUTO}/apply.$(FASLEXT): apply.$(FASLEX
*** 1169,1184 ****
  	@ cp apply.$(FASLEXT) ${AUTO}
  
  @
- <<apply.clisp>>=
- apply.clisp: apply.boot
- 	@ echo 11 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "apply.boot"))' | ${DEPSYS} ; \
- 	   else \
- 	   echo '(progn (boottran::boottocl "apply.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
-            fi ;
- 
- @
  
  \subsection{bootlex.lisp \cite{9}}
  
--- 1169,1174 ----
*************** ${AUTO}/showimp.$(FASLEXT): showimp.$(FA
*** 2875,2919 ****
  
  @
  
- \subsection{hashcode.boot}
- 
- <<hashcode.clisp>>=
- hashcode.clisp: hashcode.boot
- 	@ echo 584 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "hashcode.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "hashcode.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
- 
- \subsection{interop.boot}
- 
- <<interop.clisp>>=
- interop.clisp: interop.boot
- 	@ echo 587 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "interop.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "interop.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
- 
- \subsection{xrun.boot}
- 
- <<xrun.clisp>>=
- xrun.clisp: xrun.boot
- 	@ echo 590 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "xrun.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "xrun.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
- 
  \subsection{wi1.boot}
  
  translate files
--- 2865,2870 ----
*************** ${AUTO}/wi1.$(FASLEXT): wi1.$(FASLEXT) 
*** 2922,2961 ****
  	@ cp $< $@
  @
  
- <<wi1.clisp>>=
- wi1.clisp: wi1.boot
- 	@ echo 593 making $@ from $<
- 	@ echo '(progn (boottran::boottocl "wi1.boot"))' | ${DEPSYS}
- @
- 
  \subsection{wi2.boot}
  
  <<wi2.o (AUTO from MID)>>=
  ${AUTO}/wi2.$(FASLEXT):  wi2.$(FASLEXT)
  	@ cp $< $@
  @
- <<wi2.clisp>>=
- wi2.clisp: wi2.boot
- 	@ echo 596 making $@ from $<
- 	@ echo '(progn (boottran::boottocl "wi2.boot"))' | ${DEPSYS}
- @
  
  \subsection{pspad1.boot}
  
  <<pspad1.o (AUTO from MID)>>=
  ${AUTO}/pspad1.$(FASLEXT):  pspad1.$(FASLEXT)
  	@ cp $< $@
- 
- @
- <<pspad1.clisp>>=
- pspad1.clisp: pspad1.boot
- 	@ echo 599 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "pspad1.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "pspad1.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  @
  
  \subsection{pspad2.boot}
--- 2873,2890 ----
*************** pspad1.clisp: pspad1.boot
*** 2963,2979 ****
  <<pspad2.o (AUTO from MID)>>=
  ${AUTO}/pspad2.$(FASLEXT):  pspad2.$(FASLEXT)
  	@ cp $< $@
- 
- @
- <<pspad2.clisp>>=
- pspad2.clisp: pspad2.boot
- 	@ echo 602 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "pspad2.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "pspad2.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi 
- 
  @
  
  \subsection{mark.boot}
--- 2892,2897 ----
*************** ${AUTO}/mark.$(FASLEXT): mark.$(FASLEXT)
*** 2983,2998 ****
  	@ cp $< $@
  
  @
- <<mark.clisp>>=
- mark.clisp: mark.boot
- 	@ echo 605 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "mark.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "mark.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  
  \section{The databases}
  
--- 2901,2906 ----
*************** distclean-local: clean-local
*** 3096,3102 ****
  <<databases>>
  
  <<apply.o (AUTO from OUT)>>
- <<apply.clisp>>
  
  <<as.clisp>>
  
--- 3004,3009 ----
*************** distclean-local: clean-local
*** 3189,3196 ****
  
  <<g-timer.clisp>>
  
- <<hashcode.clisp>>
- 
  <<htcheck.o (AUTO from OUT)>>
  <<htcheck.clisp>>
  
--- 3096,3101 ----
*************** distclean-local: clean-local
*** 3221,3228 ****
  
  <<i-intern.clisp>>
  
- <<interop.clisp>>
- 
  <<i-map.clisp>>
  
  <<info.o (AUTO from OUT)>>
--- 3126,3131 ----
*************** distclean-local: clean-local
*** 3248,3254 ****
  <<lisplib.clisp>>
  
  <<mark.o (AUTO from MID)>>
- <<mark.clisp>>
  
  <<match.clisp>>
  
--- 3151,3156 ----
*************** distclean-local: clean-local
*** 3341,3350 ****
  <<profile.clisp>>
  
  <<pspad1.o (AUTO from MID)>>
- <<pspad1.clisp>>
  
  <<pspad2.o (AUTO from MID)>>
- <<pspad2.clisp>>
  
  <<record.clisp>>
  
--- 3243,3250 ----
*************** distclean-local: clean-local
*** 3370,3381 ****
  <<warm.data.stanza>>
  
  <<wi1.o (AUTO from MID)>>
- <<wi1.clisp>>
  
  <<wi2.o (AUTO from MID)>>
- <<wi2.clisp>>
- 
- <<xrun.clisp>>
  
  <<xruncomp.o (AUTO from OUT)>>
  <<xruncomp.clisp>>
--- 3270,3277 ----
*** src/interp/apply.boot.pamphlet	(revision 19373)
--- src/interp/apply.boot.pamphlet	(local)
***************
*** 46,51 ****
--- 46,53 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  oldCompilerAutoloadOnceTrigger() == nil
  
  compAtomWithModemap(x,m,e,v) ==
*** src/interp/hashcode.boot.pamphlet	(revision 19373)
--- src/interp/hashcode.boot.pamphlet	(local)
***************
*** 46,51 ****
--- 46,53 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  -- Type hasher for old compiler style type names which produces a hash code
  -- compatible with the asharp compiler.  Takes a hard error if the type
  -- is parameterized, but has no constructor modemap.
*** src/interp/interop.boot.pamphlet	(revision 19373)
--- src/interp/interop.boot.pamphlet	(local)
***************
*** 46,51 ****
--- 46,53 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  -- note domainObjects are now (dispatchVector hashCode . domainVector)
  -- lazy oldAxiomDomainObjects are (dispatchVector hashCode  (Call form) . backptr), 
  -- pre oldAxiomCategory is (dispatchVector . (cat form))
*** src/interp/mark.boot.pamphlet	(revision 19373)
--- src/interp/mark.boot.pamphlet	(local)
*************** Entire constructor is then assembled and
*** 57,62 ****
--- 57,64 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  REMPROP("and",'parseTran)
  REMPROP("or",'parseTran)
  REMPROP("not",'parseTran)
*** src/interp/pspad1.boot.pamphlet	(revision 19373)
--- src/interp/pspad1.boot.pamphlet	(local)
***************
*** 46,51 ****
--- 46,53 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  $escapeWords := ["always", "assert", "but", "define", 
    "delay", "do", "except", "export", "extend", "fix", "fluid",
      "from", "generate", "goto", "import", "inline", "never", "select",
*** src/interp/pspad2.boot.pamphlet	(revision 19373)
--- src/interp/pspad2.boot.pamphlet	(local)
***************
*** 46,51 ****
--- 46,53 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  --======================================================================
  --                Constructor Transformation Functions
  --======================================================================
*************** ident2PrintImage s ==
*** 582,588 ****
    u:= SUFFIX(s.(0),u)
    for i in 1..MAXINDEX s repeat
      if not (DIGITP s.i or ALPHA_-CHAR_-P s.i or ((c := s.i) = char '?) 
!       or (c = char '!)) then SUFFIX('__,u)
      u:= SUFFIX(s.i,u)
    INTERN u
   
--- 584,590 ----
    u:= SUFFIX(s.(0),u)
    for i in 1..MAXINDEX s repeat
      if not (DIGITP s.i or ALPHA_-CHAR_-P s.i or ((c := s.i) = char '?) 
!       or (c = char '_!)) then SUFFIX('__,u)
      u:= SUFFIX(s.i,u)
    INTERN u
   
*** src/interp/wi1.boot.pamphlet	(revision 19373)
--- src/interp/wi1.boot.pamphlet	(local)
***************
*** 46,51 ****
--- 46,53 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  -- !! do not delete the next function !
  
  spad2AsTranslatorAutoloadOnceTrigger() == nil
*** src/interp/wi2.boot.pamphlet	(revision 19373)
--- src/interp/wi2.boot.pamphlet	(local)
***************
*** 46,51 ****
--- 46,53 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  compDefineFunctor1(df, m,$e,$prefix,$formalArgList) ==
      ['DEF,form,signature,$functorSpecialCases,body] := df
      signature := markKillAll signature
*** src/interp/xrun.boot.pamphlet	(revision 19373)
--- src/interp/xrun.boot.pamphlet	(local)
***************
*** 46,51 ****
--- 46,53 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  $noSubsumption:=true
  --$MERGELIB := nil
  ------- from nrunopt.boot -----------

\start
Date: Mon, 2 Apr 2007 21:24:28 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: structural decomposition

On April 2, 2007 9:09 PM Gabriel Dos Reis wrote:
> 
> | I've changed bfLET2 to handle allow literals in
> | the patterns, currently algebra layer 13 is being
> | built.  I'll report when the build finishes.
> 
> It went OK.
> 
> ...

Gaby,

This is just a quick note to say that I REALLY appreciate the
work that you are continuing to do with Boot and the Axiom
build machinery in general. I think these improvements are
very important to the long term stability and maintainablity
of the system.

\start
Date: Mon, 02 Apr 2007 20:32:07 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: structural decomposition

Quoting Bill Page:

> On April 2, 2007 9:09 PM Gabriel Dos Reis wrote:
>>
>> | I've changed bfLET2 to handle allow literals in
>> | the patterns, currently algebra layer 13 is being
>> | built.  I'll report when the build finishes.
>>
>> It went OK.
>>
>> ...
>
> Gaby,
>
> This is just a quick note to say that I REALLY appreciate the
> work that you are continuing to do with Boot and the Axiom
> build machinery in general. I think these improvements are
> very important to the long term stability and maintainablity
> of the system.
>
> Thank you!

Thanks for the kind words.  I still need to put all the documentation
together.  So what I've been doing lazily is to put all my notes
in a sort of doodle pad file; I hope to clean it a bit and make
it available so that others can help improve it.

\start
Date: Mon, 2 Apr 2007 19:04:43 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis
Subject: re: structural decomposition

--- Bill Page wrote:

> Gaby,
> 
> This is just a quick note to say that I REALLY appreciate the
> work that you are continuing to do with Boot and the Axiom
> build machinery in general. I think these improvements are
> very important to the long term stability and maintainablity
> of the system.
> 
> Thank you!

I'd like to second that thank you!  Being able to target sbcl as a
delivery platform would open up a lot of possibilities in terms of
interaction with other Lisp libraries.

Gaby, does this result mean that the Algebra code up through layer 13
can be successfully built by shoe/new boot without needing the old boot
at all?

\start
Date: Mon, 02 Apr 2007 21:15:39 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: structural decomposition

Quoting Cliff Yapp:

> Gaby, does this result mean that the Algebra code up through layer 13
> can be successfully built by shoe/new boot without needing the old boot
> at all?

sorry I was being unclear.  What I meant was that at the time I sent the
message, I modified bfLET2 as I finally committed, and I had several
other interpsys Boot files translated by shoe and the result was strong
enough to survive the build till algebra layer 13.
We still need the old boot translator to translate quite a few other
interpsys Boot files.
I would like to finish that conversion before getting back to committing
the work that has depsys buildable with CLISP (and SBCL).

Then, we may consider what we do with algebra files -- but then, it will
be summer and everybody will be on vacation :-)

\start
Date: 02 Apr 2007 22:26:43 -0500
From: Gabriel Dos Reis
To: list
Subject: Obfuscated Boot Code Contest

It is generally admited that in Boot (whether old or new) an
identifier written in all uppercase is passed unmodified in the
generated Lisp code (except for T).  Right?

Well, Old Boot says "Wrong!".  Some of the all-uppercase identifiers
are renamed into case-sensitive uppercase, or renamed to some
something else.  Here is a short list I have:

  ASSOC        --> |assoc|
  DELETE       --> |delete|
  GET          --> GETL
  INTERSECTION --> |intersection|
  LAST         --> |last|
  MEMBER       --> |member|
  RASSOC       --> |rassoc|
  READ         --> VMREAD
  READ-LINE    --> |read-line|
  REDUCE       --> SPADREDUCE
  REMOVE       --> |remove

\start
Date: 02 Apr 2007 22:32:37 -0500
From: Gabriel Dos Reis
To: list
Subject: Re: Obfuscated Boot Code Contest

Gabriel Dos Reis writes:

| It is generally admited that in Boot (whether old or new) an
| identifier written in all uppercase is passed unmodified in the
| generated Lisp code (except for T).  Right?
| 
| Well, Old Boot says "Wrong!".  Some of the all-uppercase identifiers
| are renamed into case-sensitive uppercase, or renamed to some
| something else.  Here is a short list I have:
| 
|   ASSOC        --> |assoc|
|   DELETE       --> |delete|
|   GET          --> GETL
|   INTERSECTION --> |intersection|
|   LAST         --> |last|
|   MEMBER       --> |member|
|   RASSOC       --> |rassoc|
|   READ         --> VMREAD
|   READ-LINE    --> |read-line|
|   REDUCE       --> SPADREDUCE
|   REMOVE       --> |remove

I forgot:

    UNION  --> |union|

\start
Date: Tue, 03 Apr 2007 15:59:58 +0200
From: Christian Aistleitner
To: Ralf Hemmecke
Subject: Re: [Aldor-l] kTuple wish

Hello,

On Thu, 29 Mar 2007 02:03:25 +0200, Ralf Hemmecke wro=
te:

> So I would rather need something like
> "Cross", but I cannot even ask about the number of arguments of Cross.

one can easily teach Aldor about the size of a Cross with the help of  
extend. Then you can ask a Cross about the number of elements.
I already discussed the details with Ralf via private mail, so I am just  
stating it here for the record. If anybody else is interested in this, I  
will share some code.


> ---BEGIN aaa.as
> #include "aldor"
> I ==> MachineInteger;
> S(T: PrimitiveType): PrimitiveType == I;
> main(): () == {
> 	A ==> S Integer;
> 	B ==> S String;
> 	a: A := (0$I) pretend A; -- I need some value ...
> 	b: B := (1$I) pretend B; -- forgive the "pretend" ...
> 	equal?: Boolean := a = b;
> }
> main();
> ---END aaa.as
>
> It currently dose not compile (Aldor 1.0.3):

I am not too sure whether it should compile.

First of all, I think notation is misleading here. The "==" in

> S(T: PrimitiveType): PrimitiveType == I;

does not necessary mean that the function S maps to the same I every time.  
This is somehow the synopsis, now for the details.
 From my point of view, the above definition of S is a shorthand notation  
for

   S: PrimitiveType -> PrimitiveType == ( T: PrimitiveType ): PrimitiveType  
+-> I;

. (I quickly wanted to check the AUG on this concern, only to find out  
that I cannot find my rewrite suggestion, but only Ralf's way (page 61) of  
writing it. Nevertheless, I thoroughly believe, that my kind of writing it  
is the way the compiler looks at it, and Ralf's way is just a short-hand  
notation.)
Using this rewritten definition, it is more obvious, what the "==" refers  
to. It definitely denotes that the function is constant, not the result.  
But you did not claim otherwise.

Within the AUG, you'll find that typically only the left-hand side of the  
== is seen at certain stages of compilation. So lets omit the righthand  
part of S's definition:

   S: PrimitiveType -> PrimitiveType ==

Now it is indeed hard to see that

> 	A ==> S Integer;
> 	B ==> S String;
> 	a: A := (0$I) pretend A; -- I need some value ...
> 	b: B := (1$I) pretend B; -- forgive the "pretend" ...
> 	equal?: Boolean := a = b;

should compile, there is no obvious reason (S Integer) and (S String)  
should evaluate to the same PrimitiveType.

Having seen this from this more abstract point of view, let's investigate  
the right-hand side of S's definition

   ( T: PrimitiveType ): PrimitiveType +-> I;

. Why should this functional evaluate to the same PrimitiveType again and  
again (And this condition would have to be satisfied before allowing the  
compiler to somehow compile above code)?
 From a previous discussion, we learned that in Aldor functions typically  
are not functional. The exception are expressions in type context. "S  
Integer" and "S String" are in type context in the above piece of code.  
Nevertheless, type context does not resolve the problem, because it  
basically tells us that the types of
   c: S Integer
and
   d: S Integer
match, not that the type of a and b match. Type context allows to compile  
the line

> 	a: A := (0$I) pretend A;

as otherwise, S would be evaluated twice at Integer.
As the exception of non-functionality does not help or apply to the  
problem. S has to be evaluated twice--once for Integer and once for  
String. For each of the evaluations (which happen at run-time from my  
point of view), the function S happens to return the same value. This  
observation can only be made at run time and not at compile time, as the  
"I" may be arbitrary code.

Your code is the rather (seldom case) where the value (I) is hidden just  
to get more structure (S). One could argue that Aldor should treat this  
case properly.
However, only slight variations of your code (e.g.:

   S(T: PrimitiveType): PrimitiveType == Fraction I;

) have a different semantics. For such an S (with the above macros),

> 	a: A := (0$I) pretend A;

should work (type context of S String), but

> 	a: A := (0$I) pretend A;
> 	b: B := (1$I) pretend B;
> 	equal?: Boolean := a = b;

_has_ to fail. As Fraction Integer is not in type context, it _should_  
give _different_ instances of fractions over the domain MachineInteger.
This was just to show that your code is really rather the special case.  
Nevertheless, I see that you want and need the compiler to compile

> 	equal?: Boolean := a = b;

in your setting. The first line of your message was

> The following text describes a weakness of the Aldor language.

so we both agree that this it not a bug in the compiler (sigh), but rather  
you need something Aldor has not been designed to do.

\start
Date: Tue, 03 Apr 2007 18:19:11 +0200
From: Christian Aistleitner
To: Ralf Hemmecke, Martin Rubey
Subject: re: new problem compiling wh-sandbox

Hello,

> It seems however not so totally trivial to adapt AldorUnit for Axiom  
> since Axiom does not have exception handling. And there are some more  
> details which Christian could report about.

yes, there are indeed several problems and after discussing some of them  
with Martin, he said he'll have a look. So not all issues are resolved yet  
and as it is not a top priority issue for myself now, I assume that some  
time will pass until there is some "AxiomUnit" from me or Martin.

Writing tests like

http://lists.nongnu.org/archive/html/axiom-developer/2007-04/msg00030.html

basically works. But you don't get too much help from such a framework  
when resolving issues. For straightforward or obvious errors in code, such  
test might do. However, I assume you'll soon reach a point where you  
cannot test what you intend to test--because of the limitations imposed by  
your approach.
But don't get me wrong. I like every step towards test driven development.  
Be it some kind to specify tests or a full-blown testing framework.

In any case, I got used to JUnit and modelled AldorUnit after it. Since  
Axiom and Aldor are rather closely connected I think both sides would  
profit from using a common syntax to denote tests.

For example the Aldor-combinat project compiles to Aldor and Axiom. I  
suggest it would be of great value to them to be able to reuse their tests  
for the Axiom testing machinery.
I do not know Axiom too well. So can you point me to a document I can  
read, so I get the where your testing machinery is heading to? Afterwards  
it would certainly be good to discuss AldorUnit tests in Axiom and Axiom  
tests in Aldor.

\start
Date: Tue, 3 Apr 2007 16:18:01 -0500
From: Tim Daly
To: Christian Aistleitner
Subject: aldorunit, junit, axiom testing

Axiom test plans are evolving based on need but with an eye
to longer term plans to leverage the effort. I'll try to 
cover some of my thoughts on the subject here.

In the gold and prior releases the testing was based on the 
input files and detailed review of the console logs, as well
as comparisons of intermediate files after each change. This
is very time consuming and clearly I must have missed a bug
or two since the algebra in silver seems broken somehow.

Rather than releasing a full merged gold/BI/WH, which is what
I was attempting I've backed off and decided to build up the
testing harnesses so I can hopefully catch the bug automatically.

There are various levels of testing and I'm working most specifically
on regression testing since that's what this latest release requires.
I'll lay out some thoughts here but these are not firmly fixed, just
some musings about testing and how it matches various subgoals I have.



REGRESSION TESTING...How it works

I have built a regression test harness that uses md5sum as a tool
to show me what might have changed in the build due to a change in
the source. Its only purpose is to focus attention on changes and
is not useful or informative in any other way.

I'm also in the process of rewriting the input files into a standard
form so they can be used for regression testing. Since regression 
testing is only trying to find things that differ but not find 
bugs a simple compare mechanism is sufficient. Thus I wrote a
lisp function called "regress" that will compare the results.
(diff is insufficient since we need to ignore certain things.)

The input file rewrite involves a couple steps. First I run the
input file in the "base case axiom" (this is the comparison
standard regardless of bugs). Running these input files gives 
me "stanzas" written to the output file. Thus if "foo.input"
contains the line:

2+3

and I do

  echo ")read foo.input" | axiom | >foo.output

I'll get foo.output containing:

2+3

 (1) 5
                             Type: PositiveInteger

Next I can use this for regression by rewriting the foo.output
file into a foo.input.pamphlet file. This new pamphlet file contains
the lines:

--S 1 of 1
2+3
--R
--R (1) 5
--R                             Type: PositiveInteger
--E 1

and what we see here is an "input file" with the input line
starting with "--S" and ending with the first "--R". The
expected results are prefixed by "--R", and the test ends
with the prefixed line "--E".

Running this input file again will now give:

--S 1 of 1
2+3

 (1) 5
                             Type: PositiveInteger
--R
--R (1) 5
--R                             Type: PositiveInteger
--E 1

and I then do:

  echo ')lisp (regress "foo.output")" | axiom >foo.regress

which gives:

regression result passed 1 of 1 file foo

or 

regression result FAILED 1 of 1 file foo

depending on the result of the compare.

REGRESSION TESTING...What we gain

The regression tests show where the algebra that is executed
might fail from system to system. I've already uncovered a
minor library difference between redhat and fedora systems 
that manages to poke its head into the axiom output.

I'm working my way back thru the gold versions in the arch archive 
to find where things might have broken.

Since the regression tests are in standard pamphlet format they
contain explanations in the resulting .dvi files.

Since the regression tests are in standard input file format
and they contain the results, we have an executable file format
that also documents the expected results. This can be extended
in many ways in the future to give us better coverage.

There are also a lot of interesting examples of algebra in
these files that should be better explained. Hopefully we'll
go back and expand them.





UNIT TESTING...How it might work

In the recent past I posted a file called ffrac.spad. I have various
planned usage for this file as a test case for new facilities in 
Axiom, including experiments in "drag-and-drop", "unit testing",
"cohen algebra", and some tutorial work in how to program.

You can see that I've "decorated" the functions with example
axiom input lines. These show the common and expected uses for
these functions. They will eventually evolve into unit tests.

The first constraint I have for unit tests is that they should
help explain and document the domain. It is very important that
we capture the developers insights into the code via the testing
strategy. What are reasonable input forms for the domain? What
are boundary tests? How can we coerce/convert to this domain or
from this domain to others? 

The unit testing might evolve along the lines of the regression
testing, for three reasons. First, the regression tests contain
the results so they document the expected response "inline".
Thus you can read the file and see what the results should look like.

Second, having a compatible format between unit tests and regression
tests means that the unit tests can be automatically used for regression.

Third, since both use the pamphlet file format we can evolve the 
"standard" (hah) for pamphlet files so that unit/regression test
chunks follow a common pattern. This would allow us to use the same
technique that Bill Page --foisted, ahem-- pioneered for selecting
algebra files automatically. :-)

If we "standardize" the unit/regresion testing then we can leverage
this for "drag-and-drop" extensions of the algebra, testing, and
documentation machinery.





ALDORUNIT? ...

It is unclear how AldorUnit will fit in to testing in the short
term. It depends in part on "next weeks announcement" from Aldor.
If we get a free Aldor and there is a push to write/extend/rewrite
the Axiom domains in Aldor then clearly this is the likely future
path.

Frankly I haven't spent sufficient time considering this in
detail because I'm trying to "get this release done". I managed
to let the release mechanism get out of control and that has
clearly cost me dearly.





THE FUTURE PLANS? .... guesses/musings/random nonsense

ZERO TESTS? ... the harder problem

Ideally unit tests would be written so axiom could verify
the results. Some tests might be written in the spirit of:

-- testing plus/minus inversion
a:=3+2
b:=7-2
((a-b)==0)::Boolean

but this requires a deeper knowledge of the various domains.
Yet even knowing that the expressions are equivalent and
having domain expertise doesn't guarantee that you can wrestle
axiom into admitting zero equivalence.




PAMPHLET -> LATEX subgoal

I'd like pamphlet files to be pure latex files. That way we
don't have to "preprocess" the files to latex them and we can
submit pamphlet files as standard tex files to conferences.

One of my long-term goals is to have an open literature in computer
algebra that includes the source code for the paper within the 
paper in a literate style. So there is a push to eliminate any
non-latex format. In the long term that implies that the noweb
syntax has to go away.

I've already written a preliminary version of noweb-style chunks
in latex so at some point the plan is to change the chunk naming
mechanism to be pure, standard latex (eg:
<<chunk name>>= becomes \begin{chunk}{chunk name}
@               becomes \end{chunk}
<<chunk name>>  becomes \use{chunk name}
and I hope to introduce this when time permits. Unfortunately
getting this release out has not been a simple job. Who knew? 

TESTING IMPLICATIONS

Thus one possible idea is to just use a standard chunkname for
the test/regress stanzas and have them be verbatim blocks. A
more interesting idea is to introduce a new environment that
would enable the input and output to be captured for the testing
purposes. This would just be an extension of the above idea.
Something like:

\begin{testchunk}{1}
2+3
\result{testchunk}{1}

 (1) 5
                             Type: PositiveInteger
\end{testchunk}{1}

This could be reformed to either print format or extraction format
for test. Thus the unit test/regression test machinery has to fit 
smoothly into the rest of the pamphlet machinery.

In fact, if this subgoal is met there will be no distinction 
between latex and pamphlet files, thus reducing the complexity
of axiom significantly.

Alternatively we could extend noweb to "know" about the testing
chunk format so that it will automatically prefix the chunk lines
with "--S", "--R", "--E", etc. when extracting for test purposes.
This would be reasonable to do in the short term and involve less
controversy.




PAMPHLET -> DRAG-and-DROP subgoal

I want people to be able to fire up axiom (likely using Doyen at
a conference) and be able to drag-and-drop a literate paper from
the conference onto a running axiom. This should:

  1) unpack the algebra
  2) unit test the algebra
  3) unpack the paper
  4) add the paper to the documentation in a deep way
     including updating the front end
  5) add the algebra to the system

A person should be able to execute the paper. If the paper
contains something like a "speed comparison" the person 
should be able to execute the paper and see his own results
for his system reflected in the paper.

Thus the unit test/regression test machinery has to fit 
smoothly into the rest of the pamphlet machinery.

TESTING IMPLICATIONS

The test/regressions stanzas have to fit fluidly into the whole
pamphlet file mechanism and be easy to recognize and extract.
Plus they must be "self-verifying" so that the results obtained
can be checked against the results expected. 

And we'd like the test cases to also serve as documentation of
correct use of the domain as well as its limits and assumptions.



COMPUTER ALGEBRA TEST SUITE (CATS)

I've mused about the long term goal of constructing a CATS
standard that could be used across all of the existing algebra
platforms. Such a standard would give credibility to the results
of existing systems and leverage the mathematical expertise toward
verifying results.

Consider a CATS document that explains some algorithm, such
as a GCD algorithm.

A CATS document would start with some area of computational 
mathematics, giving a mathematical explanation, a few math
problems that cover the area in question as well as boundary
cases. The document would then have the algorithm within it.
Ideally we'd be able to drag-and-drop this document and run
the tests. 

There are (at least) two challenges with this level of testing.

First we have the issue that the mathematics might cross 
several axiom domains. This implies that the testing is not
unit testing.

Second, we have the issue that the algorithm might cross
domains or have special cases in subdomains, etc. This would
mean that we'd have to make sure that the CATS examples 
include the special cases.


TESTING IMPLICATIONS

Ultimately we'd like the CATS test cases to "just run".
How they get structured within the CATS documentation, how
we capture the axiom output, and how we resolve the axiom
results with the CATS results are all things to think about.


Tim 
"There is no such thing as a simple job" 

\start
Date: Wed, 04 Apr 2007 06:58:46 -0400
From: Cliff Yapp
To: Tim Daly
Subject: Re: conferences

Tim Daly wrote:
> I plan to attend ECCAD in Delaware and ISSAC in Canada. --Tim

Tim, isn't ECCAD in MD this year?

http://eccad07.washcoll.edu/

Or do I have the wrong conference?

\start
Date: Wed, 4 Apr 2007 13:34:14 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Obfuscated Boot Code Contest
Cc: list

> 
> 
> It is generally admited that in Boot (whether old or new) an
> identifier written in all uppercase is passed unmodified in the
> generated Lisp code (except for T).  Right?
> 
> Well, Old Boot says "Wrong!".  Some of the all-uppercase identifiers
> are renamed into case-sensitive uppercase, or renamed to some
> something else.  Here is a short list I have:
> 
>   ASSOC        --> |assoc|
>   DELETE       --> |delete|
>   GET          --> GETL
>   INTERSECTION --> |intersection|
>   LAST         --> |last|
>   MEMBER       --> |member|
>   RASSOC       --> |rassoc|
>   READ         --> VMREAD
>   READ-LINE    --> |read-line|
>   REDUCE       --> SPADREDUCE
>   REMOVE       --> |remove
> 

I would prefer to eliminate all renaming at boot/shoe level.  Instead,
I would just define needed functions at Lisp level (partially in the
style of unlisp.lisp.pamphlet, but also using compiler macros for
efficiency).  Also, I consider using all-lowercase Lisp (making
a package "common-lisp" beeing a lowercase version of "COMMON-LISP",
and setting *readtable-case* to preserve).

\start
Date: Wed, 04 Apr 2007 08:02:52 -0400
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: Obfuscated Boot Code Contest
Cc: list, Gabriel Dos Reis

Waldek Hebisch wrote:

> I would prefer to eliminate all renaming at boot/shoe level.  Instead,
> I would just define needed functions at Lisp level (partially in the
> style of unlisp.lisp.pamphlet, but also using compiler macros for
> efficiency).  Also, I consider using all-lowercase Lisp (making
> a package "common-lisp" beeing a lowercase version of "COMMON-LISP",
> and setting *readtable-case* to preserve).

The latter sounds like what Maxima went through with the Great Source
Downcasing a while back.  The emails on the Maxima list pertaining to
that might worth looking at.

\start
Date: Wed, 4 Apr 2007 17:14:50 +0200
From: Juergen Weiss
To: Gabriel Dos Reis,
Subject: RE: Obfuscated Boot Code Contest

The replacements GET --> GETL, READ --> VMREAD indicate, that
they were introduced to circumvent different semantics of
GET and READ between VMLISP and COMMON LISP. Not clear
about the others.

Regards

Juergen Weiss

Juergen Weiss	  | Universitaet Mainz, Zentrum fuer Datenverarbeitung,
Juergen Weiss| 55099 Mainz, Tel: +49(6131)39-26361, FAX:
+49(6131)39-26407


> -----Original Message-----
> From: axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org
>  On Behalf Of Gabriel Dos Reis
> Sent: Tuesday, April 03, 2007 5:33 AM
> To: list
> Subject: Re: Obfuscated Boot Code Contest
>
> Gabriel Dos Reis writes:
>
> | It is generally admited that in Boot (whether old or new) an
> | identifier written in all uppercase is passed unmodified in the
> | generated Lisp code (except for T).  Right?
> |
> | Well, Old Boot says "Wrong!".  Some of the all-uppercase identifiers
> | are renamed into case-sensitive uppercase, or renamed to some
> | something else.  Here is a short list I have:
> |
> |   ASSOC        --> |assoc|
> |   DELETE       --> |delete|
> |   GET          --> GETL
> |   INTERSECTION --> |intersection|
> |   LAST         --> |last|
> |   MEMBER       --> |member|
> |   RASSOC       --> |rassoc|
> |   READ         --> VMREAD
> |   READ-LINE    --> |read-line|
> |   REDUCE       --> SPADREDUCE
> |   REMOVE       --> |remove
>
> I forgot:
>
>     UNION  --> |union|

\start
Date: Wed, 04 Apr 2007 12:58:21 -0500
From: Gabriel Dos Reis
To: Juergen Weiss
Subject: RE: Obfuscated Boot Code Contest

Quoting Juergen Weiss:

> The replacements GET --> GETL, READ --> VMREAD indicate, that
> they were introduced to circumvent different semantics of
> GET and READ between VMLISP and COMMON LISP. Not clear
> about the others.

Many thanks.  I'll document that when I'm back to the renaming issue.

\start
Date: Wed, 4 Apr 2007 21:41:08 +0200
From: Juergen Weiss
To: Gabriel Dos Reis
Subject: RE: Obfuscated Boot Code Contest

I have just had a look at the sources.

The redefinitions of
ASSOC, DELETE, INTERSECTION, MEMBER, RASSOC, REMOVE, UNION
seem to have the same source (all defined in vmlisp.lisp).
COMMON LISP has different semantics than VMLISP
(in this case with regard to equality in those functions).

> -----Original Message-----
>
> Quoting Juergen Weiss:
>
> > The replacements GET --> GETL, READ --> VMREAD indicate, that=20
> > they were introduced to circumvent different semantics of
> > GET and READ between VMLISP and COMMON LISP. Not clear=20
> > about the others.
>
> Many thanks.  I'll document that when I'm back to the renaming issue.

\start
Date: Wed, 4 Apr 2007 17:24:02 -0400
From: Bill Page
To: list
Subject: Set Any and SXHASH

In http://wiki.axiom-developer.org/347BugInMapSet

'oklhazi' reported that "map confuses sets" and gives
the example

  A:=set [-2,-1,0]
  B:=set [0,1,4]
  C:=map(x +-> x^2,A)
  test(C=B)

where the map operation produces a "Set" C with the same
elements as B but which is not equal to B, thus violating
a major axiom of set theory.

The documentation for Set

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/SetsSpad

says, (in part):

++ In our implementation, \Language{} maintains the entries
++ in sorted order.  Specifically, the parts function returns
++ the entries as a list in ascending order and the extract
++ operation returns the maximum entry.

but the example shows that this is not true even if the Set
is composed of elements from a domain which has OrderedSet.
In the #347 I proposed a simple patch to correct this
behaviour but it is easy to show that it still fails if the
element domain is not an OrderedSet.

At the following page:

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

I have proposed an more ambitious fix that provides a constant
but otherwise arbitrary ordering for all SETs based on comparing
the Lisp SXHASH of the elements:

order(x:S,y:S):Boolean == integer(SXHASH(x)$Lisp)$Sexpression
                          < integer(SXHASH(y)$Lisp)$Sexpression

This provides an easy to compute order but since this is a
hash the ordering is in general only a partial order, so perhaps
this is not such a good idea?

The reference:

http://www.lisp.org/HyperSpec/Body/fun_sxhash.html#sxhash

says:

"3. The hash-code for an object is always the same within a
single session provided that the object is not visibly modified
with regard to the equivalence test equal.

"4. The hash-code is intended for hashing. This places no
verifiable constraint on a conforming implementation, but the
intent is that an implementation should make a good-faith effort
to produce hash-codes that are well distributed within the
range of non-negative fixnums.

---------

So my question for Axiom Developers and Lisp aficionados is
what is your opinion of the use of SXHASH? How well does SXHASH
behave in GCL? What might be a reasonable alternative for
defining a total ordering on the elements of a Set given the
possibility of the type 'Set Any'?

Also on page SandBoxSetAny I proposed a patch to the code for
the domain Any that makes use of the Lisp EQUAL comparison
instead of EQ. I think that in general EQ is too restrictive.
Do you think this change is reasonable and correct?

\start
Date: Thu, 5 Apr 2007 15:37:04 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Set Any and SXHASH

> In http://wiki.axiom-developer.org/347BugInMapSet
> 
> 'oklhazi' reported that "map confuses sets" and gives
> the example
> 
>   A:=set [-2,-1,0]
>   B:=set [0,1,4]
>   C:=map(x +-> x^2,A)
>   test(C=B)
> 
> where the map operation produces a "Set" C with the same
> elements as B but which is not equal to B, thus violating
> a major axiom of set theory.
> 
> The documentation for Set
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/SetsSpad
> 
> says, (in part):
> 
> ++ In our implementation, \Language{} maintains the entries
> ++ in sorted order.  Specifically, the parts function returns
> ++ the entries as a list in ascending order and the extract
> ++ operation returns the maximum entry.
> 
> but the example shows that this is not true even if the Set
> is composed of elements from a domain which has OrderedSet.
> In the #347 I proposed a simple patch to correct this
> behaviour but it is easy to show that it still fails if the
> element domain is not an OrderedSet.
>

I would say that sorting elements of Set is a design bug.
Namely, without any support form domain specific code it is
hard to define linear order.  AFAICS in Axiom only domains
which have OrderedSet are eqipped with linear order.
 
> So my question for Axiom Developers and Lisp aficionados is
> what is your opinion of the use of SXHASH? How well does SXHASH
> behave in GCL? What might be a reasonable alternative for
> defining a total ordering on the elements of a Set given the
> possibility of the type 'Set Any'?
>

Hashing allows reasonably efficient implementation of set
operations.
 
\start
Date: Thu, 5 Apr 2007 11:40:40 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: Set Any and SXHASH

On April 5, 2007 9:37 AM Waldek Hebisch wrote:
> ... 
> I would say that sorting elements of Set is a design bug.
> Namely, without any support form domain specific code it is
> hard to define linear order.  AFAICS in Axiom only domains
> which have OrderedSet are eqipped with linear order.
>

If Set is implemented by sorting the linear order cannot be
domain specific since there certainly are domains from which
we might wish to form finite sets for which no "natural" order
can be defined, e.g. the domain Any. But I think it is always
possible to define some lexical ordering over the members of
all domains For example, the Axiom interpreter contains the
Lisp function LEXGREATERP in

  src/interp/ggreater.lisp.pamphlet

For the implementation of Set using sorting all that is required
is that the ordering be constant within an Axiom session.

See: http://wiki.axiom-developer.org/SandBoxSetAny

> > So my question for Axiom Developers and Lisp aficionados is
> > what is your opinion of the use of SXHASH? How well does SXHASH
> > behave in GCL? What might be a reasonable alternative for
> > defining a total ordering on the elements of a Set given the
> > possibility of the type 'Set Any'?
> >
> 
> Hashing allows reasonably efficient implementation of set
> operations.
>  

Yes, but that would require a complete re-design of Set -
perhaps not a bad idea. Probably the current implementation
could be considered a little lame, but I was just looking for
a simple way to correct the existing bug. Axiom has other
domains that already use hashing such as EqTable so it might
be as easy as just choosing a different representation of the
Set domain.

\start
Date: Thu, 5 Apr 2007 19:04:23 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Set Any and SXHASH

Bill Page wrote:
> 
> If Set is implemented by sorting the linear order cannot be
> domain specific since there certainly are domains from which
> we might wish to form finite sets for which no "natural" order
> can be defined, e.g. the domain Any. But I think it is always
> possible to define some lexical ordering over the members of
> all domains For example, the Axiom interpreter contains the
> Lisp function LEXGREATERP in
> 
>   src/interp/ggreater.lisp.pamphlet
> 
> For the implementation of Set using sorting all that is required
> is that the ordering be constant within an Axiom session.
>

You need an order which is consistent with equality.  Since
equality is domain-specific you need also domian-specific
order.  I agree that we do not have one handy.  Producing
order is not very hard.  Producing "from outside" order which
agrees with equality seem to be expensive (I am affraid that
you need to store all domain elements in a hash table).
That is why I am saying about design bug.

> Yes, but that would require a complete re-design of Set -
> perhaps not a bad idea. Probably the current implementation
> could be considered a little lame, but I was just looking for
> a simple way to correct the existing bug. Axiom has other
> domains that already use hashing such as EqTable so it might
> be as easy as just choosing a different representation of the
> Set domain.
> 

I am affraid that a complete re-design is the only real fix
for design bugs.
 
\start
Date: Thu, 5 Apr 2007 13:12:25 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: Set Any and SXHASH

On April 5, 2007 1:04 PM Waldek Hebisch wrote:
> 
> Bill Page wrote:
> > 
> > If Set is implemented by sorting the linear order cannot be
> > domain specific since there certainly are domains from which
> > we might wish to form finite sets for which no "natural" order
> > can be defined, e.g. the domain Any. But I think it is always
> > possible to define some lexical ordering over the members of
> > all domains For example, the Axiom interpreter contains the
> > Lisp function LEXGREATERP in
> > 
> >   src/interp/ggreater.lisp.pamphlet
> > 
> > For the implementation of Set using sorting all that is required
> > is that the ordering be constant within an Axiom session.
> >
> 
> You need an order which is consistent with equality.

I agree.

> Since equality is domain-specific you need also domian-
> specific order.  I agree that we do not have one handy.

I do not agree. What do you think is wrong with LEXGREATERP
for this purpose?

> Producing order is not very hard.  Producing "from outside"
> order which agrees with equality seem to be expensive (I am
> affraid that you need to store all domain elements in a hash
> table). That is why I am saying about design bug.

Why?

> ...

\start
Date: Thu, 5 Apr 2007 19:25:22 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Set Any and SXHASH

Bill Page wrote:
> On April 5, 2007 1:04 PM Waldek Hebisch wrote:
> > 
> > Bill Page wrote:
> > > 
> > > If Set is implemented by sorting the linear order cannot be
> > > domain specific since there certainly are domains from which
> > > we might wish to form finite sets for which no "natural" order
> > > can be defined, e.g. the domain Any. But I think it is always
> > > possible to define some lexical ordering over the members of
> > > all domains For example, the Axiom interpreter contains the
> > > Lisp function LEXGREATERP in
> > > 
> > >   src/interp/ggreater.lisp.pamphlet
> > > 
> > > For the implementation of Set using sorting all that is required
> > > is that the ordering be constant within an Axiom session.
> > >
> > 
> > You need an order which is consistent with equality.
> 
> I agree.
> 
> > Since equality is domain-specific you need also domian-
> > specific order.  I agree that we do not have one handy.
> 
> I do not agree. What do you think is wrong with LEXGREATERP
> for this purpose?
> 

AFAICS LEXGREATERP compares representations, completly ignoring
equality from domain.

\start
Date: Thu, 5 Apr 2007 14:17:22 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: Set Any and SXHASH

On April 5, 2007 1:25 PM Waldek Hebisch wrote:
> ...
> > > 
> > > You need an order which is consistent with equality.
> > 
> > I agree.
> > 
> > > Since equality is domain-specific you need also domian-
> > > specific order.  I agree that we do not have one handy.
> > 
> > I do not agree. What do you think is wrong with LEXGREATERP
> > for this purpose?
> > 
> 
> AFAICS LEXGREATERP compares representations, completly ignoring
> equality from domain.
> 

Yes. Why do you say that this would not be consistent with
domain equality?

What problems would occur if elements of all finite sets
were ordered according to this ordering?

\start
Date: Fri, 6 Apr 2007 14:03:32 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Set Any and SXHASH

> On April 5, 2007 1:25 PM Waldek Hebisch wrote:
> > ...
> > > > 
> > > > You need an order which is consistent with equality.
> > > 
> > > I agree.
> > > 
> > > > Since equality is domain-specific you need also domian-
> > > > specific order.  I agree that we do not have one handy.
> > > 
> > > I do not agree. What do you think is wrong with LEXGREATERP
> > > for this purpose?
> > > 
> > 
> > AFAICS LEXGREATERP compares representations, completly ignoring
> > equality from domain.
> > 
> 
> Yes. Why do you say that this would not be consistent with
> domain equality?
>

Domain elements may be mathematically equal but have different
representations.  AFAICS this happens for example for general
fractions.
 
> What problems would occur if elements of all finite sets
> were ordered according to this ordering?
> 


We may miss duplicates and declare equal sets as unequal.

\start
Date: Fri, 06 Apr 2007 18:29:45 +0200
From: Gregory Vanuxem
To: list
Subject: boot : valid type checker

Hello,


At the boot level I want to know if a given type is valid. By type I
mean a category or a domain (parametrised if they must be). So for
example I want to know that 'Matrix(Character)' and 'Fields' are invalid
but not Matrix(Ring) and Matrix(Integer). There are several functions in
the interpreter for that but they are 'interactive' functions (in the
sense that they will throw an error if the type is not valid) or they do
not accept all possible categories. There is, for example, the function
'isValidType' but it seems to only accept domains and simple categories.
The nirvana would be a function that accepts things like
Matrix(Join(Foo,Bar)) [1]. 

Issues related are visible in the interpreter, try to type 
Matrix(Field) and List(Field).

Am I thinking wrong ?

Or may be you have some ideas or you know some functions that do what
I'm looking for ?

Greg

[1] This is doable, I think, via something like 'IGNORE_-ERRORS eval
mytype', but I would prefer a cleaner way.

\start
Date: 06 Apr 2007 20:33:05 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Set Any and SXHASH

Dear Bill, Waldek, *

Waldek Hebisch writes:

> I would say that sorting elements of Set is a design bug.

I disagree - but in fact, I believe that the statement above is due to
miscommunication:

"Set" uses the order of the underlying domain *if* the latter is an OrderedSet,
i.e., if it is totally ordered.  In my opinion, this is a very reasonable
decision.

If the underlying domain is not an OrderedSet, for example "ANY", then "Set"
will use slower algorithms, which do not depend on an ordering.

I think that this is very much in line with the philosophy of axiom. Note that
most domains have OrderedSet.

I think it is a mistake to pretend that a domain is ordered, using tricks like
hashing, within "Set".  If you really need fast set-operations for such a
domain, make it an OrderedSet.  However, I do not believe that making ANY an
OrderedSet is wise.  If your elements happen to be of type ANY and you need
fast Set operations for them, I'd suggest that you look for a better domain.

\start
Date: Fri, 6 Apr 2007 17:18:14 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: Set Any and SXHASH

On April 6, 2007 8:04 AM Waldek Hebisch wrote:
> ...
> Bill Page wrote [about using LEXGREATERP as an ordering]:
> >
> > Yes. Why do you say that this would not be consistent with
> > domain equality?
> >
>
> Domain elements may be mathematically equal but have different
> representations.  AFAICS this happens for example for general
> fractions.

Ah yes, in this case there is no "canonical" representative.

Marin gives another examnple like that in:

http://wiki.axiom-developer.org/348EqualityInAny#msg20070405161506-0500@w=
iki
.axiom-developer.org

Martin refers to the description of "canonical" in HyperDoc:

"canonical is true if and only if distinct elements have
 distinct data structures. For example, a domain of
 mathematical objects which has the canonical attribute means
 means that two objects are mathematically equal if and only
 if their data structures are equal."

I guess one should interpret "distinct" as a synonym for x ~= y.
So this means that for some domain D with representation Rep

  x,y:D; x = y implies rep(x) = rep(y) and
         rep(x) = rep(y) implies x = y

where by '=' I am specifically referring to the functions
exported by D and Rep, respectively.

> 
> > What problems would occur if elements of all finite sets
> > were ordered according to this ordering?
> >
>
> We may miss duplicates and declare equal sets as unequal.
>

Yes, I see that you are right if the domain is not canonical.
HyperDoc only shows 5 domains with canonical, FourierSeries,
Fraction, Integer, RomanNumeral, and SingleInteger; although
I expect there are actually many more domains that could be
given this attribute.

I assume that when you wrote "formal fractions" above, you
were not refering to Axiom's 'Fraction' domain?

Besides, the "canonical" attribute, it seems to me that there
is something else interesting here that should to be stated
more formally.

I suppose that it might be possible to design a domain in
which two representives of a given domain are equal but that
the corresponding members of the domain are not equal. But
this is somehow not "natural". So a "natural" representation
would be one for which

  x,y:D; rep(x) = rep(y) implies x = y

I was thinking about something like this when I wrote:

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

I am still looking for any computer sciense publication that
addresses this issue of representation in a formal mathematical
way.

\start
Date: Sat, 7 Apr 2007 02:07:09 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: boot : valid type checker

On April 6, 2007 12:30 PM Gregory Vanuxem wrote:
> 
> At the boot level I want to know if a given type is valid.
> By type I mean a category or a domain (parametrised if
> they must be). So for example I want to know that
> 'Matrix(Character)' and 'Fields' are invalid but not
> Matrix(Ring) and Matrix(Integer)

You implied that Matrix(Ring) is valid, but it is not. Perhaps
this was a typo?

The definition of Matrix is

  Matrix(R:Ring)

I wonder if you mean something like: since both

  Integer has Ring
  Field has Ring

are true, why not both

  Matrix(Integer)
  Matrix(Field)

Field of course, is a category while Integer is a domain.

> There are several functions in the interpreter for that but
> they are 'interactive' functions (in the sense that they will
> throw an error if the type is not valid) or they do not accept
> all possible categories. There is, for example, the function
> 'isValidType' but it seems to only accept domains and simple 
> categories.

Can you give an example of a valid category for which isValidType
does not return T?

isValidType seems to work for me (of course this is just the
interpreter but the equivalent must work in Boot):

(1) -> mytype1:=["Matrix"::Symbol::SEX, ["Integer"::Symbol::SEX]::SEX]::SEX


   (1)  (Matrix (Integer))

                                        Type: SExpression
(2) -> mytype2:=["Matrix"::Symbol::SEX,
["Character"::Symbol::SEX]::SEX]::SEX          

   (2)  (Matrix (Character))
                                        Type: SExpression

(3) -> mytype3:=["FiniteSetAggregate"::Symbol::SEX,
["Integer"::Symbol::SEX]::SEX]::SEX

   (3)  (FiniteSetAggregate (Integer))
                                        Type: SExpression

(4) -> isValidType(mytype1)$Lisp


   (4)  T
                                        Type: SExpression

(5) -> isValidType(mytype2)$Lisp

   (5)  ()
                                        Type: SExpression

(6) -> isValidType(mytype3)$Lisp

   (6)  T
                                        Type: SExpression

> The nirvana would be a function that accepts things like
> Matrix(Join(Foo,Bar)) [1].

I do not understand what you mean by this.

> 
> Issues related are visible in the interpreter, try to type 
> Matrix(Field) and List(Field).
> 
> Am I thinking wrong ?
> 

I think your examples are a little confused. Something can not
be a Field without also being a Ring, right?

Integer has Ring

Matrix(Integer)

Fraction Integer has Field

Fraction Integer has Ring

Matrix(Fraction Integer)

> Or may be you have some ideas or you know some functions that
> do what I'm looking for ?
> 

Maybe you could give another example?

\start
Date: Sat, 07 Apr 2007 12:53:03 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: boot : valid type checker

Le samedi 07 avril 2007 =E0 02:07 -0400, Bill Page a =E9crit :
> On April 6, 2007 12:30 PM Gregory Vanuxem wrote:
> >
> > At the boot level I want to know if a given type is valid.
> > By type I mean a category or a domain (parametrised if
> > they must be). So for example I want to know that
> > 'Matrix(Character)' and 'Fields' are invalid but not
> > Matrix(Ring) and Matrix(Integer)
>
> You implied that Matrix(Ring) is valid, but it is not. Perhaps
> this was a typo?

No this is not a typo, I was not very clear, here I consider
Matrix(Ring) as a valid type. Something on which I can work at the boot
level (this is probably different than a "real" domain, I don't know,
this is in part why I first want to know if I'm working on a valid
type). When I say parametrised I consider a category as a valid
parameter. I can not rely on the interpreter and what it returns or on
some parts of the functions available in the src/interp directory (there
are also 'new' and 'old' functions).

(8) -> DirectProduct(3,IntegerNumberSystem)

   (8)  DirectProduct(3,IntegerNumberSystem)
                                      Type: Domain
(9) -> [1,2,3]::%

   >> System error:
   NIL is not of type CONS.

The interpeter considers DirectProduct(3,IntegerNumberSystem) as a valid
domain (type ?) :-(


> The definition of Matrix is
>
>   Matrix(R:Ring)
>
> I wonder if you mean something like: since both
>
>   Integer has Ring
>   Field has Ring
>
> are true, why not both
>
>   Matrix(Integer)
>   Matrix(Field)
>
> Field of course, is a category while Integer is a domain.

> > There are several functions in the interpreter for that but
> > they are 'interactive' functions (in the sense that they will
> > throw an error if the type is not valid) or they do not accept
> > all possible categories. There is, for example, the function
> > 'isValidType' but it seems to only accept domains and simple
> > categories.
>
> Can you give an example of a valid category for which isValidType
> does not return T?

No, I thought, but I was wrong  :-(, thanks for pointing this out.
Think of a category, here, as the set of matrices over a ring
(Ring being a category in the Axiom sense).

> isValidType seems to work for me (of course this is just the
> interpreter but the equivalent must work in Boot):
>
> (1) -> mytype1:=["Matrix"::Symbol::SEX, ["Integer"::Symbol::SEX]::SEX=
]::SEX
>
>
>    (1)  (Matrix (Integer))
>
>                                         Type: SExpression
> (2) -> mytype2:=["Matrix"::Symbol::SEX,
> ["Character"::Symbol::SEX]::SEX]::SEX         
>
>    (2)  (Matrix (Character))
>                                         Type: SExpression
>
> (3) -> mytype3:=["FiniteSetAggregate"::Symbol::SEX,
> ["Integer"::Symbol::SEX]::SEX]::SEX
>
>    (3)  (FiniteSetAggregate (Integer))
>                                         Type: SExpression
>
> (4) -> isValidType(mytype1)$Lisp
>
>
>    (4)  T
>                                         Type: SExpression
>
> (5) -> isValidType(mytype2)$Lisp
>
>    (5)  ()
>                                         Type: SExpression
>
> (6) -> isValidType(mytype3)$Lisp
>
>    (6)  T
>                                         Type: SExpression

Yes, I was not clear. I do not have a clear overview of what Axiom
does behind the scene but I suspect some error from my part and
I must put out some simple mistakes.

> > The nirvana would be a function that accepts things like
> > Matrix(Join(Foo,Bar)) [1].
>
> I do not understand what you mean by this.

I want to know if I can extract information from what I call a
valid type, i.e:

)bo Matrix(Join(Field(),ConvertibleTo(InputForm())))

(|Matrix| (|Join| (|Field|) (|ConvertibleTo| (|InputForm|))))
Value = #<(SIMPLE-VECTOR 72) {10053B01FF}>

I'm interested by this vector :-).

[...]

> >
> > Am I thinking wrong ?

I was...

\start
Date: Sat, 7 Apr 2007 14:15:24 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Set Any and SXHASH

Martin Rubey wrote:
> Dear Bill, Waldek, *
> 
> Waldek Hebisch writes:
> 
> > I would say that sorting elements of Set is a design bug.
> 
> I disagree - but in fact, I believe that the statement above is due to
> miscommunication:
> 
> "Set" uses the order of the underlying domain *if* the latter is an OrderedSet,
> i.e., if it is totally ordered.  In my opinion, this is a very reasonable
> decision.
> 
> If the underlying domain is not an OrderedSet, for example "ANY", then "Set"
> will use slower algorithms, which do not depend on an ordering.
> 

Thanks for pointing out this -- I trusted documentation, but
documentation was wrong.  So, Bill first fix is fine if domains
has OrderedSett, but sorting must be conditional on OrderedSet.
I have now updated documentation and applied (to wh-sandbox) the fix.

When I wrote about design bug I meant idea of sorting something
which is not an OrderedSet.

\start
Date: 07 Apr 2007 18:11:09 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Set Any and SXHASH

Waldek Hebisch writes:

> Martin Rubey wrote:
> > "Set" uses the order of the underlying domain *if* the latter is an OrderedSet,
> > i.e., if it is totally ordered.  In my opinion, this is a very reasonable
> > decision.

> Thanks for pointing out this -- I trusted documentation, but
> documentation was wrong.  So, Bill first fix is fine if domains
> has OrderedSett, but sorting must be conditional on OrderedSet.
> I have now updated documentation and applied (to wh-sandbox) the fix.

Great.

> When I wrote about design bug I meant idea of sorting something
> which is not an OrderedSet.

Great! I'm very happy we agree!

\start
Date: Sat, 7 Apr 2007 12:26:06 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Axiom on Solaris 10.2 x86

Gaby,

My attempt to build axiom on my Solaris 10.2 x86 system from the
most recent build-improvements source ended with the following
error while building sman and friends:

-------
...

solveLinearlyOverQ(vector [m1, m3], m2)


         1 1
   (8)  [-,-]
         2 2
                                     Type: Union(Vector Fraction
Integer,...)
)lisp (bye)

1 finished ./../../int/input
gmake[3]: Leaving directory `/export/home0/wspage/axiom-test/src/input'
1 finished ../../../build-improvements/src/input
rm ecfact.as pdecomp0.as hilbert.as aseg7.as matops.as romnum.as aseg6.as
gmake[2]: Leaving directory `/export/home0/wspage/axiom-test/src/input'
cd booklets && gmake SYS=i386-pc-solaris2.10 "NOISE=-o
././build/i386-pc-solaris2.10/trace"
gmake[2]: Entering directory `/export/home0/wspage/axiom-test/src/booklets'
cd ../../../build-improvements/src/booklets && notangle -t8
Makefile.pamphlet > ./Makefile.in
cd /export/home0/wspage/axiom-test && /bin/sh ./config.status
src/booklets/Makefile
config.status: creating src/booklets/Makefile
gmake[2]: Leaving directory `/export/home0/wspage/axiom-test/src/booklets'
gmake[2]: Entering directory `/export/home0/wspage/axiom-test/src/booklets'
gmake[2]: Nothing to be done for `all'.
gmake[2]: Leaving directory `/export/home0/wspage/axiom-test/src/booklets'
../../build-improvements/config/mkinstalldirs
./../target/i386-pc-solaris2.10/bin
../../build-improvements/config/mkinstalldirs
./../target/i386-pc-solaris2.10/lib
cd sman && gmake SYS=i386-pc-solaris2.10 "NOISE=-o
././build/i386-pc-solaris2.10/trace"
gmake[2]: Entering directory `/export/home0/wspage/axiom-test/src/sman'
cd ../../../build-improvements/src/sman && notangle -t8 Makefile.pamphlet >
./Makefile.in
cd /export/home0/wspage/axiom-test && /bin/sh ./config.status
src/sman/Makefile
config.status: creating src/sman/Makefile
gmake[2]: Leaving directory `/export/home0/wspage/axiom-test/src/sman'
gmake[2]: Entering directory `/export/home0/wspage/axiom-test/src/sman'
./../../build/scripts/document --tangle --output=session.c
../../../build-improvements/src/sman/session.c.pamphlet
gcc -c -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
-I../../../build-improvements/src/include -I../../config -I. -o session.o
session.c
session.c:92: warning: 'pr' defined but not used
gcc session.o -o ../../target/i386-pc-solaris2.10/lib/session
-L/export/home0/wspage/axiom-test/src/lib -lspad  -o
../../target/i386-pc-solaris2.10/lib/session
session.o: In function `main':
session.c:(.text+0x3c1): undefined reference to `accept'
/export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o): In function
`open_server':


sockio-c.c:(.text+0x1b9): undefined reference to `socket'
sockio-c.c:(.text+0x205): undefined reference to `bind'
sockio-c.c:(.text+0x23c): undefined reference to `listen'
/export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o): In function
`accept_connection':
sockio-c.c:(.text+0x2d2): undefined reference to `accept'
/export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o): In function
`swrite':
sockio-c.c:(.text+0x65d): undefined reference to `send'
/export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o): In function
`sread':
sockio-c.c:(.text+0xcf3): undefined reference to `recv'
/export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o): In function
`connect_to_local_server':
sockio-c.c:(.text+0x11a8): undefined reference to `socket'
sockio-c.c:(.text+0x1200): undefined reference to `connect'
/export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o): In function
`connect_to_local_server_new':
sockio-c.c:(.text+0x1312): undefined reference to `socket'
sockio-c.c:(.text+0x136c): undefined reference to `connect'
collect2: ld returned 1 exit status
gmake[2]: *** [../../target/i386-pc-solaris2.10/lib/session] Error 1
gmake[2]: Leaving directory `/export/home0/wspage/axiom-test/src/sman'
gmake[1]: *** [all-sman] Error 2
gmake[1]: Leaving directory `/export/home0/wspage/axiom-test/src'
gmake: *** [all-src] Error 2

--------

Apparently ./configure did not locate the required sockets
headers. Do you have any idea what might be wrong? Or how
I should attemt to debug this?

\start
Date: Sat, 07 Apr 2007 16:17:38 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Axiom on Solaris 10.2 x86

Quoting Bill Page:

> Gaby,
>
> My attempt to build axiom on my Solaris 10.2 x86 system from the
> most recent build-improvements source ended with the following
> error while building sman and friends:
>
[...]

> sockio-c.c:(.text+0x1b9): undefined reference to `socket'
> sockio-c.c:(.text+0x205): undefined reference to `bind'
> sockio-c.c:(.text+0x23c): undefined reference to `listen'

[...]

> Apparently ./configure did not locate the required sockets
> headers. Do you have any idea what might be wrong? Or how
> I should attemt to debug this?

if configure did not find the sockets headers, it would have
aborted at configure time.  My suspicion is that it did find
them, but somehow, it could not find the associated libraries.
Please, could you send me the config.log file and see where
there the socket library had been put in different file?

I tried to install openSolaris nevada build 60 on my Dell Optiplex
745, but eventually I gave up and installed SuSE instead. :-(
The reason being that openSolaris 64bit seems to be largely
unsupported by GNU tool chains, and openSolaris seems to ignore
many of GNU software. :-(

\start
Date: Sat, 7 Apr 2007 14:58:14 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis, Bill Page
Subject: re: Axiom on Solaris 10.2 x86


--- Gabriel Dos Reis wrote:
> I tried to install openSolaris nevada build 60 on my Dell Optiplex
> 745, but eventually I gave up and installed SuSE instead. :-(
> The reason being that openSolaris 64bit seems to be largely
> unsupported by GNU tool chains, and openSolaris seems to ignore
> many of GNU software. :-(

I've only installed it in a plex86 environment and haven't really
worked with it, but you might want to try Nexenta and see if that
works:  http://www.gnusolaris.org/

I don't know that 64bit support will be any better, but the GNU
toolchain support in Nexenta may be in better shape.

\start
Date: Sat, 7 Apr 2007 18:06:00 -0400
From: Bill Page
To: "'Axiom-Developer'" <list>
Subject: FW: Axiom on Solaris 10.2 x86

-----Original Message-----

Gaby,


On April 7, 2007 5:18 PM you wrote:
>...
> Bill Page wrote: 
> > Apparently ./configure did not locate the required sockets
> > headers. Do you have any idea what might be wrong? Or how
> > I should attempt to debug this?
> 
> if configure did not find the sockets headers, it would have
> aborted at configure time.  My suspicion is that it did find
> them, but somehow, it could not find the associated libraries.
> Please, could you send me the config.log file and see where
> there the socket library had been put in different file?
>

Yes, I see. That is certainly possible. The Blastwave gnu tools
binaries and libraries are in a non-standard location under
/opt/csw

I've attached config.log (gz)
 
> I tried to install openSolaris nevada build 60 on my Dell
> Optiplex 745, but eventually I gave up and installed SuSE
> instead. :-( The reason being that openSolaris 64bit seems
> to be largely unsupported by GNU tool chains, and openSolaris
> seems to ignore many of GNU software. :-(
> 

What I am running is technically not OpenSolaris but rather
Sun's Solaris 10.2 release. I found installation very simple.
Of course Solaris is still not as easy an installation as
most of the Linux distributions, but if you have been around
Solaris for a long time (like I have) then installing 10.2 is
comparatively much easier than Solaris used to be on some
Sun sparc hardware.

http://www.blastwave.org

tries hard to be like what Debian is for Linux and I find that
for the most part it works very well. You should find the support
for x-86-64 binaries essentially the same as for the sparc
architecture. Actually it is mostly Blastwave that has lured
me back to Solaris after nearly giving it up for Linux. Perhaps
it is only nostalgia, but for enterprise applications I am still
inclined to prefer Solaris over any of the Linux distributions.

\start
Date: 07 Apr 2007 17:06:36 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: Axiom on Solaris 10.2 x86

Cliff Yapp writes:

| --- Gabriel Dos Reis wrote:
| > I tried to install openSolaris nevada build 60 on my Dell Optiplex
| > 745, but eventually I gave up and installed SuSE instead. :-(
| > The reason being that openSolaris 64bit seems to be largely
| > unsupported by GNU tool chains, and openSolaris seems to ignore
| > many of GNU software. :-(
| 
| I've only installed it in a plex86 environment and haven't really
| worked with it, but you might want to try Nexenta and see if that
| works:  http://www.gnusolaris.org/

Thanks for the pointer -- I did not know the status of other
openSolaris-based distribution, so after a week of frustration I gave
up (very strange for someone who's grown up in solaris environment,
isnt' it?)
I'll return to that later (probably end of the month or may).

I spend the morning having "fun" chasing bugs in Axiom with runtime
checking enabled.   Pretty scary.

\start
Date: 07 Apr 2007 17:09:29 -0500
From: Gabriel Dos Reis
To: list
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [491] branches/build-improvements

dos-reis@users.sourceforge.net writes:

[...]

| +2007-04-07  Gabriel Dos Reis  Gabriel Dos Reis
| +
| +	* configure.ac.pamphlet: Add configure support for runtime checking.
| +	(axiom_enable_checking): New.  
| +	* configure.ac: Regenerate.
| +	* configure: Likewise.

As of revision 491, I added a configure option --enable-checking for
requesting runtime checking of Lisp codes, e.g. (proclaim '(optimize
(safety 3))). 
That has the side effect of dramatically increasing the overall
compilation time.  In return, you get to know about bugs you did not
suspect or did not want to know about.

\start
Date: Sat, 7 Apr 2007 18:29:28 -0400
From: Bill Page
To: list
Subject: RE: FW: Axiom on Solaris 10.2 x86
Cc: Gabriel Dos Reis

Gaby,

I consulted:

http://sourceware.org/ml/automake/2004-01/msg00162.html

which seems to include the necessary Autoconf magic.

Indeed adding -lsocket to

gcc session.o -o ../../target/i386-pc-solaris2.10/lib/session
-L/export/home0/wspage/axiom-test/src/lib -lspad  -lsocket -o
../../target/i386-pc-solaris2.10/lib/session

seemed to do the trick.

Regards,
Bill Page.

On April 7, 2007 12:26 PM Bill Page wrote:
> ... 
> gmake[2]: Entering directory 
> `/export/home0/wspage/axiom-test/src/sman'
> ./../../build/scripts/document --tangle --output=session.c
> ../../../build-improvements/src/sman/session.c.pamphlet
> gcc -c -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE
> -I../../../build-improvements/src/include -I../../config -I. 
> -o session.o
> session.c
> session.c:92: warning: 'pr' defined but not used
> gcc session.o -o ../../target/i386-pc-solaris2.10/lib/session
> -L/export/home0/wspage/axiom-test/src/lib -lspad  -o
> ../../target/i386-pc-solaris2.10/lib/session
> session.o: In function `main':
> session.c:(.text+0x3c1): undefined reference to `accept'
> /export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o):
>  In function
> `open_server':
> 
> 
> sockio-c.c:(.text+0x1b9): undefined reference to `socket'
> sockio-c.c:(.text+0x205): undefined reference to `bind'
> sockio-c.c:(.text+0x23c): undefined reference to `listen'
> /export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o):
>  In function
> `accept_connection':
> sockio-c.c:(.text+0x2d2): undefined reference to `accept'
> /export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o):
>  In function
> `swrite':
> sockio-c.c:(.text+0x65d): undefined reference to `send'
> /export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o):
>  In function
> `sread':
> sockio-c.c:(.text+0xcf3): undefined reference to `recv'
> /export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o):
>  In function
> `connect_to_local_server':
> sockio-c.c:(.text+0x11a8): undefined reference to `socket'
> sockio-c.c:(.text+0x1200): undefined reference to `connect'
> /export/home0/wspage/axiom-test/src/lib/libspad.a(sockio-c.o):
>  In function
> `connect_to_local_server_new':
> sockio-c.c:(.text+0x1312): undefined reference to `socket'
> sockio-c.c:(.text+0x136c): undefined reference to `connect'
> collect2: ld returned 1 exit status
> gmake[2]: *** [../../target/i386-pc-solaris2.10/lib/session] Error 1
> gmake[2]: Leaving directory `/export/home0/wspage/axiom-test/src/sman'
> gmake[1]: *** [all-sman] Error 2
> gmake[1]: Leaving directory `/export/home0/wspage/axiom-test/src'
> gmake: *** [all-src] Error 2
> 

\start
Date: Sat, 7 Apr 2007 18:43:38 -0400
From: Bill Page
To: list
Subject: RE: FW: Axiom on Solaris 10.2 x86
xCc: Gabriel Dos Reis

On April 7, 2007 6:29 PM I wrote:
> 
> I consulted:
> 
> http://sourceware.org/ml/automake/2004-01/msg00162.html
> 
> which seems to include the necessary Autoconf magic.
> 
> Indeed adding -lsocket to
> 
> gcc session.o -o ../../target/i386-pc-solaris2.10/lib/session
> -L/export/home0/wspage/axiom-test/src/lib -lspad  -lsocket -o
> ../../target/i386-pc-solaris2.10/lib/session
> 
> seemed to do the trick.
> 

Build completes normally after the following patch (tested by
applying the equivalent patch to my out-of-source build directory
axiom-test/src/sman/Makefile):

-bash-3.00$ gdiff -au build-improvements/src/sman/Makefile.in.orig
build-improvements/src/sman/Makefile.in
--- build-improvements/src/sman/Makefile.in.orig        2007-04-07
18:35:02.262911000 -0400
+++ build-improvements/src/sman/Makefile.in     2007-04-07
18:35:38.674866000 -0400
@@ -23,13 +23,13 @@
 spadclient_sources = spadclient.c
 spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
 spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
-spadclient_LDADD = -L$(build_libdir) -lspad
+spadclient_LDADD = -L$(build_libdir) -lspad -lsocket
 spadclient_DEPENDENCIES =

 sman_sources = sman.c
 sman_SOURCES = $(addsuffix .pamphlet, $(sman_sources))
 sman_objects = $(sman_sources:.c=.$(OBJEXT))
-sman_LDADD = -L$(build_libdir) -lspad
+sman_LDADD = -L$(build_libdir) -lspad -lsocket
 sman_DEPENDENCIES =

--------

Does this make sense to you?

If so, I will retry the build from zero with this patch.

Regards,
Bill Page.

\start
Date: Sat, 07 Apr 2007 18:00:56 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: FW: Axiom on Solaris 10.2 x86

Quoting Bill Page:

> Gaby,
>
> I consulted:
>
> http://sourceware.org/ml/automake/2004-01/msg00162.html
>
> which seems to include the necessary Autoconf magic.
>
> Indeed adding -lsocket to
>
> gcc session.o -o ../../target/i386-pc-solaris2.10/lib/session
> -L/export/home0/wspage/axiom-test/src/lib -lspad  -lsocket -o
> ../../target/i386-pc-solaris2.10/lib/session
>
> seemed to do the trick.

That is great.  Many thanks for the detective work.

\start
Date: 07 Apr 2007 18:35:13 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: Axiom on Solaris 10.2 x86

Bill Page writes:

[...]

| -bash-3.00$ gdiff -au build-improvements/src/sman/Makefile.in.orig
| build-improvements/src/sman/Makefile.in
| --- build-improvements/src/sman/Makefile.in.orig        2007-04-07
| 18:35:02.262911000 -0400
| +++ build-improvements/src/sman/Makefile.in     2007-04-07
| 18:35:38.674866000 -0400
| @@ -23,13 +23,13 @@
|  spadclient_sources = spadclient.c
|  spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
|  spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
| -spadclient_LDADD = -L$(build_libdir) -lspad
| +spadclient_LDADD = -L$(build_libdir) -lspad -lsocket
|  spadclient_DEPENDENCIES =
| 
|  sman_sources = sman.c
|  sman_SOURCES = $(addsuffix .pamphlet, $(sman_sources))
|  sman_objects = $(sman_sources:.c=.$(OBJEXT))
| -sman_LDADD = -L$(build_libdir) -lspad
| +sman_LDADD = -L$(build_libdir) -lspad -lsocket
|  sman_DEPENDENCIES =
| 
| --------
| 
| Does this make sense to you?

You're almost there.  Please could you try the patch below?
(I've not test a build yet, but it is along the line of what I think
should happen).  After apply the patch, you need to ./build-setup.sh

Many thanks.

-- Gaby

*** configure.ac.pamphlet	(revision 19377)
--- configure.ac.pamphlet	(local)
*************** case $host in
*** 252,257 ****
--- 252,260 ----
          AC_CHECK_HEADERS([sys/socket.h], 
                           [axiom_host_has_socket=yes],
  		         [])
+ 	AC_SEARCH_LIBS([accept], [socket],
+ 	               [axiom_c_runtime_extra="-lsocket"],
+ 		       [AC_MSG_ERROR([socket library not found])])
  	;;
  esac
  if test x$axiom_host_has_socket != xyes; then \
*** src/sman/Makefile.pamphlet	(revision 19377)
--- src/sman/Makefile.pamphlet	(local)
*************** spadclient_DEPENDENCIES =
*** 47,53 ****
  sman_sources = sman.c
  sman_SOURCES = $(addsuffix .pamphlet, $(sman_sources))
  sman_objects = $(sman_sources:.c=.$(OBJEXT))
! sman_LDADD = -L$(build_libdir) -lspad
  sman_DEPENDENCIES =
  
  
--- 47,53 ----
  sman_sources = sman.c
  sman_SOURCES = $(addsuffix .pamphlet, $(sman_sources))
  sman_objects = $(sman_sources:.c=.$(OBJEXT))
! sman_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
  sman_DEPENDENCIES =
  
  
\start
Date: Sun, 8 Apr 2007 01:16:18 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: build-improvements revision 491

Gaby,

After 'svn update' to revision 491 my attempt to build Axiom
from build-improvements threw the following error:

...
./../../build/scripts/document --tangle --output=i-output.boot
../../../build-improvements/src/interp/i-output.boot.pamphlet
./../../build/scripts/document --tag=boot --mode=translate
--use=./../../build/i386-pc-solaris2.10/bin/bootsys     i-output.boot
ERROR IN LINE 448
;  REVERSIP head
|
syntax error
ERROR IN LINE 449
; REVERSIP is a function specific to CCL
|
syntax error
i-output.clisp PRODUCED
make[3]: *** [i-output.clisp] Error 1
make[3]: Leaving directory `/export/home0/wspage/axiom-test/src/interp'
make[2]: *** [all-interpsys] Error 2
make[2]: Leaving directory `/export/home0/wspage/axiom-test/src/interp'
make[1]: *** [all-interpsys] Error 2
make[1]: Leaving directory `/export/home0/wspage/axiom-test/src'
make: *** [all-src] Error 2

-------

Revision 490 builds with no problems.

\start
Date: 08 Apr 2007 02:03:33 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: build-improvements revision 491

Bill Page writes:

| Gaby,
| 
| After 'svn update' to revision 491 my attempt to build Axiom
| from build-improvements threw the following error:
| 
| ...
| ./../../build/scripts/document --tangle --output=i-output.boot
| ../../../build-improvements/src/interp/i-output.boot.pamphlet
| ./../../build/scripts/document --tag=boot --mode=translate
| --use=./../../build/i386-pc-solaris2.10/bin/bootsys     i-output.boot
| ERROR IN LINE 448
| ;  REVERSIP head
| |
| syntax error
| ERROR IN LINE 449
| ; REVERSIP is a function specific to CCL
| |
| syntax error
| i-output.clisp PRODUCED
| make[3]: *** [i-output.clisp] Error 1
| make[3]: Leaving directory `/export/home0/wspage/axiom-test/src/interp'
| make[2]: *** [all-interpsys] Error 2
| make[2]: Leaving directory `/export/home0/wspage/axiom-test/src/interp'
| make[1]: *** [all-interpsys] Error 2
| make[1]: Leaving directory `/export/home0/wspage/axiom-test/src'
| make: *** [all-src] Error 2
| 
| -------
| 
| Revision 490 builds with no problems.

Grrr, I did not know I commited that change that was trying to
translate i-output.boot by bootsys.  The issue is that
i-output.boot contains an invalid boot comment -- someone was using
Lisp comment instead of boot comment, and ';' means sequencing, not
comment.  That but was there undetected since before
build-improvements was created and nobody noticed!
I'll fix that.

\start
Date: Sun, 8 Apr 2007 11:02:20 +0200
From: Juergen Weiss
To: Gabriel Dos Reis,
Subject: re: [Axiom-commit] SF.net SVN: axiom: [491]branches/build-improvements

> dos-reis@users.sourceforge.net writes:
> As of revision 491, I added a configure option --enable-checking for
> requesting runtime checking of Lisp codes, e.g. (proclaim '(optimize
> (safety 3))).
> That has the side effect of dramatically increasing the overall
> compilation time.  In return, you get to know about bugs you did not
> suspect or did not want to know about.
>
This is not too suprising, when you consider all the mails in this
newsgroup about errors with the following message
>> System error:
    Caught fatal error [memory may be damaged]
I always wondered why nobody recompiled the system with better error
checking, to localize these bugs. I'm glad you did that.

\start
Date: 08 Apr 2007 09:59:28 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: Axiom on Solaris 10.2 x86

Gabriel Dos Reis writes:

[...]

| You're almost there.  Please could you try the patch below?

The patch I sent did not work on GNU/Linux boxes, for the reason that
there is no separate libsocket library.  Consequently, we must special
case the addition for solaris-based systems.  I've checked in a patch
that does that and passes the build on an i686-suse-linux.  Please
could you update and see whether the build works for?

\start
Date: Sun, 8 Apr 2007 13:24:13 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: FW: Axiom on Solaris 10.2 x86

Gaby,

On April 8, 2007 10:59 AM you wrote:
> ... 
> The patch I sent did not work on GNU/Linux boxes, for the reason
> that there is no separate libsocket library.  Consequently, we
> must special case the addition for solaris-based systems.  I've
> checked in a patch that does that and passes the build on an
> i686-suse-linux. Please could you update and see whether the
> build works for?
> 

Sorry, the earlier patch also did not work on 'i386-pc-solaris2.10'.
The same error as before. No -lsocket was added to the gcc command.
I will revert the earlier patch and svn update and try again.

The first thing to check immedately after ./configure is the
src/sman/Makefile, I guess...

\start
Date: 08 Apr 2007 13:12:44 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: Axiom on Solaris 10.2 x86

Bill Page writes:

| Gaby,
| 
| On April 8, 2007 10:59 AM you wrote:
| > ... 
| > The patch I sent did not work on GNU/Linux boxes, for the reason
| > that there is no separate libsocket library.  Consequently, we
| > must special case the addition for solaris-based systems.  I've
| > checked in a patch that does that and passes the build on an
| > i686-suse-linux. Please could you update and see whether the
| > build works for?
| > 
| 
| Sorry, the earlier patch also did not work on 'i386-pc-solaris2.10'.
| The same error as before. No -lsocket was added to the gcc command.

Huh.  It was added on my machine and compiler-link failed precisely
because the system ld could not find -lsocket.  I have special cased
solaris.  The build was OK on both i686-suse-linux and
x86_64-suse-linux.  If your build fails, please send me again your
config.log. 

| I will revert the earlier patch and svn update and try again.
| 
| The first thing to check immedately after ./configure is the
| src/sman/Makefile, I guess...

Yes, see what gets substituted there.

\start
Date: Sun, 8 Apr 2007 17:43:58 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: FW: Axiom on Solaris 10.2 x86

Gaby,

On April 8, 2007 2:13 PM you wrote:
> ...
> Bill Page writes:
> |
> | Sorry, the earlier patch also did not work on 'i386-pc-solaris2.10'.
> | The same error as before. No -lsocket was added to the gcc command.
>
> Huh.  It was added on my machine and compiler-link failed
> precisely because the system ld could not find -lsocket.  I have
> special cased solaris.  The build was OK on both i686-suse-linux
> and x86_64-suse-linux.  If your build fails, please send me again
> your config.log.

Perhaps I just screwed up the previous patch last night. The build
completed this time but I did have to make the following additional
patch:

-bash-3.00$ svn diff src/sman/Makefile.pamphlet
Index: src/sman/Makefile.pamphlet
==========================
==========================
=================
--- src/sman/Makefile.pamphlet  (revision 496)
+++ src/sman/Makefile.pamphlet  (working copy)
@@ -35,13 +35,13 @@
 session_sources = session.c
 session_SOURCES = $(addsuffix .pamphlet, $(session_sources))
 session_objects = $(session_sources:.c=.$(OBJEXT))
-session_LDADD = -L$(build_libdir) -lspad
+session_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
 session_DEPENDENCIES =

 spadclient_sources = spadclient.c
 spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
 spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
-spadclient_LDADD = -L$(build_libdir) -lspad
+spadclient_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
 spadclient_DEPENDENCIES =

 sman_sources = sman.c

-------

>
> | I will revert the earlier patch and svn update and try again.
> |
> | The first thing to check immedately after ./configure is the
> | src/sman/Makefile, I guess...
>
> Yes, see what gets substituted there.
>

I think the build is ok now and I can start AXIOMsys. But I
do get an error when I try hyperdoc:

-bash-3.00$ axiom
(HyperDoc) read_ht_db: No ht.db file found
GCL (GNU Common Lisp)  2.6.8 CLtL1    Apr  7 2007 01:22:27
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
                        AXIOM Computer Algebra System
             Version: Axiom build-improvements branch 2006-04-07
                Timestamp: Monday April 9, 2007 at 06:30:33
-------------------------------------------------------------------------=
---
-
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
---
-

(1) ->
(1) -> 1+1

   (1)  2
                                                        Type:
PositiveInteger

(2) -> )quit

   Please enter y or yes if you really want to leave the interactive
      environment and return to the operating system:
yes

------

HyperDoc does not start but otherwise Axiom is ok.

Any ideas on why ht.db is not found?

I haven't run HyperDoc recently from the build-improvements
branch. Have you tested this and do you expect it to work?

I will now try to build from wh-sandbox which I believe includes
a number of significant changes to hyperdoc which are not yet
brought into build-improvements.

\start
Date: Sun, 8 Apr 2007 18:05:52 -0400
From: Bill Page
To: Waldek Hebisch
Subject: building wh-sandbox on Axiom on Solaris 10.2 x86
Cc: Gabriel Dos Reis

Waldek,

My attempt to build wh-sandbox from the most recent source
fails with a configure error:

-bash-3.00$ svn co
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/wh-sandbox
...
A    wh-sandbox/configure.ac.pamphlet
A    wh-sandbox/axiomlogo.jpg
Checked out revision 496.
-bash-3.00$ mkdir axiom-sandbox
-bash-3.00$ cd axiom-sandbox
-bash-3.00$ ../wh-sandbox/configure 2>&1 | tee build
...
config.status: creating src/doc/Makefile
mkdir: "build/scripts": Not a directory
config.status: error: cannot create directory "build/scripts"

-------

Any ideas?

I will try to create 'build/scripts' and continue.

\start
Date: Sun, 8 Apr 2007 18:09:40 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: building wh-sandbox on Axiom on Solaris 10.2
Cc: Gabriel Dos Reis

On April 8, 2007 6:06 PM I wrote:
> 
> My attempt to build wh-sandbox from the most recent source
> fails with a configure error:
> ...
> -bash-3.00$ ../wh-sandbox/configure 2>&1 | tee build
> ...
> config.status: creating src/doc/Makefile
> mkdir: "build/scripts": Not a directory
> config.status: error: cannot create directory "build/scripts"
> 
> -------
> 
> Any ideas?
> 

Oops, my stupid error. I meant to run:

-bash-3.00$ ../wh-sandbox/configure 2>&1 | tee build.log

\start
Date: Sun, 8 Apr 2007 18:12:41 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: building wh-sandbox on Axiom on Solaris 10.2
Cc: Gabriel Dos Reis

Waldek,

Ok, I think I have a real problem to report this time. The
configure worked but make fails as shown below:

-bash-3.00$ make 2>&1 | tee -a build.log
cd ../wh-sandbox && notangle -t8 Makefile.pamphlet > Makefile.inp \
        && mv Makefile.inp  Makefile.in
cd /export/home0/wspage/axiom-sandbox && /bin/sh ./config.status =
Makefile
config.status: creating Makefile
mkdir -p =
/export/home0/wspage/axiom-sandbox/build/i386-pc-solaris2.10/bin
mkdir -p =
/export/home0/wspage/axiom-sandbox/build/i386-pc-solaris2.10/lib
mkdir -p =
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/bin
mkdir -p =
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/lib
mkdir -p =
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/doc
mkdir -p =
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/share
mkdir -p
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/share/texmf=
/te
x
cd ./src &&
SPAD=/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10 =
SRC=/src
INT=/export/home0/wspage/axiom-sandbox/int
OBJ=/export/home0/wspage/axiom-sandbox/obj
INC=/export/home0/wspage/axiom-sandbox/../wh-sandbox/src/include =
NOISE="-o
/export/home0/wspage/axiom-sandbox/build/i386-pc-solaris2.10/trace"
VERSION="Axiom build-improvements branch 2006-03-28"
DOCUMENT=/export/home0/wspage/axiom-sandbox/build/scripts/document =
PLF=""
CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" =
LISP=lsp make
make[1]: Entering directory `/export/home0/wspage/axiom-sandbox/src'
cd ../../wh-sandbox/src && notangle -t8 Makefile.pamphlet > Makefile.inp =
\
        && mv Makefile.inp  Makefile.in
cd /export/home0/wspage/axiom-sandbox/src/../. && /bin/sh =
./config.status
src/Makefile
config.status: creating src/Makefile
make[1]: Leaving directory `/export/home0/wspage/axiom-sandbox/src'
make[1]: Entering directory `/export/home0/wspage/axiom-sandbox/src'
make[2]: Entering directory `/export/home0/wspage/axiom-sandbox/src/lib'
cd ../../../wh-sandbox/src/lib && notangle -t8 Makefile.pamphlet >
Makefile.inp \
        && mv Makefile.inp  Makefile.in
cd /export/home0/wspage/axiom-sandbox/src/lib/../../. && /bin/sh
./config.status src/lib/Makefile
config.status: creating src/lib/Makefile
make[2]: Leaving directory `/export/home0/wspage/axiom-sandbox/src/lib'
make[2]: Entering directory `/export/home0/wspage/axiom-sandbox/src/lib'
/export/home0/wspage/axiom-sandbox/src/lib/../.././build/scripts/document=

--tangle --output=bsdsignal.c
../../../wh-sandbox/src/lib/bsdsignal.c.pamphlet
gcc -O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -c
-I/export/home0/wspage/wh-sandbox/src/include
-I/export/home0/wspage/axiom-sandbox/src/lib/../.././config
-I/usr/openwin/include  bsdsignal.c -o bsdsignal.o
bsdsignal.c: In function `bsdSignal':
bsdsignal.c:59: error: `SA_INTERRUPT' undeclared (first use in this
function)
bsdsignal.c:59: error: (Each undeclared identifier is reported only once
bsdsignal.c:59: error: for each function it appears in.)
make[2]: *** [bsdsignal.o] Error 1
make[2]: Leaving directory `/export/home0/wspage/axiom-sandbox/src/lib'
make[1]: *** [all-lib] Error 2
make[1]: Leaving directory `/export/home0/wspage/axiom-sandbox/src'
make: *** [all-src] Error 2
-bash-3.00$

-----------

Perhaps wh-sandbox needs some more of the autoconf magic that
is now part of build-improvements?

Can you suggest how to proceed?

\start
Date: 08 Apr 2007 18:16:02 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: Axiom on Solaris 10.2 x86

Bill Page writes:

[...]

| > | I will revert the earlier patch and svn update and try again.
| > | 
| > | The first thing to check immedately after ./configure is the
| > | src/sman/Makefile, I guess...
| > 
| > Yes, see what gets substituted there.
| > 
| 
| I think the build is ok now and I can start AXIOMsys. But I
| do get an error when I try hyperdoc:
| 
| -bash-3.00$ axiom
| (HyperDoc) read_ht_db: No ht.db file found

Yes, currently there is a breakage concerning HyperDoc that I
introduced some time ago but never got around to fix (as I don't use
it).  I'll refocus on that.  Sorry.
Many thanks for testing and reporting back.

\start
Date: 08 Apr 2007 18:13:55 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: Axiom on Solaris 10.2 x86

Bill Page writes:

| Gaby,
| 
| On April 8, 2007 2:13 PM you wrote:
| > ... 
| > Bill Page writes:
| > | 
| > | Sorry, the earlier patch also did not work on 'i386-pc-solaris2.10'.
| > | The same error as before. No -lsocket was added to the gcc command.
| > 
| > Huh.  It was added on my machine and compiler-link failed
| > precisely because the system ld could not find -lsocket.  I have
| > special cased solaris.  The build was OK on both i686-suse-linux
| > and x86_64-suse-linux.  If your build fails, please send me again
| > your config.log. 
| 
| Perhaps I just screwed up the previous patch last night. The build
| completed this time but I did have to make the following additional
| patch:
| 
| -bash-3.00$ svn diff src/sman/Makefile.pamphlet
| Index: src/sman/Makefile.pamphlet
| ===================================================================
| --- src/sman/Makefile.pamphlet  (revision 496)
| +++ src/sman/Makefile.pamphlet  (working copy)
| @@ -35,13 +35,13 @@
|  session_sources = session.c
|  session_SOURCES = $(addsuffix .pamphlet, $(session_sources))
|  session_objects = $(session_sources:.c=.$(OBJEXT))
| -session_LDADD = -L$(build_libdir) -lspad
| +session_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
|  session_DEPENDENCIES =
| 
|  spadclient_sources = spadclient.c
|  spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
|  spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
| -spadclient_LDADD = -L$(build_libdir) -lspad
| +spadclient_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
|  spadclient_DEPENDENCIES =
| 
|  sman_sources = sman.c

Yes, you're right.  Please commit that if you can.  Many thanks!

\start
Date: 08 Apr 2007 18:18:34 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: building wh-sandbox on Axiom on Solaris 10.2 x86

Bill Page writes:

| Waldek,
| 
| My attempt to build wh-sandbox from the most recent source
| fails with a configure error:
| 
| -bash-3.00$ svn co
| https://axiom.svn.sourceforge.net/svnroot/axiom/branches/wh-sandbox
| ...
| A    wh-sandbox/configure.ac.pamphlet
| A    wh-sandbox/axiomlogo.jpg
| Checked out revision 496.
| -bash-3.00$ mkdir axiom-sandbox
| -bash-3.00$ cd axiom-sandbox
| -bash-3.00$ ../wh-sandbox/configure 2>&1 | tee build
| ...
| config.status: creating src/doc/Makefile
| mkdir: "build/scripts": Not a directory
| config.status: error: cannot create directory "build/scripts"
| 
| -------
| 
| Any ideas?

Waldek recently did cherry picking of various patches from
build-improvements without properly labelling them, and added 
tweaks of his own.  He might know more about that issue than I do.

\start
Date: 08 Apr 2007 19:13:55 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: building wh-sandbox on Axiom on Solaris 10.2 x86

Bill Page writes:

| Waldek,
| 
| My attempt to build wh-sandbox from the most recent source
| fails with a configure error:
| 
| -bash-3.00$ svn co
| https://axiom.svn.sourceforge.net/svnroot/axiom/branches/wh-sandbox
| ...
| A    wh-sandbox/configure.ac.pamphlet
| A    wh-sandbox/axiomlogo.jpg
| Checked out revision 496.
| -bash-3.00$ mkdir axiom-sandbox
| -bash-3.00$ cd axiom-sandbox
| -bash-3.00$ ../wh-sandbox/configure 2>&1 | tee build
                                                 ^^^^^^

Hmm, you're giving both a file and a directory the same name; that is
likely to cause troubles.

\start
Date: 08 Apr 2007 20:35:47 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: HyperDoc

Bill Page writes:

[...]

| I think the build is ok now and I can start AXIOMsys. But I
| do get an error when I try hyperdoc:
| 
| -bash-3.00$ axiom
| (HyperDoc) read_ht_db: No ht.db file found

OK, I found where the bug comes from.  It is a very stupid bug.

A while ago, I added support for relative paths -- that was a
necessary step to make axiom.build-improvements buildable on Windows.
I believe that is when HyperDoc stopped working.  The reason?
Well, a very sloppy logic in the HyperDoc source code. 


More precisely, the function src/hyper/addfile.c:build_ht_filename

static int
build_ht_filename(char *fname, char *aname, char *name)
{
    char cdir[256];
    char *c_dir;
    char *HTPATH;
    char *trace;
    char *trace2;
    int ht_file;

    if (cwd(name)) {
        /* user wants to use the current working directory */
        c_dir = (char *) getcwd(cdir, 254);
        strcpy(fname, c_dir);

        /* Now add the rest of the filename */
        strcat(fname, "/");
        strcat(fname, &name[2]);

        /** now copy the actual file name to addname **/
        for (trace = &name[strlen(name)]; trace != name &&
             (*trace != '/'); trace--);
        if (trace == name) {
            fprintf(stderr, "ht_open_file: Didn't expect a filename like %s\n",
                    name);
            exit(-1);
        }
        trace++;
        strcpy(aname, trace);

        /** add  the .ht extension if needed **/
        extend_ht(aname);
        extend_ht(fname);

        /* Now just try to access the file */
        return (access(fname, R_OK));
    }
    else if (pathname(name)) {
        /* filename already has the path specified */
        strcpy(fname, name);

        /** now copy the actual file name to addname **/
        for (trace = &name[strlen(name)]; trace != name &&
             (*trace != '/'); trace--);
        if (trace == name) {
            fprintf(stderr, "ht_open_file: Didn't expect a filename like %s\n",
                    name);
            exit(-1);
        }
        trace++;
        strcpy(aname, trace);

        /** add  the .ht extension if needed **/
        extend_ht(aname);
        extend_ht(fname);

        /* Now just try to access the file */
        return (access(fname, R_OK));
    }
    else {/** If not I am going to have to append path names to it **/
        HTPATH = (char *) getenv("HTPATH");
        if (HTPATH == NULL) {
        /** The user does not have a HTPATH, so I will use the the directory
        $AXIOM/share/hypertex/pages/ as the default path ***/
          char *spad = (char *) getenv("AXIOM");
          if (spad == NULL) {
            fprintf(stderr,
            "ht_file_open:Cannot find ht data base: setenv HTPATH or AXIOM\n");
             exit(-1);
          }
          HTPATH = (char *) halloc(1024 * sizeof(char), "HTPATH");
          strcpy(HTPATH, spad);
          strcat(HTPATH, "/share/hypertex/pages");
        }

        /** Now that I have filled HTPATH, I should try to open a file by the
          given name **/
        strcpy(aname, name);
        extend_ht(aname);
        for (ht_file = -1, trace2 = HTPATH;
             ht_file == -1 && *trace2 != '\0';) {
            for (trace = fname; *trace2 != '\0' && (*trace2 != ':');)
                *trace++ = *trace2++;
            *trace++ = '/';
            *trace = 0;
            if (!strcmp(fname, "./")) {
                /** The person wishes me to check the current directory too **/
                getcwd(fname, 256);
                strcat(fname, "/");
            }
            if (*trace2)
                trace2++;
            strcat(fname, aname);
            ht_file = access(fname, R_OK);
        }
        return (ht_file);
    }
}


The comment fragment

    if (cwd(name)) {
        /* user wants to use the current working directory */

is deceptive because here is how it is deduced that user wanst the
current working directory


   #define cwd(n) ((n[0] == '.' && n[1] == '/')?(1):(0))


That is only the first two characters are tested!
It happens that in the build machinery we use things like

  ./../../target/i686-ps-linux-gnu

and teh cwd() macro thinks that that is current working directory!
Ahem.

The other fragment

    else if (pathname(name)) {
        /* filename already has the path specified */

is equally deceptive.

\start
Date: Sun, 08 Apr 2007 21:03:12 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: building wh-sandbox on Axiom on Solaris 10.2

Quoting Bill Page:

>
> Perhaps wh-sandbox needs some more of the autoconf magic that
> is now part of build-improvements?
>
> Can you suggest how to proceed?

Cherry picking from axiom.build-improvements is asking for trouble.
I would have thought that merge from axiom.build-improvements should
be done whole sale to keep in sync.  If you find a problem that needs
addressing please let us know (and even better send a patch :-).

\start
Date: Mon, 9 Apr 2007 01:39:29 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: FW: Axiom on Solaris 10.2 x86

Gaby,

On April 8, 2007 7:14 PM you wrote:
> ...
> Bill Page wrote: 
> | Perhaps I just screwed up the previous patch last night. The build
> | completed this time but I did have to make the following additional
> | patch:
> | 
> | -bash-3.00$ svn diff src/sman/Makefile.pamphlet
> | Index: src/sman/Makefile.pamphlet
> | ===================================================================
> | --- src/sman/Makefile.pamphlet  (revision 496)
> | +++ src/sman/Makefile.pamphlet  (working copy)
> | @@ -35,13 +35,13 @@
> |  session_sources = session.c
> |  session_SOURCES = $(addsuffix .pamphlet, $(session_sources))
> |  session_objects = $(session_sources:.c=.$(OBJEXT))
> | -session_LDADD = -L$(build_libdir) -lspad
> | +session_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
> |  session_DEPENDENCIES =
> | 
> |  spadclient_sources = spadclient.c
> |  spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
> |  spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
> | -spadclient_LDADD = -L$(build_libdir) -lspad
> | +spadclient_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
> |  spadclient_DEPENDENCIES =
> | 
> |  sman_sources = sman.c
> 
> Yes, you're right.  Please commit that if you can.  Many thanks!
> 

Yes, I could commit this change but I just noticed that I am using
autoconf-2.61 so 'build-setup.sh' produces a lot of "housekeeping"
changes in 'configure'. Do you want me to include the new onfigure
in the commit? Or will you update it later?

\start
Date: Mon, 9 Apr 2007 02:56:25 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: boot : valid type checker

On April 7, 2007 6:53 AM Gregory Vanuxem wrote:
> ... 
> (8) -> DirectProduct(3,IntegerNumberSystem)
> 
>    (8)  DirectProduct(3,IntegerNumberSystem)
>                                       Type: Domain
> (9) -> [1,2,3]::%
>  
>    >> System error:
>    NIL is not of type CONS.
> 
> The interpeter considers DirectProduct(3,IntegerNumberSystem) 
> as a valid domain (type ?) :-(

Yes it is valid according to the defintion

  DirectProduct(dim: NonNegativeInteger,R: Type)

It is odd perhaps, that R is specified as just Type, but this
is technically possible. What you should have written above is
something like:

  (9) -> [Integer,SingleInteger,MachineInteger]::%

not [1,2,3] since IntegerNumberSystem is a category and only
domains belong to categories, not the objects of some domain.

But my expression (9) above fails for another reason - because
currently Axiom has no domain named Domain.

(10) -> [Integer,Integer,Integer]

   >> System error:
   The function |Domain| is undefined.

I think this can be fixed. See the page

http://wiki.axiom-developer.org/209TheFunctionDomainIsUndefined

The example is in Aldor but this can be more easily written in Spad.
Axiom needs a domain called Domain whose objects are domains. But
this idea still needs more work.

> ...
> Think of a category, here, as the set of matrices over a ring
> (Ring being a category in the Axiom sense).
>

Well there is the category:

MatrixCategory(R: Ring,Row: FiniteLinearAggregate R,
                       Col: FiniteLinearAggregate R)

(10) -> Matrix(Integer) has MatrixCategory(Integer, Vector Integer,
                                           Vector Integer)

   (7)  true

                                                 Type: Boolean

I think it is reasonable to describe MatrixCategory as the set
of matrices over a ring.

> 
> > > The nirvana would be a function that accepts things like
> > > Matrix(Join(Foo,Bar)) [1].
> > 
> > I do not understand what you mean by this.
> 
> I want to know if I can extract information from what I call a
> valid type, i.e:
> 
> )bo Matrix(Join(Field(),ConvertibleTo(InputForm())))
> 
> (|Matrix| (|Join| (|Field|) (|ConvertibleTo| (|InputForm|))))
> Value = #<(SIMPLE-VECTOR 72) {10053B01FF}>
> 
> I'm interested by this vector :-).
> 

Do you suppose in this example that Matrix is something other than
what is currently defined in the Axiom library? If so, then perhaps
"Matrix" is not a good name for what you want.

I suppose that Join also that Join must be a category constructor
which the interpreter might also have to understand.

\start
Date: Mon, 9 Apr 2007 03:06:19 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: building wh-sandbox on Axiom on Solaris 10.2

On April 8, 2007 10:03 PM Gaby wrote:
> 
> Quoting Bill Page:
> 
> >
> > Perhaps wh-sandbox needs some more of the autoconf magic that
> > is now part of build-improvements?
> >
> > Can you suggest how to proceed?
> 
> Cherry picking from axiom.build-improvements is asking for
> trouble. I would have thought that merge from build-improvements
> should be done whole sale to keep in sync.

That concerns me a lot. I think that both Gaby and Waldek have done
an enormous amount of really important work on the Axiom build system
and this should continue. But for other axiom developers and axiom
users to really benefit from *both* of these efforts, I think we need
to merge the results at the current stage of development into a new
Axiom Silver distribution that builds on as many systems as possible
and which includes critical fixes to HyperDoc and some very important
fixes to Axiom's algebra.

What can I do to encourage you (Waldek and Gaby) to devote some
time to such a merge?

> If you find a problem that needs addressing please let us know
> (and even better send a patch :-).
> 

I will be glad to do that when/if I can.

\start
Date: 09 Apr 2007 10:06:30 +0200
From: Martin Rubey
To: Bill Page
Subject: re: building wh-sandbox on Axiom on Solaris 10.2 x86
Cc: Waldek Hebisch, Gabriel Dos Reis

> > Cherry picking from axiom.build-improvements is asking for
> > trouble. I would have thought that merge from build-improvements
> > should be done whole sale to keep in sync.
> 
> That concerns me a lot. I think that both Gaby and Waldek have done
> an enormous amount of really important work on the Axiom build system
> and this should continue. But for other axiom developers and axiom
> users to really benefit from *both* of these efforts, I think we need
> to merge the results at the current stage of development into a new
> Axiom Silver distribution that builds on as many systems as possible
> and which includes critical fixes to HyperDoc and some very important
> fixes to Axiom's algebra.
> 
> What can I do to encourage you (Waldek and Gaby) to devote some
> time to such a merge?

I really have to second that. It is not unlikely that I lost a very important
user (Neil Sloane) - because of difficulties to build.  This might as well ruin
the success of my guessing package in the scientific community, since: "if
Sloane wasn't able to build it, why should I try?"

Of course, I am in a bad position, since I did not contribute anything but
algebra code, so I can only beg.

PLEASE PLEASE merge!

Second most important thing: make HyperDoc run on Windows. I'm in the process
of advertising Axiom for the departments of Mathematics and physics at Vienna
University, since they are going to take a decision between Maple and
Mathematica.  One of the major issues is about integrated help
functionality. With Waldek's patches to HyperDoc, it is *really* usable, and it
seems that it will take a long time to have the same functionality on a
webbrowser, given that there is so much discussion to do.

I do the best I can to improve the algebra and to attract more scientists to
use and improve axiom, but I have to rely on you to make Axiom build and
organize all these improvements. I'm well aware of the fact that many of you
are also more interested in the algebra than in the build process... And I am
really grateful for all your work!

\start
Date: Mon, 9 Apr 2007 15:24:28 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: HyperDoc

Gabriel Dos Reis wrote:

> A while ago, I added support for relative paths -- that was a
> necessary step to make axiom.build-improvements buildable on Windows.

Why do you want relative paths on Windows?  AFAICS relative paths
cause a lot of trouble and the simplest way to handle them is
converting to absolute path as soon as possible.

\start
Date: Mon, 9 Apr 2007 15:59:25 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Axiom on Solaris 10.2 x86
Cc: Gabriel Dos Reis

Bill Page wrote:
> Waldek,
> 
> Ok, I think I have a real problem to report this time. The
> configure worked but make fails as shown below:
> 

> bsdsignal.c: In function `bsdSignal':
> bsdsignal.c:59: error: `SA_INTERRUPT' undeclared (first use in this
> function)
> bsdsignal.c:59: error: (Each undeclared identifier is reported only once
> bsdsignal.c:59: error: for each function it appears in.)
> make[2]: *** [bsdsignal.o] Error 1
> make[2]: Leaving directory `/export/home0/wspage/axiom-sandbox/src/lib'
> make[1]: *** [all-lib] Error 2
> make[1]: Leaving directory `/export/home0/wspage/axiom-sandbox/src'
> make: *** [all-src] Error 2
> -bash-3.00$
> 
> -----------
> 
> Perhaps wh-sandbox needs some more of the autoconf magic that
> is now part of build-improvements?
> 
> Can you suggest how to proceed?
> 

Configure machinery should be in place, but build-improvements
also changed src/lib files to use results of configure run.
So one have to merge changes to src/lib (and possibly also
other C parts).

\start
Date: 09 Apr 2007 09:37:11 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: HyperDoc

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| 
| > A while ago, I added support for relative paths -- that was a
| > necessary step to make axiom.build-improvements buildable on Windows.
| 
| Why do you want relative paths on Windows?  AFAICS relative paths
| cause a lot of trouble and the simplest way to handle them is
| converting to absolute path as soon as possible.

I beg to disagree.  

\start
Date: Mon, 9 Apr 2007 18:02:26 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: HyperDoc

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | Gabriel Dos Reis wrote:
> | 
> | > A while ago, I added support for relative paths -- that was a
> | > necessary step to make axiom.build-improvements buildable on Windows.
> | 
> | Why do you want relative paths on Windows?  AFAICS relative paths
> | cause a lot of trouble and the simplest way to handle them is
> | converting to absolute path as soon as possible.
> 
> I beg to disagree.  
> 

Could you elaborate: you say that relative paths are needed on
Windows but you did not say why?

\start
Date: Mon, 09 Apr 2007 11:25:54 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: HyperDoc

Quoting Waldek Hebisch:

> Gabriel Dos Reis wrote:
>> Waldek Hebisch writes:
>>
>> | Gabriel Dos Reis wrote:
>> |
>> | > A while ago, I added support for relative paths -- that was a
>> | > necessary step to make axiom.build-improvements buildable on Windows.
>> |
>> | Why do you want relative paths on Windows?  AFAICS relative paths
>> | cause a lot of trouble and the simplest way to handle them is
>> | converting to absolute path as soon as possible.
>>
>> I beg to disagree.
>>
>
> Could you elaborate: you say that relative paths are needed on
> Windows but you did not say why?

try to build Axiom out of source under MingW.

It gave me lots headache, only to discover later that the absolute
path seen by configure is not the one other tools were expecting.
A workaround was to use "pwd -W" -- only under mingw, because -W
is a non-standard option, only to get into another whoop.

One thing I used to do on the windows machine I was testing
the build is to checkout the working directory on a USB key,
boot under windows, try the build there, fix things, and reboot
back under linux.  That does not work if paths are required to
be absolute -- don't ask me why.

Finally, I solved the issue by making Axiom to accept relative path.

Please notice that what it means is that none of the Axiom component
should assume that $AXIOM is an absolute path; they should only care
that it is a valid path.  The software isn't more difficult or less robust to
write that way.  At installation time, $AXIOM can be set to an absolute
path, which makes all other paths absolute.  Note also that Axiom
is designed to be "re-routed".

There is nothing gained in writing the components to assume that
all paths are absolute.  We could as well assume that Earth is flat.

\start
Date: 09 Apr 2007 09:47:42 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: building wh-sandbox on Axiom on Solaris 10.2 x86

Waldek Hebisch writes:

| Bill Page wrote:
| > Waldek,
| > 
| > Ok, I think I have a real problem to report this time. The
| > configure worked but make fails as shown below:
| > 
| 
| > bsdsignal.c: In function `bsdSignal':
| > bsdsignal.c:59: error: `SA_INTERRUPT' undeclared (first use in this
| > function)
| > bsdsignal.c:59: error: (Each undeclared identifier is reported only once
| > bsdsignal.c:59: error: for each function it appears in.)
| > make[2]: *** [bsdsignal.o] Error 1
| > make[2]: Leaving directory `/export/home0/wspage/axiom-sandbox/src/lib'
| > make[1]: *** [all-lib] Error 2
| > make[1]: Leaving directory `/export/home0/wspage/axiom-sandbox/src'
| > make: *** [all-src] Error 2
| > -bash-3.00$
| > 
| > -----------
| > 
| > Perhaps wh-sandbox needs some more of the autoconf magic that
| > is now part of build-improvements?
| > 
| > Can you suggest how to proceed?
| > 
| 
| Configure machinery should be in place, but build-improvements
| also changed src/lib files to use results of configure run.
| So one have to merge changes to src/lib (and possibly also
| other C parts).

That was the point of doing the exercise -- things are detected
at confuguration time and sub-components use that results.

\start
Date: 09 Apr 2007 11:42:42 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: HyperDoc

Gabriel Dos Reis writes:

| Quoting Waldek Hebisch:
| 
| > Gabriel Dos Reis wrote:
| >> Waldek Hebisch writes:
| >>
| >> | Gabriel Dos Reis wrote:
| >> |
| >> | > A while ago, I added support for relative paths -- that was a
| >> | > necessary step to make axiom.build-improvements buildable on Windows.
| >> |
| >> | Why do you want relative paths on Windows?  AFAICS relative paths
| >> | cause a lot of trouble and the simplest way to handle them is
| >> | converting to absolute path as soon as possible.
| >>
| >> I beg to disagree.
| >>
| >
| > Could you elaborate: you say that relative paths are needed on
| > Windows but you did not say why?
| 
| try to build Axiom out of source under MingW.
| 
| It gave me lots headache, only to discover later that the absolute
| path seen by configure is not the one other tools were expecting.
| A workaround was to use "pwd -W" -- only under mingw, because -W
| is a non-standard option, only to get into another whoop.


Oh, yeah, one more thing: mingw uses windows native tools, in
particular options  start with forward slash.  I don't remember the
exact details, but at some point some of the absolute paths (using
Unix-style notation) started being interpreted as options; it isn't funny.

\start
Date: Mon, 09 Apr 2007 10:52:37 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: FW: Axiom on Solaris 10.2 x86

Quoting Bill Page:

> Gaby,
>
> On April 8, 2007 7:14 PM you wrote:
>> ...
>> Bill Page wrote:
>> | Perhaps I just screwed up the previous patch last night. The build
>> | completed this time but I did have to make the following additional
>> | patch:
>> |
>> | -bash-3.00$ svn diff src/sman/Makefile.pamphlet
>> | Index: src/sman/Makefile.pamphlet
>> | ===================================================================
>> | --- src/sman/Makefile.pamphlet  (revision 496)
>> | +++ src/sman/Makefile.pamphlet  (working copy)
>> | @@ -35,13 +35,13 @@
>> |  session_sources = session.c
>> |  session_SOURCES = $(addsuffix .pamphlet, $(session_sources))
>> |  session_objects = $(session_sources:.c=.$(OBJEXT))
>> | -session_LDADD = -L$(build_libdir) -lspad
>> | +session_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
>> |  session_DEPENDENCIES =
>> |
>> |  spadclient_sources = spadclient.c
>> |  spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
>> |  spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
>> | -spadclient_LDADD = -L$(build_libdir) -lspad
>> | +spadclient_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
>> |  spadclient_DEPENDENCIES =
>> |
>> |  sman_sources = sman.c
>>
>> Yes, you're right.  Please commit that if you can.  Many thanks!
>>
>
> Yes, I could commit this change but I just noticed that I am using
> autoconf-2.61 so 'build-setup.sh' produces a lot of "housekeeping"
> changes in 'configure'. Do you want me to include the new onfigure
> in the commit? Or will you update it later?

OK, I'll do it.

\start
Date: Mon, 9 Apr 2007 19:44:10 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: HyperDoc

Gabriel Dos Reis wrote:
> Quoting Waldek Hebisch:
> > Could you elaborate: you say that relative paths are needed on
> > Windows but you did not say why?
> 
> try to build Axiom out of source under MingW.
> 
> It gave me lots headache, only to discover later that the absolute
> path seen by configure is not the one other tools were expecting.
> A workaround was to use "pwd -W" -- only under mingw, because -W
> is a non-standard option, only to get into another whoop.
>

I did not try to build Axiom (I tried GCL first, and it seems that
GCL build fails unless you have the exact versions of software
used by Mike Thomas).  I know that Mysys (and Cygwin) is remapping
files (I hit the problem once).  MingW executables expect native
Windows paths, but the build tools are Mysys executables and remap
paths.  So if yonemix calls to  MingW and Mysys executables
(which happens if you run freshly build MingW binaries) one
have trouble.  My solution was to use paths with explicit drive
letter: AFAIK such paths are not remapped.

BTW: Without drive letter Windows path is still relative with
respect to current drive.

> One thing I used to do on the windows machine I was testing
> the build is to checkout the working directory on a USB key,
> boot under windows, try the build there, fix things, and reboot
> back under linux.  That does not work if paths are required to
> be absolute -- don't ask me why.
> 
> Finally, I solved the issue by making Axiom to accept relative path.
> 
> Please notice that what it means is that none of the Axiom component
> should assume that $AXIOM is an absolute path; they should only care
> that it is a valid path.  The software isn't more difficult or less robust to
> write that way.  At installation time, $AXIOM can be set to an absolute
> path, which makes all other paths absolute.  Note also that Axiom
> is designed to be "re-routed".
> 
> There is nothing gained in writing the components to assume that
> all paths are absolute.  We could as well assume that Earth is flat.
> 

Relative $AXIOM have to change when you change directory.  This
means that some variable settings have to be repeated.  Passing
of filenames to programs working in different directory become
harder.  Also relative paths are likely to hardwire relative positions
of directories, making change harder.

Recently I noticed that in Lisp relative paths behave in funny way
(it looks that Axiom is frequently calling truename to make
paths absolute and avoid problem).

So there are costs (IMHO substantial) to relative paths.

Later:
> Oh, yeah, one more thing: mingw uses windows native tools, in
> particular options  start with forward slash.  I don't remember the
> exact details, but at some point some of the absolute paths (using
> Unix-style notation) started being interpreted as options; it isn't funny.

Explicit drive letter should cure this problem.

\start
Date: Mon, 9 Apr 2007 13:03:45 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch, Gabriel Dos Reis
Subject: Relative vs. Absolute paths (was Re: HyperDoc)

--- Waldek Hebisch wrote:

> Relative $AXIOM have to change when you change directory.

Um.  I'm not quite following you here Waldek - isn't that the whole
point of relative linking?  We set $AXIOM once to define where the
toplevel Axiom directory is located, and then everything else changes
automatically?

> This means that some variable settings have to be repeated.  Passing
> of filenames to programs working in different directory become
> harder.

Can you give an example?  I'm missing something, I think - what is the
difference between having $AXIOM/lib/lib1.spad vs.
/usr/local/axiom/mnt/linux/lib/lib1.spad?  If I am in $AXIOM/lib and I
tell the program to output to $AXIOM/bin, or I want a file in ../input/
or $AXIOM/input, (or for that matter $AXIOM/$INPUT if you want to
generalize) those should Just Work.  Perhaps lisp has some limitations
here?

> Also relative paths are likely to hardwire relative
> positions of directories, making change harder.

Now I'm really confused.  How do absolute pathnames not hardwire things
as much as relative pathnames?

> Recently I noticed that in Lisp relative paths behave in funny way
> (it looks that Axiom is frequently calling truename to make
> paths absolute and avoid problem).

I confess I have not fully understood Lisp's handling of paths as yet,
so perhaps there are some issues I am not aware of.

> So there are costs (IMHO substantial) to relative paths.
> 
> Later:
> > Oh, yeah, one more thing: mingw uses windows native tools, in
> > particular options  start with forward slash.  I don't remember the
> > exact details, but at some point some of the absolute paths (using
> > Unix-style notation) started being interpreted as options; it isn't
> funny.
> 
> Explicit drive letter should cure this problem.

Shouldn't Axiom not care at all what drive or directory it is in?  I
would think the only thing most of the system should need to know is
where other parts of the system are relative to the toplevel Axiom
directory - where that toplevel directory is located shouldn't make
much difference.  

I am sure I'm missing something important - is there an example where
the relative merits of the two approaches can be clearly seen?

\start
Date: 09 Apr 2007 16:31:18 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: HyperDoc

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > Quoting Waldek Hebisch:
| > > Could you elaborate: you say that relative paths are needed on
| > > Windows but you did not say why?
| > 
| > try to build Axiom out of source under MingW.
| > 
| > It gave me lots headache, only to discover later that the absolute
| > path seen by configure is not the one other tools were expecting.
| > A workaround was to use "pwd -W" -- only under mingw, because -W
| > is a non-standard option, only to get into another whoop.
| >
| 
| I did not try to build Axiom 

That might be why we have a different opinion on the issue.

| (I tried GCL first, and it seems that
| GCL build fails unless you have the exact versions of software
| used by Mike Thomas).  I know that Mysys (and Cygwin) is remapping
| files (I hit the problem once).  MingW executables expect native
| Windows paths,

I've installed many other tools, and I did not have to specifiy the
exact drive letter. 

| but the build tools are Mysys executables and remap
| paths.  So if yonemix calls to  MingW and Mysys executables
| (which happens if you run freshly build MingW binaries) one
| have trouble.  My solution was to use paths with explicit drive
| letter: AFAIK such paths are not remapped.

I tried that one to with my USE key; did not work.
Anyway; the issue is solved now.  

If you want to re-solve it, please do so but please don't break my
builds, otherwise I'll be very unhappy.

[...]

| Relative $AXIOM have to change when you change directory.

Yes, but there are only *two* such variables and they are always set to
the same syntactic variable which Autoconf computes automatically for
me.  One of the variables need to be changed any, where absolute path
or not.

| This
| means that some variable settings have to be repeated.

I consider this a feature -- Axiom, was designed that way, whether you
use absolute path or not.  So this is a ed herring.

| Passing
| of filenames to programs working in different directory become
| harder.  Also relative paths are likely to hardwire relative positions
| of directories, making change harder.

That does not follow.  Sorry.  Currently, that is what Axiom does, but
it does not mean that it has to do that because of relative path.  As
a matter of fact all the hardwiring of paths predate my work.

| 
| Recently I noticed that in Lisp relative paths behave in funny way
| (it looks that Axiom is frequently calling truename to make
| paths absolute and avoid problem).

in several places, yes.  That predates the relative path support.
But please describe the problem in detail.  Notice also that GCL will
accept that you designate an "alternate" system directory with the
-lib option.
If you save to disk, many Lisp systems will forget forever where they
come from.  

| So there are costs (IMHO substantial) to relative paths.

Please be more specific; I've run into many build path issues, almost
all of them can be traced by to absolute path.  If there are costs, it
is one due to NOT coding the components without assming relative path.
Again, none of the components need absolute paths.  They just care
that a path is valid.

| 
| Later:
| > Oh, yeah, one more thing: mingw uses windows native tools, in
| > particular options  start with forward slash.  I don't remember the
| > exact details, but at some point some of the absolute paths (using
| > Unix-style notation) started being interpreted as options; it isn't funny.
| 
| Explicit drive letter should cure this problem.

It did not for me.

I don't intend to spend more resources on a problem I consider solved.
However, you're free to do so, but please don't break my builds; I've
burnt enough cycles in that issue.

\start
Date: 09 Apr 2007 16:48:09 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Relative vs. Absolute paths (was Re: HyperDoc)

Cliff Yapp writes:

| --- Waldek Hebisch wrote:
| 
| > Relative $AXIOM have to change when you change directory.
| 
| Um.  I'm not quite following you here Waldek - isn't that the whole
| point of relative linking?  We set $AXIOM once to define where the
| toplevel Axiom directory is located, and then everything else changes
| automatically?

Yes, the old build does that.  I did not change anything in that
respect.  The only thing that changed is what can be a value for
AXIOM.

| > This means that some variable settings have to be repeated.  Passing
| > of filenames to programs working in different directory become
| > harder.
| 
| Can you give an example?  I'm missing something, I think - what is the
| difference between having $AXIOM/lib/lib1.spad vs.
| /usr/local/axiom/mnt/linux/lib/lib1.spad?  If I am in $AXIOM/lib and I
| tell the program to output to $AXIOM/bin, or I want a file in ../input/
| or $AXIOM/input, (or for that matter $AXIOM/$INPUT if you want to
| generalize) those should Just Work.  Perhaps lisp has some limitations
| here?

I don't know.  I'm happy that I can re-root Axiom, and Axiom was
designed that way.  I'm unhappy about some other choices, but they
seem minor with respect to what I ran into.

[...]

| Shouldn't Axiom not care at all what drive or directory it is in? 

Absolutely.  
Furthermore, I really, really, really care that users should simply
say 

    ./configure && make && make install

and be done with it.  Most users don't want, or don't have time to
fiddle with the build machinery.  If the try two times and it did not
work, they are likely to stay away from Axiom, not matter how Great we
think it is.  That is a simple fact.  We can argue that we should have
many binaries that people can download, but that is a separate issue
that does not change the simplicity of the build -- personally, I
don't like downloading binaries unless it is properly signed and I can
trace back to the author in can it turned out to be a scam. 

Now, that simple requirement means that the complexity has to be
shifted somewhere else; I don't want the build machinery to be
complex; relative paths helped me port to windows in reasonable amount
of time, and I do consider it important to facilitate porting without
assuming much on the host system.  Although my primary machine
is now windows only (because GNU/Linux cannot fully support it), I don't
intend to become a windows developer -- I don't have the time for
that.  Consequently, it is important that I don't spend too
much time solving windows only issues.  Your mileage may vary.

\start
Date: Mon, 9 Apr 2007 21:08:21 -0400
From: Bill Page
To: Markus Cozowicz
Subject: Axiom on MediaWiki (was: Axiom)

Markus,

I hope you do not mind that I am copying this to the Axiom
developer mailing list. I think there may be some other
people here who are interested in this subject.

On April 9, 2007 6:43 PM Markus Cozowicz wrote:

> I'm actually trying to integrate Axiom into MediaWiki. I'm
> using it to write my statistics homework (www.eisber.net/StatWiki).

Well, I thinks that's a pretty ambitious project just to do
your homework! :-) But I think this is interesting for much
more than that.

> MediaWiki is written in PHP.

Yes. Very famous. It is the wiki software behind Wikipedia.
I think it is a very good choice (except for PHP, but that's
a different story).

> I'm not sure if I actually want to properly interface with
> Axiom, as I'm only interested in the generated latex, that
> needs to be piped into texvc (yet another binary - the latex
> interface used in MediaWiki).

I don't know what you mean exactly by "properly interface with
Axiom". Axiom can generate LaTeX output for the results that it
calculates. I assume that if you are interested in Axiom, you
are also interested in symbolic computer algebra in some form
or other - otherwise I don't see much point in using Axiom just
to generate LaTeX output. I think you would find it rather
awkward if that was all you wanted it to do.

I suppose that you are familiar with the Axiom Wiki web site:
http://wiki.axiom-developer.org
If you are using Axiom for statistics - even if it is just for
a course - then you are certainly welcome to use this web site
(which is publically available) or it's sister portal site:
http://portal.axiom-developer.org
where you can log-in and control who gets access to the pages
you prepare. We are always interested in more examples of
applications where Axiom can be used. Your exercises might
help other people realize how Axiom can be used in their
own situation.

As you can discover from the wiki site, these web sites are
based on Zwiki, Zope and Python - quite different from most
PHP applications although they accomplish mostly the same
thing in the end.

If you are more interested in continuing the development of
a general purpose MediaWiki plug-in that allows MediaWiki to
send commands to Axiom and display the results on a wiki page
in nicely LaTeX typeset form, then as an Axiom developer I am
very interested in that. I would very much like to be able to
offer such an interface for Axiom to other MediaWiki users.
So I would be glad to help you with this.

> Can I disabled shell execution in Axiom? Because for security
> reason, I probably don't want anybody to execute arbitrary
> code on my server.

Axiom is not designed with this kind of security in mind, but
in the PHP interface to Axiom, it would be possible to intercept
commands which might execute arbitrary code and still leave a
significant subset of Axiom available to the user. If malicous
code is a serious risk, I think the best option would be to run
Axiom in a chroot environment or perhaps on a separate virtual
machine using Xen or other VM tool.

\start
Date: 09 Apr 2007 21:43:13 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: Axiom on Solaris 10.2 x86

Bill Page writes:

[...]

| Yes, I could commit this change but I just noticed that I am using
| autoconf-2.61 so 'build-setup.sh' produces a lot of "housekeeping"
| changes in 'configure'. Do you want me to include the new onfigure
| in the commit? Or will you update it later?

Bill --

Tha patch below addresses the issues you have raised:
  
  * It adds the additional C runtime libraries for linking programs
  * It brings HyperDoc back.

For the second point, 

  (1) I removed a workaround for Autoconf-2.59 bug, whereby
      top_builddir was left undefined -- therefore I added ./ to
      imply correct semantics.  Since that bug was fixed in
      Autoconf-2.60 and later, we don't need it anymore.

  (2) We were not telling htadd that we were building the system
      database.  Fixed by supplying the option "-s" so that htadd can
      look up the value of the AXIOM environment variable.

Tested on an x86_64-suse-linux.  Committed to build-improvements.

Please let me know if it works on your solaris box.

-- Gaby

2007-04-09  Gabriel Dos Reis  Gabriel Dos Reis

	* config/var-def.mk (axiom_top_builddir): Remove leading ./ now
	that we require Autoconf 2.60 and the Autoconf 2.59 bug is fixed.
	(axiom_targetdir): Likewise.
	(INC): Likewise.
	(AXIOM): Likewise.
	* configure.ac.pamphlet: Update version information.
	* configure.ac: Regenerate.
	* configure: Likewise.

src/hyper/
2007-04-09  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (${HYPER}/pages/ht.db): Tell htadd that we're
	building a system database.
	* Makefile.in: Regenerate.

src/sman/
2007-04-09  Bill Page  Bill Page

	* Makefile.pamphlet (session_LDADD): Add extrac C runtime libraries.
	(spadclient_LDADD): Likewise.
	* Makefile.in: Regenerate.

*** config/var-def.mk	(revision 15444)
--- config/var-def.mk	(local)
*************** axiom_abs_build_mandir = $(axiom_abs_bui
*** 123,129 ****
  axiom_abs_build_datadir = $(axiom_abs_builddir)/share
  axiom_abs_build_texdir = $(axiom_abs_build_datadir)/texmf/tex
  
! axiom_top_builddir = ./$(top_builddir)/build
  axiom_builddir = $(axiom_top_builddir)/$(build)
  axiom_build_bindir = $(axiom_builddir)/bin
  axiom_build_libdir = $(axiom_builddir)/lib
--- 123,129 ----
  axiom_abs_build_datadir = $(axiom_abs_builddir)/share
  axiom_abs_build_texdir = $(axiom_abs_build_datadir)/texmf/tex
  
! axiom_top_builddir = $(top_builddir)/build
  axiom_builddir = $(axiom_top_builddir)/$(build)
  axiom_build_bindir = $(axiom_builddir)/bin
  axiom_build_libdir = $(axiom_builddir)/lib
*************** axiom_c_macros = $(axiom_configdir)/axio
*** 138,144 ****
  LATEX = @LATEX@
  
  ## Staging directory for the target DESTDIR
! axiom_targetdir = ./$(top_builddir)/target/$(target)
  axiom_target_bindir = $(axiom_targetdir)/bin
  axiom_target_libdir = $(axiom_targetdir)/lib
  axiom_target_srcdir = $(axiom_targetdir)/src
--- 138,144 ----
  LATEX = @LATEX@
  
  ## Staging directory for the target DESTDIR
! axiom_targetdir = $(top_builddir)/target/$(target)
  axiom_target_bindir = $(axiom_targetdir)/bin
  axiom_target_libdir = $(axiom_targetdir)/lib
  axiom_target_srcdir = $(axiom_targetdir)/src
*************** axiom_target_texdir = $(axiom_target_dat
*** 150,156 ****
  ## Where Axiom keeps the tarballs for optional components
  axiom_optional_srcdir = $(abs_top_srcdir)/zips
  
! INC=./$(top_srcdir)/src/include
  PLF=@PLF@
  CCF=@CCF@
  LDF=@LDF@
--- 150,156 ----
  ## Where Axiom keeps the tarballs for optional components
  axiom_optional_srcdir = $(abs_top_srcdir)/zips
  
! INC=$(top_srcdir)/src/include
  PLF=@PLF@
  CCF=@CCF@
  LDF=@LDF@
*************** AXIOM_X11_LDFLAGS = @X_LIBS@ @X_PRE_LIBS
*** 162,168 ****
  axiom_includes = -I$(axiom_src_srcdir)/include -I$(axiom_configdir)
  
  ## Where the staging build directory is found
! AXIOM = ./$(top_builddir)/target/$(target)
  
  ## Where to find Axiom data bases.
  DAASE = $(axiom_src_datadir)
--- 162,168 ----
  axiom_includes = -I$(axiom_src_srcdir)/include -I$(axiom_configdir)
  
  ## Where the staging build directory is found
! AXIOM = $(top_builddir)/target/$(target)
  
  ## Where to find Axiom data bases.
  DAASE = $(axiom_src_datadir)
*** configure	(revision 15444)
--- configure	(local)
***************
*** 1,6 ****
  #! /bin/sh
  # Guess values for system-dependent variables and create Makefiles.
! # Generated by GNU Autoconf 2.60 for Axiom build-improvements branch 2006-04-07.
  #
  # Report bugs to <list>.
  #
--- 1,6 ----
  #! /bin/sh
  # Guess values for system-dependent variables and create Makefiles.
! # Generated by GNU Autoconf 2.60 for Axiom build-improvements branch 2007-04-09.
  #
  # Report bugs to <list>.
  #
*************** SHELL=${CONFIG_SHELL-/bin/sh}
*** 559,566 ****
  # Identity of this package.
  PACKAGE_NAME='Axiom build-improvements branch'
  PACKAGE_TARNAME='axiom-build-improvements-branch'
! PACKAGE_VERSION='2006-04-07'
! PACKAGE_STRING='Axiom build-improvements branch 2006-04-07'
  PACKAGE_BUGREPORT='list'
  
  ac_unique_file="src/Makefile.pamphlet"
--- 559,566 ----
  # Identity of this package.
  PACKAGE_NAME='Axiom build-improvements branch'
  PACKAGE_TARNAME='axiom-build-improvements-branch'
! PACKAGE_VERSION='2007-04-09'
! PACKAGE_STRING='Axiom build-improvements branch 2007-04-09'
  PACKAGE_BUGREPORT='list'
  
  ac_unique_file="src/Makefile.pamphlet"
*************** if test "$ac_init_help" = "long"; then
*** 1213,1219 ****
    # Omit some internal or obsolete options to make the list less imposing.
    # This message is too long to be a string in the A/UX 3.1 sh.
    cat <<_ACEOF
! \`configure' configures Axiom build-improvements branch 2006-04-07 to adapt to many kinds of systems.
  
  Usage: $0 [OPTION]... [VAR=VALUE]...
  
--- 1213,1219 ----
    # Omit some internal or obsolete options to make the list less imposing.
    # This message is too long to be a string in the A/UX 3.1 sh.
    cat <<_ACEOF
! \`configure' configures Axiom build-improvements branch 2007-04-09 to adapt to many kinds of systems.
  
  Usage: $0 [OPTION]... [VAR=VALUE]...
  
*************** fi
*** 1283,1289 ****
  
  if test -n "$ac_init_help"; then
    case $ac_init_help in
!      short | recursive ) echo "Configuration of Axiom build-improvements branch 2006-04-07:";;
     esac
    cat <<\_ACEOF
  
--- 1283,1289 ----
  
  if test -n "$ac_init_help"; then
    case $ac_init_help in
!      short | recursive ) echo "Configuration of Axiom build-improvements branch 2007-04-09:";;
     esac
    cat <<\_ACEOF
  
*************** fi
*** 1373,1379 ****
  test -n "$ac_init_help" && exit $ac_status
  if $ac_init_version; then
    cat <<\_ACEOF
! Axiom build-improvements branch configure 2006-04-07
  generated by GNU Autoconf 2.60
  
  Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
--- 1373,1379 ----
  test -n "$ac_init_help" && exit $ac_status
  if $ac_init_version; then
    cat <<\_ACEOF
! Axiom build-improvements branch configure 2007-04-09
  generated by GNU Autoconf 2.60
  
  Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
*************** cat >config.log <<_ACEOF
*** 1387,1393 ****
  This file contains any messages produced by compilers while
  running configure, to aid debugging if configure makes a mistake.
  
! It was created by Axiom build-improvements branch $as_me 2006-04-07, which was
  generated by GNU Autoconf 2.60.  Invocation command line was
  
    $ $0 $@
--- 1387,1393 ----
  This file contains any messages produced by compilers while
  running configure, to aid debugging if configure makes a mistake.
  
! It was created by Axiom build-improvements branch $as_me 2007-04-09, which was
  generated by GNU Autoconf 2.60.  Invocation command line was
  
    $ $0 $@
*************** exec 6>&1
*** 9060,9066 ****
  # report actual input values of CONFIG_FILES etc. instead of their
  # values after options handling.
  ac_log="
! This file was extended by Axiom build-improvements branch $as_me 2006-04-07, which was
  generated by GNU Autoconf 2.60.  Invocation command line was
  
    CONFIG_FILES    = $CONFIG_FILES
--- 9060,9066 ----
  # report actual input values of CONFIG_FILES etc. instead of their
  # values after options handling.
  ac_log="
! This file was extended by Axiom build-improvements branch $as_me 2007-04-09, which was
  generated by GNU Autoconf 2.60.  Invocation command line was
  
    CONFIG_FILES    = $CONFIG_FILES
*************** Report bugs to <bug-autoconf@gnu.org>."
*** 9109,9115 ****
  _ACEOF
  cat >>$CONFIG_STATUS <<_ACEOF
  ac_cs_version="\\
! Axiom build-improvements branch config.status 2006-04-07
  configured by $0, generated by GNU Autoconf 2.60,
    with options \\"`echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`\\"
  
--- 9109,9115 ----
  _ACEOF
  cat >>$CONFIG_STATUS <<_ACEOF
  ac_cs_version="\\
! Axiom build-improvements branch config.status 2007-04-09
  configured by $0, generated by GNU Autoconf 2.60,
    with options \\"`echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`\\"
  
*** configure.ac	(revision 15444)
--- configure.ac	(local)
***************
*** 1,5 ****
  sinclude(config/axiom.m4)
! AC_INIT([Axiom build-improvements branch], [2006-04-07], 
          [list])
  AC_CONFIG_AUX_DIR(config)
  AC_CONFIG_MACRO_DIR(config)
--- 1,5 ----
  sinclude(config/axiom.m4)
! AC_INIT([Axiom build-improvements branch], [2007-04-09], 
          [list])
  AC_CONFIG_AUX_DIR(config)
  AC_CONFIG_MACRO_DIR(config)
*** configure.ac.pamphlet	(revision 15444)
--- configure.ac.pamphlet	(local)
*************** information:
*** 936,942 ****
  \end{itemize}
  <<Autoconf init>>=
  sinclude(config/axiom.m4)
! AC_INIT([Axiom build-improvements branch], [2006-04-07], 
          [list])
  @
  
--- 936,942 ----
  \end{itemize}
  <<Autoconf init>>=
  sinclude(config/axiom.m4)
! AC_INIT([Axiom build-improvements branch], [2007-04-09], 
          [list])
  @
  
*** src/hyper/Makefile.in	(revision 15444)
--- src/hyper/Makefile.in	(local)
*************** ${HYPER}/pages/ht.db: $(HTADD) $(srcdir)
*** 161,168 ****
  			> ${HYPER}/pages/`basename $$A`; \
  	     done
  	@ rm -f ${HYPER}/pages/ht.db ; \
!           rm -f ${HYPER}/pages/*~ ; \
! 	  ${HTADD} ${HYPER}/pages/*.ht ${HYPER}/pages/*.pht
  	@ cp -pr $(srcdir)/bitmaps ${HYPER}
  	@ cp -pr $(srcdir)/viewports $(axiom_target_datadir)
  
--- 161,168 ----
  			> ${HYPER}/pages/`basename $$A`; \
  	     done
  	@ rm -f ${HYPER}/pages/ht.db ; \
!           rm -f ${HYPER}/pages/*~ ; AXIOM=$(AXIOM) \
! 	  ${HTADD} -s ${HYPER}/pages/*.ht ${HYPER}/pages/*.pht
  	@ cp -pr $(srcdir)/bitmaps ${HYPER}
  	@ cp -pr $(srcdir)/viewports $(axiom_target_datadir)
  
*** src/hyper/Makefile.pamphlet	(revision 15444)
--- src/hyper/Makefile.pamphlet	(local)
*************** ${HYPER}/pages/ht.db: $(HTADD) $(srcdir)
*** 287,294 ****
  			> ${HYPER}/pages/`basename $$A`; \
  	     done
  	@ rm -f ${HYPER}/pages/ht.db ; \
!           rm -f ${HYPER}/pages/*~ ; \
! 	  ${HTADD} ${HYPER}/pages/*.ht ${HYPER}/pages/*.pht
  	@ cp -pr $(srcdir)/bitmaps ${HYPER}
  	@ cp -pr $(srcdir)/viewports $(axiom_target_datadir)
  
--- 287,294 ----
  			> ${HYPER}/pages/`basename $$A`; \
  	     done
  	@ rm -f ${HYPER}/pages/ht.db ; \
!           rm -f ${HYPER}/pages/*~ ; AXIOM=$(AXIOM) \
! 	  ${HTADD} -s ${HYPER}/pages/*.ht ${HYPER}/pages/*.pht
  	@ cp -pr $(srcdir)/bitmaps ${HYPER}
  	@ cp -pr $(srcdir)/viewports $(axiom_target_datadir)
  
*** src/sman/Makefile.in	(revision 15444)
--- src/sman/Makefile.in	(local)
*************** bin_PROGRAMS = session$(EXEEXT) \
*** 17,29 ****
  session_sources = session.c
  session_SOURCES = $(addsuffix .pamphlet, $(session_sources))
  session_objects = $(session_sources:.c=.$(OBJEXT))
! session_LDADD = -L$(build_libdir) -lspad
  session_DEPENDENCIES =
  
  spadclient_sources = spadclient.c
  spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
  spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
! spadclient_LDADD = -L$(build_libdir) -lspad
  spadclient_DEPENDENCIES =
  
  sman_sources = sman.c
--- 17,29 ----
  session_sources = session.c
  session_SOURCES = $(addsuffix .pamphlet, $(session_sources))
  session_objects = $(session_sources:.c=.$(OBJEXT))
! session_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
  session_DEPENDENCIES =
  
  spadclient_sources = spadclient.c
  spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
  spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
! spadclient_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
  spadclient_DEPENDENCIES =
  
  sman_sources = sman.c
*** src/sman/Makefile.pamphlet	(revision 15444)
--- src/sman/Makefile.pamphlet	(local)
*************** bin_PROGRAMS = session$(EXEEXT) \
*** 35,47 ****
  session_sources = session.c
  session_SOURCES = $(addsuffix .pamphlet, $(session_sources))
  session_objects = $(session_sources:.c=.$(OBJEXT))
! session_LDADD = -L$(build_libdir) -lspad
  session_DEPENDENCIES =
  
  spadclient_sources = spadclient.c
  spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
  spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
! spadclient_LDADD = -L$(build_libdir) -lspad
  spadclient_DEPENDENCIES =
  
  sman_sources = sman.c
--- 35,47 ----
  session_sources = session.c
  session_SOURCES = $(addsuffix .pamphlet, $(session_sources))
  session_objects = $(session_sources:.c=.$(OBJEXT))
! session_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
  session_DEPENDENCIES =
  
  spadclient_sources = spadclient.c
  spadclient_SOURCES = $(addsuffix .pamphlet, $(spadclient_sources))
  spadclient_objects = $(spadclient_sources:.c=.$(OBJEXT))
! spadclient_LDADD = -L$(build_libdir) -lspad @axiom_c_runtime_extra@
  spadclient_DEPENDENCIES =
  
  sman_sources = sman.c

\start
Date: Tue, 10 Apr 2007 00:36:14 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: building wh-sandbox on Axiom on Solaris 10.2 x86
Cc: Gabriel Dos Reis

Waldek,

On April 9, 2007 9:59 AM you wrote:
> ...
> Configure machinery should be in place, but build-improvements
> also changed src/lib files to use results of configure run.
> So one have to merge changes to src/lib (and possibly also
> other C parts).
>

I checked the revision log for bsdsignal:

http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvements=
/sr
c/lib/bsdsignal.c.pamphlet?view=log

apparently wh-sandbox is missing build-improvements revision 366.

I have merged these changes with my working copy of wh-sandbox
and the build is progressing normally (now at Stage 2 object
bootstrap). It may take another few hours to complete.

The diffs are attached. Would you like me to commit this to
wh-sandbox if it completes normally or should I leave that up
to you?

Note: I am using autoconf-2.61 so configure may differ slightly.

Regards,
Bill Page.

------=_NextPart_000_033E_01C77B08.422B3070
	name="wh-sandbox-r366.patch.gz"
	filename="wh-sandbox-r366.patch.gz"

H4sICFMSG0YAA3doLXNhbmRib3gtcjM2Ni5wYXRjaADtPGlT20q2n9GvOJOk7kBsGcyShSwPXyDg
ugQo7LxkClK+balt90OWPFowfoz/+zvntFZbNksyM1XzcmuSgHS6z752a5quLW93IfCt9cFkJP31
QThQYVAbieFo4MjQ+PDj/xmmaS7GsLLqyxsVKM+F7bev1oxKpbIMeOz518rtg+WNJmvG3h6Y26+q
r6GCf7+CvT0D4OW6Ac9t2VOuhM5x+7jZbnX28ZFyLSeyJTwTt8obmpY5FJbvBbXBM8PMXkaBHPle
6NFjyK+yZTfq66fNTGiO6q53AztQfVc4NeufI7dFSBaJbjH8vPS2SHj0F8nOgCtXji1vOBSufXd1
I/zpZf373VUob8PAuXten04RyLwKVejIu6tPCv8uQYhQlXth4DymCre8ElE48Py79kBCg7QDbSmG
UyaoK/vKvbM9KxpKF4GJ6M3tN0S2/ocIb/Gux0i1I/1PkWsZgLj001XlhoBoq/NQIKwQpVcFAvFl
EAo/bE2CUA73heOsGXBHptFDdffgc+tvrZEjwp7nD40KPoXjxn8fdg4O9086reZRY7/dPDsligGC
0I8sxqn3x+2rXhS+o3fKrQWiM9A0wIeYgnearZ231c1t5Iv+rTNjCAdjCa6UNoQeWL4UoQSBD8aQ
UAOoJyW6jqxBe6ACsHD3vgT8aSjQcnGZAWjTI69Pa8OBCEuWGvD+/cuPHz8ww6Ddx149aZ5++ZYA
r8E//pG8gdXGyflxI32VvVm9aJ61ypastr6cbp+1dvLv0ldHzbLHx+f1jdKtPjf2z1qlhK3+3jpI
n7OeSHmtRufisNVuXLRZB73VeWXHmuk5oh+gXrIVrDbpBHIGYuMdyko6OWkhg3nUxXeNTvO0fXhx
8eW8vaaJgPup2FiEPL/dHB3H528zOkyY25PiGu2Z2ePMO9dWPXpJf3wZRr4Lq6k1r7Iv/YY2Db+h
Va/Bf8HqnGetgVmHXdxgBUrf4sKcH6xpFpDL9ZcFR6NgXknf/KXE4zjcZ1SWEsK7E09l25uEIHm5
CAGHotm4v89+duL1a91IObaphuhlN5LCVPDT4/8yZMvywPJ18/mgXt2CSr36hqJPZXNj45VZ3zQ3
tgCORNdX0oEDL4ALicEF3vdtf88KaqEYRjVpRx+NilFZeQllqWcXvqAOLc/tqX7kSzNUQwmcgHFJ
idRraHwVA1ICNh9GABkcqlhcoydgUEuww6rl+bITeJFvyaAKofSHCgnsKC99mGg3pbEmrJ+mxfym
Zdoqvi/Tyg5pZYdzQhDXJKt61TrXM7XhNvp6Yx/DQrO9eqmz6LzKoesL1xp8r8Ily3Zjy9x8g78Z
lZml44EZoBd1vduFSyD571JXVLa8kY6HVdue67l9N6p5fv87xjp+2wm9UQeN0lb+hz8tG17on+G3
32A0tv80APG3vvzeaq/OgmsJbOqM/6Za39JlHtCKz62jztfGxenq5bkjBVqY64WqN4HFBFHcnXgR
BJFlYVKtEYE9hUHvOXwdSJ/SpecEgNEBM6XUEszSpUCAQP49wriNsLZR0cQyFHNGvKzzr+sv+J8C
SKerXAJ7UVy2jo+LcOi5ZXD4OBGnhgsGSFEZJL/AyPYczn30hduUIUw4fbItzDt9dAzlKnziIH9k
j7hSWqHnTxJqNFTGmf59/YX+l42moLQEfI1r5+fQsLBsixyqOxxEBF4PolChfKmgwSqiXMy8tBlS
BXOjkDpds7jeWHbp2QjTJtoy0p5bK90b5XsuW3ktrqZeVd9gMNt8tVmtbyZGU/zvMrYhTKRnF4np
E20B6BCGdjIaeX6IdkKWguD7x4f7f3C0aq1epkmRvCP+M4fmMm0i3sdxcfDxu3ZWvdnxYePg8IK2
mwTrqI6wht7Gwi15H2JfhE0LMKxnXUuGnscKRAxl/4ez/D7D/1EzXEJjRBZjM87HI0gWf5zZPRYn
Gk+k7CrgvzL5oZ88wB8yKc/hzQk5hwSz+xySa+U4D9uooC2LwsuLgReQ4elVLzGJ9Mcv17I95sU1
Vi5paZNVOi+sBKn2H9oda6KgoxX7YSKDpau+51DrHayOH7mUXDvYsvniwzPTGdNmW5vPMtB372L6
l1I+a2ALyXgi9UXyiSYZYMo1MUCHGF/h9kXptvCXD3CLW78j53fhSm+xxI8j8l+ONHqDgGK+iTHf
nIleM7JLjOfw6OLwPBbL6iURInodx7OEU8bdZdoZYp3ZaZ3t/3HY7hyXSOE51d6JoeVE/bEMlqv1
5Xtkhla+A9f0JS90g9T41Dk522+clKorz/PCvRfGgoPDT83Tw9VLFkqCh5yvTn8dk0MhgpQCHRmW
yR79+/Y/S/RfTpvflkmeOP5xwROWUrnzi7WZaFmIA2OhKAowROqfz14Iq2PddAZS2NLvIFyH4DqD
Z7DARQtxmGAXxZXLx794XlCpJvhj4unzWQDjwXVZ9H/os4XpZl484kZ2bGk5HcKZyCaRCpiiDJTo
LxfjTKz68OzFzJN8d/MsvwbL6Q6WeumK+HfAP2YwFC7/YDmyN7cqiKgcDQor42dAC4CWx6sa35pn
nzufG3+g9Z2g9VEjSjDrSVeWRP0yQNqnAJh5XxzhT8/azX2EbkVY1xPRljccYd3ncrloq4CmWXYt
U/wM78SjckdRCEUpPDMqpU60KKvoXFSoDhcUbLqggqxuKsNU/rSIn0ap2DO7ahTF9bolRqKrHBUq
NCjqTYYqwO6wn1Wr5432cedb+6LBNfVZFBLnusxXNzLrc/ZZjojAz3Vi3zr7J58aR614Uvz6dfUV
VLbqm3o6UOKE5UrVk/xMq+XVasZuouJjWnfgWTOKjTs26m0+Nb99PtyFT9jfhDT5pEbDryXNy4N9
BMlhupMuKm1jcrJggLVkSJBNVcaDnzYkyG9aNiQovl84unmdjG5emxvb5sZbgN+x4oVz0cdghdbi
1Eb4Y30vmLio+UAFNTSpaxGENUskI5yhRAlASsLWq1fQ80sHCvGURuN6A/BVOLa8hmPZVYE1AHg/
0D/tDUU4qKET1Ma+Z9VGTjKsIQsRTl92fbHe86WsBSNh5+ZGpNxu1Iet7a1acUazPnuQU8PC/Gcp
YzGKxfObcuiyM5ftbTp0qW+wH62/hN9bB9BzxI0X+fr8KuIzh9wsm85daEA5Wy7xCDMGL1RYFPtm
FlCeL4PX5QeDH+hzs9CDejIpoaTEMYISk/B15MFG/k9KZ3+t8hEFwm8k8Lbn/hVbcAras7h4xvfp
7OKPJ2CLW8B5hIxJIy1HeHTYPjxqHjwRZ/RknF+eirOUzXvliiifzGUpkw/B+DQeqQV/Ar4/midk
1vBIbOmQpkSPUNAjzKHMn+w9lkuq4Z7A5ddGs/0ALt8rN4xnQR9Bl+DAQ+85Rpqn7fbfzg9b2AsB
x5/X9Wp9BwPQ6+rbJAAtxZQbO92DihqvDNd9AstX6nP7mrP7klyonbuf3rQiX04shr1W++BhlOZa
vOWUfm2eUue5mVJ6otzotiy4F85Ws9Olf8mp0mNPk554ilT/kWOk/JlI7iTnChsP+p9kl77TB37B
dG0XDt0g8llfuD5WUjbDoypS3AjlUB0JyBzNlWqArEnrWo+HkjiBy2NIqq0nNZijZxdp70tXorfL
WvHtLmr8Wo5VUHhRVhrMbPJT5YTSuB1R5EkuTnBYqj2ZkacexS1Q4kw5jso7lePcZYSSs7iff7Wm
dPf7TueWX0XaoJOGCv2jT6kcOoHi4wsDpEu8BXTXRPp0KhWbF4xVOAB5izFL7+beoL6QAOFg0S2G
kvAEVbiS/bupweHo6PRLfOyRAmBCodszoQiuydK5K6Y4Y0N3wmt6aNv6IIV+S9FdtT3PuePWdkpn
CqEcYjiMd3DkLaevG+lPYOR5vjNJDUraVU15F0OYcEN8RXJylMX7er5h8jkZMUIeZ3k2JhB0pceQ
WUYdnQoRPUYlJhHN89gbo6T9Ki3CEGB7KGfXC41KIHEFhvSuhL7n2djSiMBzdd9b2JxgWKIqDMAb
u9AfyDD0amTH7cWUjH0VhtJN++ghldsj4fPp1IkKRlWUBAqU6fJ6GG/axBu+RDzS6XFUgj5d6wF9
Ek2lA80UEuswKuwWdHaLb2jLp2xCF4BQC8Pgqud5IYpG3qHAXBA9NEbMc7iJAAvVGqFkcTHbh3Qt
OaVmnXxWOJ5Ll4oCVCqKkVptrmswMSbjCG4RhwKfhEgL5rT4AJbMRZ+rVvHRSKK+XYtjMElKWbje
Z85AkULTcIXAIYZhXCVDSx/q7WxX63Wo7OwkHpbnMuERBfQJH0cu0uhMEqOg+chY0qxLD23IgA00
YRthIAq0PfMvaZqo8gKe5zGzdDIcr0YbN2DfxByjbvBdntP4KFKft3O4D9KjzYCVpz3YMGOjikKP
956imbLvuKxAJHuoWYlNi3YkkhAAqRyKa0l0IyjbF2S7kSNOs8kY40Qb0QaOGWiAhY4/Sd0EKaF9
svW09ZQ9Xz87UV0icIobnUsPVcRBzLX5INlDymzVmxARdDpLxq+pn0NIKpC3I0zd2na65O9DVB7q
n2NJQSTMBTr3AikZlZycqjpmoGwo5Po068B0Ny+8TGgoQqOyVGxVpD9k+cxKxsXoVpkRjVH5zGIg
0khy8jaVUCIJo5KJQvOQ3FCgwPT3SPmoD+YjLT4DpBuuXW/sSLuPdQ2yOyuOLETxXctkzjaFJFPF
ezJfgVykGCONZRhXBIzFRC8TXfRmDMqZDYOylRdMXAsfK53QPN1XvGHnfFOP+4orRVGSZSyRlDs+
PE12IbqvUEJ30sV8QvUH3y1tz1+6oDDLHjxOXvFFBo7BcVrUALEbsBjSnI3R2vLViMfD8lZaEdpe
7IQFejjpaTyFWD+m4RnWKbjm1EvuT6KIehE+16UTBZ8kyuAmhiloHOlnLOzmhBBfvMjEAPFVBwLB
p8wypZPxQFkDwxzryMWMJ9akeUeTI/PmlBN4vXBMcGR6/CTOZhiLMXcojqd082mgTcCXMotJRkXo
uhkCrCZ2Sc4WHQxo/cd0YzDFSFe27ZSSfeV/IkQ6D6rNk91wMlK47VLCYsoy0mCOMuPRtMFi0shq
327QzaK38eB0JkFpUzjaP5lqfSThP9AxOL+d9kOPKhhKR/qurYQ4WXBG9r0+1mvzSaFarOoMMy4w
aG5HzNjCt9X/YpTgnMgtTTJlyO1BcqE7SWlN+LT1saQSB9KQLm4ZkK02YP4FZ08dzw1955ijMtsY
ZoNczTFguRKzNIBPMAnXc9k0QnRUuhFO/qWPCKTwHYUVCsZ0qsm5BpoJ2NNd3XLu1Ln4ru9s/rPu
iO0ZZhYCxlRmcnYIQm/EPBUlg9q2JGq5Ky1BGUcvwIL02jAREnnF9KKSYlRbhLbg5FSJJmsZQvaC
AdUjSZ8El5e8rKPPbtDKvtM5UpFGZTORfCaZXgJ7yDYJ3YyaErtHt+TjcMQuxZ2Mro1QYRg7KQSW
3eeq8AlOr4fQuAWXieFs/I1j8kNIQyGGSb8wm725v8ZldPZ1cXbU2d/HFUDX7iz0yCChUqeK7NRL
mzDX0VoTyYuaLhIeAFmNIwS/SrnF5ZMRO0RJdEKev/IabKfdfoBbkxehO2hB6oWoiZKV/G1EcRSy
L1xhKzoSJbqm8bCv/nqT4lv99Xb6kQd3YDFV2m5j1oKBFznaXrranJlZLs3CmUXGAoYwmaE39ZCm
uEbFECTdgAdrXNKIJMgVVsY1SuYFqYDNTMBXSmKu1+Efowva1fwWD148k2RSje3qYpm6Uw6IcZSa
kW5tcVuYltVMT+zM+hc9D0CdYsIeDagFtzTpE0lVesPBNBj1B5yBWRWp2xbRxyJk/b7Zqta3UcFv
dqqb+mA23aZAXUpWQlE+5CD+KrV5RtznFdFx0zEW3MXpEjqetBXiINWP0iitL2dKSj58pq7LTdMp
xsSMHBrLYWCki7Y0WKgWr3pic8mdWXYTF72Ze7OEIA1HpZAu9UtiEga4vPsm1vs4tJVHo4VVTCoD
wLysdcOXWqdrGNMQF0q1ayZ3cKmynomZHBYC/lRnkJV4hYJyGNA3PP+Zt5mBglcl1yDECRY9Vbso
3W2WNlUpn6VwdbFMmhnQxYlx2oTlO9QS/2Ud0zUJLTtSZ9oSal3replNNy18dBzkeBErviS76f5A
0FhqRCdFsqDxSawnga6oYy+ywEXmEHe9vNSK/v7dqNyn/3/jve/KHo2lKTfFWYkPoC1UIHq99Dnk
cW6CRgBDPejU9QNRiRWF79lR/FWeoHtFGK8ThRWUpQJ9y7v+FpvODahsbu1Ut+plF1MW3Ohlc8IK
ayaLUveota6lol1xSpAtasa5op2jJr2WI/lcKL8Br9f6nxjm0EMjQJ04ZLkaAFWMunKkpWs8Gof6
Ds8RUk8N5JDSnIXOb5bMg+LhAZyftZrfMmDuqigPsBukQ1GTh6KuJOcR/iQZJ1Il5yv9wWJcCHRp
66FHAy7qJDx8I6gQDALFY3qUyfv3+/GBmOYZndoXxDF/S3jPFfeSe4v0dGXl1y31J95S36NTx9kj
Mn3teZqUfhw7ckNKGFIxTwUfXSdzuMLjD/P0ccRwGLlJmYKVExkUmlB8lRrSYim2Qf1NB3cG1Ahn
Jwx0fwo1N8Xgt3xtXJHmsHZlOJbSndspN6FMrgNO9ZhGWcmgxpYYQSY6b2ujtiWWVthmGskoR5NK
wQd0cs4qFZ6E4OOQhkA63Obd3jDHg5SulATiiOqh+BsXZEkk9wW1d0xiCMNMJ83YZty/FRf9yx1u
6VcKK/d9nrAy5yVLb/avrKzwHf6VB3x7sPKv/ehgJWNFk/jr+4J/9yX3X98X/Pq+4LEftS24Kb28
QCi7m617hweWehAXhTFYO74rDM31M0xfP6EKrPxwFVj54Sqw8tOqwHuT0q9vSn59U/L/9JuSH/wk
ZD7QPfojEJ74xreTtvkDju06DQypUdaHGklgLA93NG1Y4tw/8TOMbHSQEcO3QmJo/f8HlB3I+dIh
luNxC1KluLbWEL9/OphW45mCdirj/wBXfuhx7EoAAA==

------=_NextPart_000_033E_01C77B08.422B3070--

\start
Date: Tue, 10 Apr 2007 01:42:09 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: FW: Axiom on Solaris 10.2 x86

I am very grateful for your effort to resolve the problem!

On April 9, 2007 10:43 PM you wrote:
> 
> The patch below addresses the issues you have raised:
>   
>   * It adds the additional C runtime libraries for linking programs
>   * It brings HyperDoc back.
> 
> For the second point, 
> 
>   (1) I removed a workaround for Autoconf-2.59 bug, whereby
>       top_builddir was left undefined -- therefore I added ./ to
>       imply correct semantics.  Since that bug was fixed in
>       Autoconf-2.60 and later, we don't need it anymore.
> 
>   (2) We were not telling htadd that we were building the system
>       database.  Fixed by supplying the option "-s" so that htadd can
>       look up the value of the AXIOM environment variable.
> 
> Tested on an x86_64-suse-linux.  Committed to build-improvements.
> 
> Please let me know if it works on your solaris box.
> 

The build completed normally and I now have a fully functional
Axiom with HyperDoc.

\start
Date: 10 Apr 2007 01:04:14 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: FW: Axiom on Solaris 10.2 x86

Bill Page writes:

| Gaby,
| 
| I am very grateful for your effort to resolve the problem!

You're welcome.

[...]

| The build completed normally and I now have a fully functional
| Axiom with HyperDoc.

Yay!

Now, I'm testing a patch that brings Axiom.build-improvements back to
Windows machine -- there is a combination of Autoconf-2.60,
GCL-2.6.8pre and Msys voodoo going on.  The patch is ismple though.

Oops, the build just completed on windows.

| Thank you.

Thank *you* for testing and reporting back.

\start
Date: 10 Apr 2007 14:21:42 +0200
From: Martin Rubey
To: Alasdair McAndrew, Bill Page
Subject: Re: [Axiom-mail] Two beginner questions

Alasdair McAndrew writes:

> Hi Martin,
> 
> Thanks so much for your detailed reply!  So - I'm using Axiom in TeXmacs.
> Without starting a new instance of Axiom from another shell, how do I access
> HyperDoc?  

Oh, HyperDoc does not appear when started from within Axiom? I'd call that a
bug. (I'm not using TeXmacs, anybody out there who knows?)

However, it is not so inconvenient as you might think.  When Axiom is doing a
big calculation, HyperDoc becomes unresponsive.  Thus I often start a second
Axiom, to do some browsing while I let Axiom compute.  Maybe you want to write
a tiny shell script like

## call this file axiom and put it into your private ~/bin directory ##########
#! /bin/bash

$AXIOM/bin/axiom
$AXIOM/bin/axiom $@
###############################################################################

(i.e., first start axiom without any parameters, which you will use for
HyperDoc browsing, then start the "real" axiom process, which TeXmacs will
use.)

> And how do Windows users get their Axiom help?

They don't :-(.  It's too sad, but we have not found a programmer who is either

* willing to port HyperDoc to MS Windows (HyperDoc relies on X)

or

* willing to write a HyperDoc replacement as outlined in
  http://wiki.axiom-developer.org/SummerOfCode2007 and many many long email
  discussions.

If you have somebody handy, please tell me immediately.  We can even pay a
(very) symbolic amount of money.  If he decides today (deadline is April 11),
he probably can do it as a Summer of Code project and earn 4500$.  In this case
he should apply here:

http://lispnyc.org/soc.clp

and mention Martin Rubey as (inofficial) co-mentor.

\start
Date: Tue, 10 Apr 2007 10:11:37 -0400
From: Bill Page
To: Martin Rubey, Alasdair McAndrew
Subject: RE: [Axiom-mail] Two beginner questions

On April 10, 2007 8:22 AM Martin Rubey wrote:
> 
> Alasdair McAndrew writes:
> 
> > Hi Martin,
> > 
> > Thanks so much for your detailed reply!  So - I'm using Axiom
> > in TeXmacs. Without starting a new instance of Axiom from
       ^^^^^^^
> > another shell, how do I access HyperDoc?  
> 
> Oh, HyperDoc does not appear when started from within Axiom? 
> I'd call that a bug. (I'm not using TeXmacs, anybody out there
> who knows?)

No. Of course HyperDoc does not start when Axiom is used under
TeXmacs. TeXmacs (normally) uses only AXIOMsys.

> 
> However, it is not so inconvenient as you might think.  When 
> Axiom is doing a big calculation, HyperDoc becomes unresponsive.
> Thus I often start a second Axiom, to do some browsing while
> I let Axiom compute.  Maybe you want to write a tiny shell script
> like
> 
> ## call this file axiom and put it into your private ~/bin 
> #! /bin/bash
> 
> $AXIOM/bin/axiom
> $AXIOM/bin/axiom $@
> ##############################################################
> 
> (i.e., first start axiom without any parameters, which you 
> will use for HyperDoc browsing, then start the "real" axiom
> process, which TeXmacs will use.)

Martin, your "advice" is confusing. TeXmacs starts it's own
copy of Axiom. It cannot use a previously started process.

> 
> > And how do Windows users get their Axiom help?
> 
> They don't :-(.  It's too sad, but we have not found a 
> programmer who is either
> 
> * willing to port HyperDoc to MS Windows (HyperDoc relies on X)
> 
> or
> 
> * willing to write a HyperDoc replacement as outlined in
>   http://wiki.axiom-developer.org/SummerOfCode2007 and many 
> many long email discussions.
> 
> If you have somebody handy, please tell me immediately.  We 
> can even pay a (very) symbolic amount of money.  If he decides
> today (deadline is April 11), he probably can do it as a Summer
> of Code project and earn 4500$.  In this case he should apply
> here:
> 
> http://lispnyc.org/soc.clp
> 
> and mention Martin Rubey as (inofficial) co-mentor.
> 

Sorry, but Summer of Code application deadline was March 26.

\start
Date: 10 Apr 2007 16:51:47 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: [Axiom-mail] Two beginner questions
Cc: Alasdair McAndrew

Bill Page writes:

> Martin, your "advice" is confusing. TeXmacs starts it's own copy of Axiom. It
> cannot use a previously started process.

I didn't say that the first process should be used by TeXmacs. It is just there
for HyperDoc to pop up.

OK, I didn't know that TeXmacs uses AXIOMsys. So, maybe it is possible to
modify TeXmacs to start HyperDoc? Alternatively, write a script that first
starts axiom normally (such that HyperDoc can be used) and then starts TeXmacs
(which will start it's own axiom mode, of course)

> Sorry, but Summer of Code application deadline was March 26.

LispNYC says that their deadline is today. If I misunderstood, please remove
the advertisment on the Frontpage.

\start
Date: Tue, 10 Apr 2007 11:13:16 -0400
From: Alfredo Portes
To: Martin Rubey
Subject: re: [Axiom-mail] Two beginner questions
Cc: Alasdair McAndrew

> > Sorry, but Summer of Code application deadline was March 26.
>
> LispNYC says that their deadline is today. If I misunderstood, please remove
> the advertisment on the Frontpage.

The deadline of April 11 is for mentors.

\start
Date: 10 Apr 2007 10:54:51 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] msys and double-colon

  With a recent version of msys (Windows XP), I'm seeing a surprising
behaviour where the '::' in boottran::boottoclc will be passed to the
Lisp image as a semicolon!  I don't know whether is GCL doign it or
msys, but I think it is msys.

  Another hunk of this patch concerns the use of "ln -s".  With
Autoconf-2.60 and later, Autoconf test all possible ways of using 
"ln -s" (between files, from files to directories, etc.) and if any of
those possibilities fails, Autoconf deduces that "ln -s" is unusable on
the platform, therefore default to "cp -p".  In the cases where we use 
"ln -s", it is for just creating a symlink to a directory (which works
on msys) and the fallback "cp -p" just does not work for that
situation!  So, I explicitly set LN_S to "ln -s" -- that is incorrect
for theoretical maximum portability, but from practical portability
point of view, it is OK.

Tested on an i686-pc-linux and i686-pc-mingw32.
Committed to build-improvements.

-- Gaby

2007-04-10  Gabriel Dos Reis  Gabriel Dos Reis

	* config/var-def.mk (LN_S): Override.
	* configure.ac.pamphlet (<<file utils>>): Comment out test for
	"ln -s".
	* configure.ac: Regenerate.
	* configure: Likewise.

src/scripts/ 
2007-04-10  Gabriel Dos Reis  Gabriel Dos Reis

	* document.in: Don't use full internal name of symbols in package
	boottran.  Push into that package first, and use short name.

*** config/var-def.mk	(revision 15445)
--- config/var-def.mk	(local)
*************** install_sh_script = $(install_sh) -c
*** 68,74 ****
  INSTALL_DATA = @INSTALL_DATA@
  INSTALL_PROGRAM = @INSTALL_PROGRAM@
  INSTALL_SCRIPT = @INSTALL_SCRIPT@
! LN_S = @LN_S@
  mkinstalldirs = $(top_srcdir)/config/mkinstalldirs
  PATCH = @PATCH@
  RANLIB = @RANLIB@
--- 68,79 ----
  INSTALL_DATA = @INSTALL_DATA@
  INSTALL_PROGRAM = @INSTALL_PROGRAM@
  INSTALL_SCRIPT = @INSTALL_SCRIPT@
! ## FIXME:  The test done with Autoconf-2.60 and later concludes
! ##         that "ln -s" is unusable on msys, and therefore defaults to
! ##         "cp -p", but that default is unusable for us.  For our
! ##         purpose "ln -s" is just fine on that platform.  Consequently
! ##         we are explicitly overrding that value here.
! LN_S = ln -s
  mkinstalldirs = $(top_srcdir)/config/mkinstalldirs
  PATCH = @PATCH@
  RANLIB = @RANLIB@
*** configure	(revision 15445)
--- configure	(local)
*************** axiom_cflags
*** 663,669 ****
  INSTALL_PROGRAM
  INSTALL_SCRIPT
  INSTALL_DATA
- LN_S
  TOUCH
  MKTEMP
  AWK
--- 663,668 ----
*************** test -z "$INSTALL_SCRIPT" && INSTALL_SCR
*** 3143,3159 ****
  
  test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
  
! { echo "$as_me:$LINENO: checking whether ln -s works" >&5
! echo $ECHO_N "checking whether ln -s works... $ECHO_C" >&6; }
! LN_S=$as_ln_s
! if test "$LN_S" = "ln -s"; then
!   { echo "$as_me:$LINENO: result: yes" >&5
! echo "${ECHO_T}yes" >&6; }
! else
!   { echo "$as_me:$LINENO: result: no, using $LN_S" >&5
! echo "${ECHO_T}no, using $LN_S" >&6; }
! fi
! 
  # Extract the first word of "touch", so it can be a program name with args.
  set dummy touch; ac_word=$2
  { echo "$as_me:$LINENO: checking for $ac_word" >&5
--- 3142,3148 ----
  
  test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
  
! # AC_PROG_LN_S
  # Extract the first word of "touch", so it can be a program name with args.
  set dummy touch; ac_word=$2
  { echo "$as_me:$LINENO: checking for $ac_word" >&5
*************** axiom_cflags!$axiom_cflags$ac_delim
*** 9364,9370 ****
  INSTALL_PROGRAM!$INSTALL_PROGRAM$ac_delim
  INSTALL_SCRIPT!$INSTALL_SCRIPT$ac_delim
  INSTALL_DATA!$INSTALL_DATA$ac_delim
- LN_S!$LN_S$ac_delim
  TOUCH!$TOUCH$ac_delim
  MKTEMP!$MKTEMP$ac_delim
  AWK!$AWK$ac_delim
--- 9353,9358 ----
*************** axiom_src_all!$axiom_src_all$ac_delim
*** 9398,9403 ****
--- 9386,9392 ----
  PLF!$PLF$ac_delim
  CCF!$CCF$ac_delim
  LDF!$LDF$ac_delim
+ LISP!$LISP$ac_delim
  _ACEOF
  
    if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c X` = 97; then
*************** _ACEOF
*** 9439,9451 ****
  ac_delim='%!_!# '
  for ac_last_try in false false false false false :; do
    cat >conf$$subs.sed <<_ACEOF
- LISP!$LISP$ac_delim
  GCLOPTS!$GCLOPTS$ac_delim
  LIBOBJS!$LIBOBJS$ac_delim
  LTLIBOBJS!$LTLIBOBJS$ac_delim
  _ACEOF
  
!   if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c X` = 4; then
      break
    elif $ac_last_try; then
      { { echo "$as_me:$LINENO: error: could not make $CONFIG_STATUS" >&5
--- 9428,9439 ----
  ac_delim='%!_!# '
  for ac_last_try in false false false false false :; do
    cat >conf$$subs.sed <<_ACEOF
  GCLOPTS!$GCLOPTS$ac_delim
  LIBOBJS!$LIBOBJS$ac_delim
  LTLIBOBJS!$LTLIBOBJS$ac_delim
  _ACEOF
  
!   if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c X` = 3; then
      break
    elif $ac_last_try; then
      { { echo "$as_me:$LINENO: error: could not make $CONFIG_STATUS" >&5
*** configure.ac	(revision 15445)
--- configure.ac	(local)
*************** AC_SUBST(axiom_cflags)
*** 64,70 ****
  AC_OBJEXT
  
  AC_PROG_INSTALL
! AC_PROG_LN_S
  AC_CHECK_PROG([TOUCH], [touch],
                [touch], [AC_MSG_ERROR(['touch' program is missing.])])
  AC_CHECK_PROGS([MKTEMP], [mktemp])
--- 64,70 ----
  AC_OBJEXT
  
  AC_PROG_INSTALL
! # AC_PROG_LN_S
  AC_CHECK_PROG([TOUCH], [touch],
                [touch], [AC_MSG_ERROR(['touch' program is missing.])])
  AC_CHECK_PROGS([MKTEMP], [mktemp])
*** configure.ac.pamphlet	(revision 15445)
--- configure.ac.pamphlet	(local)
*************** AC_OBJEXT
*** 603,612 ****
  
  \paragraph{File utils}
  Then, check for a usable [[install]] program.  Also, find out
! way to hard- or soft-link files.
  <<file utils>>=
  AC_PROG_INSTALL
! AC_PROG_LN_S
  AC_CHECK_PROG([TOUCH], [touch],
                [touch], [AC_MSG_ERROR(['touch' program is missing.])])
  AC_CHECK_PROGS([MKTEMP], [mktemp])
--- 603,622 ----
  
  \paragraph{File utils}
  Then, check for a usable [[install]] program.  Also, find out
! way to hard- or soft-link files.  
! 
! After a recent migration to
! \Tool{Autoconf-2.60}, it turns out that all possibilities of
! soft-linking are tried (to ``play safe''), and if any variation
! fails then, [[LN_S]] is defined to [[cp -p]], which works
! only for files as sources.  But, the only way we currently
! use [[LN_S]] is when the first argument is a directory.  So, the 
! ``portability help'' we get from \Tool{Autoconf} is no help.  
! Consequently, the test for
! [[ln -s]] is commented out for the moment.
  <<file utils>>=
  AC_PROG_INSTALL
! # AC_PROG_LN_S
  AC_CHECK_PROG([TOUCH], [touch],
                [touch], [AC_MSG_ERROR(['touch' program is missing.])])
  AC_CHECK_PROGS([MKTEMP], [mktemp])
*** src/scripts/document.in	(revision 15445)
--- src/scripts/document.in	(local)
***************
*** 37,42 ****
--- 37,51 ----
  #       Anything that comes after is treated as an argument, even
  #       if it looks like an option
  
+ ## 2007-04-10:
+ ##   After moving to a recent version of MSYS, and GCL-2.6.8pre, I
+ ##   noticed that double-colon ('::' in boottran::boottocl) will be
+ ##   translated to semi-colon (';') as if interpreted for path
+ ##   separator.  I don't who is doing that, and I have no time to
+ ##   investigate it, and even if I do, it would not help much.  
+ ##   Therefore, I've changed the script not to use double-colon.
+ ##      -- Gaby
+ 
  
  # set -x
  
*************** load_lisp_and_save_image() {
*** 121,132 ****
             ## image.  Consequently, we don't supply the $quiet flags
             ## when loading-and-saving.
  	   if test $enable_checking = yes; then
!               $command $eval_flags \
                   "(progn (proclaim (quote (optimize safety))) (load \"$1\"))" \
! 	       $eval_flags "(boottran::save-core \"$output\")"
             else
                $command $eval_flags "(load \"$1\")" \
! 	         $eval_flags "(boottran::save-core \"$output\")"
             fi
  	   ;;
  	*)
--- 130,143 ----
             ## image.  Consequently, we don't supply the $quiet flags
             ## when loading-and-saving.
  	   if test $enable_checking = yes; then
!               $command $eval_flags "(in-package \"boottran\")" \
! 		  $eval_flags \
                   "(progn (proclaim (quote (optimize safety))) (load \"$1\"))" \
! 		  $eval_flags "(save-core \"$output\")"
             else
                $command $eval_flags "(load \"$1\")" \
! 		  $eval_flags "(in-package \"boottran\")" \
! 		  $eval_flags "(save-core \"$output\")"
             fi
  	   ;;
  	*)
*************** load_lisp_and_save_image() {
*** 140,147 ****
  make_program() {
      case $lisp_flavor in
  	gcl|sbcl|clisp)
!            $command $eval_flags \
! 	       "(boottran::make-program \"$output\" (quote ($*)))"
  	   ;;
  	*)
  	   error "don't know how to build program with '$lisp_flavor' Lisp"
--- 151,158 ----
  make_program() {
      case $lisp_flavor in
  	gcl|sbcl|clisp)
!            $command $eval_flags "(in-package \"boottran\")" \
! 	       $eval_flags "(make-program \"$output\" (quote ($*)))"
  	   ;;
  	*)
  	   error "don't know how to build program with '$lisp_flavor' Lisp"
*************** make_program() {
*** 156,163 ****
  translate_boot_file() {
      case $lisp_flavor in
  	gcl|sbcl|clisp)
! 	   $command $quiet $eval_flags \
! 	       "(progn (boottran::boottoclc \"$1\") (quit))" | tee $2 
  	   ;;
  	*)
  	   error "don't know how to translate with '$lisp_flavor' Lisp"
--- 167,174 ----
  translate_boot_file() {
      case $lisp_flavor in
  	gcl|sbcl|clisp)
! 	   $command $quiet $eval_flags "(in-package \"boottran\")" \
! 	       $eval_flags "(progn (boottoclc \"$1\") (quit))" | tee $2 
  	   ;;
  	*)
  	   error "don't know how to translate with '$lisp_flavor' Lisp"



\start
Date: Tue, 10 Apr 2007 12:01:43 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: [Axiom-mail] Two beginner questions
Cc: Alasdair McAndrew

Martin,

On April 10, 2007 10:52 AM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> > Martin, your "advice" is confusing. TeXmacs starts it's own 
> > copy of Axiom. It cannot use a previously started process.
> 
> I didn't say that the first process should be used by TeXmacs.
> It is just there for HyperDoc to pop up.

Ok.

> 
> OK, I didn't know that TeXmacs uses AXIOMsys. So, maybe it is 
> possible to modify TeXmacs to start HyperDoc?

Yes, it is possible. There are some instructions for this on
the wiki somewhere I think. Of course it is only applicable to
TeXmacs running on Linux. This also enables the use of Axiom
graphics.

> Alternatively, write a script that first starts axiom normally
> (such that HyperDoc can be used) and then starts TeXmacs
> (which will start it's own axiom mode, of course)
> 

Ok.

> > Sorry, but Summer of Code application deadline was March 26.
> 
> LispNYC says that their deadline is today.
>

Student applications closed March 26. Today (April 10) is the
day that all applications must have assigned mentors. Revisions
and comments on applications submitted before March 26 will be
accepted until April 11 at which point the winners will be
posted by Google.

http://code.google.com/support/bin/answer.py?answer=60325&topic=10729

But Google has been juggling these dates a little, perhaps there
is a little slack, however I do not think any new applications
are being accepted.

Unfortunately we did not receive any eligible applications from
students regarding Axiom. :-( I think we should try to analyze
why that happened. Although I do think that Lisp is an important
programming language, I fear that Axiom's association with Lisp
is of very little benefit to Axiom. It seems that very of the
already very few student Lisp programmers are really interested
in Axiom... Does anyone have any other ideas about why we did
not receive any applications?

>  If I misunderstood, please remove the advertisment on the
> Frontpage.

I have just updated FrontPage.

\start
Date: Tue, 10 Apr 2007 12:15:03 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: [build-improvements] msys and double-colon

On April 10, 2007 11:55 AM Gabriel Dos Reis wrote:
> 
>   With a recent version of msys (Windows XP), I'm seeing a
> surprising behaviour where the '::' in boottran::boottoclc
> will be passed to the Lisp image as a semicolon!  I don't know
> whether is GCL doign it or msys, but I think it is msys.

Do you mean when passed via the command line? I think MSYS does
do some mangling of things it thinks might be file names. There
is a difference for Windows in the PATH separator - Windows
uses ; instead of :. Perhaps that is relevant. But you might
want to report this to the MSYS developers.

> 
>   Another hunk of this patch concerns the use of "ln -s".
> With Autoconf-2.60 and later, Autoconf test all possible ways
> of using "ln -s" (between files, from files to directories,
> etc.) and if any of those possibilities fails, Autoconf
> deduces that "ln -s" is unusable on the platform, therefore
> default to "cp -p".  In the cases where we use "ln -s", it is
> for just creating a symlink to a directory (which works
> on msys) and the fallback "cp -p" just does not work for that
> situation!

As far as I know autoconf is right and Windows does not support
symlinks. I recall that MSYS actually internally "implements"
'ln -s' as a copy. I am not sure why you say 'cp -p' doesn't
work. What error do you get?

> So, I explicitly set LN_S to "ln -s" -- that is incorrect
> for theoretical maximum portability, but from practical
> portability point of view, it is OK.
> 
> Tested on an i686-pc-linux and i686-pc-mingw32.
> Committed to build-improvements.
> ...

Thank you for you continuing work to support a Windows version
of Axiom in the build-improvements branch.

\start
Date: Tue, 10 Apr 2007 12:22:13 -0400
From: Bill Page
To: Waldek Hebisch
Subject: re: building wh-sandbox on Axiom on Solaris 10.2x86
Cc: Gabriel Dos Reis

Waldek,

On April 10, 2007 12:36 AM I wrote:

> ...
> apparently wh-sandbox is missing build-improvements revision
> 366.
>
> I have merged these changes with my working copy of wh-sandbox
> and the build is progressing normally (now at Stage 2 object
> bootstrap). It may take another few hours to complete.
> ...

Here is the result. AXIOMsys was built but the build failed
again in sman. (I presume like in build-improvements although
the error message is different.) I will try to debug this later
today:

...
Finished loading makeint.lisp
6a
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/bin/AXIOMsys
created
make
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/bin/AXIOMsys
make[3]: Entering directory `/export/home0/wspage/axiom-sandbox/src/interp'
79 making newaux.o from
/export/home0/wspage/axiom-sandbox/int/interp/newaux.lisp
make[3]: Leaving directory `/export/home0/wspage/axiom-sandbox/src/interp'
make[2]: Leaving directory `/export/home0/wspage/axiom-sandbox/src/interp'
../../wh-sandbox/config/mkinstalldirs
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/bin
../../wh-sandbox/config/mkinstalldirs
/export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/lib
cd sman &&  make
/bin/sh: line 0: cd: sman: No such file or directory
make[1]: *** [all-sman] Error 1
make[1]: Leaving directory `/export/home0/wspage/axiom-sandbox/src'
make: *** [all-src] Error 2

\start
Date: 10 Apr 2007 11:21:50 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: [Axiom-mail] Two beginner questions
Cc: Alasdair McAndrew

Bill Page writes:

[...]

| why that happened. Although I do think that Lisp is an important
| programming language, I fear that Axiom's association with Lisp
| is of very little benefit to Axiom. It seems that very of the
| already very few student Lisp programmers are really interested
| in Axiom...

We should all view Lisp as just an *assembly language* for the
Axiom runtime system.  Any argument that elevates Lisp to the level of
Axiom on whatever ground completely misses the whole point.
Lisp, as any other assembly language in a high-level system, should be
rarely be advertised.  It is of interest only to those who want to go
under the cover and dismantle the system -- there are very people of
those.  We may very well just have an Axiom Virtual Machine that does
not require full Lisp power.

Spad and the computational aspect is what we want to advertise.

BTW, it would be great if either you or Alfredo can make a new Windows
binary (from build-improvements or wh-sandbox, whichever builds).

\start
Date: 10 Apr 2007 11:24:59 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: building wh-sandbox on Axiom on Solaris 10.2x86

Bill Page writes:

[...]

| cd sman &&  make
| /bin/sh: line 0: cd: sman: No such file or directory

I believe it is saying that the directory sman does not exist -- so it
is not like the error you reported earlier for build-improvements.

\start
Date: Tue, 10 Apr 2007 18:31:51 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Axiom on Solaris 10.2 x86
Cc: Gabriel Dos Reis

> Waldek,
> 
> On April 9, 2007 9:59 AM you wrote:
> > ... 
> > Configure machinery should be in place, but build-improvements
> > also changed src/lib files to use results of configure run.
> > So one have to merge changes to src/lib (and possibly also
> > other C parts).
> > 
> 
> I checked the revision log for bsdsignal:
> 
> http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvements/sr
> c/lib/bsdsignal.c.pamphlet?view=log
> 
> apparently wh-sandbox is missing build-improvements revision 366.
> 
> I have merged these changes with my working copy of wh-sandbox
> and the build is progressing normally (now at Stage 2 object
> bootstrap). It may take another few hours to complete.
> 
> The diffs are attached. Would you like me to commit this to
> wh-sandbox if it completes normally or should I leave that up
> to you?
> 

There is a problem with the diff: configure.ac.pamphlet in wh-sandbox
is synced with build improvements 485 (the differences are intentional).
It looks that your diff reverts configure.ac.pamphlet to some earlier
version.

For succesful build on Solaris you probably also need the recent
-lsocket change (IIRC this was after version 485).

FYI: the src/boot and src directory is synced with build improvements 485.
In src/interp and src/algebra I belive that I picked all changes
that I now want to go into wh-sandbox -- in this sense both directories
are synced, but differences are significant (I may use some changes later
but ATM other changes conflict with my work).  Other directories
(src/lib, src/clef, src/sman, src/graph, src/hyper) were synced
with build improvements 358 and need re-syncing.

Some changes will require work to resolve conflicts with changes to
wh-sandbox so it will take some time before I will sync all
directories.  There are some cleanup (and preparation for SBCL
port) related to recent merge which I prefer to do first.  Also
ATM I working via text-only connection, so I prefer to defer
work on graphics for few days (I will be them back to my machine).
I 
If bsdsignal.c change works separatly then please commit it 
(but without the configure changes).

\start
Date: Tue, 10 Apr 2007 12:34:25 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: [Axiom-mail] Two beginner questions

On April 10, 2007 12:22 PM Gaby wrote:
> 
> Bill Page writes:
> 
> [...]
> 
> | why that happened. Although I do think that Lisp is an important
> | programming language, I fear that Axiom's association with Lisp
> | is of very little benefit to Axiom. It seems that very of the
> | already very few student Lisp programmers are really interested
> | in Axiom...
> 
> We should all view Lisp as just an *assembly language* for the
> Axiom runtime system.  Any argument that elevates Lisp to the
> level of Axiom on whatever ground completely misses the whole
> point. Lisp, as any other assembly language in a high-level system,
> should be rarely be advertised.  It is of interest only to those
> who want to go under the cover and dismantle the system -- there
> are very people of those.

Personally I agree with your conclusion, however I have been
waiting the last few years for some more Lisp-oriented people to
appear who are interested in participating in the Axiom project.

> We may very well just have an Axiom Virtual Machine that does
> not require full Lisp power.

Yes. Aldor for example provides a "C" run-time environment that is
in essence a "Lisp" virtual machine. It is conceivable that Axiom
could be re-written in Aldor running in this environment - although
that would be **lot** of work.

> 
> Spad and the computational aspect is what we want to advertise.
> 
> BTW, it would be great if either you or Alfredo can make a new
> Windows binary (from build-improvements or wh-sandbox, whichever
> builds).
> 

I am willing to help anyone who wants to do this. I created the
previous Windows binary distribution more than two years ago.
I could do it again now but I think there would be greated
benefit if someone else also participates in this task.

\start
Date: 10 Apr 2007 11:39:48 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [build-improvements] msys and double-colon

Bill Page writes:

| On April 10, 2007 11:55 AM Gabriel Dos Reis wrote:
| > 
| >   With a recent version of msys (Windows XP), I'm seeing a
| > surprising behaviour where the '::' in boottran::boottoclc
| > will be passed to the Lisp image as a semicolon!  I don't know
| > whether is GCL doign it or msys, but I think it is msys.
| 
| Do you mean when passed via the command line?

Yeah, sort of; this is from document.in.
Note that similar thing in the Makefile works -- and the makefile is
supposed to use the same shell.

| I think MSYS does
| do some mangling of things it thinks might be file names. There
| is a difference for Windows in the PATH separator - Windows
| uses ; instead of :. 

Yes, I know that.  But, how do you explain the difference between the
behaviour of document and that of Makefile?

| Perhaps that is relevant. But you might
| want to report this to the MSYS developers.

Definitely, something things that it sees a path separator when it is
not. 

| >   Another hunk of this patch concerns the use of "ln -s".
| > With Autoconf-2.60 and later, Autoconf test all possible ways
| > of using "ln -s" (between files, from files to directories,
| > etc.) and if any of those possibilities fails, Autoconf
| > deduces that "ln -s" is unusable on the platform, therefore
| > default to "cp -p".  In the cases where we use "ln -s", it is
| > for just creating a symlink to a directory (which works
| > on msys) and the fallback "cp -p" just does not work for that
| > situation!
| 
| As far as I know autoconf is right and Windows does not support
| symlinks.

Except that I'm talking of msys, not windows.  Autoconf is right in
its decision but for a different reason: it does not know beforehand
how I'm going to use "ln -s"; therefore it should not tell me that 
"ln -s" works, when in fact it is "ln -s" works with qualification.

The exact fallback has this comment:

   if ln -s conf$$.file conf$$ 2>/dev/null; then
     as_ln_s='ln -s'
     # ... but there are two gotchas:
     # 1) On MSYS, both `ln -s file dir' and `ln file dir' fail.
     # 2) DJGPP < 2.04 has no symlinks; `ln -s' creates a wrapper executable.
     # In both cases, we have to default to `cp -p'.
     ln -s conf$$.file conf$$.dir 2>/dev/null && test ! -f conf$$.exe ||
       as_ln_s='cp -p'
   elif ln conf$$.file conf$$ 2>/dev/null; then
     as_ln_s=ln
   else
     as_ln_s='cp -p'
   fi


Notice that  the first test passes fine -- the only way we use "ln -s".
It is the second test that fails -- when one uses a file as first
argument and a directory as the second argument.  

Try

    $ cd /tmp && mkdir foo && touch bar
    $ ln -s bar foo

You should get an error.  However

   $ rm bar && ln -s foo bar

works just fine.  That is what we use.
   

| I recall that MSYS actually internally "implements"
| 'ln -s' as a copy. 

More like a link than a copy in recent versions -- it augments the
"inode" counts.

| I am not sure why you say 'cp -p' doesn't
| work. What error do you get?

Oh, cp by defaults works on files.  It you want to use it on
directories then you have to specify -r.  That behaviour is uniform
and not specific to msys.  Therefore Autoconf is wrong to default to 
"cp -p" when it does not know how I'm going to use LN_S.

\start
Date: Tue, 10 Apr 2007 12:41:14 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: building wh-sandbox on Axiom on Solaris 10.2 x86
Cc: Gabriel Dos Reis

Waldek,

On April 10, 2007 12:32 PM you wrote:
> ... 
> There is a problem with the diff: configure.ac.pamphlet in
> wh-sandbox is synced with build improvements 485 (the
> differences are intentional). It looks that your diff reverts
> configure.ac.pamphlet to some earlier version.

Yes that is possible. I merged changes in configure.ac.pamphlet
from r 366. If configure is already at r 485, that was my
mistake.

> 
> For succesful build on Solaris you probably also need the recent
> -lsocket change (IIRC this was after version 485).
>

I was expecting that but received a different error message -
perhaps related to the unintentional configure reversion.
 
> ...
> If bsdsignal.c change works separatly then please commit it 
> (but without the configure changes).
> 

Ok. I will revert my changes to configure so that I have
wh-sandbox at r 485 again and repeat the build.

\start
Date: Tue, 10 Apr 2007 19:10:41 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: re: building wh-sandbox on Axiom on Solaris 10.2x86
Cc: Gabriel Dos Reis

Bill Page wrote:
> Waldek,
> 
> On April 10, 2007 12:36 AM I wrote:
> 
> > ...
> > apparently wh-sandbox is missing build-improvements revision
> > 366.
> >
> > I have merged these changes with my working copy of wh-sandbox
> > and the build is progressing normally (now at Stage 2 object
> > bootstrap). It may take another few hours to complete.
> > ...
> 
> Here is the result. AXIOMsys was built but the build failed
> again in sman. (I presume like in build-improvements although
> the error message is different.) I will try to debug this later
> today:
> 
> ...
> Finished loading makeint.lisp
> 6a
> /export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/bin/AXIOMsys
> created
> make
> /export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/bin/AXIOMsys
> make[3]: Entering directory `/export/home0/wspage/axiom-sandbox/src/interp'
> 79 making newaux.o from
> /export/home0/wspage/axiom-sandbox/int/interp/newaux.lisp
> make[3]: Leaving directory `/export/home0/wspage/axiom-sandbox/src/interp'
> make[2]: Leaving directory `/export/home0/wspage/axiom-sandbox/src/interp'
> ../../wh-sandbox/config/mkinstalldirs
> /export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/bin
> ../../wh-sandbox/config/mkinstalldirs
> /export/home0/wspage/axiom-sandbox/target/i386-pc-solaris2.10/lib
> cd sman &&  make
> /bin/sh: line 0: cd: sman: No such file or directory
> make[1]: *** [all-sman] Error 1
> make[1]: Leaving directory `/export/home0/wspage/axiom-sandbox/src'
> make: *** [all-src] Error 2
> 

My guess is that change to configure broke it and configure 
decided that there is no socket support.  Consequently configure
did not create sman subdirectory.  In such case src/Makefile
should skip sman subdriectory -- it looks that wh-sandbox have
unnecessery dependency on all-sman.

\start
Date: Tue, 10 Apr 2007 10:20:36 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: (Possible) reasons Axiom didn't appeal to SoC	coders...

--- Bill Page wrote:

> Unfortunately we did not receive any eligible applications from
> students regarding Axiom. :-( I think we should try to analyze
> why that happened. Although I do think that Lisp is an important
> programming language, I fear that Axiom's association with Lisp
> is of very little benefit to Axiom. It seems that very of the
> already very few student Lisp programmers are really interested
> in Axiom... Does anyone have any other ideas about why we did
> not receive any applications?

A few, none of which have any particular supporting evidence:

a)  There are very few students interested in CAS work
b)  Axiom is not a CAS that appeals to students (this has been
discussed in the past - there are good reasons for Axiom doing things
the way it does but the benefits take time to appear).
c)  Using GCL in non-ANSI mode is not a work environment that would
appeal to most lisp programmers today (no SLIME, many standard libs
won't work, etc...)
d)  There is still a lot of "cleanup" work to be done before more
interesting projects that will produce user visible results will begin
e)  The "learn the territory" work needed to do useful work on Axiom is
much more extensive as opposed to other projects (learning how Axiom
does things and how to change them without breakage is a process WE are
still going through, after all...) - a single summer is not a lot of
time to both get up to speed and code something interesting.

The work that is being done on the branches now will help to address
many of these problems (running on SBCL should be a big help...)

For example, I've wondered about the possibility of using the
hunchentoot code http://weitz.de/hunchentoot/ to define a "gateway" for
Axiom IO that would be used for everything - have the terminal connect
to it, a webpage interface connect to it, and a GUI connect to it. 
Essentially Axiom would become the mathematical "server" and all client
interaction systems would talk to it through the same basic mechanism,
with different communications protocols being chosen based on the
interface connecting.  Mathematica uses this kernel-client approach,
but they defined their own protocol to do it called MathLink.  I'm
wondering if Axiom couldn't achieve the same result with the server
code in hunchentoot, and more or less for free get a web interface at
the same time.  However, this requires a) sufficient knowledge of
Axiom's systems to know how to set up something like that and b) a
system on which hunchentoot and its requirements (and there are a
number of those) can be run - i.e. not GCL in its current form.  When I
look at trying to do this from the SoC point of view, I can see that
Axiom would be a very intimidating prospect.  Most other projects would
have similar hurdles.

I think in the future Axiom will fare better, as we are slowly cleaning
up the system and porting to SBCL et. al.  That should be one big step
forward, and improved code documentation also will be a big help.

\start
Date: Tue, 10 Apr 2007 13:06:22 -0500
From: Tim Daly
To: list
Subject: ECCAD on Axiom Mailing List
Cc: Austin Lobo

ECCAD, The East Coast Computer Algebra Day, is being held at
Washington College on April 21st in Chestertown, Maryland, USA.

Please come.
Please register (eccad07.washcoll.edu) so they know how much food
to order (they are providing lunch).

There are slots left for posters and demonstrations.
Deadline for receipt is April 14th.

\start
Date: 10 Apr 2007 21:03:26 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

Bill Page writes:

> Unfortunately we did not receive any eligible applications from students
> regarding Axiom. :-( I think we should try to analyze why that
> happened. Although I do think that Lisp is an important programming language,
> I fear that Axiom's association with Lisp is of very little benefit to
> Axiom. It seems that very of the already very few student Lisp programmers
> are really interested in Axiom... Does anyone have any other ideas about why
> we did not receive any applications?

I must say that this question makes me a little angry.  There is at least one
*very* simple reason why we will not participate in SOC:

I prepared a wiki page, in the contents of which I put roughly five hours,
trying to prepare something which would be focussed and possible to
tackle. (not all of this effort is visible on the page, I did do some more
thinking) In fact, I also prepared a rather detailed application for google.

I then asked for mentors to step forward.  I got *very* little response, and in
the end, *not a single person* was ready to send me his/her google account
adress as required by google.

In other words, I wasted a lot of energy.

It is quite obvious to me why nobody from the lisp community wanted to write
something for axiom: the projects I proposed had nothing at all to do with
lisp... Furthermore, the last lisp project was, in my opinion, a complete
failure.

I guess that it would have been possible to prepare some lispy project, for
example cleaning up the boot compiler.  This might have been interesting, but
I'm unable to prepare such a project for several reasons:

* I do not know enough about the boot/lisp internals of axiom

* I doubt that it would be very interesting for somebody not enthusiastic about
  the axiom project

* I'm not sure whether it would be useful.

I believe it is not true that there are too few interested people in CAS.  At
least Ondrej stated that he had more students applications than he could
mentor, and I'm convinced that this is only partially due to Pythons
popularity.

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

Finally, I'd like to ask you for help.

It seems that I have lost (more or less) Neil Sloane. I hope I'll be able to
win him back, it is very important for me personally.  I am currently extremely
close to having to stop maths (and thereby also axiom), and I badly need some
"success" stories.

I am also advertising axiom at the maths and physics departments of Vienna
university -- that's one of the bigger players in the game, by the way.

I am not sure what I can ask for, I only know what would be most helpful
(regarding non-mathematical projects):

* HyperDoc or a HyperDoc replacement on Windows

* a free Aldor, or, since this is quite unlikely to happen, SPAD becoming more
  Aldor-like. Furthermore, but maybe also a first step, Axiom should understand
  Aldor's "extend".  Concerning SPAD becoming more Aldor-like, the most
  important thing would be to allow signatures as used in the Species project:

SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;

Plus(
    F: SPECIES,
    G: SPECIES
)(L: LabelType): CombinatorialSpecies(L) == add {
        Rep == Union(left: F L, right: G L);
        import from Rep;
        <<implementation: Plus>>
}


  (To make this easies to understand, here is a usage example:

Partition(L: LabelType): with {
        <<exports: Partition>>
} == add {
        <<representation: Partition>>
        import from Rep;
        <<implementation: Partition: auxiliary functions>>
        <<implementation: Partition>>
}

  is used (in Axiom roughly) like

generatingSeries()$Partition(Integer)

  which would give the generating function for the Bell numbers, or

structures(set [1,2,3])$Partition(Integer)

  which would return all set partitions of [1,2,3]: [[1,2,3]], [[1,2],[3]],
  [[1,3],[2]], [[2,3],[1]], [[1],[2],[3]]


P2 ==> Plus(Partition, Partition)(Integer)

generatingSeries()$P2

  would return twice the generating series of the set partitions.



  Another remark: I'm meanwhile more convinced than ever that SPAD is simply a
  subset of Aldor.  A while ago, somebody said that "==" would have different
  semantics, since "==" would mean "delayed evaluation" in Axiom, but that's
  not quite true: it's meaning within SPAD is compatible with Aldor's meaning,
  namely "constant assingment": functions in Aldor and SPAD are constants, and
  the usage

  f(1)==1; f(2)==1; f(n)==f(n-1)+f(n-2)

  is only possible in the interpreter -- and that's a wise decision, too, as
  Christian Aistleitner confirmed.

\start
Date: Tue, 10 Apr 2007 12:09:09 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: ECCAD on Axiom Mailing List

That's a bit of a drive for me, but I think I can make it.  I'll try to
attend. 

Cliff

--- Tim Daly wrote:

> ECCAD, The East Coast Computer Algebra Day, is being held at
> Washington College on April 21st in Chestertown, Maryland, USA.
> 
> Please come.
> Please register (eccad07.washcoll.edu) so they know how much food
> to order (they are providing lunch).
> 
> There are slots left for posters and demonstrations.
> Deadline for receipt is April 14th.

\start
Date: 10 Apr 2007 21:16:45 +0200
From: Martin Rubey
To: Gabriel Dos Reis, Waldek Hebisch, Bill Page
Subject: Kudos

Dear Bill, Gaby and Waldek!

lest my recent rant stirs bad emotions, I'd like to send the three of you a

                               BIG  "THANK YOU!"

for your work on making axiom available and stable!  Sometimes I am very
impatient, and in fear I become even more impatient and more uneasy.

Also, especially Waldek earns another

                               BIG  "THANK YOU!"

for succeeding in making my guessing package available, even if Neil Sloane was
unable to build it, for whatever reason.

I am very much indebted,

\start
Date: Tue, 10 Apr 2007 13:28:54 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

--- Martin Rubey wrote:

> It is quite obvious to me why nobody from the lisp community wanted
> to write something for axiom: the projects I proposed had nothing
> at all to do with lisp... Furthermore, the last lisp project was, in
> my opinion, a complete failure.

Well, to be fair it was lispnyc that was the "parent" project supporter
- if we are going to ask them to support an Axiom project it's only
reasonable to expect their potentital students to be looking for
"lispy" projects.

Just as another data point - Maxima has not qualified as an SoC mentor
on its own.  In one sense it might have an easier time being a
sub-project of lispnyc than Axiom in that the hurdles to jump through
to get working on it are lower (runs on more common lisps, for one
thing) but I didn't seen any such projects.

> I guess that it would have been possible to prepare some lispy
> project, for example cleaning up the boot compiler.  This might
> have been interesting, but I'm unable to prepare such a project
> for several reasons:
> 
> * I do not know enough about the boot/lisp internals of axiom

I think that's a problem with many potential Axiom projects.  I know I
certainly don't have enough knowledge currently to act as a mentor.
 
> * I doubt that it would be very interesting for somebody not
> enthusiastic about the axiom project

Most of our projects are going to be like that, unless we are looking
for some more "general purpose" lisp library we can make use of.

> * I'm not sure whether it would be useful.

Hard to say.  Done well I'm sure it would be, but it is not a simple
job.  I am not sure how many of the projects Axiom needs at the lisp
level at this stage are good summer projects.

> I believe it is not true that there are too few interested people in
> CAS.  At least Ondrej stated that he had more students applications
> than he could mentor, and I'm convinced that this is only partially
> due to Pythons popularity.

Well, that's a good sign.  

> Finally, I'd like to ask you for help.
> 
> It seems that I have lost (more or less) Neil Sloane. I hope I'll be
> able to win him back, it is very important for me personally.  I am
> currently extremely close to having to stop maths (and thereby also
> axiom), and I badly need some "success" stories.

Sorry to hear that!

> I am also advertising axiom at the maths and physics departments of
> Vienna university -- that's one of the bigger players in the game, 
> by the way.

If I may ask, what applications would they be likely to use Axiom for?

> I am not sure what I can ask for, I only know what would be most
> helpful (regarding non-mathematical projects):
> 
> * HyperDoc or a HyperDoc replacement on Windows

One question - as I understand it, AXIOMsys works on Windows but the
parent program axiom does not.  Would a HyperDoc for Windows also
require a new communications mechanism?  Doing this straight from lisp
(ala hunchentoot or something similar) would be my preference, but
again it's probably not simple.

In this problem being on a non-ANSI lisp without the support of most of
the library of Lisp goodies available today hurts.

> * a free Aldor, or, since this is quite unlikely to happen, SPAD
> becoming more Aldor-like. Furthermore, but maybe also a first step,
> Axiom should understand Aldor's "extend".  Concerning SPAD becoming
> more Aldor-like, the most important thing would be to allow 
> signatures as used in the Species
> project:

Has anyone attempted ANY SPAD compiler hacking as yet?  To the best of
my knowledge that area is almost completely uncharted waters.

Martin, is the most important thing for you to have available a Windows
binary with the Guess package successfully installed?  I can see where
we might be able to put together a NSIS based installer of a merger of
the latest build-improvements, the Guess package and maybe Emacs as a
GUI for Windows, if that would help, but getting to the point where we
can be reasonably sure of not running into the same sort of issue that
originally caused the problems with the Guess package is (IMO) a ways
down the road.  (Not that I'm qualified to have an opinion - Tim, Gaby,
or Waldek would be a much better source.)  I might be able to take a
stab at compiling a Windows release, but I'd be starting from square
one and I'm not completely sure I'll have access to a Windows box.  If
that would be a very significant help, I will look into it - let me
know.

\start
Date: Tue, 10 Apr 2007 16:48:12 -0400
From: Bill Page
To: Martin Rubey
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

Quoting Martin Rubey:

>
> lest my recent rant stirs bad emotions, I'd like to send the
. three of you a
>
>                                BIG  "THANK YOU!"
>
> for your work on making axiom available and stable!  Sometimes
> I am very impatient, and in fear I become even more impatient
> and more uneasy. 
>

Don't worry. I understand very well the reasons for your frustration. 

> Also, especially Waldek earns another
>
>                                BIG  "THANK YOU!"
>
> for succeeding in making my guessing package available, even if
> Neil Sloane was unable to build it, for whatever reason. 
>

Well, it is difficult to help people who do not ask for help ... 

> I am very much indebted,
>

As are we all. 

Earlier quoting Martin Rubey:

> Bill Page writes:
>
>> .. Does anyone have any other ideas about why we did not
>> receive any applications?
>
> I must say that this question makes me a little angry.  There is
> at least one *very* simple reason why we will not participate in
> SOC:
>
> I prepared a wiki page, in the contents of which I put roughly
> five hours, trying to prepare something which would be focussed
> and possible to tackle. (not all of this effort is visible on the
> page, I did do some more thinking) In fact, I also prepared a
> rather detailed application for google. 
>
> I then asked for mentors to step forward.  I got *very* little
> response, and in the end, *not a single person* was ready to
> send me his/her google account adress as required by google. 
>
> In other words, I wasted a lot of energy. 
>

I am sorry Martin. I recall clearly the SOC wiki page you created
but I do not recall your request for mentors, as such. Certainly
I was willing. In fact a couple of weeks later when Hoew asked me
if the Axiom project was interested in participating in SOC via
LispNYC, I immediately said "yes!" and in that case I did register
online with Google as a mentor under the LispNYC project, but I
did not have to supply Hoew directly with my Google email account. 
Perhaps there was some misunderstanding of the requirements?

> It is quite obvious to me why nobody from the lisp community
> wanted to write something for axiom: the projects I proposed
> had nothing at all to do with lisp... 
>

I added two new items to your SOC 2007 page which were specifically
directed at people with Lisp experience as soon as Hoew invited us
to participate. 

>  Furthermore, the last lisp project was, in my opinion, a complete
> failure. 

Why do you say that? Have you looked at the code that Kai produced?
I would say that the fact that we are not yet using any of this code
is not related to Kai's effort at all. I counted it as successful
because at least he showed that it was possible to work with Axiom
using common lisp tools and how to adapt Axiom's boot code to better
interface with an externally supplied user interface based on a web
browser. Personally I think that was a lot to accomplish during one
summer project. 

> I guess that it would have been possible to prepare some lispy
> project, for example cleaning up the boot compiler.  This might
> have been interesting, but I'm unable to prepare such a project
> for several reasons:

No, that is not the kind of project I would consider suitable for SOC. 

>
> * I do not know enough about the boot/lisp internals of axiom
>
> * I doubt that it would be very interesting for somebody not 
> enthusiastic about the axiom project
>
> * I'm not sure whether it would be useful. 
>

I would be useful. In fact we already have at least two people doing
that: Gaby and Waldek - although that is not their only objective. 

> I believe it is not true that there are too few interested people
> in CAS. 

I never said that. I think that C.Y. might have argued that in
another email. I also do not agree with that. What I said was that
there are first of all only a few students currently interested in
Lisp and of those there seem to be only a few who are interested
in Axiom. In fact the only proposals that LispNYC did receive that
could be considered related to Axiom did not even seem to realize
that what they were proposing was already a basic part of Axiom!
I replied to these applicants and at least one of them has since
joined the Axiom developer email list. 

> At least Ondrej stated that he had more students applications
> than he could mentor, and I'm convinced that this is only
> partially due to Pythons popularity. 

I disagree. From other emails from Ondrej it is clear that SymPy
also was only an "add-on" to three separate Python-oriented projects. 
It seems to me that the attention that SymPy got was directly
related to SymPy's association with these projects. 

> --------------------------------------------------------------------->
> Finally, I'd like to ask you for help. 
>
> It seems that I have lost (more or less) Neil Sloane. I hope I'll
> be able to win him back, it is very important for me personally. 
> I am currently extremely close to having to stop maths (and
> thereby also axiom), and I badly need some "success" stories. 

I would be glad to help. I would be VERY GOOD to have Sloane a
supporter of Axiom and I would really hate to lose your input to
the Axiom project. 

>
> I am also advertising axiom at the maths and physics departments
> of Vienna university -- that's one of the bigger players in the
> game, by the way. 
>
> I am not sure what I can ask for, I only know what would be most
> helpful (regarding non-mathematical projects):
>
> * HyperDoc or a HyperDoc replacement on Windows
>

Tim Daly reported successfully building HyperDoc under cygwin on
Windows and accessing it via Xming (an X-windows server for
Windows). I think that it is a real possibility to build both
HyperDoc and Axiom graphics under cygwin in this manner. Cygwin
is a "unix emulator" for windows. GCL however currently only
builds under MSYS/MinGW which a native Windows build environment. 
Requiring both cygwin and MSYS/MinGW to build Axiom on Windows is
a bit of a heavy requirement but it is possible. 

I use Xming together with Putty on Windows to access HyperDoc
on a unix host all the time. I works great for me. So if this
was also the way we accessed HyperDoc and Axiom Graphics on
Windows I would be quite happy. 

It is currently quite easy (but not for the "turn-key faint-of-
heart) to run Axiom on a virtual machine runing Linux under
Windows. Some people use VMware but I am particularly fond of
Microsoft's own free virtual server environment. It runs SuSE
10.2 for me under Windows XP on a dual processor AMD 4300+
machine very nicely. If I want to, I can use Putty and Xming to
access Axiom in this environment although in this case it is
easier (if you know linux) just to run a standard Linux windows
like gnome in the virtual machine. 

If anyone wants details about running Axiom in this way under
Windows, I would be glad to discuss it. 

> * a free Aldor, or, since this is quite unlikely to happen,

I still think it is possible. Please keep up the pressure however
you can. Most recently (two weeks ago) it was publicly promised
by Steven Watt that there would be some news within a week. 
But we are still waiting ... 

> SPAD becoming more Aldor-like. Furthermore, but maybe also
> a first step, Axiom should understand Aldor's "extend". 
>
> Concerning SPAD becoming more Aldor-like, the most important
> thing would be to allow signatures as used in the Species
> project:
>
> SPECIES ==> (L: LabelType) -> CombinatorialSpecies L;
>
> Plus(
>     F: SPECIES,
>     G: SPECIES
> )(L: LabelType): CombinatorialSpecies(L) == add {
>         Rep == Union(left: F L, right: G L);
>         import from Rep;
>         <<implementation: Plus>>
> }
>
>   (To make this easies to understand, here is a usage example:
>
> Partition(L: LabelType): with {
>         <<exports: Partition>>
> } == add {
>         <<representation: Partition>>
>         import from Rep;
>         <<implementation: Partition: auxiliary functions>>
>         <<implementation: Partition>>
>
>   is used (in Axiom roughly) like
>
> generatingSeries()$Partition(Integer)
>
>   which would give the generating function for the Bell numbers,
>   or
>
> structures(set [1,2,3])$Partition(Integer)
>
>   which would return all set partitions of [1,2,3]: [[1,2,3]],
>   [[1,2],[3]], [[1,3],[2]], [[2,3],[1]], [[1],[2],[3]]
>
>
> P2 ==> Plus(Partition, Partition)(Integer)
>
> generatingSeries()$P2
>
>   would return twice the generating series of the set partitions. 
>

I think it would be great if you and other members of the "Species
project" could find a way to make your work more visible (and
therefore more interesting) to others. I still do not completely
understand the objectives and what has been accomplished so far. 

>
>   Another remark: I'm meanwhile more convinced than ever that
> SPAD is simply a subset of Aldor.  A while ago, somebody said
> that "==" would have different semantics, since "==" would mean
> "delayed evaluation" in Axiom, but that's not quite true: it's
> meaning within SPAD is compatible with Aldor's meaning, namely
> "constant assingment": functions in Aldor and SPAD are constants,
> and the usage
>
>   f(1)==1; f(2)==1; f(n)==f(n-1)+f(n-2)
>
> is only possible in the interpreter -- and that's a wise decision,
> too, as Christian Aistleitner confirmed. 
>

I think that is basically correct however you do realize that Aldor
was specifically designed to be the replacement for SPAD, so this
relationship to SPAD is not at all unexpected. 

\start
Date: Tue, 10 Apr 2007 16:57:44 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

I can't resist "jumping" at the conclusion of your last email... 

Quoting Cliff Yapp:

> ... 
> Martin, is the most important thing for you to have available a
> Windows binary with the Guess package successfully installed?
> I can see where we might be able to put together a NSIS based
> installer of a merger of the latest build-improvements, the
> Guess package and maybe Emacs as a GUI for Windows, if that
> would help,

Yes, that is very easy to accomplish. 

> but getting to the point where we can be reasonably sure of not
> running into the same sort of issue that originally caused the
> problems with the Guess package is (IMO) a ways down the road. 
> (Not that I'm qualified to have an opinion - Tim, Gaby, or
> Waldek would be a much better source.)

I would not anticipate any problems at all - especially if we
can merge changes from wh-sandbox back into build-improvements. 

> I might be able to take a stab at compiling a Windows release,
> but I'd be starting from square one and I'm not completely sure
> I'll have access to a Windows box.  If that would be a very
> significant help, I will look into it - let me know. 
>

I hope Martin says "yes". Surely you can find a Windows box down
at the K-mart for not much money. ;) And I as I have said several
times before: I have done this before and I would be very glad
to help someone do it again. 

\start
Date: 10 Apr 2007 23:21:06 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Help needed, was: (Possible) reasons Axiom didn't appeal to SoC coders...

Cliff Yapp writes:

> If I may ask, what applications would they be likely to use Axiom for?

research and teaching.

> Martin, is the most important thing for you to have available a Windows
> binary with the Guess package successfully installed?

Although that would be nice, it won't help too much.  A functional HyperDoc (or
a HyperDoc replacement) is a must, because, how do you expect an MS Windows
user (used to clicking on buttons) to find out how to express and solve an ODE?
I guess, you won't teach him how to use asq or, gasp!, grep?

If you do put together a new windows binary (and: please do!), and if you want
to include my package, please note that its most recent version depends on
several algebra fixes currently only applied to wh-sandbox.

Therefore, I guess it would be more useful (especially for non-windows
developers) to help Gaby and Waldek merge there distributions (although I must
admit that I do not even know what functionality of build-improvements is
missing from wh-sandbox).

Bill writes:

> Tim Daly reported successfully building HyperDoc under cygwin on Windows and
> accessing it via Xming (an X-windows server for Windows).

But didn't he say that it was somewhat non-functional, namely, browse wouldn't
work?

> I think that it is a real possibility to build both HyperDoc and Axiom
> graphics under cygwin in this manner. Cygwin is a "unix emulator" for
> windows. GCL however currently only builds under MSYS/MinGW which a native
> Windows build environment. Requiring both cygwin and MSYS/MinGW to build
> Axiom on Windows is a bit of a heavy requirement but it is possible.

Do you think it would be possible to bundle this up in a (albeit huge) package,
that works more or less out of the box? (However, again: it makes sense only if
HyperDoc browse works)

This would be WONDERFUL!

You see, I'm a bit reluctant to drive people into developing HyperDoc too much,
since what I really want is a bit different. (namely, a HyperDoc replacement
running on any good internet browser, having the functionality of HyperDoc but
moreover understanding documentation written in LaTeX with ALLPROSE / aldoc
conventions.)

But if it is not tooooo big a project, such a bundle would be, again:
WONDERFUL.

\start
Date: Tue, 10 Apr 2007 14:24:33 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Martin Rubey
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

--- Bill Page wrote:

> > I believe it is not true that there are too few interested people
> > in CAS. 
> 
> I never said that. I think that C.Y. might have argued that in
> another email. I also do not agree with that. 

What I suggested was a possible cause of the SoC result - that there
are very few students interested in CAS work. I also mentioned that I
was only listing possible causes without having data to back them up. 
I am not arguing that IS the case, only suggesting it as a possible
casue of lack of SoC interest (if it WERE true, it would explain it - I
do not know if it is true.)  From our standpoint, lack of CAS interest
vs. lack of Axiom/Lisp interest would look pretty much the same in
terms of project results.

> What I said was that
> there are first of all only a few students currently interested in
> Lisp and of those there seem to be only a few who are interested
> in Axiom.

Right.

> In fact the only proposals that LispNYC did receive that
> could be considered related to Axiom did not even seem to realize
> that what they were proposing was already a basic part of Axiom!
> I replied to these applicants and at least one of them has since
> joined the Axiom developer email list. 

Well, that's good news.

\start
Date: Tue, 10 Apr 2007 14:30:35 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

> > I can see where we might be able to put together a NSIS based
> > installer of a merger of the latest build-improvements, the
> > Guess package and maybe Emacs as a GUI for Windows, if that
> > would help,
> 
> Yes, that is very easy to accomplish. 

OK.  I am of the opinion that, given the already large size of Axiom,
it is worth bundling a binary of Emacs and making that the default UI
unless/until something better becomes available.  Anyone else have an
opinion on that one?
 
> I would not anticipate any problems at all - especially if we
> can merge changes from wh-sandbox back into build-improvements. 

OK.
 
> I hope Martin says "yes". Surely you can find a Windows box down
> at the K-mart for not much money. ;) And I as I have said several
> times before: I have done this before and I would be very glad
> to help someone do it again. 

We are long overdue for a Windows release.  I might be able to get
access to a box in about 3 weeks, and if I can I'll set up an Axiom
build environment and take a stab at it.  I'm a Linux guy myself but we
really need something newer than the current binary...

\start
Date: 10 Apr 2007 23:40:34 +0200
From: Martin Rubey
To: Bill Page
Subject: species project, was: (Possible) reasons Axiom didn't appeal to SoC coders...

Bill Page writes:

> > * a free Aldor, or, since this is quite unlikely to happen,
> 
> I still think it is possible. Please keep up the pressure however you
> can. Most recently (two weeks ago) it was publicly promised by Steven Watt
> that there would be some news within a week. But we are still waiting ...

well, the trouble really is: in what sense do you expect aldor to be open
source? would you be happy if it was open source but without granting the right
for redistribution?  I expect something of this sort.  And, although I believe
that this would still be great, I also believe that in this case it would be
better to have a free implementation of the Aldor language, too, even if it
implements only a subset and is, say, much slower.

This model works very well in the Lisp world, and it would prevent another
MuPAD catastrophy from happening...

> I think it would be great if you and other members of the "Species project"
> could find a way to make your work more visible (and therefore more
> interesting) to others. 

There are two developers: Ralf and me. We do have at least two advisors:
Nicolas Thiery for maths and design and Christian Aistleitner for Aldor.

> I still do not completely understand the objectives and what has been
> accomplished so far.

We implemented Andre Joyal's theory of "Combinatorial Species", as developed by
Francois Bergeron, Gilbert Labelle and Pierre Leroux

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

in a *very* mathematical manner.  In one sentence: a species is a collection of
labelled objects, closed under relabelling.

I.e., to define binary trees (the labels are on the leaves) they write:

        B = X + B*B

and we write

        macro {
                CS == CombinatorialSpecies;
                X == SingletonSpecies;
        }
        B(L: LabelType): CS L == Plus(X, Times(B, B))(L) add;

I hope, you see the similarity.  To define forests of binary trees we continue
with

        F(L: LabelType): CS L == Compose(SetSpecies, B)(L) add;

So far we can 

* generate exhaustively the structures - and also use them, i.e., for example,
  write a function that computes the height of a given tree.

* experimentally, generate exhaustively the isomorphismtypes of the structures.
  For example, we can generate all set partitions, but also all integer
  partitions.

* compute the generating function (in the sense of a lazy stream) for the
  structures, the isomorphismtypes, but also a formal power series that
  generalises these two generating functions, namely, the cycle index series.

Our next goals are

* extend to multisorted species, i.e., species where the labels are structured
  according to colour

and maybe

* investigate vectorial species, i.e., functors from the category of finite
  sets into the category of finite dimensional vector spaces

* investigate whether we can compute the molecular expansion of a species

\start
Date: Tue, 10 Apr 2007 14:56:30 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Bill Page
Subject: Re: species project

--- Martin Rubey wrote:

> well, the trouble really is: in what sense do you expect aldor to be
> open source? would you be happy if it was open source but without
> granting the right for redistribution?

Arrgh.  In other words, we still couldn't integrate it into the Axiom
system?

> I expect something of this sort.

While of course it is the right of the copyright holders to do as they
see fit, I'd be curious as to what they would expect to gain from this
move.  As you mention below:

> it would be better to have a free implementation of the Aldor
> language, too, even if it implements only a subset and is, say,
> much slower.

SPAD will probably become that, if it must.  Which would pretty much
leave Aldor where it is now - is there another potential large scale
application for the Aldor language that can't be adequately filled by
O'Caml, Haskell, or one of the other such languages available today?

There are some potentially interesting long term projects that could be
investigated with either SPAD or Aldor in terms of integrating proof
systems with Axiom, and the flexibility to work deeply with the
language implementation and even the language definition itself could
wind up being important.  Either way, something definite on Aldor would
be nice - even if we find out for sure we can't use it at least we
could then devote time to SPAD knowing we wouldn't have the rug yanked
out from under us by an Aldor release (i.e. it would be work we do
actually need to do and couldn't avoid by waiting).

\start
Date: 10 Apr 2007 17:08:22 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: building wh-sandbox on Axiom on Solaris 10.2x86

Waldek Hebisch writes:

[...]

| My guess is that change to configure broke it and configure 
| decided that there is no socket support.

If socket support is detected not to exist, configure would not have
generated Makefiles to that instruct to build sman.

\start
Date: Tue, 10 Apr 2007 18:14:24 -0400
From: Cliff Yapp
To: Martin Rubey
Subject: Re: Help needed, was: (Possible) reasons Axiom	didn't appeal to SoC coders...

Martin Rubey wrote:

>> I think that it is a real possibility to build both HyperDoc and Axiom
>> graphics under cygwin in this manner. Cygwin is a "unix emulator" for
>> windows. GCL however currently only builds under MSYS/MinGW which a native
>> Windows build environment. Requiring both cygwin and MSYS/MinGW to build
>> Axiom on Windows is a bit of a heavy requirement but it is possible.
> 
> Do you think it would be possible to bundle this up in a (albeit huge) package,
> that works more or less out of the box? (However, again: it makes sense only if
> HyperDoc browse works)

That might be technically possible but large doesn't even begin to
describe it.  At that point we might as well think about bundling a live
ISO with an emulator and do things that way - it would probably be simpler.

> This would be WONDERFUL!

Keep in mind that this would be an X Windows application under Microsoft
Windows, and would not match at all closely the look and feel of any
normal Windows application.  Also, it may conflict with existing
cygwin/X setups - not sure about that.

> You see, I'm a bit reluctant to drive people into developing HyperDoc too much,
> since what I really want is a bit different. (namely, a HyperDoc replacement
> running on any good internet browser, having the functionality of HyperDoc but
> moreover understanding documentation written in LaTeX with ALLPROSE / aldoc
> conventions.)
> 
> But if it is not tooooo big a project, such a bundle would be, again:
> WONDERFUL.

I don't quite know about the technical difficulty, as it's been a while
since I have dealt with any of these systems.  I would expect such a
bundle to be HUGE.

If we can successfully release a "normal" Windows binary perhaps we can
look next at bundling cygwin and X for an "all-in-one" type release.

\start
Date: 10 Apr 2007 17:28:52 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

Cliff Yapp writes:

[...]

| > * I do not know enough about the boot/lisp internals of axiom
| 
| I think that's a problem with many potential Axiom projects.  I know I
| certainly don't have enough knowledge currently to act as a mentor.

At this point, there is no much to improve at the boot/lisp internals
per see.  But, you definitely want to integrate the new parser into
the compiler and share more between in the intepreter and the
compiler. 

Also, people should really look at the trace file and try to correct
the algebra files -- there are quite a few bugs there.

[...]

| > I am not sure what I can ask for, I only know what would be most
| > helpful (regarding non-mathematical projects):
| > 
| > * HyperDoc or a HyperDoc replacement on Windows
| 
| One question - as I understand it, AXIOMsys works on Windows but the
| parent program axiom does not.  Would a HyperDoc for Windows also
| require a new communications mechanism?  Doing this straight from lisp
| (ala hunchentoot or something similar) would be my preference, but
| again it's probably not simple.

I see no fundamental reason why both process should not be threads in
the same problem and therefore bypass the socket stuff.  From my
perspective, that is just another over-engineering aspect of Axiom.
Notice that if you use sockets, the the anti-virus firewall will
consider Axiom as a program that wants access to network and it might
be blocked; then the anti-virus will ask you whether you want to grant
access or not.  That is silly.

\start
Date: 10 Apr 2007 17:17:25 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

Martin Rubey writes:

[...]

| It is quite obvious to me why nobody from the lisp community wanted to write
| something for axiom: the projects I proposed had nothing at all to do with
| lisp... Furthermore, the last lisp project was, in my opinion, a complete
| failure.

The idea that Axiom is a Lisp project is largely fantasy. 
Semi ;-)

\start
Date: 10 Apr 2007 17:23:06 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Kudos
Cc: Waldek Hebisch

Martin Rubey writes:

[...]

| even if Neil Sloane was unable to build it, for whatever reason.

I believe we must not underestimate people's time.  If it does not
work out from the box, you'll have hard time convincing people that it
is worth their time.  It is a fact I've observed  many times in many
occassions. This is partly why I'm spending so much resource in
simplifying the build machinery; and I hope it does not get lost
because the Axiom community is unfocused -- even though it is a very
very tiny community. 

For my class using Axiom to "succeed", I need an Axiom that does not
require heroic effort -- please don't tell me "yum", "apt-get"; they
don't work for everybody.

\start
Date: Tue, 10 Apr 2007 18:54:36 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: Help needed

Quoting Cliff Yapp:

> Martin Rubey wrote:
>
>>> I think that it is a real possibility to build both HyperDoc
>>> and Axiom graphics under cygwin in this manner. Cygwin is a
>>> "unix emulator" for windows. GCL however currently only builds
>>> under MSYS/MinGW which a native Windows build environment.
>>> Requiring both cygwin and MSYS/MinGW to build Axiom on Windows
>>> is a bit of a heavy requirement but it is possible.
>>
>> Do you think it would be possible to bundle this up in a
>> (albeit huge) package, that works more or less out of the
>> box? (However, again: it makes sense only if HyperDoc browse
>> works)
>
> That might be technically possible but large doesn't even begin
> to describe it.

No. Let's be clear. The *build* environment would require both
cygwin and MSYS/MinGW. That is large but not huge. I run both of
these easily in my usual Windows development environment.

But the *run-time* (binary) environment would not be much bigger
than the current Linux and Windows binaries. Applications built
with cygwin require only the presence of the cygwin dll library.
There used to be a license issue about distributing packages
containing only that part of cygwin - I am not sure if that is
still the case or not - but in any case requiring that the user
install a minimal cygwin environment as a prerequiste is not all
that bad. Applications built with MSYS/MinGW on the other hand
run natively on Windows and do not require any extra specially
licensed libraries.

cygwin provides a online download and update facility similar
to Debian apt-get, so if it was possible to package Axiom for
cygwin this way, it would make it very easy for Windows users
to install Axiom.

> At that point we might as well think about bundling a live
> ISO with an emulator and do things that way - it would probably
> be simpler.

A live ISO that will boot under VMware was developed by Alfredo
and is already available. See

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

>
>> This would be WONDERFUL!
>

In principle it would be easy to create a new DoyenCD with
Axiom compiled from wh-sandbox which would already contain
Martin's guess package.

> Keep in mind that this would be an X Windows application
> under Microsoft Windows, and would not match at all closely
> the look and feel of any normal Windows application.

That is true, however Xming integrates very well with Windows
in my opinion. The X managed windows appear along with the
windows managed directly by Microsoft Windows. It is true
that they have an "odd" menu system by Windows standards but
in other respects they look familiar.

> Also, it may conflict with existing cygwin/X setups - not
> sure about that.
>

No, I don't think so. But in general I avoid running the
X windows server under cygwin. I like Xming much better.

>> You see, I'm a bit reluctant to drive people into developing
>> HyperDoc too much, since what I really want is a bit different.
>> (namely, a HyperDoc replacement running on any good internet
>> browser, having the functionality of HyperDoc but moreover
>> understanding documentation written in LaTeX with ALLPROSE
>> / aldoc conventions.)
>>
>> But if it is not tooooo big a project, such a bundle would be,
>> again: WONDERFUL.
>
> I don't quite know about the technical difficulty, as it's been
> a while since I have dealt with any of these systems.  I would
> expect such a bundle to be HUGE.
>

No, I don't agree. It is not likely to be any bigger than the
existing HyperDoc application under Linux - smaller perhaps
because the web browser itself would presumably be just be an
easily satisfied pre-requisite, i.e. all Windows users have at
least IExplorer and FireFox is very easy it acquire.

> If we can successfully release a "normal" Windows binary perhaps
> we can look next at bundling cygwin and X for an "all-in-one"
> type release.
>

That's the easy part. Finding a way to build HyperDoc and
Axiom Graphics as cygwin applications while running AXIOMsys
as a native application with the right support for sockets
might be the hard part.

\start
Date: 10 Apr 2007 17:10:29 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: building wh-sandbox on Axiom on Solaris 10.2 x86

Waldek Hebisch writes:

[...]

| There is a problem with the diff: configure.ac.pamphlet in wh-sandbox
| is synced with build improvements 485 (the differences are intentional).

I do hope you do all your best to avoid duplicated build-improvements
work. 

\start
Date: 10 Apr 2007 17:30:32 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

Bill Page writes:

[...]

| I would not anticipate any problems at all - especially if we
| can merge changes from wh-sandbox back into build-improvements.

We should.  I see no compelling reason why we should hae parallel
build effort on branches from build-improvements and keep them
separate. 

\start
Date: 10 Apr 2007 17:32:09 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Help needed, was: (Possible) reasons Axiom didn't appeal to SoC coders...

Martin Rubey writes:

[...]

| Bill writes:
| 
| > Tim Daly reported successfully building HyperDoc under cygwin on Windows and
| > accessing it via Xming (an X-windows server for Windows).

GCL-2.6.8pre cannot build on cygwin; I don't know how to get the whole
thing. 

\start
Date: Tue, 10 Apr 2007 19:34:56 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

Quoting Gabriel Dos Reis:

> ... 
> C Y wrote:
> |
> | One question - as I understand it, AXIOMsys works on Windows but the
> | parent program axiom does not.  Would a HyperDoc for Windows also
> | require a new communications mechanism?  Doing this straight from lisp
> | (ala hunchentoot or something similar) would be my preference, but
> | again it's probably not simple. 
>

Currently AXIOMsys can only be built using gcl on windows. The only
available version of gcl for windows is built as a native windows application
using MSYS/MinGW. There is an experimental version of Axiom built
with SBCL for Windows by Gregory Vanuxem but as far as I know it
does not include socket support. For that matter, neither does the
gcl version of Axiom for windows. Axiom has it's own routines written
in C that provide the socket interface and so far this has not been
incorporated into the version of Axiom for Windows. 

If by "parent program" you mean "sman" and "session"? Since these are
C programs there is no good reason not be able to compile them under
either cygwin or MSYS/MinGW (native windows). The trick is to get the
right support for sockets.  On the other hand, 'hyperdoc' and 'graphics'
both require X-windows. This is something that (as far as I know) is only
available under cygwin. 

> I see no fundamental reason why both process should not be threads in
> the same problem and therefore bypass the socket stuff.  From my
> perspective, that is just another over-engineering aspect of Axiom. 
> Notice that if you use sockets, the the anti-virus firewall will
> consider Axiom as a program that wants access to network and it might
> be blocked; then the anti-virus will ask you whether you want to grant
> access or not.  That is silly. 
>

That is correct however historically Axiom was designed at a time when
there was not thread suppor under unix (or what ever Axiom was built
on at that time) and it was still considered "pretty neat" to get this stuff
working via sockets. So I would call it legacy rather than over engineering. 

\start
Date: Tue, 10 Apr 2007 17:42:16 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...

--- Bill Page wrote:

> If by "parent program" you mean "sman" and "session"? Since these are
> C programs there is no good reason not be able to compile them under
> either cygwin or MSYS/MinGW (native windows). The trick is to get the
> right support for sockets.  On the other hand, 'hyperdoc' and
> 'graphics' both require X-windows. This is something that (as far
> as I know) is only available under cygwin. 

There are X servers for Windows other than cygwin but I believe they
are all commercial - nor do I know if we could successfully work with
them.  The correct approach here is to work with some cross platform
toolkit and avoid the need for an X server, but that will take time
:-(.  Socket support on Windows should be possible - IIRC Maxima makes
use of this.

> > I see no fundamental reason why both process should not be threads
> > in the same problem and therefore bypass the socket stuff.  From my
> > perspective, that is just another over-engineering aspect of Axiom.

It helps in at least one respect - threads in lisp are not universal
between implementations and platforms, and if thread support is not
robust depending on it is a bit risky.  Sockets are at least universal
and flexible.  My understanding was GCL does not currently support
threads - has this changed?  What about on Windows and Linux?  How
about Solaris and MacOSX?  SBCL has threads on Linux and I think they
are either close or there on Windows (with what level of robustness I
don't know.)  CMUCL has threads on x86, but I'm not sure about other
platforms.  Other lisps I don't know - IIRC Clisp does not have
threads.  If we decide to go only with SBCL we might be able to use
threads only but sockets should work virtually anywhere.

Also, what about situations where (for example) someone wants to run
the Axiom kernel on a dedicated machine and the interface on another
machine?  Sockets are ideal for this sort of situation.

> > Notice that if you use sockets, the the anti-virus firewall will
> > consider Axiom as a program that wants access to network and it
> > might be blocked; then the anti-virus will ask you whether you
> > want to grant access or not.  That is silly. 

Yes, XMaxima and possible WxMaxima have that problem on Windows. 
Normally it is dealt with once and then works fine from there on.  I
agree it is annoying but I'm not convinced that issue in and of itself
it is sufficient reason to abandon sockets.  Or perhaps there is some
other inter-process communication mechanism we could take advantage of
that doesn't involve sockets and their firewall issues (does
Mathematica's MathLink have firewall problems?  I don't know.)
 
> That is correct however historically Axiom was designed at a time
> when there was not thread suppor under unix (or what ever Axiom was 
> built on at that time) and it was still considered "pretty neat" to 
> get this stuff working via sockets. So I would call it legacy rather 
> than over engineering. 

Thread support is still spotty between implementations and platforms. 
I would say use it if available, but don't depend on it as a do-or-die
feature.  Couldn't we do something like:

Start Axiom GUI ->  If threads, start new thread with kernel
                    If no threads, start new process with kernel

\start
Date: Tue, 10 Apr 2007 20:59:20 -0400
From: Bill Page
To: Cliff Yapp
Subject: Re: (Possible) reasons Axiom didn't appeal to SoC coders...
Cc: Gabriel Dos Reis

Quoting C Y :

> --- Bill Page wrote:
>
>> If by "parent program" you mean "sman" and "session"? Since these are
>> C programs there is no good reason not be able to compile them under
>> either cygwin or MSYS/MinGW (native windows). The trick is to get the
>> right support for sockets.  On the other hand, 'hyperdoc' and
>> 'graphics' both require X-windows. This is something that (as far
>> as I know) is only available under cygwin.
>
> There are X servers for Windows other than cygwin but I believe they
> are all commercial - nor do I know if we could successfully work with
> them.

No. I meant X-windows *client* support, i.e. the X libraries and associated
machinery. Both hyperdoc and graphics require this X-windows client
support.

The X server component is no problem. A good free X server is provided
by Xming on Windows:

http://sourceforge.net/projects/xming

I would not recommend running the X server component under cygwin.
I've tried it and I think it sucks. If you really want this, then I think you
really want Linux.

>  The correct approach here is to work with some cross platform
> toolkit and avoid the need for an X server, but that will take time

I am not convinced that this is the correct approach. It works for
some, e.g. GIMP, but it still looks ugly to me. I am much more
in favor of the web-browser-as-gui solution for cross platform
support. But both of these are too much work for the resources
we have available right now.

> :-(.  Socket support on Windows should be possible - IIRC
> Maxima makes use of this.

Certainly GCL supports sockets on Windows. No problem. But
Axiom rolls it's own socket support, so linking it into GCL on
Windows is a little technically challenging (but not too difficult,
I think). But probably it would be better to modify AXIOM to use
the socket support built in to Lisp (GCL).

\start
Date: Tue, 10 Apr 2007 23:34:13 -0400
From: Cliff Yapp
To: Bill Page
Subject: Re: (Possible) reasons Axiom didn't appeal to	SoC coders...

Bill Page wrote:

> No. I meant X-windows *client* support, i.e. the X libraries and associated
> machinery. Both hyperdoc and graphics require this X-windows client
> support.

Ah.

> The X server component is no problem. A good free X server is provided
> by Xming on Windows:
> 
> http://sourceforge.net/projects/xming

Neat!  Clearly I'm behind on the state of the art in free Windows X servers.

> I would not recommend running the X server component under cygwin.
> I've tried it and I think it sucks. If you really want this, then I
> think you really want Linux.

Agreed - that was the context I was originally considering for X
Hyperdoc on Windows.  Xming changes things.

>>  The correct approach here is to work with some cross platform
>> toolkit and avoid the need for an X server, but that will take time
> 
> I am not convinced that this is the correct approach. It works for
> some, e.g. GIMP, but it still looks ugly to me. I am much more
> in favor of the web-browser-as-gui solution for cross platform
> support. But both of these are too much work for the resources
> we have available right now.

GIMP uses GTK, which I agree is not very good for a native Windows look
and feel.  TK with the Tile extensions is somewhat better, and there are
other alternatives as well (QT is excellent, but does not have robust
lisp bindings).  The Right Way to do native behavior would be a robust
McCLIM with native backends for each platform, but that is likely many
man-years of work away :-(.

In theory, a proper communications API would allow browsers, GUIs, and
anything else to communicate with the same core with minimal trouble -
IIRC Kai and I agreed that was a logical point to focus initial efforts,
the last time the issue came up.

>> :-(.  Socket support on Windows should be possible - IIRC
>> Maxima makes use of this.
> 
> Certainly GCL supports sockets on Windows. No problem. But
> Axiom rolls it's own socket support, so linking it into GCL on
> Windows is a little technically challenging (but not too difficult,
> I think). But probably it would be better to modify AXIOM to use
> the socket support built in to Lisp (GCL).

Agreed.  Maybe an overlay to hide implementation specific socket APIs
would be good, but I'm not familiar with the options except knowing
about the existence of usocket:  http://common-lisp.net/project/usocket/
 Apparently GCL is not on the usocket list yet.

\start
Date: 11 Apr 2007 09:02:20 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: differences wh-sandbox and build-improvements,	was: Kudos
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> I hope it does not get lost because the Axiom community is unfocused -- even
> though it is a very very tiny community.

Yes, I also think that this is a great problem, although it is a problem of all
packages developed by people in their spare time or as a hobby.

For this reason I started the axiom workshops together with Ralf, and tried
hard to make them VERY focussed. If the coming workshop is as successful as the
last in terms of resulting code, it would be wonderful.


Waldek, Gaby, maybe you could spend a minute explaining in what ways
build-improvements and wh-sandbox differ. I have the impression that wh-sandbox
covers most if not all of build-improvements.  Is this incorrect?  If not, why
do you want to merge things back from wh-sandbox into build-improvements and
not the other way round?

\start
Date: 11 Apr 2007 08:40:05 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: differences wh-sandbox and build-improvements, was: Kudos
Cc: Waldek Hebisch

Martin Rubey writes:

[...]

| Waldek, Gaby, maybe you could spend a minute explaining in what ways
| build-improvements and wh-sandbox differ. I have the impression that wh-sandbox
| covers most if not all of build-improvements.  Is this incorrect?

I believe wh-sandbox does not contain all of build-improvements as
evidenced by the recent experiment of Bill and Waldek.  It is hard for
me tell which is which because when the changes are merged to
wh-sandbox, the ChangeLog does not contain proper labels, which
changes are taken, which are left out, etc and the rationale.  Waldek
knows best all the details. 

Furthermore, in any sane development development environment, when you
create a branch B from a tree A, you regularly merge from A to B, not
to lose track.  And other branches are created as well from A, so it
is simpler to merge back to A to minimize conflicts, manual
resolutions etc.  That is why, for example I try to make sure
gdr-sandbox does not stay too far from build-improvements.  Anything
else tend to create unnecessary work -- I don't know for others, but I
don't enough time to spend solving problems I could avoid in the first
place. 

\start
Date: 11 Apr 2007 10:08:49 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: [501] branches/build-improvements

Gabriel Dos Reis writes:

| Gregory Vanuxem writes:
|
| | Hello,
| |
| | Le mercredi 11 avril 2007 =E0 06:49 -0700, dos-reis@users.sourceforge.n=
et
| | a =E9crit :
| | > Revision: 501
| | >           http://svn.sourceforge.net/axiom/?rev=501&view=rev
| | > Author:   dos-reis
| | > Date:     2007-04-11 06:49:23 -0700 (Wed, 11 Apr 2007)
| | >
| | > Log Message:
| | > -----------
| | > 2007-04-11  Gabriel Dos Reis  Gabriel Dos Reis
| | >
| | >         * configure.ac.pamphlet: Update version info.
| | >         * configure.ac: Regenerate.
| | >         * configure: Likewise.
| | >
| | > 2007-04-11  Gabriel Dos Reis  Gabriel Dos Reis
| | >
| | >         * postpar.boot.pamphlet: Push into package BOOT.
| | >         Remove cached Lisp translation
| | >         * Makefile.pamphlet (<<postpar.clisp>>): Remove.
| | >         (postpar.boot): Translate with bootsys.
| | >         * Makefile.in: Regenerate.
| | >
| | > Modified Paths:
| | > --------------
| | >     branches/build-improvements/ChangeLog.build-improvements
| | >     branches/build-improvements/configure
| | >     branches/build-improvements/configure.ac
| | >     branches/build-improvements/configure.ac.pamphlet
| | >     branches/build-improvements/src/interp/ChangeLog.build-improvemen=
ts
| | >     branches/build-improvements/src/interp/Makefile.in
| | >     branches/build-improvements/src/interp/Makefile.pamphlet
| | >     branches/build-improvements/src/interp/c-util.boot.pamphlet
| | >     branches/build-improvements/src/interp/postpar.boot.pamphlet
| | >     branches/build-improvements/src/scripts/document.in
| |
| | c-util.boot was modified too :-). I don't know if this is intentional
| | but you did not push it into the "BOOT" package.
|
| Ooooops, I checked in the WRONG tree -- I meant to check in the tree
| that constains only the change to c-util.  I'm deeply sorry.
                                    ^^^^^^

gloops; I meant "postpar.boot" changes only.  As is the tree cannot
build.

There is a bug in c-util.boot that I wanted to correct before adding
the changes that make it compilable with bootsys.
I should not commit to Axiom early in the morning before enough
coffee.

I'll notify you when I reinstate the tree in a good shape.  Sorry for
the inconvenience.

\start
Date: 11 Apr 2007 10:59:17 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: [501] branches/build-improvements

Gregory Vanuxem writes:

| Hello,
|
| Le mercredi 11 avril 2007 =E0 06:49 -0700, dos-reis@users.sourceforge.net
| a =E9crit :
| > Revision: 501
| >           http://svn.sourceforge.net/axiom/?rev=501&view=rev
| > Author:   dos-reis
| > Date:     2007-04-11 06:49:23 -0700 (Wed, 11 Apr 2007)
| >
| > Log Message:
| > -----------
| > 2007-04-11  Gabriel Dos Reis  Gabriel Dos Reis
| >
| >         * configure.ac.pamphlet: Update version info.
| >         * configure.ac: Regenerate.
| >         * configure: Likewise.
| >
| > 2007-04-11  Gabriel Dos Reis  Gabriel Dos Reis
| >
| >         * postpar.boot.pamphlet: Push into package BOOT.
| >         Remove cached Lisp translation
| >         * Makefile.pamphlet (<<postpar.clisp>>): Remove.
| >         (postpar.boot): Translate with bootsys.
| >         * Makefile.in: Regenerate.
| >
| > Modified Paths:
| > --------------
| >     branches/build-improvements/ChangeLog.build-improvements
| >     branches/build-improvements/configure
| >     branches/build-improvements/configure.ac
| >     branches/build-improvements/configure.ac.pamphlet
| >     branches/build-improvements/src/interp/ChangeLog.build-improvements
| >     branches/build-improvements/src/interp/Makefile.in
| >     branches/build-improvements/src/interp/Makefile.pamphlet
| >     branches/build-improvements/src/interp/c-util.boot.pamphlet
| >     branches/build-improvements/src/interp/postpar.boot.pamphlet
| >     branches/build-improvements/src/scripts/document.in
|
| c-util.boot was modified too :-). I don't know if this is intentional
| but you did not push it into the "BOOT" package.

I reverted the tree to the state it was at revision 500.

\start
Date: Wed, 11 Apr 2007 21:54:38 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: differences wh-sandbox and build-improvements, was: Kudos
Cc: Waldek Hebisch, Gabriel Dos Reis

Martin Rubey wrote:
> Waldek, Gaby, maybe you could spend a minute explaining in what ways
> build-improvements and wh-sandbox differ. I have the impression that wh-sandbox
> covers most if not all of build-improvements.  Is this incorrect?  If not, why
> do you want to merge things back from wh-sandbox into build-improvements and
> not the other way round?
> 

Concerning parts of build-improvements included in wh-sandbox let
me repeat (with little correction) what I wrote in another mail:

The src/boot directory and src/scripts/document.in is synced with
build improvements 485.
In src/interp and src/algebra I belive that I picked all changes
that I now want to go into wh-sandbox -- in this sense both directories
are synced, but differences are significant (I may use some changes later
but ATM other changes conflict with my work).  Other directories
(src/lib, src/clef, src/sman, src/graph, src/hyper) were synced 
with build improvements 358 and need re-syncing.

In particular many portability improvements to build-improvements
are still not merged.

If you look at line counts (and skip genereated files) probably the
biggest part of build-improvements not include in wh-sandbox is in
src/interp/Makefile.pamphlet and src/algebra/Makefile.pamphlet.  ATM
this difference is intentional, algebra build in wh-sandbox is quite
different then in build-improvements, and in interp Makefile I belive
that wh-sandbox has similar functionality as build-improvements, but
the Makefile is simpler.

I intend to merge other changes but I considered wholesale merge
inpractical (it would generate too much breakage).  So my tactic
was to merge configure part (most other changes depend on configure),
boot part (easy to do and needed for my other work), and 
interp changes (needed to avoid major breakage).  In principle
merging the other part should be now easier, but there are
some conflicts there...

What wh-sandbox has which is not in build-improvements:
1) A lot of unused code is removed from wh-sandbox
2) depsys boot files are converted to shoe (and bootstrap
   Lisp is removed).  IIUC Gaby is doing similar thing
   in build-improvements.
3) new algebra bootstrap
4) many bug fixes

\start
Date: 11 Apr 2007 15:25:08 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: differences wh-sandbox and build-improvements, was: Kudos
Cc: Waldek Hebisch

Waldek Hebisch writes:

[...]

| 2) depsys boot files are converted to shoe (and bootstrap
|    Lisp is removed).  IIUC Gaby is doing similar thing
|    in build-improvements.

This is something I would have liked to go into build-improvements so
that I don't have to do the same thing.

\start
Date: Wed, 11 Apr 2007 16:39:57 -0400
From: Bill Page
To: Waldek Hebisch
Subject: re: building wh-sandbox on Axiom on Solaris 10.2x86
Cc: Gabriel Dos Reis

Quoting Waldek Hebisch:

> ... 
> My guess is that change to configure broke it and configure
> decided that there is no socket support.  Consequently configure
> did not create sman subdirectory.  In such case src/Makefile
> should skip sman subdriectory -- it looks that wh-sandbox have
> unnecessery dependency on all-sman. 
>

I can now confirm that after removing my unintentional reversion
of 'configure.ac.pamphlet' to build-improvements revision 366 but
keeping the other changes from that revision, wh-sandbox builds
successfully on my Solaris x86 system. 

I would consider the next challenge for portability of wh-sandbox
to be a successful build under Windows. I think this will require
the incorporation of a few more revisions from build-improvements. 

Waldek, I am ready to commit my revisioin 366 based changes
to wh-sandbox. Shall I proceed?

\start
Date: Wed, 11 Apr 2007 23:14:58 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: re: building wh-sandbox on Axiom on Solaris 10.2x86
Cc: Gabriel Dos Reis

Bill Page wrote:
> I can now confirm that after removing my unintentional reversion
> of 'configure.ac.pamphlet' to build-improvements revision 366 but
> keeping the other changes from that revision, wh-sandbox builds
> successfully on my Solaris x86 system. 
> 
> I would consider the next challenge for portability of wh-sandbox
> to be a successful build under Windows. I think this will require
> the incorporation of a few more revisions from build-improvements. 
> 
> Waldek, I am ready to commit my revisioin 366 based changes
> to wh-sandbox. Shall I proceed?
> 

Yes, go on.

\start
Date: 11 Apr 2007 19:59:30 -0500
From: Gabriel Dos Reis
To: list
Subject: [Richard Fateman] Re:	[Maxima] strange behaviour with simple decimals / Axiom

FYI.

Date: Wed, 11 Apr 2007 17:54:35 -0700
From: Richard Fateman
Subject: Re: [Maxima] strange behaviour with simple decimals / Axiom

In Axiom version of  1/17/2005

1.4^2  comes out as 1.96

1.96 - 1.4^2  comes out as  0.7 E -20

I don't know if this counts as unexpected to a 5th grader, but does a 
5th grader even know about "E" scientific notation?

\start
Date: Wed, 11 Apr 2007 21:27:58 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: [Richard Fateman]	Re: [Maxima] strange behaviour with simple decimals / Axiom

Quoting Gabriel Dos Reis:

>
> FYI. 
>

Here is the result from Maxima:

Maxima 5.11.99rc1 http://maxima.sourceforge.net
Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)
Distributed under the GNU Public License. See the file COPYING. 
Dedicated to the memory of William Schelter. 
This is a development version of Maxima. The function bug_report()
provides bug reporting information. 
(%i1) 1.4^2;
(%o1)                                1.96
(%i2) 1.96 - 1.4^2;
(%o2)                       2.2204460492503131E-16
(%i3)

---------

Date: Wed, 11 Apr 2007 17:54:35 -0700
Subject: Re: [Maxima] strange behaviour with simple decimals / Axiom
From: Richard Fateman
To: maxima@math.utexas.edu
In Axiom version of  1/17/2005

1.4^2  comes out as 1.96

1.96 - 1.4^2  comes out as  0.7 E -20

I don't know if this counts as unexpected to a 5th grader, but does a
5th grader even know about "E" scientific notation?

\start
Date: 11 Apr 2007 20:40:21 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [Richard Fateman] Re: [Maxima] strange behaviour with simple decimals / Axiom

Bill Page writes:

| Quoting Gabriel Dos Reis:
| 
| >
| > FYI.
| 
| Here is the result from Maxima:
| 
| Maxima 5.11.99rc1 http://maxima.sourceforge.net
| Using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (aka GCL)
| Distributed under the GNU Public License. See the file
| COPYING. Dedicated to the memory of William Schelter. This is a
| development version of Maxima. The function bug_report()
| provides bug reporting information. (%i1) 1.4^2;
| (%o1)                                1.96
| (%i2) 1.96 - 1.4^2;
| (%o2)                       2.2204460492503131E-16
| (%i3)

I believe that can explained by the fact that Axiom uses the host
"long double" C datatype for DoubleFloat whereas Maxima must be using
the more conventional and reliable "double" C datatype.

| ---------
| 
| Date: Wed, 11 Apr 2007 17:54:35 -0700
| Subject: Re: [Maxima] strange behaviour with simple decimals / Axiom
| From: Richard Fateman
| To: maxima@math.utexas.edu
| In Axiom version of  1/17/2005
| 
| 1.4^2  comes out as 1.96
| 
| 1.96 - 1.4^2  comes out as  0.7 E -20
| 
| I don't know if this counts as unexpected to a 5th grader, but does a
| 5th grader even know about "E" scientific notation?
| 
| ------
| 
| What's his point?

If he reads this mailing list you would get an answer :-)

\start
Date: Wed, 11 Apr 2007 22:30:04 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: [Richard Fateman]	Re: [Maxima] strange behaviour with simple decimals / Axiom

Quoting Gabriel Dos Reis:

> ... 
> Bill Page wrote:
> | (%i2) 1.96 - 1.4^2;
> | (%o2)                       2.2204460492503131E-16
> | (%i3)
>
> I believe that can explained by the fact that Axiom uses the host
> "long double" C datatype for DoubleFloat whereas Maxima must be
> using the more conventional and reliable "double" C datatype. 
>

No. By default Axiom uses it's own adjustable precision floating
point. See domain Float and the 'precision()' function. 

If you want DoubleFloat you would write:

(1) -> A:=1.4::DoubleFloat

    (1)  1.3999999999999999
                                       Type: DoubleFloat

(2) -> A^2

    (2)  1.9599999999999997
                                       Type: DoubleFloat

(3) -> B:=1.9599999999999997::DoubleFloat

    (3)  1.9599999999999997
                                       Type: DoubleFloat

(4) -> B-A^2

    (4)  0.0
                                       Type: DoubleFloat

Of the "machine" float:

(5) -> A:=1.4::MachineFloat

    (5)  1.4
                                       Type: MachineFloat

(6) -> A^2

    (6)  1.96
                                       Type: MachineFloat

(7) -> B:=1.96::MachineFloat

    (7)  1.96
                                       Type: MachineFloat

(8) -> B-A^2

    (8)  0.2220446049 250313 E -15
                                       Type: MachineFloat

> ... 
> | In Axiom version of  1/17/2005
> |
> | 1.4^2  comes out as 1.96
> |
> | 1.96 - 1.4^2  comes out as  0.7 E -20
> |

\start
Date: 11 Apr 2007 21:45:08 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: [Richard Fateman] Re: [Maxima] strange behaviour with simple decimals / Axiom

Bill Page writes:

| Quoting Gabriel Dos Reis:
| 
| > ... Bill Page wrote:
| > | (%i2) 1.96 - 1.4^2;
| > | (%o2)                       2.2204460492503131E-16
| > | (%i3)
| >
| > I believe that can explained by the fact that Axiom uses the host
| > "long double" C datatype for DoubleFloat whereas Maxima must be
| > using the more conventional and reliable "double" C datatype.
| 
| No. By default Axiom uses it's own adjustable precision floating
| point. See domain Float and the 'precision()' function. If you want
| DoubleFloat you would write:

[...]

| Of the "machine" float:
| 
| (5) -> A:=1.4::MachineFloat
| 
|     (5)  1.4
|                                        Type: MachineFloat
| 
| (6) -> A^2
| 
|     (6)  1.96
|                                        Type: MachineFloat
| 
| (7) -> B:=1.96::MachineFloat
| 
|     (7)  1.96
|                                        Type: MachineFloat
| 
| (8) -> B-A^2
| 
|     (8)  0.2220446049 250313 E -15
|                                        Type: MachineFloat

which agrees with what Maxima computes.

\start
Date: Wed, 11 Apr 2007 19:56:25 -0700 (PDT)
From: Cliff Yapp
To: Bill Page,	Gabriel Dos Reis
Subject: re: [Maxima] strange behaviour with simple decimals / Axiom

--- Bill Page wrote:
> 
> What's his point?

Heh - there's a discussion on the Maxima list about expected behavior
of numerical operations - Jay is discussing whether it would make more
sense to work some calculations in base 10, since things like  

1.96 - 1.4^2 = 2.2204460492503131E-16

are not intuitive to some audiences - exactly 0 would be the expected
response.  (Personally, I can see his point.)  Axiom came up when the
topic got to comparative behavior of CASs and calculators.  I don't
think there is a criticism of Axiom involved as such, the discussion is
more general than that.

\start
Date: Wed, 11 Apr 2007 22:24:43 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Sockets, threads and GUI<->Kernel communication

I looked around and asked on #lisp (thank y'all on #lisp for correcting
my ignorance about such basic matters).  The upshot appears to be that
sockets are sufficiently useful to be worth dealing with the firewall
issues.  This page was mentioned as a useful introduction to the
options available: 
http://en.wikipedia.org/wiki/Inter-process_communication  A couple of
the general protocols have lisp implementations (CORBA: 
http://clorb.sourceforge.net/ and XML-RPC: 
http://common-lisp.net/project/s-xml-rpc/) but as far as I can tell
both involve MORE overhead than sockets, not less.  A real local
alternative to sockets for inter-process communication would probably
need to involve pipes or file operations, either one of which I would
worry about for portability.  I would disagree with the
characterization of socket use in Axiom as over-engineering - I think
the client-server setup adds useful flexibility, and sockets appear to
be the Right Way to implement it.

I do agree that threads are a more attractive way to implement the
client-server setup when dealing with a strictly local copy of Axiom,
and they might be more available than I previously thought.  The
closest thing to useful information I have dug up thus far are these
sites:

http://common-lisp.net/project/bordeaux-threads/
http://wiki.alu.org/Portable_Threads

While I don't know how current or comprehensive the information there
is (SBCL's support status has recently changed, according to nyef on
#lisp), they do suggest thread support might be fairly widely available
in some form.  Of course, that still doesn't help us with GCL...

I would say the thing to do is this:

Allow Axiom to have both local and remote interface clients.  The
default would be a local client, with remote connections being handled
as options.  The flow would be something like this:

1)  User starts Axiom client, default settings.
2)  Client checks for thread support.
    a.  If available, start new thread with kernel
    b.  If not available, start new process with kernel on default
socket.
3)  If process is available in in-image thread, use local calls for IO.
 If not, send them over the socket.  This should be abstracted and be
simply a matter of defining a few settings/variables.

To handle the issue of firewall interaction, I would suggest
investigating if the NSIS installer can prompt the user to add the
Axiom client and server programs to the Windows Firewall allowed list,
and perhaps open the needed port as well.  I'm not sure if this
functionality is defined there currently but it might be worth
suggesting, as I doubt Axiom and Maxima would be the only open source
programs to confront this issue.  It would also be a good idea to make
sure our error messages are informative in the case of failure to
connect, and provide all available information for resolving the
issues.

\start
Date: 12 Apr 2007 08:16:34 +0200
From: Martin Rubey
To: list
Subject: gcl configure breakage

I tried to configure gcl, which a collegue fetched yesterday via

svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/gcl gcl

Unfortunately it (i.e., configure) fails

Many many thanks in advance,

Martin

# Subconfigure of GMP done
# ------------------------
#
cp: cannot stat `gmp3/gmp.h': No such file or directory
checking for leading underscore in object symbols... no
checking for GNU ld option -Map... yes
checking for size of gmp limbs... Cannot determine mpsize

Here is config.log:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:797: checking host system type
configure:1212: checking for gcc
configure:1325: checking whether the C compiler (gcc    ) works
configure:1341: gcc -o conftest      conftest.c  1>&5
configure:1367: checking whether the C compiler (gcc    ) is a cross-compiler
configure:1372: checking whether we are using GNU C
configure:1381: gcc -E conftest.c
configure:1400: checking whether gcc accepts -g
configure:1432: checking how to run the C preprocessor
configure:1453: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:1565: checking for gawk
configure:1686: checking system version (for dynamic loading)
configure:1694: checking for makeinfo
configure:1827: checking for unistd.h
configure:1837: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:1854: checking for sysconf in -lc
configure:1873: gcc -o conftest      conftest.c -lc   1>&5
configure:1889: checking for _SC_CLK_TCK
configure:1906: gcc -o conftest      conftest.c  1>&5
configure:1950: checking for gmp.h
configure:1960: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:1956:17: error: gmp.h: No such file or directory
configure: failed program was:
#line 1955 "configure"
#include "confdefs.h"
#include <gmp.h>
configure:2075: checking use_gmp=yes, doing configure in gmp directory
configure:2107: checking for leading underscore in object symbols
configure:2126: checking for GNU ld option -Map
configure:2143: checking for size of gmp limbs
configure:2159: gcc -o conftest      conftest.c  1>&5
configure:2150:20: error: h/gmp.h: No such file or directory
configure: In function 'main':
configure:2153: error: 'mp_limb_t' undeclared (first use in this function)
configure:2153: error: (Each undeclared identifier is reported only once
configure:2153: error: for each function it appears in.)
configure: failed program was:
#line 2148 "configure"
#include "confdefs.h"
#include <stdio.h>
        #include "h/gmp.h"
        int main() {
        FILE *fp=fopen("conftest1","w");
        fprintf(fp,"%u",sizeof(mp_limb_t));
        fclose(fp);
        return 0;
        }

\start
Date: 12 Apr 2007 08:55:21 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: problems compiling wh-sandbox 503

Dear Waldek,

unfortunately I have yet again trouble compiling. This time on a collegues
machine, ubuntu 7.04

we downloaded a pre-packaged gcl, since the gcl from build improvements didn't
build either...

cd ax-build
../wh-sandbox/configure 

works fine, but

LANG=C make

says:


cd ./src && SPAD=/home/harre/ax-build/target/i686-pc-linux SRC=/src
INT=/home/harre/ax-build/int OBJ=/home/harre/ax-build/obj
INC=/home/harre/ax-build/../wh-sandbox/src/include NOISE="-o
/home/harre/ax-build/build/i686-pc-linux/trace" VERSION="Axiom wh-sandbox
branch 2006-03-28" DOCUMENT=/home/harre/ax-build/build/scripts/document PLF=""
CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make
make[1]: Entering directory `/home/harre/ax-build/src'
make[2]: Entering directory `/home/harre/ax-build/src/lib'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/harre/ax-build/src/lib'
cd lisp &&  make all-lisp
make[2]: Entering directory `/home/harre/ax-build/src/lisp'
echo '(compiler::link nil "/home/harre/ax-build/build/i686-pc-linux/bin/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))' \
                                  ' (setq compiler::*default-system-p* t))"' \
                      ' si::*system-directory* (quote (list ".lsp")))' \
               '  "/home/harre/ax-build/src/lib/bsdsignal.o
/home/harre/ax-build/src/lib/cfuns-c.o
/home/harre/ax-build/src/lib/sockio-c.o")' \
            | /usr/bin/gcl
GCL (GNU Common Lisp)  2.6.7 CLtL1    Nov  9 2006 17:51:02
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/

>/usr/bin/ld: cannot find -lXmu
collect2: ld returned 1 exit status
sh: /home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp: not found

Error: Cannot delete the file #p"/home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp": "No such file or directory".
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LET*.
Broken at DELETE-FILE.  Type :H for Help.
>>make[2]: *** [/home/harre/ax-build/build/i686-pc-linux/bin/lisp] Error 255
make[2]: Leaving directory `/home/harre/ax-build/src/lisp'
make[1]: *** [all-lisp] Error 2
make[1]: Leaving directory `/home/harre/ax-build/src'
make: *** [all-src] Error 2

\start
Date: 12 Apr 2007 09:26:35 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: problems compiling build-improvements 502 was:	Re: problems compiling wh-sandbox 503
Cc: Waldek Hebisch

same problem in build-improvements.

I realized that binutils-dev and m4 was not installed, I installed those, no
change, unfortunately.

Martin


Martin Rubey writes:

> Dear Waldek,
> 
> unfortunately I have yet again trouble compiling. This time on a collegues
> machine, ubuntu 7.04
> 
> we downloaded a pre-packaged gcl, since the gcl from build improvements didn't
> build either...
> 
> cd ax-build
> ../wh-sandbox/configure 
> 
> works fine, but
> 
> LANG=C make
> 
> says:
> 
> 
> cd ./src && SPAD=/home/harre/ax-build/target/i686-pc-linux SRC=/src
> INT=/home/harre/ax-build/int OBJ=/home/harre/ax-build/obj
> INC=/home/harre/ax-build/../wh-sandbox/src/include NOISE="-o
> /home/harre/ax-build/build/i686-pc-linux/trace" VERSION="Axiom wh-sandbox
> branch 2006-03-28" DOCUMENT=/home/harre/ax-build/build/scripts/document PLF=""
> CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make
> make[1]: Entering directory `/home/harre/ax-build/src'
> make[2]: Entering directory `/home/harre/ax-build/src/lib'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/harre/ax-build/src/lib'
> cd lisp &&  make all-lisp
> make[2]: Entering directory `/home/harre/ax-build/src/lisp'
> echo '(compiler::link nil "/home/harre/ax-build/build/i686-pc-linux/bin/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))' \
>                                   ' (setq compiler::*default-system-p* t))"' \
>                       ' si::*system-directory* (quote (list ".lsp")))' \
>                '  "/home/harre/ax-build/src/lib/bsdsignal.o
> /home/harre/ax-build/src/lib/cfuns-c.o
> /home/harre/ax-build/src/lib/sockio-c.o")' \
>             | /usr/bin/gcl
> GCL (GNU Common Lisp)  2.6.7 CLtL1    Nov  9 2006 17:51:02
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> Temporary directory for compiler files set to /tmp/
> 
> >/usr/bin/ld: cannot find -lXmu
> collect2: ld returned 1 exit status
> sh: /home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp: not found
> 
> Error: Cannot delete the file #p"/home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp": "No such file or directory".
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by LET*.
> Broken at DELETE-FILE.  Type :H for Help.
> >>make[2]: *** [/home/harre/ax-build/build/i686-pc-linux/bin/lisp] Error 255
> make[2]: Leaving directory `/home/harre/ax-build/src/lisp'
> make[1]: *** [all-lisp] Error 2
> make[1]: Leaving directory `/home/harre/ax-build/src'
> make: *** [all-src] Error 2

\start
Date: 12 Apr 2007 09:29:58 +0200
From: Martin Rubey
To: list
Subject: Re: gcl configure breakage

After installing binutils-dev and m4 configure worked. Now it's making...

Shouldn't configure fail more gracefully?

Martin

Martin Rubey writes:

> I tried to configure gcl, which a collegue fetched yesterday via
> 
> svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/gcl gcl
> 
> Unfortunately it (i.e., configure) fails
> 
> Many many thanks in advance,
> 
> Martin
> 
> # Subconfigure of GMP done
> # ------------------------
> #
> cp: cannot stat `gmp3/gmp.h': No such file or directory
> checking for leading underscore in object symbols... no
> checking for GNU ld option -Map... yes
> checking for size of gmp limbs... Cannot determine mpsize
> 
> Here is config.log:
> 
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> configure:797: checking host system type
> configure:1212: checking for gcc
> configure:1325: checking whether the C compiler (gcc    ) works
> configure:1341: gcc -o conftest      conftest.c  1>&5
> configure:1367: checking whether the C compiler (gcc    ) is a cross-compiler
> configure:1372: checking whether we are using GNU C
> configure:1381: gcc -E conftest.c
> configure:1400: checking whether gcc accepts -g
> configure:1432: checking how to run the C preprocessor
> configure:1453: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:1565: checking for gawk
> configure:1686: checking system version (for dynamic loading)
> configure:1694: checking for makeinfo
> configure:1827: checking for unistd.h
> configure:1837: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:1854: checking for sysconf in -lc
> configure:1873: gcc -o conftest      conftest.c -lc   1>&5
> configure:1889: checking for _SC_CLK_TCK
> configure:1906: gcc -o conftest      conftest.c  1>&5
> configure:1950: checking for gmp.h
> configure:1960: gcc -E  conftest.c >/dev/null 2>conftest.out
> configure:1956:17: error: gmp.h: No such file or directory
> configure: failed program was:
> #line 1955 "configure"
> #include "confdefs.h"
> #include <gmp.h>
> configure:2075: checking use_gmp=yes, doing configure in gmp directory
> configure:2107: checking for leading underscore in object symbols
> configure:2126: checking for GNU ld option -Map
> configure:2143: checking for size of gmp limbs
> configure:2159: gcc -o conftest      conftest.c  1>&5
> configure:2150:20: error: h/gmp.h: No such file or directory
> configure: In function 'main':
> configure:2153: error: 'mp_limb_t' undeclared (first use in this function)
> configure:2153: error: (Each undeclared identifier is reported only once
> configure:2153: error: for each function it appears in.)
> configure: failed program was:
> #line 2148 "configure"
> #include "confdefs.h"
> #include <stdio.h>
>         #include "h/gmp.h"
>         int main() {
>         FILE *fp=fopen("conftest1","w");
>         fprintf(fp,"%u",sizeof(mp_limb_t));
>         fclose(fp);
>         return 0;
>         }

\start
Date: Thu, 12 Apr 2007 11:52:52 +0200
From: Gregory Vanuxem
To: Martin Rubey
Subject: Re: problems compiling build-improvements 502	was: Re: problems compiling wh-sandbox 503
Cc: Waldek Hebisch, Gabriel Dos Reis

Hello,

Le jeudi 12 avril 2007 =E0 09:26 +0200, Martin Rubey a =E9crit :

> > echo '(compiler::link nil "/home/harre/ax-build/build/i686-pc-linux/b=
in/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))' \
> >                                   ' (setq compiler::*default-system-p=
* t))"' \
> >                       ' si::*system-directory* (quote (list ".lsp")))=
' \
> >                '  "/home/harre/ax-build/src/lib/bsdsignal.o
> > /home/harre/ax-build/src/lib/cfuns-c.o
> > /home/harre/ax-build/src/lib/sockio-c.o")' \
> >             | /usr/bin/gcl
> > GCL (GNU Common Lisp)  2.6.7 CLtL1    Nov  9 2006 17:51:02
> > Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)

                                                 ^^^^^

GCL was compiled with xgcl support therefore it needs X development
libraries for creating a new image via compiler::link. The best thing
would be to use another version of GCL (without xgcl support), the other
way is to install libxmu-dev (if package installation is possible). For
information, if you encounter any other errors of this type here is the
list of the (names of package) development libraries that should be
needed. It is derived from the list of libraries GCL is linked against :

libsm-dev: /usr/lib/libSM.a
libsm-dev: /usr/lib/libSM.so
libice-dev: /usr/lib/libICE.a
libice-dev: /usr/lib/libICE.so
libxmu-dev: /usr/lib/libXmu.a
libxmu-dev: /usr/lib/libXmu.so
libxmuu-dev: /usr/lib/libXmuu.a
libxmuu-dev: /usr/lib/libXmuu.so
libxt-dev: /usr/lib/libXt.a
libxt-dev: /usr/lib/libXt.so
libxtst-dev: /usr/lib/libXtst.a
libxtst-dev: /usr/lib/libXtst.so
libxext-dev: /usr/lib/libXext.a
libxext-dev: /usr/lib/libXext.so
libxaw7-dev: /usr/lib/libXaw7.a
libxaw7-dev: /usr/lib/libXaw7.so
libxaw7-dev: /usr/lib/libXaw.so
libx11-dev: /usr/lib/libX11.a
libx11-dev: /usr/lib/libX11.so
libxau-dev: /usr/lib/libXau.a
libxau-dev: /usr/lib/libXau.so
libxpm-dev: /usr/lib/libXpm.a
libxpm-dev: /usr/lib/libXpm.so
libxdmcp-dev: /usr/lib/libXdmcp.a
libxdmcp-dev: /usr/lib/libXdmcp.so

This information is probably hold in a Lisp variable but I don't know
which one. Waldek could be of better help.


In any case if you pass this phase I hope you'll be able to compile
wh-sandbox. I'm no longer able, a bad interaction between my computer
and GCL is highly probable.

Hope that helps and I'm not wrong,

Greg


> > Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNE=
XEC)
> > Modifications of this banner must retain notice of a compatible licen=
se
> > Dedicated to the memory of W. Schelter
> >
> > Use (help) to get some basic information on how to use GCL.
> > Temporary directory for compiler files set to /tmp/
> >
> > >/usr/bin/ld: cannot find -lXmu
> > collect2: ld returned 1 exit status
> > sh: /home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp: not found
> >
> > Error: Cannot delete the file #p"/home/harre/ax-build/build/i686-pc-l=
inux/bin/raw_lisp": "No such file or directory".
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by LET*.
> > Broken at DELETE-FILE.  Type :H for Help.
> > >>make[2]: *** [/home/harre/ax-build/build/i686-pc-linux/bin/lisp] Er=
ror 255
> > make[2]: Leaving directory `/home/harre/ax-build/src/lisp'
> > make[1]: *** [all-lisp] Error 2
> > make[1]: Leaving directory `/home/harre/ax-build/src'
> > make: *** [all-src] Error 2

\start
Date: 12 Apr 2007 06:41:28 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Sockets, threads and GUI<->Kernel communication

Cliff Yapp writes:

| I looked around and asked on #lisp (thank y'all on #lisp for correcting
| my ignorance about such basic matters).  The upshot appears to be that
| sockets are sufficiently useful to be worth dealing with the firewall
| issues.  This page was mentioned as a useful introduction to the
| options available: 
| http://en.wikipedia.org/wiki/Inter-process_communication  A couple of
| the general protocols have lisp implementations (CORBA: 
| http://clorb.sourceforge.net/ and XML-RPC: 
| http://common-lisp.net/project/s-xml-rpc/) but as far as I can tell
| both involve MORE overhead than sockets, not less.  A real local
| alternative to sockets for inter-process communication would probably
| need to involve pipes or file operations, either one of which I would
| worry about for portability.  I would disagree with the
| characterization of socket use in Axiom as over-engineering - I think
| the client-server setup adds useful flexibility, and sockets appear to
| be the Right Way to implement it.
| 
| I do agree that threads are a more attractive way to implement the
| client-server setup when dealing with a strictly local copy of Axiom,

If you agree with that, then you must agree with the over-engineering
characterization.  We have more uses of Axiom as local copy than we
have as a truly distributed system over network.  A 101 principle
of engineering is to keep common thing simple.

Oh yes, I know Axiom was designed a long time ago; that does not
change my point.

[...]

| Allow Axiom to have both local and remote interface clients. 

Well obviously, no improvement will remove the socket support.
The point wasn't that socket are useless -- quite the contrary.  But,
the engineering has forgotten the basics.

| The
| default would be a local client, with remote connections being handled
| as options.  The flow would be something like this:
| 
| 1)  User starts Axiom client, default settings.
| 2)  Client checks for thread support.
|     a.  If available, start new thread with kernel
|     b.  If not available, start new process with kernel on default
| socket.
| 3)  If process is available in in-image thread, use local calls for IO.
|  If not, send them over the socket.  This should be abstracted and be
| simply a matter of defining a few settings/variables.
| 
| To handle the issue of firewall interaction, I would suggest
| investigating if the NSIS installer can prompt the user to add the
| Axiom client and server programs to the Windows Firewall allowed list,
| and perhaps open the needed port as well.  I'm not sure if this
| functionality is defined there currently but it might be worth
| suggesting, as I doubt Axiom and Maxima would be the only open source
| programs to confront this issue.  It would also be a good idea to make
| sure our error messages are informative in the case of failure to
| connect, and provide all available information for resolving the
| issues.

I'm not a windows developer, so patches are welcome.

\start
Date: Thu, 12 Apr 2007 13:49:02 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: problems compiling wh-sandbox 503
Cc: Camm Maguire

Martin Rubey wrote:
> Dear Waldek,
> 
> unfortunately I have yet again trouble compiling. This time on a collegues
> machine, ubuntu 7.04
> 
> we downloaded a pre-packaged gcl, since the gcl from build improvements didn't
> build either...
> 
> cd ax-build
> ../wh-sandbox/configure 
> 
> works fine, but
> 
> LANG=C make
> 
> says:
> 
> 
> cd ./src && SPAD=/home/harre/ax-build/target/i686-pc-linux SRC=/src
> INT=/home/harre/ax-build/int OBJ=/home/harre/ax-build/obj
> INC=/home/harre/ax-build/../wh-sandbox/src/include NOISE="-o
> /home/harre/ax-build/build/i686-pc-linux/trace" VERSION="Axiom wh-sandbox
> branch 2006-03-28" DOCUMENT=/home/harre/ax-build/build/scripts/document PLF=""
> CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make
> make[1]: Entering directory `/home/harre/ax-build/src'
> make[2]: Entering directory `/home/harre/ax-build/src/lib'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/harre/ax-build/src/lib'
> cd lisp &&  make all-lisp
> make[2]: Entering directory `/home/harre/ax-build/src/lisp'
> echo '(compiler::link nil "/home/harre/ax-build/build/i686-pc-linux/bin/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))' \
>                                   ' (setq compiler::*default-system-p* t))"' \
>                       ' si::*system-directory* (quote (list ".lsp")))' \
>                '  "/home/harre/ax-build/src/lib/bsdsignal.o
> /home/harre/ax-build/src/lib/cfuns-c.o
> /home/harre/ax-build/src/lib/sockio-c.o")' \
>             | /usr/bin/gcl
> GCL (GNU Common Lisp)  2.6.7 CLtL1    Nov  9 2006 17:51:02
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
> Temporary directory for compiler files set to /tmp/
> 
> >/usr/bin/ld: cannot find -lXmu
> collect2: ld returned 1 exit status
> sh: /home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp: not found
> 
> Error: Cannot delete the file #p"/home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp": "No such file or directory".
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by LET*.
> Broken at DELETE-FILE.  Type :H for Help.
> >>make[2]: *** [/home/harre/ax-build/build/i686-pc-linux/bin/lisp] Error 255
> make[2]: Leaving directory `/home/harre/ax-build/src/lisp'
> make[1]: *** [all-lisp] Error 2
> make[1]: Leaving directory `/home/harre/ax-build/src'
> make: *** [all-src] Error 2
> 
> 

As Gregory Vanuxem the problem appeared because gcl (more precisely
compiler::link) requires _developement_ versions of X libraries,
but the system contains only normal versions.

I would say that this is a bug in Ubutu gcl package.  AFAICS in
may version of Debian gcl description reads:

Package: gcl
Priority: optional
Section: interpreters
Installed-Size: 160052
Maintainer: Camm Maguire
Architecture: amd64
Version: 2.6.7-32
Depends: libc6 (>= 2.3.5-1), libgmp3c2, libice6 (>= 1:1.0.0), libncurses5 (>= 5.
4-5), libreadline5 (>= 5.2), libsm6, libx11-6, libxaw7, libxext6, libxmu6, libxt
6, tcl8.4 (>= 8.4.5), tk8.4 (>= 8.4.5), debconf (>= 0.5) | debconf-2.0, gcc, deb
conf (>= 1.2.0)
Suggests: gcl-doc
Filename: pool/main/g/gcl/gcl_2.6.7-32_amd64.deb
Size: 33929666
MD5sum: 1846a63096382273dfd4cf7652d224c8

In particular there is no dependency on developement libraries, so
it is passible that current Debian have similar problem.

\start
Date: 12 Apr 2007 06:50:57 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: problems compiling build-improvements 502 was: Re: problems compiling wh-sandbox 503
Cc: Waldek Hebisch

Martin Rubey writes:

| same problem in build-improvements.
| 
| I realized that binutils-dev and m4 was not installed, I installed those, no
| change, unfortunately.

Please send me your config.log and the exact message of failure and
surronding contexts.  It should not be the same as with wh-sandbox
because build-improvements configures GCL with --disable-xgcl and
--disable-tkconfig.

\start
Date: 12 Apr 2007 14:10:40 +0200
From: Martin Rubey
To: Waldek Hebisch, Bill Page
Subject: Re: problems compiling wh-sandbox 503

Waldek Hebisch writes:

> As Gregory Vanuxem the problem appeared because gcl (more precisely
> compiler::link) requires _developement_ versions of X libraries,
> but the system contains only normal versions.

I meanwhile managed to build gcl from build-improvements (by installing
binutils-dev, and m4), and now wh-sandbox compiles *nearly*.  Now I get these
rather "random" failures, where some of the algebra fails to compile.  I
believe that the first error message was some "memory may be damaged" stuff,
while compiling ALGEBRA.

Didn't Bill Page say that one has to tweak some setting in gcl?

\start
Date: 12 Apr 2007 07:24:21 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: problems compiling wh-sandbox 503

Martin Rubey writes:

| Waldek Hebisch writes:
| 
| > As Gregory Vanuxem the problem appeared because gcl (more precisely
| > compiler::link) requires _developement_ versions of X libraries,
| > but the system contains only normal versions.
| 
| I meanwhile managed to build gcl from build-improvements (by installing
| binutils-dev, and m4), and now wh-sandbox compiles *nearly*.  Now I get these
| rather "random" failures, where some of the algebra fails to compile.  I
| believe that the first error message was some "memory may be damaged" stuff,
| while compiling ALGEBRA.

Please, please, please.  General message to people experiencing
"memory may be damaged".  Configure Axiom.build-improvements with

   --enable-checking

The build is slower but you may get a chance to make a meaningful
report that may eventually help fix the bug you run into.

\start
Date: 12 Apr 2007 14:36:47 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: problems compiling wh-sandbox 503

Gabriel Dos Reis writes:

> Martin Rubey writes:
> 
> | Waldek Hebisch writes:
> | 
> | > As Gregory Vanuxem the problem appeared because gcl (more precisely
> | > compiler::link) requires _developement_ versions of X libraries,
> | > but the system contains only normal versions.
> | 
> | I meanwhile managed to build gcl from build-improvements (by installing
> | binutils-dev, and m4), and now wh-sandbox compiles *nearly*.  Now I get these
> | rather "random" failures, where some of the algebra fails to compile.  I
> | believe that the first error message was some "memory may be damaged" stuff,
> | while compiling ALGEBRA.
> 
> Please, please, please.  General message to people experiencing
> "memory may be damaged".  Configure Axiom.build-improvements with
> 
>    --enable-checking
> 
> The build is slower but you may get a chance to make a meaningful
> report that may eventually help fix the bug you run into.

Does this work also in wh-sandbox?

\start
Date: 12 Apr 2007 15:13:26 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: problems compiling build-improvements 502 was: Re: problems compiling wh-sandbox 503
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> Martin Rubey writes:
> 
> | same problem in build-improvements.
> | 
> | I realized that binutils-dev and m4 was not installed, I installed those, no
> | change, unfortunately.
> 
> Please send me your config.log and the exact message of failure and
> surronding contexts.  It should not be the same as with wh-sandbox
> because build-improvements configures GCL with --disable-xgcl and
> --disable-tkconfig.
> 
> -- Gaby

after installing binutils-dev, m4, libxpm-dev, libx11-dev, libxt-dev,
libext-dev, libxmu-dev, libxmu-headers

build-improvements succeeded.

I am currently retrying wh-sandbox with --enable-checking.

\start
Date: Thu, 12 Apr 2007 15:45:08 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: problems compiling wh-sandbox 503
Cc: Gabriel Dos Reis

Martin Rubey wrote:
> Gabriel Dos Reis writes:
> 
> > Please, please, please.  General message to people experiencing
> > "memory may be damaged".  Configure Axiom.build-improvements with
> > 
> >    --enable-checking
> > 
> > The build is slower but you may get a chance to make a meaningful
> > report that may eventually help fix the bug you run into.
> 
> Does this work also in wh-sandbox?
> 

No, Gaby added  --enable-checking in version 491 and the latest parts
merged are from 485.

To get extra checking I used code like below (ho.  Her, after 16
hours the build died due to uninitialized variable when compileing
guessing package (I still have to investigate the problem).

--- /home/s/test/tt/axiom2/wh-sandbox2/src/interp/interp-proclaims.lisp	2007-02-16 22:27:49.000000000 +0100
+++ wh-sandbox2/src/interp/interp-proclaims.lisp	2007-04-12 15:39:58.000000000 +0200
@@ -1,4 +1,6 @@
-
+(eval-when (:execute :compile-toplevel :load-toplevel)
+  (proclaim
+    '(optimize (safety 3))))
 (IN-PACKAGE "USER") 
 (PROCLAIM '(FTYPE (FUNCTION (*) (VALUES T T)) BOOT:|ReadLine|)) 
 (PROCLAIM

\start
Date: 12 Apr 2007 08:54:46 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: problems compiling build-improvements 502 was: Re: problems compiling wh-sandbox 503
Cc: Waldek Hebisch

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > Martin Rubey writes:
| > 
| > | same problem in build-improvements.
| > | 
| > | I realized that binutils-dev and m4 was not installed, I installed those, no
| > | change, unfortunately.
| > 
| > Please send me your config.log and the exact message of failure and
| > surronding contexts.  It should not be the same as with wh-sandbox
| > because build-improvements configures GCL with --disable-xgcl and
| > --disable-tkconfig.
| > 
| > -- Gaby
| 
| after installing binutils-dev, m4, libxpm-dev, libx11-dev, libxt-dev,
| libext-dev, libxmu-dev, libxmu-headers
| 
| build-improvements succeeded.

OK.

| I am currently retrying wh-sandbox with --enable-checking.

It is not clear to me that wh-sandbox has the --enable-checking
bits.  One drawback of Autoconf design is that when configure does not
understand an --enable-FEATURE switch, it says nothing.  

\start
Date: 12 Apr 2007 16:13:25 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: problems compiling build-improvements 502 was: Re: problems compiling wh-sandbox 503
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> Martin Rubey writes:

> | after installing binutils-dev, m4, libxpm-dev, libx11-dev, libxt-dev,
> | libext-dev, libxmu-dev, libxmu-headers
> | 
> | build-improvements succeeded.
> 
> OK.

No. WONDERFUL! SUPERB! 

> | I am currently retrying wh-sandbox with --enable-checking.
> 
> It is not clear to me that wh-sandbox has the --enable-checking bits.  One
> drawback of Autoconf design is that when configure does not understand an
> --enable-FEATURE switch, it says nothing.

Waldek already stated that it hasn't. 

You see, I really need wh-sandbox because of three reasons:

* HyperDoc "users" and "dependents" works

* there are many algebra bug fixes

* it contains my guessing package

(the last item depends on the second item, but the first item also is extremely
helpful)

\start
Date: 12 Apr 2007 16:17:35 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Request for wh-sandbox and build-improvements
Cc: Waldek Hebisch

A request for both build-improvements and wh-sandbox:

could you please install "document" by default, and include my SPADEDIT file,
which is located at

http://wiki.axiom-developer.org/144DomainAbbreviationIsNoLongerAssociatedWithFilename

second comment from below.

I also believe that the installed source files in src/algebra really should be
the ".spad.pamphlet"s, not the ".spad"s

Is there any reason for copying the "spad"s instead?

\start
Date: 12 Apr 2007 09:19:20 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: problems compiling build-improvements 502 was: Re: problems compiling wh-sandbox 503
Cc: Waldek Hebisch

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > Martin Rubey writes:
| 
| > | after installing binutils-dev, m4, libxpm-dev, libx11-dev, libxt-dev,
| > | libext-dev, libxmu-dev, libxmu-headers
| > | 
| > | build-improvements succeeded.
| > 
| > OK.
| 
| No. WONDERFUL! SUPERB! 

:-)

| > | I am currently retrying wh-sandbox with --enable-checking.
| > 
| > It is not clear to me that wh-sandbox has the --enable-checking bits.  One
| > drawback of Autoconf design is that when configure does not understand an
| > --enable-FEATURE switch, it says nothing.
| 
| Waldek already stated that it hasn't. 

yes, you're right; I saw his message only after I sent mine.

| You see, I really need wh-sandbox because of three reasons:
| 
| * HyperDoc "users" and "dependents" works
| 
| * there are many algebra bug fixes
| 
| * it contains my guessing package
| 
| (the last item depends on the second item, but the first item also is extremely
| helpful)

I do not doubt wh-sandbox is useful :-)
I believe that part of the HyperDoc and algebra that is known to be
solid and OK should be merged back to build-improvements, while the
other more experimental parts can remain in wh-sandbox until
consolidated. 

Ideally, all of this should be merged back to silver, but I don't know
what Silver is.  I would hate to change target every two or three
months. 

\start
Date: Thu, 12 Apr 2007 16:20:42 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Sockets and threads

Gabriel Dos Reis wrote:
> Cliff Yapp writes:
> | One question - as I understand it, AXIOMsys works on Windows but the
> | parent program axiom does not.  Would a HyperDoc for Windows also
> | require a new communications mechanism?  Doing this straight from lisp
> | (ala hunchentoot or something similar) would be my preference, but
> | again it's probably not simple.
> 
> I see no fundamental reason why both process should not be threads in
> the same problem and therefore bypass the socket stuff.  From my
> perspective, that is just another over-engineering aspect of Axiom.
> Notice that if you use sockets, the the anti-virus firewall will
> consider Axiom as a program that wants access to network and it might
> be blocked; then the anti-virus will ask you whether you want to grant
> access or not.  That is silly.
> 

There is a good reason to run other processes in separate address
space: Lisp garbage collector.  This places significant restrictions
on possible interface between C and Lisp.  According to Camm Maguire
Gcl has additional problem: C malloc may trigger garbage collection.
So passing unbouded amount of data to C becomes almost impossible
(one can use  GCLspecific method to reqest storage which in not
moved by garbage collection, but that is awkward and hurts
performance).

Other Lisp may also place restrictions on possible behaviour of C
code.  Socket interface seem to be accepted way to interface
general programs with Lisp (and other high level runtimes).

\start
Date: Thu, 12 Apr 2007 09:30:18 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Sockets and threads

Quoting Waldek Hebisch:

> Gabriel Dos Reis wrote:
>> Cliff Yapp writes:
>> | One question - as I understand it, AXIOMsys works on Windows but the
>> | parent program axiom does not.  Would a HyperDoc for Windows also
>> | require a new communications mechanism?  Doing this straight from lisp
>> | (ala hunchentoot or something similar) would be my preference, but
>> | again it's probably not simple.
>>
>> I see no fundamental reason why both process should not be threads in
>> the same problem and therefore bypass the socket stuff.  From my
>> perspective, that is just another over-engineering aspect of Axiom.
>> Notice that if you use sockets, the the anti-virus firewall will
>> consider Axiom as a program that wants access to network and it might
>> be blocked; then the anti-virus will ask you whether you want to grant
>> access or not.  That is silly.
>>
>
> There is a good reason to run other processes in separate address
> space: Lisp garbage collector.

Yes, if the collector is designed to be uncoperative -- yes.
But "garbage collector" in itself is not a reason.
If you take the flash media player for example, it has
a garbage collector, but is does run in environment that do use
expect garbage collection. Many other projects do the same.

Be liberal in what you accept and conservative in what you deliver.
That was known engineering principle decades ago.

For some reasons, I've been exposed to all the intricate details
of garbage collector I did not want to know -- and some I wanted to
know, because we are considering Programmer Controlled Garbage
Collection for C++ and we have to solve issues related to
combining component that can leave with GC, those that prohibit it,
and those that require it.

In the FRISCO projects, we had components that were GC'd and some that
aren't.

> This places significant restrictions
> on possible interface between C and Lisp.

Not that much.

\start
Date: Thu, 12 Apr 2007 09:39:20 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Request for wh-sandbox and build-improvements
Cc: Waldek Hebisch

Quoting Martin Rubey:

> A request for both build-improvements and wh-sandbox:
>
> could you please install "document" by default, and include my SPADEDIT file,
> which is located at

Install it where?
I consider installing it in $prefix/bin an unwarranted  pollution.
We can install it in $libdir and add an option "--document" to the
axiom script, e.g. you could say

   axiom --document=tangle foo.pamphlet

that will untangle the SPAD code.  We may add more options as
we have better idea of what to support.

This is something I planned to do, but so far, it wasn't high
on the priority list.

>
> http://wiki.axiom-developer.org/144DomainAbbreviationIsNoLongerAssociatedWithFilename
>
> second comment from below.
>
> I also believe that the installed source files in src/algebra really 
> should be
> the ".spad.pamphlet"s, not the ".spad"s
>
> Is there any reason for copying the "spad"s instead?

\start
Date: 12 Apr 2007 09:40:56 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Sockets and threads

Gabriel Dos Reis writes:

| Quoting Waldek Hebisch:
| 
| > Gabriel Dos Reis wrote:
| >> Cliff Yapp writes:
| >> | One question - as I understand it, AXIOMsys works on Windows but the
| >> | parent program axiom does not.  Would a HyperDoc for Windows also
| >> | require a new communications mechanism?  Doing this straight from lisp
| >> | (ala hunchentoot or something similar) would be my preference, but
| >> | again it's probably not simple.
| >>
| >> I see no fundamental reason why both process should not be threads in
| >> the same problem and therefore bypass the socket stuff.  From my
| >> perspective, that is just another over-engineering aspect of Axiom.
| >> Notice that if you use sockets, the the anti-virus firewall will
| >> consider Axiom as a program that wants access to network and it might
| >> be blocked; then the anti-virus will ask you whether you want to grant
| >> access or not.  That is silly.
| >>
| >
| > There is a good reason to run other processes in separate address
| > space: Lisp garbage collector.
| 
| Yes, if the collector is designed to be uncoperative -- yes.
| But "garbage collector" in itself is not a reason.
| If you take the flash media player for example, it has
| a garbage collector, but is does run in environment that do use
                                                           ^^

s/do/does not/

Sorry for the confusion.

\start
Date: 12 Apr 2007 16:49:08 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: Request for wh-sandbox and build-improvements
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> Quoting Martin Rubey:
> 
> > A request for both build-improvements and wh-sandbox:
> >
> > could you please install "document" by default, and include my SPADEDIT file,
> > which is located at
> 
> Install it where?
> I consider installing it in $prefix/bin an unwarranted  pollution.
> We can install it in $libdir and add an option "--document" to the
> axiom script, e.g. you could say
> 
>    axiom --document=tangle foo.pamphlet

that would be OK, although I'd prefer

  axiom --document foo.pamphlet

(I know I'd forget the tangle all the time.)

Maybe even

  axiom foo.pamphlet

but no, that's confusing...

\start
Date: Thu, 12 Apr 2007 08:10:08 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Sockets, threads and GUI<->Kernel communication


--- Gabriel Dos Reis wrote:

> | I do agree that threads are a more attractive way to implement the
> | client-server setup when dealing with a strictly local copy of
> | Axiom,
> 
> If you agree with that, then you must agree with the over-engineering
> characterization.  We have more uses of Axiom as local copy than we
> have as a truly distributed system over network.

At the moment yes, but the future is unknown.  It is far easier to
design the system from the beginning to be flexible (client-server) and
then not use that ability.  Otherwise we might have to go back and do a
major redesign.  In my opinion the flexibility to have a non-local copy
of Axiom is worthwhile.  

I can't speak to this since I don't know the history, but I would not
be surprised to learn that thread support was not a viable option when
the original design was done, and since what was done worked no one
revisited the decisions until now.

> A 101 principle of engineering is to keep common thing simple.

Sockets seem to be a minor detail to me (not technically, perhaps) -
basically one more way to implement a client-server mechanism in
addition to threads/pipes/what have you.  You have worked more with the
code than I have - how much complexity does it really add?  What would
you propose that would be simpler without being less robust as well? 
My original impression of threads in lisp was that support was not
broadly developed and robust.  That may have changed since, but I would
want more information than I have now before I would be willing to
regard thread support in Lisp as something to depend on.

> | Allow Axiom to have both local and remote interface clients. 
> 
> Well obviously, no improvement will remove the socket support.
> The point wasn't that socket are useless -- quite the contrary.  But,
> the engineering has forgotten the basics.

Thread support in lisp implementations is not usually described as
basic, in my experience... maybe to use but certainly not to implement.

Do you mean the CURRENT implementation of things in Axiom is not well
engineered, irrespective of the use of sockets?

> I'm not a windows developer, so patches are welcome.

I'll take a crack at NSIS once I have a Windows box available.

Cheers,
CY

P.S.  I don't mean to be an irritation, Gaby - it's possible I'm just
lacking enough basic understanding to follow you correctly.  Is there
some introductory material on thread vs. socket issues that I could read?

\start
Date: Thu, 12 Apr 2007 10:20:05 -0500
From: Tim Daly
To: list
Subject: sockets

X11 is a socket-based design. When we tried to write graphics
(actually it was originally in X10) we needed to use sockets.
Given that the graphics had sockets it made sense to communicate
from Axiom to the graphics component using the same protocol.

\start
Date: Thu, 12 Apr 2007 11:29:07 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: problems compiling wh-sandbox 503

On April 12, 2007 8:11 AM Martin Rubey wrote:
> ... 
> I meanwhile managed to build gcl from build-improvements (by 
> installing binutils-dev, and m4), and now wh-sandbox compiles
> *nearly*.  Now I get these rather "random" failures, where
> some of the algebra fails to compile.  I believe that the
> first error message was some "memory may be damaged" stuff,
> while compiling ALGEBRA.
> 
> Didn't Bill Page say that one has to tweak some setting in
> gcl?
> 

On one system (axiom-developer.org) which is configured with a
variant of RedHat 9 as a shared virtual server - don't know
many more details than that - I have found that is necessary
to change the GCLOPTS so that --max-page is a little less than
256*1024 (I use 192*1024 on axiom-developer.org). If this doesn't
work, then I suggest to try configure with this number a little
larger - maybe 320*1024. In general GCL seems to depend very
strongly on the detailed memory management features of those
operating systems on which it runs. This and the specific code
relocation method is the what changes most from machine to
machine.

\start
Date: 12 Apr 2007 10:46:18 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Sockets, threads and GUI<->Kernel communication

Cliff Yapp writes:

| --- Gabriel Dos Reis wrote:
| 
| > | I do agree that threads are a more attractive way to implement the
| > | client-server setup when dealing with a strictly local copy of
| > | Axiom,
| > 
| > If you agree with that, then you must agree with the over-engineering
| > characterization.  We have more uses of Axiom as local copy than we
| > have as a truly distributed system over network.
| 
| At the moment yes, but the future is unknown.

If you can't handle the known present, how do you plan to handle the
unknown future?

|  It is far easier to
| design the system from the beginning to be flexible (client-server) and
| then not use that ability.

Please, note that "client-server" does not necessarily imply sockets,
and using threads does not necessarily exclude "client-server".

However, my fundamental point remains: common things should be simple.

I think we should be careful about the arguments we make.

[...]

| > A 101 principle of engineering is to keep common thing simple.
| 
| Sockets seem to be a minor detail to me (not technically, perhaps) -

Yet, they are they roots of many unpleasant aspects when working on
the internal details and improvements of Axiom.

[...]

| broadly developed and robust.  That may have changed since, but I would
| want more information than I have now before I would be willing to
| regard thread support in Lisp as something to depend on.

Well, my initial comment is more a statement about the current state
as opposed to an active suggestion to redesign Axiom.  Certainly, we
have around Lisp systems mapping to threads and using them.  They
don't look more complicated than the current mess we have.  Now, you
may have a point about standard thread interface, but that is more of
a general problem with Lisp environments once you start doing anything
useful -- you have to catter for all kinds of variabilities.

| > | Allow Axiom to have both local and remote interface clients. 
| > 
| > Well obviously, no improvement will remove the socket support.
| > The point wasn't that socket are useless -- quite the contrary.  But,
| > the engineering has forgotten the basics.
| 
| Thread support in lisp implementations is not usually described as
| basic, in my experience... maybe to use but certainly not to implement.
| 
| Do you mean the CURRENT implementation of things in Axiom is not well
| engineered, irrespective of the use of sockets?

Yes.

| > I'm not a windows developer, so patches are welcome.
| 
| I'll take a crack at NSIS once I have a Windows box available.
| 
| Cheers,
| CY
| 
| P.S.  I don't mean to be an irritation, Gaby - it's possible I'm just
| lacking enough basic understanding to follow you correctly.  Is there
| some introductory material on thread vs. socket issues that I could read?

They are not mutually exclusive, so I don't understand your point.

\start
Date: 12 Apr 2007 10:47:55 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > Quoting Martin Rubey:
| > 
| > > A request for both build-improvements and wh-sandbox:
| > >
| > > could you please install "document" by default, and include my SPADEDIT file,
| > > which is located at
| > 
| > Install it where?
| > I consider installing it in $prefix/bin an unwarranted  pollution.
| > We can install it in $libdir and add an option "--document" to the
| > axiom script, e.g. you could say
| > 
| >    axiom --document=tangle foo.pamphlet
| 
| that would be OK, although I'd prefer
| 
|   axiom --document foo.pamphlet
| 
| (I know I'd forget the tangle all the time.)


How do you say, produce a clisp/dvi/pdf out of this?  How do you say,
just compile the tangled code?

\start
Date: 12 Apr 2007 10:54:26 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: sockets

Tim Daly writes:

| X11 is a socket-based design.

Yes,  but X11 is vastly distinct in functionality, scope than Axiom. 

| When we tried to write graphics
| (actually it was originally in X10) we needed to use sockets.

But, what if I don't have X11 and don't use the graphics?

I agree that Axiom is mamouth system, but it does not need to be a fat
mamouth system.

| Given that the graphics had sockets it made sense to communicate
| from Axiom to the graphics component using the same protocol.

I agree with that; whoever, why should sman be designed to rely
critically on sockets?  

Take Emacs, for example.

\start
Date: 12 Apr 2007 17:54:43 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> Martin Rubey writes:
> 
> | Gabriel Dos Reis writes:
> | 
> | > Quoting Martin Rubey:
> | > 
> | > > A request for both build-improvements and wh-sandbox:
> | > >
> | > > could you please install "document" by default, and include my SPADEDIT file,
> | > > which is located at
> | > 
> | > Install it where?
> | > I consider installing it in $prefix/bin an unwarranted  pollution.
> | > We can install it in $libdir and add an option "--document" to the
> | > axiom script, e.g. you could say
> | > 
> | >    axiom --document=tangle foo.pamphlet
> | 
> | that would be OK, although I'd prefer
> | 
> |   axiom --document foo.pamphlet
> | 
> | (I know I'd forget the tangle all the time.)
> 
> 
> How do you say, produce a clisp/dvi/pdf out of this?  How do you say,
> just compile the tangled code?


OK, personally, I only use "document", from within emacs (I made it a command
in AucTeX), so it produces the spad and the dvi.

Since I strongly believe that we should switch to ALLPROSE as soon as possible,
(which will replace "document" with "make") I won't insist on anything.

Thus, I think that

  axiom --document=tangle foo.pamphlet

is quite ok.

\start
Date: 12 Apr 2007 11:01:26 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: Request for wh-sandbox and build-improvements
Cc: Waldek Hebisch

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > Martin Rubey writes:
| > 
| > | Gabriel Dos Reis writes:
| > | 
| > | > Quoting Martin Rubey:
| > | > 
| > | > > A request for both build-improvements and wh-sandbox:
| > | > >
| > | > > could you please install "document" by default, and include my SPADEDIT file,
| > | > > which is located at
| > | > 
| > | > Install it where?
| > | > I consider installing it in $prefix/bin an unwarranted  pollution.
| > | > We can install it in $libdir and add an option "--document" to the
| > | > axiom script, e.g. you could say
| > | > 
| > | >    axiom --document=tangle foo.pamphlet
| > | 
| > | that would be OK, although I'd prefer
| > | 
| > |   axiom --document foo.pamphlet
| > | 
| > | (I know I'd forget the tangle all the time.)
| > 
| > 
| > How do you say, produce a clisp/dvi/pdf out of this?  How do you say,
| > just compile the tangled code?
| 
| 
| OK, personally, I only use "document", from within emacs (I made it a command
| in AucTeX), so it produces the spad and the dvi.
| 
| Since I strongly believe that we should switch to ALLPROSE as soon as possible,
| (which will replace "document" with "make") I won't insist on anything.
| 
| Thus, I think that
| 
|   axiom --document=tangle foo.pamphlet
| 
| is quite ok.

We can simplify the switches if we are willing to use the same
switches as document itself.

\start
Date: Thu, 12 Apr 2007 12:03:37 -0400
From: Bill Page
To: list
Subject: FW: summer of code

Axiom Developers;

As motivation for further "sole searching" concerning the
minimal interest in Axiom expressed by Summer of Code
applicants to LispNYC (which very generously included Axiom
in it's list of possible projects), I am forwarding the
following email concerning SymPy. As you will read, a total
of 5 applications were accepted for SymPy related projects!

But first I would like to sincerely congratulate Ondrej Certik
for obtaining such a large response to the SymPy project. I
think that this is an encouraging sign that there is indeed
still a lot of interest in computer algebra/symbolic compuation
on the part of computer sciene students. I wish him and the
participants in the SOC 2007 projects the the greatest success.
I plan to continue to monitor the SymPy project and update the
version of SymPy that is accessible on the Axiom Wiki:

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

I don't see this as in conflict with any objectives of the
Axiom project and in fact I hope that we can continue to
collaborate to the greatest extent possible. Axiom developers
can contribute just by trying examples online or by downloading
and testing SymPy locally on their own computers and reporting
problems as usual to the SymPy developers. I believe that
Ondrej is subscribed to this Axiom email list, but obviously
he may be a little too busy with details of the Sympy projects
to contribute much to our discussion here. :-)

Regards,
Bill Page.

-----Original Message-----
From: sympy@googlegroups.com [mailto:sympy@googlegroups.com]
      On Behalf Of Ondrej Certik
Sent: April 12, 2007 5:56 AM
To: sympy@googlegroups.com
Subject: summer of code

Hi all,

thanks to all of you for participating in the GSoC. As I wrote, we
got 11 applications in total and 5 were selected (congratulations
to Mateusz, Robert, Brian, Chris and Jason!), so it's a huge success,
I didn't expect that.

You can check it here:

http://code.google.com/soc/psf/about.html
http://code.google.com/soc/stsci/about.html
http://code.google.com/soc/psu/about.html

Thanks also to Mladen, Marc-Etienne and George, even though you
weren't selected, you still helped SymPy a lot just by applying a
high quality application. Because that's better than any other
advertising.

The technical issues with those selected will be done later, don't
worry about it now. I'll be in touch.

\start
Date: 12 Apr 2007 18:22:10 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> | Thus, I think that
> | 
> |   axiom --document=tangle foo.pamphlet
> | 
> | is quite ok.
> 
> We can simplify the switches if we are willing to use the same switches as
> document itself.

Do you mean 

  axiom --tangle foo.pamphlet 

?

Would

  axiom foo.pamphlet

then do the same as currently 

  document foo.pamphlet

?

I'd rather have

  axiom --document=tangle foo.pamphlet

tangle foo.pamphlet

  axiom --document foo.pamphlet

be equivalent to current
  
  document foo.pamphlet

and

  axiom foo.pamphlet

show a usage message just as axiom -h. 

\start
Date: Thu, 12 Apr 2007 09:23:15 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Sockets, threads and GUI<->Kernel communication

--- Gabriel Dos Reis wrote:

> However, my fundamental point remains: common things should be
> simple.
> 
> I think we should be careful about the arguments we make.

Agreed.  My understanding was that it was the use of sockets itself
which you were objecting to.  Maxima's socket mechanism is both
effective and extremely simple, if I remember correctly.  I can see
where Axiom's CURRENT use of the idea may be suboptimal.

> Yet, they are they roots of many unpleasant aspects when working on
> the internal details and improvements of Axiom.

I will have to take a closer look at that aspect of the code - that is
surprising to me.  Of course, Maxima is a simple two way communication
and Axiom seems to communicate between core, graphics, and hyperdoc all
at once...

> | broadly developed and robust.  That may have changed since, but I
> would
> | want more information than I have now before I would be willing to
> | regard thread support in Lisp as something to depend on.
> 
> Well, my initial comment is more a statement about the current state
> as opposed to an active suggestion to redesign Axiom.  Certainly, we
> have around Lisp systems mapping to threads and using them.  They
> don't look more complicated than the current mess we have.

OK, that's probably true.

> Now, you
> may have a point about standard thread interface, but that is more of
> a general problem with Lisp environments once you start doing
> anything useful -- you have to catter for all kinds of variabilities.

Also true, but my expectation would be that sockets are more likely to
be available and robust in a given case than threads.  I admit I do not
have the facts in hand to justify that expectation.

> | some introductory material on thread vs. socket issues that I could
> | read?
> 
> They are not mutually exclusive, so I don't understand your point.

I misunderstood your original objection - I thought sockets applied to
Axiom in any fashion was a problem.  It sounds more like the way we
CURRENTLY do things isn't so good regardless of mechanism, and that's a
different sort of issue.  I'm surprised that this aspect of Axiom is
complex, so there are clearly some design issues I'm not taking into
account yet.

\start
Date: 12 Apr 2007 11:32:02 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Sockets, threads and GUI<->Kernel communication

Cliff Yapp writes:

| --- Gabriel Dos Reis wrote:
| 
| > However, my fundamental point remains: common things should be
| > simple.
| > 
| > I think we should be careful about the arguments we make.
| 
| Agreed.  My understanding was that it was the use of sockets itself
| which you were objecting to.

I'm objecting to unconditional use of "sockets" because they might
better handle the future.  

I think most of my objections are qualified :-)

[...]

| > | some introductory material on thread vs. socket issues that I could
| > | read?
| > 
| > They are not mutually exclusive, so I don't understand your point.
| 
| I misunderstood your original objection - I thought sockets applied to
| Axiom in any fashion was a problem.  It sounds more like the way we
| CURRENTLY do things isn't so good regardless of mechanism, and that's a
| different sort of issue.

Yes.

|  I'm surprised that this aspect of Axiom is
| complex, so there are clearly some design issues I'm not taking into
| account yet.

Well, they are not outstandingly complex, but they do add complexity.
When you try to port Axiom to say, ECL, SBCL, CLISP, etc. that added
complexity becomes non-negligeable.  Since, I've been doing that, I
think I let my exasperation out.

\start
Date: 12 Apr 2007 11:34:35 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > | Thus, I think that
| > | 
| > |   axiom --document=tangle foo.pamphlet
| > | 
| > | is quite ok.
| > 
| > We can simplify the switches if we are willing to use the same switches as
| > document itself.
| 
| Do you mean 
| 
|   axiom --tangle foo.pamphlet 
| 
| ?

For example.

| Would
| 
|   axiom foo.pamphlet
| 
| then do the same as currently 
| 
|   document foo.pamphlet
| 
| ?

 (1) latex the foo.tex
 (2) extract the root module and compile/interpret it

| I'd rather have
| 
|   axiom --document=tangle foo.pamphlet
| 
| tangle foo.pamphlet
| 
|   axiom --document foo.pamphlet
| 
| be equivalent to current
|   
|   document foo.pamphlet
| 
| and
| 
|   axiom foo.pamphlet
| 
| show a usage message just as axiom -h. 

I would also like to be able to dump intermediate representation,
compile to machine objects or FASLs, create a standalone executable.

\start
Date: 12 Apr 2007 18:41:08 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> | Do you mean 
> | 
> |   axiom --tangle foo.pamphlet 
> | 
> | ?
> 
> For example.
> 
> | Would
> | 
> |   axiom foo.pamphlet
> | 
> | then do the same as currently 
> | 
> |   document foo.pamphlet
> | 
> | ?
> 
>  (1) latex the foo.tex
>  (2) extract the root module and compile/interpret it

but currently, document does not compile/interpret, does it?
 
> | I'd rather have
> | 
> |   axiom --document=tangle foo.pamphlet
> | 
> | tangle foo.pamphlet
> | 
> |   axiom --document foo.pamphlet
> | 
> | be equivalent to current
> |   
> |   document foo.pamphlet
> | 
> | and
> | 
> |   axiom foo.pamphlet
> | 
> | show a usage message just as axiom -h. 
> 
> I would also like to be able to dump intermediate representation,
> compile to machine objects or FASLs, create a standalone executable.

I'd go for the 

axiom --document=tangle foo.pamphlet
axiom --document foo.pamphlet

version.  But do as you wish.  In any case, please install ".spad.pamphlet"
instead of ".spad" into src/algebra.  There is quite a bit of documented
algebra source meanwhile.

\start
Date: Thu, 12 Apr 2007 09:45:22 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Sockets, threads and GUI<->Kernel communication

--- Gabriel Dos Reis wrote:

> Well, they are not outstandingly complex, but they do add complexity.
> When you try to port Axiom to say, ECL, SBCL, CLISP, etc. that added
> complexity becomes non-negligeable.  Since, I've been doing that, I
> think I let my exasperation out.

Ah :-).  No problem - I FULLY understand that issue ;-).  API
differences without compelling motivation seem to be a hobby of free
lisp implementations...  One question - where is most of the code for
Axiom's use of sockets, in the lisp image or sman?  That task sounds
like one where the usocket library would be (or at least should be)
very helpful, although I suppose the C code makes assumptions that make
life difficult...

Axiom is not good at using existing libraries for this sort of thing,
probably because a) most don't seem to work on GCL and b) it was
written before most of them were available.  I think if we can make use
of those libraries (distribute them with Axiom if need be) we should be
able to make a lot of this sort of thing a LOT better, much more
easily.  (And I still think such an improved situation would mean more
interest from other Lisp projects...)

A long time back we had the discussion somewhere (as a project) about
the merits of selecting one lisp implementation as opposed to
supporting many.  I'm beginning to see the other side of that argument
more and more, although I think sbcl would be a better choice if 1 lisp
had to be chosen...  My hope is that once we ARE working on ANSI lisps
and perhaps using some of the "make life easier" libraries like CFFI
and usocket matters will remain much simpler going forward.  One can
hope anyway...

Cheers, and thanks for all the hard work you've been doing!

\start
Date: 12 Apr 2007 19:45:43 +0200
From: Martin Rubey
To: Tim Daly, Waldek Hebisch
Subject: docstrings created by aldor

Dear Tim, Waldek,

I'm currently experimenting with libdb.text files generated by aldor when
compiling for axiom.

Would you have an idea why

+++   \begin{adusage}
+++     x: \adthistype{} :=
\adname[CombinatorialSpeciesCategory]{cycleIndexSeries}$\adtype{SetSpecies}(Integer);
+++     k: MachineInteger := 3;
+++     s: \adthistype{} := \adthisname(x, k);
+++   \end{adusage}%$
+++   \begin{addescription}{Stretch a \useterm{cycle index series}.}
+++     For some integer $k$ and a given \useterm{cycle index series}
+++     \begin{gather*}
+++       f = \sum_{n=0}^\infty f_n(x_1,x_2,\ldots,x_n)
+++     \end{gather*}
+++     the function returns a \emph{stretched} series $g$
+++     \begin{gather*}
+++       g = \sum_{n=0}^\infty f_n(x_k,x_{2k},\ldots,x_{nk}).
+++     \end{gather*}
+++   \end{addescription}
+++   \begin{adremarks}
+++     This functions respects the fact that
+++     \adcode$\adname[FormalPowerSeriesCategory]{coefficient}(g,n)$
+++     returns a polynomial of (weighted) degree $n$, \ie, the function
+++     \adcode$\adname[FormalPowerSeriesCategory]{coefficients}(g)$
+++     returns a sequence with gaps of size $k-1$ between actual non-zero
+++     polynomials.
+++   \end{adremarks}


in the aldor source would be transformed into 

ostretch`2`x`(_$,ACMachineInteger)->_$`dCycleIndexSeries``\begin{adusage}
x: \adthistype{} := \adname[CombinatorialSpeciesCategory]{cycl
eIndexSeries}$\adtype{SetSpecies}(Integer);      k: MachineInteger := 3;
s: \adthistype{} := \adthisname(x, k);    \end{adusage}%$    \b
egin{addescription}{Stretch a \useterm{cycle index series}.}      For some
integer $k$ and a given \useterm{cycle index series}      \begin{g
ather*}        f = \sum_{n=0}^\infty f_n(x_1,x_2,\ldots,x_n)
\end{gather----------------*}      the function returns a \emph{stretched}
series $g$      \begin{gather*}        g = \sum_{n=0}^\infty
f_n(x_k,x_{2k},\ldots,x_{nk}).      \end{gather*}    \end{addescription}
\beg
in{adremarks}      This functions respects the fact that
\adcode$\adname[FormalPowerSeriesCategory]{coefficient}(g,n)$      returns a po
lynomial of (weighted) degree $n$, \ie, the function
\adcode$\adname[FormalPowerSeriesCategory]{coefficients}(g)$      returns a
sequenc
e with gaps o--f --si--ze-- $--k---1$-- b--etween actual non-zero
polynomials.    \end{adremarks}

in libdb.text?

(The line breaks are OK, but the minus signs in

\end{gather----------------*}      the function returns a \emph{stretched}

and

e with gaps o--f --si--ze-- $--k---1$-- b--etween actual non-zero

are terrible!

Some hints:

in the asy file, everything is still ok:

                (|symeNameCode| . 798514742)
                (|symeTypeCode| . 622595490)))
            (|Declare|
              |stretch|
              (|Apply| -> (|Comma| % |ACMachineInteger|) %)
              ((|documentation| .
                  "   \\begin{adusage}
     x: \\adthistype{} :=
                \\adname[CombinatorialSpeciesCategory]{cycleIndexSeries}$\\adtype{SetSpecies}(Integer);
     k: MachineInteger := 3;
     s: \\adthistype{} := \\adthisname(x, k);
   \\end{adusage}%$
   \\begin{addescription}{Stretch a \\useterm{cycle index series}.}
     For some integer $k$ and a given \\useterm{cycle index series}
     \\begin{gather*}
       f = \\sum_{n=0}^\\infty f_n(x_1,x_2,\\ldots,x_n)
     \\end{gather*}
     the function returns a \\emph{stretched} series $g$
     \\begin{gather*}
       g = \\sum_{n=0}^\\infty f_n(x_k,x_{2k},\\ldots,x_{nk}).
     \\end{gather*}
   \\end{addescription}
   \\begin{adremarks}
     This functions respects the fact that
     \\adcode$\\adname[FormalPowerSeriesCategory]{coefficient}(g,n)$
     returns a polynomial of (weighted) degree $n$, \\ie, the function
     \\adcode$\\adname[FormalPowerSeriesCategory]{coefficients}(g)$
     returns a sequence with gaps of size $k-1$ between actual non-zero
     polynomials.
   \\end{adremarks}
")

Also the version in libcombinatax.al is fine.  I could not find any other files
that contain the docstring.

The libdb is created magically when I first )lib the compiled files

Any insight would be great,

\start
Date: Thu, 12 Apr 2007 13:08:32 -0500
From: Tim Daly
To: Martin Rubey
Subject: docstrings created by aldor
Cc: Waldek Hebisch

Sorry, I have no clue. -- t

\start
Date: 12 Apr 2007 20:15:06 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: docstrings created by aldor
Cc: Waldek Hebisch

Tim Daly writes:

> Sorry, I have no clue. -- t

Do you know which part (i.e., boot or lisp function) is responsible for
creating libdb.text?

I guess it is created from the asy file, but even that I do not know.

\start
Date: 12 Apr 2007 20:27:33 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: docstrings created by aldor

Martin Rubey writes:

> Do you know which part (i.e., boot or lisp function) is responsible for
> creating libdb.text?
> 
> I guess it is created from the asy file, but even that I do not know.

OK, that one is pretty sure now.  Furthermore, it seems that minus signs start
always after exactly 500 characters, however, the number of minus signs
appearing at this position varies. After 500 more characters, I get minus signs
again, but there may be some other characters inbetween, as here:

(unfortunately, copy pasting modifies some characters, so the positions are not
exact anymore below)

Martin

dCycleIndexSeries`0`x`()->Join(FormalPowerSeriesCategory(SparseDistributedPolynomial(ACFraction(ACInteger),CycleIndexVariable,SparseIndexedPowerProduct(CycleIndexVariable,ACMachineInteger))),etc)``CYCLEIN`\begin{addescription}{Cycle
index series.}      \adthistype{} is the domain that represents \useterm{cycle
index        series}, \ie, \useterm{formal power series} in infinitely many
variables $x_1,x_2,x_3,\ldots$ of the form    \begin{gather}
f(x_1,x_2,\ldots)=\sum_{j_1+2j_2+\dots<\i----------------nfty}
f_{(j_1,j_2,j_3,\ldots)} x_1^{j_1} x_2^{j_2} x_3^{j_3}\cdots    \end{gather}
We group certain terms together and obtain    \begin{gather}
f(x_1,x_2,\ldots)=\sum_{n\geq0}
\sum_{\substack{j=(j_1,\ldots,j_n)\in\setN^n\\j_1+2j_2+\dots+nj_n=n}}
f_j x_1^{j_1} x_2^{j_2} \cdots x_n^{j_n}    \end{gather}    where the
polynomial under the outer sum is the \emph{sum} (over    all
\useterm[isomorphism types]{isomorphism type}) of certain    \useterm[cycle
index-- p--ol--yn--om--ia--ls--]{--cycle index polynomial} of degree    $n$.
In fact, if $f=Z_F$ for some \useterm{combinatorial species} $F$    then $f_j =
\frac{\fix F[j]}{\aut j}$ where $\aut(j)$ is defined    by~\eqref{eq:def:aut}.
If we denote by $\setN^{(\setN)}$ the set of finite sequences of    natural
numbers then a \useterm{cycle index series} $f$ is a    function from
$\setN^{(\setN)}$ to $\setQ$ in anology to the fact    that a \useterm{formal
power series} (over $\setQ$) is a f--unct--ion --   f--rom --$\se--tN$ --to
$--\setQ$.    \end{addescription}

\start
Date: Thu, 12 Apr 2007 21:04:10 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: docstrings created by aldor
Cc: Waldek Hebisch

Martin Rubey wrote:
> Martin Rubey writes:
> 
> > Do you know which part (i.e., boot or lisp function) is responsible for
> > creating libdb.text?
> > 
> > I guess it is created from the asy file, but even that I do not know.
> 
> OK, that one is pretty sure now.  Furthermore, it seems that minus signs start
> always after exactly 500 characters, however, the number of minus signs
> appearing at this position varies. After 500 more characters, I get minus signs
> again,

Look at the function writedb in br-data.boot.pamphlet.  It looks that
this function is resposible for mangling you see.

\start
Date: 12 Apr 2007 21:42:29 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: docstrings created by aldor

Waldek Hebisch writes:

> Look at the function writedb in br-data.boot.pamphlet.  It looks that
> this function is resposible for mangling you see.

Oh, I should have had the idea to 

grep "500" *.pamphlet

:-)

Any idea what that's good for?  Well, in any case, it will help me a lot to
reach my goal!

\start
Date: 12 Apr 2007 17:46:37 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > | Do you mean 
| > | 
| > |   axiom --tangle foo.pamphlet 
| > | 
| > | ?
| > 
| > For example.
| > 
| > | Would
| > | 
| > |   axiom foo.pamphlet
| > | 
| > | then do the same as currently 
| > | 
| > |   document foo.pamphlet
| > | 
| > | ?
| > 
| >  (1) latex the foo.tex
| >  (2) extract the root module and compile/interpret it
| 
| but currently, document does not compile/interpret, does it?

I was talking of the axiom script.

But, yes currently, document can translate Boot to Lisp, compile
Lisp to object codes, and assemble object codes to executable.

\start
Date: 12 Apr 2007 17:56:24 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: docstrings created by aldor

Martin Rubey writes:

| Waldek Hebisch writes:
| 
| > Look at the function writedb in br-data.boot.pamphlet.  It looks that
| > this function is resposible for mangling you see.
| 
| Oh, I should have had the idea to 
| 
| grep "500" *.pamphlet
| 
| :-)
| 
| Any idea what that's good for?  Well, in any case, it will help me a lot to
| reach my goal!


500 characters should be enough for everybody!

\start
Date: Thu, 12 Apr 2007 21:54:07 -0600
From: Jeremy Siek
To: list
Subject: CFP: Library-Centric Software Design 2007


     ACM SIGPLAN SYMPOSIUM ON LIBRARY-CENTRIC SOFTWARE DESIGN - LCSD'07

                     http://lcsd.cs.tamu.edu/2007

              on October 21st, 2007 at

         Object-Oriented Programming, Systems, Languages and 
Applications
         (OOPSLA'07) conference in Montreal, Canada, October 21-25, 2007

CALL FOR PAPERS

Libraries are central to all major scientific, engineering, and
business areas, yet the design, implementation, and use of libraries
are underdeveloped arts. This symposium is one of the first steps in
the process of placing all aspects of libraries on a sound technical
and scientific basis through research into fundamental issues and
documentation of best practices.

A software library is an organized collection of code with associated
tools supporting programming in general or in specific domains,
usually united by a specified set of principles and conventions. Most
libraries are aimed for use by several people and in different
environments. The areas of software library research include

     * Design and implementation of libraries
     * Program and system design based on libraries
     * Libraries supporting specific application domains, such as
       biology or banking
     * Evolution, refactoring, and maintenance of libraries
     * Empirical studies of library use
     * Performance of libraries, including benchmarking and
       library-based optimizations
     * Design of language facilities and tools in support of library
       definition and use
     * Validation, debugging, and testing of libraries
     * Extensibility, parameterization, and customization
     * Distribution of libraries
     * Specification of libraries and their semantics
     * Usability for library users and developers
     * Assessing quality of libraries
     * Documentation and teaching of libraries
     * Creating and supporting communities of library users
     * Using several libraries in combination

We invite the submission of papers on software library
research, including, but not limited to, the above list of topics.
The papers should address issues important to libraries as
a field, i.e., describe ideas or techniques that can be reused for
libraries across problem domains and/or languages.

Authors should use the latest ACM SIGS conference
style file (option 1) at
http://www.acm.org/sigs/pubs/proceed/template.html. Submissions should
be limited to 12 pages in this style.

Accepted papers will be published in the ACM proceedings for the 
symposium.

IMPORTANT DATES

Aug 1     Submission of papers
Sep 1     Notification of acceptance
Sep 15    Submission of final versions of the papers
Oct 21    Symposium

SUBMISSION PROCEDURE

For details of the electronic submission procedure, see the symposium's
Web site, http://lcsd.cs.tamu.edu/2007.

ORGANIZERS

     *  Jaakko J=89rvi, Texas A&M University
     *  David Musser, Rensselaer Polytechnic Institute
     *  Sibylle Schupp, Chalmers University of Technology
     *  Jeremy Siek, University of Colorado at Boulder
     *  Frank Tip, IBM T.J. Watson Research

PROGRAM COMMITTEE

     * Matthew Austern, Google
     * Antonio Cisternino, University of Piza
     * Sean Parent, Adobe Systems Incorporated
     * Brian Goetz, Quiotix Corp.
     * Andrew Lumsdaine, Indiana University
     * Oege de Moor, Oxford University
     * Lawrence Rauchwerger, Texas A&M
     * Peter Sestoft, University of Copenhagen
     * Bjarne Stroustrup, AT&T Labs, Texas A&M
     * Michelle Strout, Colorado State University
     * Matthias Troyer, ETH Zurich
     * Todd Veldhuizen, University of Waterloo

In addition, the organizers will serve as program committee members,
with Jaakko J=89rvi and Josh Bloch as program co-chairs.

Primarily, the email address lcsd07@cs.tamu.edu should be used for
questions addressed to the organizers.

KEYNOTE ADDRESS

There will be an invited talk by Doug Lea, State University of New
York at Oswego. Doug Lea is the author of the book "Concurrent
Programming in Java", and co-author of the text "Object-Oriented
System Development". He is the author of several widely used software
packages and components, as well as articles, reports, and
standardization efforts dealing with object oriented software
development including those on specification, design and
implementation techniques, distributed, concurrent, and parallel
object systems, and software reusability.

SYMPOSIUM GOALS AND ACTIVITIES

The symposium is a scientific forum for presenting original
research in the design, implementation, and evaluation of software
libraries. Other major activities include the identification of open
questions specific to library research and the discussion of a
strategic plan for establishing library research as a field. The
outcome of the symposium is a combination of research contributions and
specific next steps for improving the infrastructure for library
research.

Participants are expected to read the accepted submissions beforehand.
The technical presentations, although based on the accepted papers,
should not provide mere summaries of the papers. Instead, authors are
encouraged to use their presentation slots (20 + 10 mins) to bring up
topics for discussion.

The technical presentations are mixed with scientific and
organizational discussions. The discussions aim at furthering the
topics of the presentations, thus their agenda will be publicly
discussed among the participants and then posted on the website of the
symposium. All participants are expected to come prepared with their
tentative answers or thoughts.

The full-day symposium starts with a keynote talk for the stimulation
of discussion and concludes with a plenary discussion that decides the
specific next steps for improving the infrastructure for library
research.

FOR MORE INFORMATION AND UPDATES please visit
the symposium's Web site, http://lcsd.cs.tamu.edu/2007

\start
Date: 13 Apr 2007 10:07:52 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> | >  (1) latex the foo.tex
> | >  (2) extract the root module and compile/interpret it
> | 
> | but currently, document does not compile/interpret, does it?
> 
> I was talking of the axiom script.

Yes, I know.
 
> But, yes currently, document can translate Boot to Lisp, compile
> Lisp to object codes, and assemble object codes to executable.

Yes, but I was talking of the default action.  I believe, default should be to
create documentation and source only.

Haven't we reached concensus yet?

\start
Date: 13 Apr 2007 03:30:27 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Martin Rubey writes:

| Gabriel Dos Reis writes:
| 
| > | >  (1) latex the foo.tex
| > | >  (2) extract the root module and compile/interpret it
| > | 
| > | but currently, document does not compile/interpret, does it?
| > 
| > I was talking of the axiom script.
| 
| Yes, I know.
|  
| > But, yes currently, document can translate Boot to Lisp, compile
| > Lisp to object codes, and assemble object codes to executable.
| 
| Yes, but I was talking of the default action.  I believe, default should be to
| create documentation and source only.
| 
| Haven't we reached concensus yet?

I don't really know.  You seem to be arguing all aspects.

\start
Date: 13 Apr 2007 11:26:52 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch

Gabriel Dos Reis writes:

> | Haven't we reached concensus yet?
> 
> I don't really know.  You seem to be arguing all aspects.

Hm, I believe I voted for:

1) modify the axiom script to transform

     axiom --document=foo bar etc

   into a call

     document --foo=bar etc

   furthermore
 
     axiom --document=foo bar
 
   into a call
 
     document --foo bar
 
   and finally
 
     axiom --document bar
 
   into 
 
     document bar

2) and install *.spad.pamphlet instead of *.spad into
   target/i686-pc-linux/src/algebra/
 
   That this didn't happen in the first place is *really* strange in my
   opinion.

3) apart of that, install the SPADEDIT script into target/i686-pc-linux/lib/

   I'll have to modify it a tiny little bit if you agree on (2).  In
   particular, it may make sense to make it obey an environment variable, say,
   AXIOMEDITOR, that contains the name of an editor to be called with two
   arguments, namely line-number and filename.

   However, I believe that any script is better than no script, because many
   people will not have write access to the target/i686-pc-linux/lib/
   directory, so they cannot use the HyperDoc functionality.


Well, I do not insist on (3). But (1) and (2) would be important to me.

\start
Date: Fri, 13 Apr 2007 20:36:43 +0200
From: Ondrej Certik
To: Bill Page
Subject: Re: FW: summer of code

Hi, yes, I am subsribed to both axiom lists, but I was just busy. I
missed a discussion about the GSoC. I think all of us has already
expressed our opinions.

Thanks for the wishes, I also wish the Axiom project to become more
widespread and to succeed.

I think CAS is popular among students (as SAGE or SymPy shows) and
also I think that a full potential of the computer algebra systems was
not fully explited at all so far. However, it needs to be usable from
a widespread, standard, preferably highlevel language. Lisp, SPAD, or
Aldor are probably not going to be mainstream soon (and in my opinion
that is the crucial factor of attracting more people to any software),
but we had this discussion already, I know that some of you disagree,
but that's what I think about it.

I am also interested in collaboration. For example I am curious, how
the Gruntz algorithm is going to look like in Aldor. However, Aldor is
still not opensource and as I read some posts, maybe it is still not
clear if it ever will (by open source, I mean DFSG free
http://www.debian.org/social_contract#guidelines). And if you choose
the way of improving SPAD by yourself, with Axiom the only program
that uses it (correct me if I am wrong), then in my opinion it's the
same technological mistake as Maple or Mathematica did. I understand
the points of trying to make a better language, however, I myself am
not going to do it, as I don't believe it can ever really succeed. As
I talked with some of the students applying to SymPy, they have pretty
similar opinions to mine. So the time will tell, who invested his time
better. I just want to make the point, that although we all want to
contribute in the CAS field, I came to the conclusion that I can help
the field more by contributing to SymPy rather than to Axiom.

Regards,
Ondrej

On 4/12/07, Bill Page wrote:
> Axiom Developers;
>
> As motivation for further "sole searching" concerning the
> minimal interest in Axiom expressed by Summer of Code
> applicants to LispNYC (which very generously included Axiom
> in it's list of possible projects), I am forwarding the
> following email concerning SymPy. As you will read, a total
> of 5 applications were accepted for SymPy related projects!
>
> But first I would like to sincerely congratulate Ondrej Certik
> for obtaining such a large response to the SymPy project. I
> think that this is an encouraging sign that there is indeed
> still a lot of interest in computer algebra/symbolic compuation
> on the part of computer sciene students. I wish him and the
> participants in the SOC 2007 projects the the greatest success.
> I plan to continue to monitor the SymPy project and update the
> version of SymPy that is accessible on the Axiom Wiki:
>
> http://wiki.axiom-developer.org/SandBoxSymPy
>
> I don't see this as in conflict with any objectives of the
> Axiom project and in fact I hope that we can continue to
> collaborate to the greatest extent possible. Axiom developers
> can contribute just by trying examples online or by downloading
> and testing SymPy locally on their own computers and reporting
> problems as usual to the SymPy developers. I believe that
> Ondrej is subscribed to this Axiom email list, but obviously
> he may be a little too busy with details of the Sympy projects
> to contribute much to our discussion here. :-)
>
> Regards,
> Bill Page.
>
> -----Original Message-----
> From: sympy@googlegroups.com [mailto:sympy@googlegroups.com]
>       On Behalf Of Ondrej Certik
> Sent: April 12, 2007 5:56 AM
> To: sympy@googlegroups.com
> Subject: summer of code
>
> Hi all,
>
> thanks to all of you for participating in the GSoC. As I wrote, we
> got 11 applications in total and 5 were selected (congratulations
> to Mateusz, Robert, Brian, Chris and Jason!), so it's a huge success,
> I didn't expect that.
>
> You can check it here:
>
> http://code.google.com/soc/psf/about.html
> http://code.google.com/soc/stsci/about.html
> http://code.google.com/soc/psu/about.html
>
> Thanks also to Mladen, Marc-Etienne and George, even though you
> weren't selected, you still helped SymPy a lot just by applying a
> high quality application. Because that's better than any other
> advertising.
>
> The technical issues with those selected will be done later, don't
> worry about it now. I'll be in touch.

\start
Date: Fri, 13 Apr 2007 15:39:07 -0400
From: Bill Page
To: Ondrej Certik
Subject: RE: FW: summer of code

On April 13, 2007 2:37 PM Ondrej Certik wrote:
> ... 
> I think CAS is popular among students (as SAGE or SymPy shows)
> and also I think that a full potential of the computer algebra
> systems was not fully exploited at all so far. However, it needs
> to be usable from a widespread, standard, preferably high-level
> language. Lisp, SPAD, or Aldor are probably not going to be
> mainstream soon (and in my opinion that is the crucial factor
> of attracting more people to any software), but we had this
> discussion already, I know that some of you disagree, but
> that's what I think about it.
> ...

Perhaps there is a little more to say about it.

One thing to keep in mind is that at the time Axiom development
began, circa 1980, Lisp *was* then what one might have been
called a "main stream" language. Arguably it is still main stream
although somewhat marginalized by the current alternatives. Lisp
is an ideal environment for developing new languages so that it
was quite natural for the developers of Axiom to develop a new
language for Axiom as part of the basic design. Even Sage has
a front-end pre-processor to make Python more "friendly" for
math users and it has forked a version of Pyrex as it's
"compiled" language. So I am saying this as a caution: Just
because Python is popular today, this does not provide any long
term guarantee longevity.

But language politics aside, I am no longer convinced that the
association of Axiom with Lisp is particularly beneficial to
the Axiom project. And personally I believe your approach is
right in turns of attracting new people to the subject. For
that reason I do not see any conflict in us pursuing different
parallel paths to the same goals. After all, the internal design
of Axiom and even the SPAD language itself is not so different
than Python. Maybe some day even parts of Axiom might be written
in Python or SymPy might incorporate a large part of the current
Axiom Library in Pythonic form. That this sort of collaboration
might be possible is one of the great strengths of open source
software development.

So lets remain in touch as and when time permits.

\start
Date: Fri, 13 Apr 2007 14:14:16 -0700
From: Scott Morrison
To: list
Subject: Re: Sockets, threads and GUI<->Kernel communication

On 12 Apr 2007 06:41:28 -0500, Gabriel Dos Reis wrote:
>
> Cliff Yapp writes:
>
> | I do agree that threads are a more attractive way to implement the
> | client-server setup when dealing with a strictly local copy of Axiom,
>
> If you agree with that, then you must agree with the over-engineering
> characterization.  We have more uses of Axiom as local copy than we
> have as a truly distributed system over network.  A 101 principle
> of engineering is to keep common thing simple.
>

Mea Culpa.

As the designer and developer of the overly complex socket communication
system, I must take responsibility for this mess.  This system was
originally implemented on IBM RT workstations running AIX in 1989.  In AIX
there were no lightweight threads, so that really was not an option.  But
the real motivation for using sockets was that we envisioned running
HyperDoc  and Axiom on different machines.  In those days we had powerful
mainframes and wimpy workstations.  Of course it was never really
implemented to work that way, but the overly complex socket approach was
never removed.

There also would have been no HyperDoc if we'd done this a few years later.
At the time web browsers were non-existent.  I'd be in favor of dumping
HyperDoc and implementing a browser interface, but I'm not going to do that,
and I don't see it happening soon.

I also did the socket interface to the graphics system for the same reason:
we wanted to run things of different systems, and again it never happened.

So that's the historical perspective.

I apologize for leaving you guys with this overly complex mess.

\start
Date: Sat, 14 Apr 2007 02:33:03 +0200
From: Ondrej Certik
To: Bill Page
Subject: Re: FW: summer of code

> language for Axiom as part of the basic design. Even Sage has
> a front-end pre-processor to make Python more "friendly" for
> math users and it has forked a version of Pyrex as it's
> "compiled" language. So I am saying this as a caution: Just

And also I disagree with their decision in this. :)

> because Python is popular today, this does not provide any long
> term guarantee longevity.

...

> in Python or SymPy might incorporate a large part of the current
> Axiom Library in Pythonic form. That this sort of collaboration
> might be possible is one of the great strengths of open source
> software development.

That is true. However the key to success is just in finding enough
motivated people who are going to stick together and produce something
useful. And actually, to me it seems it's only about the politics. I
wasn't even alive when Axiom was started, thus it's difficult for me
to judge what the most popular language was at that time, however it's
seems to me that at that time, the methodology of programming was
quite different (for example the computer memory was a limiting factor
and the overhead of a language like python would be completely
devastating, none of which is a problem today for most of the
problems).

So it's almost certain that Python is going to be around for couple of
years, but in the 25 years horizon, it's actually pretty clear it will
not, at least not in the current form. However, if my program is not
going to be used anyway in 25 years, or only marginally, I prefer to
have something good today and attract people today, not tomorrow. Do
you have some estimate, how successful Axiom was in 1980s, when lisp
was quite more popular, than it is today? It's an unfair comparison,
because something like SymPy wouldn't be possible without the internet
and opensource and if I lived in 1980s, I wouldn't even started
anything like that, becase I wouldn't have means of spreading it to
people and especially getting anyone interested. Today's situation is
incredible - it's enough to write a code, put it on the web, create
some documentation and it will start living on its own if it is good
enough, because people will find it in google.

As to the collaboration - I think SAGE could use much of the Axiom, as
it already glues a lot of nice software. And once it is in python, it
can be used immediatelly by SymPy or any other project.

> So lets remain in touch as and when time permits.

Yes.

\start
Date: Fri, 13 Apr 2007 21:02:55 -0400
From: Cliff Yapp
To: Ondrej Certik
Subject: re: FW: summer of code

Ondrej Certik wrote:

> seems to me that at that time, the methodology of programming was
> quite different (for example the computer memory was a limiting factor
> and the overhead of a language like python would be completely
> devastating, none of which is a problem today for most of the
> problems).

I think you will find in the case of Axiom that efficiency concerns are
still very important - I refer you to the earlier discussion on notangle
in lisp as an example.  (note to self - iron out the last bugs in that...)

For simple computer algebra problems computers may have made the
question of resources less critical, but mathematical software in
particular has a tendency to always push the bounds of what is possible.
 Of course the trade-off must be made between maintainability and
efficiency, but I think Axiom as a project is most likely going to
devote a lot of attention to being (or remaining) fast.

\start
Date: Fri, 13 Apr 2007 23:38:19 -0400
From: Bill Page
To: Ondrej Certik
Subject: RE: FW: summer of code

[Warning: The following contains mostly philosophy and opinions.
If your interest is purely technical, you all know where the
delete key is on your keyboard... ]

On April 13, 2007 8:33 PM Ondrej Certik wrote:

> ...
> 
> So it's almost certain that Python is going to be around for
> couple of years, but in the 25 years horizon, it's actually
> pretty clear it will not, at least not in the current form.

It feels rather odd to me to be able to point out that Lisp
is well past that original 25 year horizon and it is still
essentially the same language as it was - dialects and various
libraries not withstanding.

> However, if my program [SymPy] is not going to be used anyway
> in 25 years, or only marginally, I prefer to have something
> good today and attract people today, not tomorrow.

When I started with the Axiom project (nearly 5 years ago) I
was at first a little amused by Tim Daly's insistence that one
should look at Axiom as something with (at least) a 30 year
horizon. That didn't seem credible to me at all.

But then what we are really talking about here is mathematics
and many of the algorithms that we are implementing in our
computer algebra systems are actually based on mathematics that
was developed as much as a *hundred* years earlier. Perhaps
Lisp is a little like that - more mathematics than a trendy
programming language.

So I wonder about Axiom. Are the design principles on which it
is based firm enough to be relevant over the long haul? Perhaps.
I have serious doubts that the principles on which Maple and
Mathematica are based will stand this long. In fact during the
time I have known them, they both seem to be converging toward
Axiom.

And here Axiom is now, nearly 30 years after it's inception. But
then Maxima (formerly Macsyma) is a system of the same time period
as Axiom and it is still alive today. We need something else to
explain that.

> Do you have some estimate, how successful Axiom was in 1980s,
> when lisp was quite more popular, than it is today?

It is difficult to talk about "popularity" because the situation
(as you say) was very different. But actually there are probably
more lisp programmers today then there was then just like there
are more horses in North America now then there was prior to the
era of mechanization of agriculture motor vehicles. Axiom was
certainly one of the premier computer algebra systems of it's
time - because it was (almost) the only computer algebra system.
And if you will permit me to distinguish between computer algebra
and symbolic computation, then it is still (almost) the only
computer algebra system. It was and still ahead of it's time.

> It's an unfair comparison, because something like SymPy wouldn't
> be possible without the internet and open source and if I lived
> in 1980s, I wouldn't even started anything like that, because
> I wouldn't have means of spreading it to people and especially
> getting anyone interested.

But I think it is a fair comparison because the same things are
true about Axiom. Axiom would not be here today if it was not
for open source and the Internet. In fact nearly 30 years of
research effort was saved largely because it became possible
to make it public rather than simply die like a lot of other
commercial software packages.

> Today's situation is incredible - it's enough to write a code,
> put it on the web, create some documentation and it will start
> living on its own if it is good enough, because people will
> find it in Google.
> 

I agree it is incredible but I have serious doubts about the
rest of your claim. I don't know what "good enough" means. I am
afraid that your model of development means just a lot of people
re-inventing the same thing in essentially the same way according
to the current fashion. I think that is a form of entertainment
but not real progress.

The way Axiom started was probably very similar expect for the
much smaller scale. It exists because a small number of people
where able to interest a larger number of people and a company
with enough resources like IBM. We are incredibly rich in
resources these days, but the critical part is still finding
the right people with really new ideas.

On the other hand, Axiom as a project with a 30 year time
horizon is very different. The system design on which we are
working today is essentially the same as the one originally
envisaged nearly 30 years ago. Besides saving 30 year of
intellectual effort from the trash bin, we are mostly trying to
carry on the same programme: to encode more mathematics in the
form that can be manipulated by a computer and at the same time
trying to "sell" the basic idea to people who have not yet
realized that the problem it is trying to solve even exists!

I like Python and I am glad that people are interested in it,
but I prefer to focus on the larger picture in order to see
how it fits into the long term. And I think that Python, SymPy,
Sage and Google's summer of code all have a role to play even
if that ends up by just getting more people interest in the
main subject - computer algebra.

\start
Date: Sat, 14 Apr 2007 00:23:06 -0400
From: Cliff Yapp
To: Bill Page
Subject: re: FW: summer of code

Bill Page wrote:

> It feels rather odd to me to be able to point out that Lisp
> is well past that original 25 year horizon and it is still
> essentially the same language as it was - dialects and various
> libraries not withstanding.

Indeed - IIRC it is up there with Fortran in terms of age.


> But then what we are really talking about here is mathematics
> and many of the algorithms that we are implementing in our
> computer algebra systems are actually based on mathematics that
> was developed as much as a *hundred* years earlier. Perhaps
> Lisp is a little like that - more mathematics than a trendy
> programming language.

Exactly - that is what appeals to me about making Axiom's math level
programming as much like "actual math" (whatever that means, we're still
exploring that I think) as possible.  If we really do the job well, the
result should be timeless.  I view TeX as a good example of this - it
solves its targeted problem so well that it has lasted for decades and
is still going strong.  Even if a new system should replace it the
design decisions and algorithms are likely to live on.  Axiom has the
potential to do the same thing for mathematics, and that is what makes
it such an exciting project for me.  I hate doing things more than once
- it's a waste of effort and it shouldn't be necessary except for
teaching/learning.  Axiom has the potential to let people solve problems
once, correctly, and then build off of them in a way that is convenient,
rigorous and scalable.

> So I wonder about Axiom. Are the design principles on which it
> is based firm enough to be relevant over the long haul? Perhaps.

If not, we will upgrade to better ones as we discover them.  Even if we
aren't optimal now, I think Axiom is close enough that we can profitably
build on it as a starting point.

> And here Axiom is now, nearly 30 years after it's inception. But
> then Maxima (formerly Macsyma) is a system of the same time period
> as Axiom and it is still alive today. We need something else to
> explain that.

That is not particularly difficult.  1)  The original researchers are
still available to work on it, which helps fuel the community 2)  it was
open source before Axiom, and so built a community while it was the
"only game in town" 3) it is more of an "engineering" system at the
moment in that it focuses less on mathematical typing et. al. and more
on "getting the answer that is useful."  (Axiom may someday do that as a
special case of being correct, but it's not there yet.)  4)  It
integrates better with other tools (gnuplot and wxmaxima) that people
find convenient to use for practical work they need to get done now.

Maxima is what you look to if you want a free Maple/Mathematica.  Axiom
is a new breed and currently requires more of an initial learning
investment.  Eventually Axiom may adsorb or surpass Maxima's abilities
and be attractive to a broader audience but IMHO that will come later
(and should come later, as we have Maxima to handle those needs until we
are ready to offer something demonstrably better for the applications
needing "engineering" CAS.)

> I agree it is incredible but I have serious doubts about the
> rest of your claim. I don't know what "good enough" means. I am
> afraid that your model of development means just a lot of people
> re-inventing the same thing in essentially the same way according
> to the current fashion. I think that is a form of entertainment
> but not real progress.

That is true to an extent (just look at the number of graphical toolkits
and window managers for X...)  but I think it is less true for more
complex software.  Blender, for example, does not have serious
competition in the open source world that I am aware of.  Nor does
BRL-CAD.  (Of course, those both started as closed source packages but
that's another post...)  Even if someone wants to re-code it in a
different language the research into the algorithms in projects like
this is re-used out of necessity.

I do not expect that people will begin working on heavy duty CASs in the
sense of trying to duplicate Axiom from scratch.  The problem is too
difficult - it is one of the few cases where learning the existing tool
is unambiguously easier than re-creating it (a problem with more basic
tools/libraries, especially in Lisp it seems...)

> On the other hand, Axiom as a project with a 30 year time
> horizon is very different. The system design on which we are
> working today is essentially the same as the one originally
> envisaged nearly 30 years ago.

Which is encouraging, because it means we may have a well defined
project idea here :-).  I'd say that longevity is a sign of strength.

> Besides saving 30 year of
> intellectual effort from the trash bin, we are mostly trying to
> carry on the same programme: to encode more mathematics in the
> form that can be manipulated by a computer and at the same time
> trying to "sell" the basic idea to people who have not yet
> realized that the problem it is trying to solve even exists!

That is a very interesting point and I wonder if it will be one of the
major formative changes in the field over the next 100 years of
mathematical research - the pursuit of assurance of correctness without
direct human mechanical verification.  The human mind has limitations
and there may be interesting and useful correctness proofs that are
intrinsically beyond the ability of any one human mind to verify.  But
if we can verify a verifier and trust that verifier, we can know the
proof is real.  (After all, if we accept a review of a proof as correct
we are trusting the minds of the reviewers to be accurate.)  CASs offer
convenient ways to solve problems today, but they are not yet better
than human minds at being correct/verified.  I hope someday Axiom will
be - just as we can only see into the depths of the universe with tools
beyond our own senses, we may find ourselves gazing into the depths of
mathematics with mechanical tools more capable of recognizing
correctness of large scale proofs than our own minds.

\start
Date: Sat, 14 Apr 2007 12:58:46 +0200
From: Ondrej Certik
To: Cliff Yapp
Subject: re: FW: summer of code

I see. I am not interested in mathematics (for this there is Axiom),
but just a basic symbolic manipulation and for this the algorithms are
not difficult and are well-known. And it's really not difficult to
code them. The time consuming part is the interface and that is imho
quite different from Axiom's.

Ondrej

On 4/14/07, Cliff Yapp wrote:
> Bill Page wrote:
>
> > It feels rather odd to me to be able to point out that Lisp
> > is well past that original 25 year horizon and it is still
> > essentially the same language as it was - dialects and various
> > libraries not withstanding.
>
> Indeed - IIRC it is up there with Fortran in terms of age.
>
>
> > But then what we are really talking about here is mathematics
> > and many of the algorithms that we are implementing in our
> > computer algebra systems are actually based on mathematics that
> > was developed as much as a *hundred* years earlier. Perhaps
> > Lisp is a little like that - more mathematics than a trendy
> > programming language.
>
> Exactly - that is what appeals to me about making Axiom's math level
> programming as much like "actual math" (whatever that means, we're still
> exploring that I think) as possible.  If we really do the job well, the
> result should be timeless.  I view TeX as a good example of this - it
> solves its targeted problem so well that it has lasted for decades and
> is still going strong.  Even if a new system should replace it the
> design decisions and algorithms are likely to live on.  Axiom has the
> potential to do the same thing for mathematics, and that is what makes
> it such an exciting project for me.  I hate doing things more than once
> - it's a waste of effort and it shouldn't be necessary except for
> teaching/learning.  Axiom has the potential to let people solve problems
> once, correctly, and then build off of them in a way that is convenient,
> rigorous and scalable.
>
> > So I wonder about Axiom. Are the design principles on which it
> > is based firm enough to be relevant over the long haul? Perhaps.
>
> If not, we will upgrade to better ones as we discover them.  Even if we
> aren't optimal now, I think Axiom is close enough that we can profitably
> build on it as a starting point.
>
> > And here Axiom is now, nearly 30 years after it's inception. But
> > then Maxima (formerly Macsyma) is a system of the same time period
> > as Axiom and it is still alive today. We need something else to
> > explain that.
>
> That is not particularly difficult.  1)  The original researchers are
> still available to work on it, which helps fuel the community 2)  it was
> open source before Axiom, and so built a community while it was the
> "only game in town" 3) it is more of an "engineering" system at the
> moment in that it focuses less on mathematical typing et. al. and more
> on "getting the answer that is useful."  (Axiom may someday do that as a
> special case of being correct, but it's not there yet.)  4)  It
> integrates better with other tools (gnuplot and wxmaxima) that people
> find convenient to use for practical work they need to get done now.
>
> Maxima is what you look to if you want a free Maple/Mathematica.  Axiom
> is a new breed and currently requires more of an initial learning
> investment.  Eventually Axiom may adsorb or surpass Maxima's abilities
> and be attractive to a broader audience but IMHO that will come later
> (and should come later, as we have Maxima to handle those needs until we
> are ready to offer something demonstrably better for the applications
> needing "engineering" CAS.)
>
> > I agree it is incredible but I have serious doubts about the
> > rest of your claim. I don't know what "good enough" means. I am
> > afraid that your model of development means just a lot of people
> > re-inventing the same thing in essentially the same way according
> > to the current fashion. I think that is a form of entertainment
> > but not real progress.
>
> That is true to an extent (just look at the number of graphical toolkits
> and window managers for X...)  but I think it is less true for more
> complex software.  Blender, for example, does not have serious
> competition in the open source world that I am aware of.  Nor does
> BRL-CAD.  (Of course, those both started as closed source packages but
> that's another post...)  Even if someone wants to re-code it in a
> different language the research into the algorithms in projects like
> this is re-used out of necessity.
>
> I do not expect that people will begin working on heavy duty CASs in the
> sense of trying to duplicate Axiom from scratch.  The problem is too
> difficult - it is one of the few cases where learning the existing tool
> is unambiguously easier than re-creating it (a problem with more basic
> tools/libraries, especially in Lisp it seems...)
>
> > On the other hand, Axiom as a project with a 30 year time
> > horizon is very different. The system design on which we are
> > working today is essentially the same as the one originally
> > envisaged nearly 30 years ago.
>
> Which is encouraging, because it means we may have a well defined
> project idea here :-).  I'd say that longevity is a sign of strength.
>
> > Besides saving 30 year of
> > intellectual effort from the trash bin, we are mostly trying to
> > carry on the same programme: to encode more mathematics in the
> > form that can be manipulated by a computer and at the same time
> > trying to "sell" the basic idea to people who have not yet
> > realized that the problem it is trying to solve even exists!
>
> That is a very interesting point and I wonder if it will be one of the
> major formative changes in the field over the next 100 years of
> mathematical research - the pursuit of assurance of correctness without
> direct human mechanical verification.  The human mind has limitations
> and there may be interesting and useful correctness proofs that are
> intrinsically beyond the ability of any one human mind to verify.  But
> if we can verify a verifier and trust that verifier, we can know the
> proof is real.  (After all, if we accept a review of a proof as correct
> we are trusting the minds of the reviewers to be accurate.)  CASs offer
> convenient ways to solve problems today, but they are not yet better
> than human minds at being correct/verified.  I hope someday Axiom will
> be - just as we can only see into the depths of the universe with tools
> beyond our own senses, we may find ourselves gazing into the depths of
> mathematics with mechanical tools more capable of recognizing
> correctness of large scale proofs than our own minds.

\start
Date: Sat, 14 Apr 2007 08:06:17 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Book order link on front page is broken

http://www.lulu.com/content/190827 just leads to "item not available." 
Did it get moved?

\start
Date: Sat, 14 Apr 2007 10:30:06 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Book order link.

http://www.lulu.com/content/190827

the link is fixed. thanks for the tip --t

\start
Date: Sun, 15 Apr 2007 00:31:29 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: differences wh-sandbox and build-improvements

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> [...]
> 
> | 2) depsys boot files are converted to shoe (and bootstrap
> |    Lisp is removed).  IIUC Gaby is doing similar thing
> |    in build-improvements.
> 
> This is something I would have liked to go into build-improvements so
> that I don't have to do the same thing.
> 

It looks that you just re-did work on last file that I converted
(I left non-bootstrap files as-is).

\start
Date: Sat, 14 Apr 2007 18:01:32 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: differences wh-sandbox and

Quoting Waldek Hebisch:

> Gabriel Dos Reis wrote:
>> Waldek Hebisch writes:
>>
>> [...]
>>
>> | 2) depsys boot files are converted to shoe (and bootstrap
>> |    Lisp is removed).  IIUC Gaby is doing similar thing
>> |    in build-improvements.
>>
>> This is something I would have liked to go into build-improvements so
>> that I don't have to do the same thing.
>>
>
> It looks that you just re-did work on last file that I converted
> (I left non-bootstrap files as-is).
>

Hi,

  As I said, if there is something valuable to the entire comunity,
we should try to get it proposed to the "upper" stream (i.e. where
we branched from).

What I committed before leaving was part of a larger patch.  If it is
worked already done, I'm sad to see it wasn't proposed for build-improvements.
Because I would have concentrated on some other paters.

There are more changes to come, but not before I find a more
reliable network connection and ways to install autoconf-2.60 on
mingw/msys.

\start
Date: Sat, 14 Apr 2007 20:38:34 -0500
From: Tim Daly
To: Alasdair McAndrew
Subject: book order link

The lulu.com book and the src/doc/bookvol1.pdf are the same file.

\start
Date: Sun, 15 Apr 2007 02:12:14 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: differences wh-sandbox and build-improvements

On April 14, 2007 7:02 PM Gaby wrote:
> 
> There are more changes to come, but not before I find a more
> reliable network connection and ways to install autoconf-2.60
> on mingw/msys.
>

What problems are you having with autoconf on MSYS/MinGW?

I built autoconf-2.61 and m4-1.4.9 directly from the gnu distribution
sources. Provided you have upgraded m4 first, autoconf passes all
tests.

Apparently you can also install autoconf-2.61 and m4-1.4.7 binaries
from:

http://sourceforge.net/project/showfiles.php?group_id=148008

I ran build-setup.sh with autoconf-2.61 to create a new ./configure
and built build-improvements on my Solaris 10.2 x86 system and on
Windows without any problems.

Is there any particular reason you want to continue using the older
version autoconf-2.60? (I think you can, but I haven't actually built
2.60 on MSYS/MinGW.)

\start
Date: Sun, 15 Apr 2007 04:56:15 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: differences wh-sandbox and	build-improvements

Quoting Bill Page:

> On April 14, 2007 7:02 PM Gaby wrote:
>>
>> There are more changes to come, but not before I find a more
>> reliable network connection and ways to install autoconf-2.60
>> on mingw/msys.
>>
>
> What problems are you having with autoconf on MSYS/MinGW?
>

Build of Autoconf-2.6[01] fails for me with:

  "The system cannot find the specified file"

I've spent some time understanding this; I made some progress, but not
to the point of getting pass that failure.  my frustration with windows
is only growing.

> I built autoconf-2.61 and m4-1.4.9 directly from the gnu distribution
> sources. Provided you have upgraded m4 first, autoconf passes all
> tests.
>

I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.

> Apparently you can also install autoconf-2.61 and m4-1.4.7 binaries
> from:
>
> http://sourceforge.net/project/showfiles.php?group_id=148008
>

yes, i donwloaded the autoconf package from there last night; I've
not tried that version yet.

> I ran build-setup.sh with autoconf-2.61 to create a new ./configure
> and built build-improvements on my Solaris 10.2 x86 system and on
> Windows without any problems.
>
> Is there any particular reason you want to continue using the older
> version autoconf-2.60? (I think you can, but I haven't actually built
> 2.60 on MSYS/MinGW.)
>

my three main linux boxes are running that version,

\start
Date: Sun, 15 Apr 2007 15:20:53 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: differences wh-sandbox andbuild-improvements

On April 15, 2007 5:56 AM Gaby wrote:

> ... 
> Build of Autoconf-2.6[01] fails for me with:
> 
>   "The system cannot find the specified file"
> 
> I've spent some time understanding this; I made some progress,
> but not to the point of getting pass that failure. my
> frustration with windows is only growing.
>

I think it best to avoid the trap that most linux developers
fall into when working with Windows. As far as I am concerned
it is just another operating system ...
 
> Bill Page wrote:
> > I built autoconf-2.61 and m4-1.4.9 directly from the gnu 
> > distribution sources. Provided you have upgraded m4 first,
> > autoconf passes all tests.
> >
> 
> I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.

I have:

$ m4 --version
m4 (GNU M4) 1.4.9

$ perl --version

This is perl, v5.6.1 built for msys

$ gcc --version
gcc.exe (GCC) 3.4.2 (mingw-special)
$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
Built for i686-pc-msys

----------

My first guess is that your problem might have something to do
with be the version of Perl that you are using. I have never
used ActivePerl for buidling MSYS/MinGW apps.

I prefer to install as much from the MSYS/MinGW distribution
as possible. See for example the instructions here:

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

under the heading "Building Axiom on Windows".

Then I built m4 and autoconf from the GNU sources without any
problems.

> 
> > Apparently you can also install autoconf-2.61 and m4-1.4.7
> > binaries from:
> >
> > http://sourceforge.net/project/showfiles.php?group_id=148008
> >
> 
> yes, i donwloaded the autoconf package from there last night;
> I've not tried that version yet.

Let me know how it turns out.

> ... 
> > Is there any particular reason you want to continue using
> > the older version autoconf-2.60?
> >
> 
> my three main linux boxes are running that version,
> 

I recommend that we go to autoconf-2.61 for all Axiom builds.

\start
Date: Sun, 15 Apr 2007 16:27:55 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: differences wh-sandbox andbuild-improvements

Quoting Bill Page:

> On April 15, 2007 5:56 AM Gaby wrote:
>
>> ...
>> Build of Autoconf-2.6[01] fails for me with:
>>
>>   "The system cannot find the specified file"
>>
>> I've spent some time understanding this; I made some progress,
>> but not to the point of getting pass that failure. my
>> frustration with windows is only growing.
>>
>
> I think it best to avoid the trap that most linux developers
> fall into when working with Windows. As far as I am concerned
> it is just another operating system ...
>

Maybe -- I don't know what trap it is.

>> Bill Page wrote:
>> > I built autoconf-2.61 and m4-1.4.9 directly from the gnu
>> > distribution sources. Provided you have upgraded m4 first,
>> > autoconf passes all tests.
>> >
>>
>> I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.
>
> I have:
>
> $ m4 --version
> m4 (GNU M4) 1.4.9
>
> $ perl --version
>
> This is perl, v5.6.1 built for msys
>
> $ gcc --version
> gcc.exe (GCC) 3.4.2 (mingw-special)
> $ make --version
> GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
> Built for i686-pc-msys
>

Apart from ActivePerl, I have the same setting.

> ----------
>
> My first guess is that your problem might have something to do
> with be the version of Perl that you are using. I have never
> used ActivePerl for buidling MSYS/MinGW apps.
>

Maybe.  But, again, the idea of using ActivePerl for msys/mingw came from
mingw website.  I did not pull it out of my hat.


> I prefer to install as much from the MSYS/MinGW distribution
> as possible. See for example the instructions here:
>
> http://wiki.axiom-developer.org/BuildAxiom
>
> under the heading "Building Axiom on Windows".
>
> Then I built m4 and autoconf from the GNU sources without any
> problems.
>
>>
>> > Apparently you can also install autoconf-2.61 and m4-1.4.7
>> > binaries from:
>> >
>> > http://sourceforge.net/project/showfiles.php?group_id=148008
>> >
>>
>> yes, i donwloaded the autoconf package from there last night;
>> I've not tried that version yet.
>
> Let me know how it turns out.
>

not well -- my Perl is not /bin/perl.

>> ...
>> > Is there any particular reason you want to continue using
>> > the older version autoconf-2.60?
>> >
>>
>> my three main linux boxes are running that version,
>>
>
> I recommend that we go to autoconf-2.61 for all Axiom builds.
>

As long as you prepare and commit all my patches, I'm fine with that.

\start
Date: Sun, 15 Apr 2007 22:52:51 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: differences wh-sandbox andbuild-improvements

On April 15, 2007 5:28 PM Gaby wrote:
> 
> Quoting Bill Page:
> 
> > On April 15, 2007 5:56 AM Gaby wrote:
> > ...
> > > my frustration with windows is only growing.
> > >
> >
> > I think it best to avoid the trap that most linux
> > developers fall into when working with Windows. As
> > far as I am concerned it is just another operating
> > system ...
> >
> 
> Maybe -- I don't know what trap it is.

The "trap" to which I was referring has been called "Linux
chauvinism", see for example:

http://www.softpanorama.org/OSS/Bla_faq/raymondism.shtml

by Nikolai Bezroukov

In my own words its something like this: Assuming that because
one is having trouble in an environment with which one is less
familiar, that it is therefore inferior and a unnecessary source
of frustration - sort of opposite to the slogan: "familiarity
breeds contempt". It is a trap because believing this tends to
make it seem true.

But I did *not* intend to accuse you of this even by implication.
Sorry. It's just that I see this statement made very often in
different ways and I think it tends to perpetuate views that I
think are undesirable. However frustration, is of course quite
natural. 

> ...
> I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.
>
> > ...
> > I have:
> >
> > $ perl --version
> >
> > This is perl, v5.6.1 built for msys

I suppose you meant ActivePerl-5.8.8.820?

http://www.activestate.com/Products/ActivePerl/more_information.plex

Perl comes in two flavours from ActiveState the 5.6.x track and the
5.8.x track. Both are considered current releases. I have 5.8.8 in
my Windows installation but 5.6.1 in MSYS.

> Bill Page wrote:
> >
> > My first guess is that your problem might have something to do
> > with be the version of Perl that you are using. I have never
> > used ActivePerl for buidling MSYS/MinGW apps.
> >
> 
> Maybe.  But, again, the idea of using ActivePerl for msys/mingw
> came from mingw website.  I did not pull it out of my hat.
> 

Well, it was only my first guess. But just be sure I renamed my
MSYS /bin/perl to /bin/old_perl and restarted MSYS so that it
picks up ActivePerl-5.8.8.820 from my Windows installation. Now
I can reproduce the error that you reported:

$ perl --version

This is perl, v5.8.8 built for MSWin32-x86-multi-thread

$ cd autoconf-2.61

$ make clean

$ ./configure
...
$ make
...
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
         ../bin/autom4te -B '..'/lib -B '..'/lib
         --language M4sh --cache '' --melt ./autoconf.as -o autoconf.in
The system cannot find the path specified.
autom4te: need GNU m4 1.4 or later: /usr/local/bin/m4
make[1]: *** [autoconf.in] Error 1
make[1]: Leaving directory `/home/Administrator/autoconf-2.61/bin'
make: *** [all-recursive] Error 1

Administrator@ASUS ~/autoconf-2.61


> >
> >>
> >> > Apparently you can also install autoconf-2.61 and m4-1.4.7
> >> > binaries from:
> >> >
> >> > http://sourceforge.net/project/showfiles.php?group_id=148008
> >> >
> >>
> >> yes, i donwloaded the autoconf package from there last night;
> >> I've not tried that version yet.
> >
> > Let me know how it turns out.
> >
> 
> not well -- my Perl is not /bin/perl.
>

Do you mean that they assume that perl is in /bin/perl?
 
> >> ...
> >> > Is there any particular reason you want to continue using
> >> > the older version autoconf-2.60?
> >> >
> >>
> >> my three main linux boxes are running that version,
> >>
> >
> > I recommend that we go to autoconf-2.61 for all Axiom builds.
> >
> 
> As long as you prepare and commit all my patches, I'm fine with
> that.
> 

Gee, that sounds familiar. Where did I hear that before? Oh,
sorry. I forgot. This is the Axiom open source project - the
one where each developer chooses there own flavor and version
of the basic tools ... I with draw my recommendation. Let's
just all continue to do it our own way. ;)

\start
Date: Mon, 16 Apr 2007 02:31:43 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: differences wh-sandbox andbuild-improvements

Quoting Bill Page:

> On April 15, 2007 5:28 PM Gaby wrote:
>>
>> Quoting Bill Page:
>>
>> > On April 15, 2007 5:56 AM Gaby wrote:
>> > ...
>> > > my frustration with windows is only growing.
>> > >
>> >
>> > I think it best to avoid the trap that most linux
>> > developers fall into when working with Windows. As
>> > far as I am concerned it is just another operating
>> > system ...
>> >
>>
>> Maybe -- I don't know what trap it is.
>
> The "trap" to which I was referring has been called "Linux
> chauvinism", see for example:
>
> http://www.softpanorama.org/OSS/Bla_faq/raymondism.shtml
>
> by Nikolai Bezroukov
>
> In my own words its something like this: Assuming that because
> one is having trouble in an environment with which one is less
> familiar, that it is therefore inferior and a unnecessary source
> of frustration - sort of opposite to the slogan: "familiarity
> breeds contempt". It is a trap because believing this tends to
> make it seem true.
>
> But I did *not* intend to accuse you of this even by implication.
> Sorry. It's just that I see this statement made very often in
> different ways and I think it tends to perpetuate views that I
> think are undesirable. However frustration, is of course quite
> natural.
>

I have a functional development environment under windows -- cygwin --
but I cannot use it because GCL does not work under cygwin and I
have been told on this list that windows people don't care about
GCL under cygwin.  I guess the fact that windows people on this list don't
help that much to make concrete forward progress is OK.  Now, I've
been trying to set up a reasonable environment for working on Axiom
with no good result so far and I'm told by non-implicative non-accusation
that I would be suffering from trap known as "linux chauvinism" when nobody
knows what I think of comparison of linux and windows.  I guess that is
fair.  And my problems did not go away.  I guess that is forward progress.

>> ...
>> I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.
>>
>> > ...
>> > I have:
>> >
>> > $ perl --version
>> >
>> > This is perl, v5.6.1 built for msys
>
> I suppose you meant ActivePerl-5.8.8.820?
>
> http://www.activestate.com/Products/ActivePerl/more_information.plex
>
> Perl comes in two flavours from ActiveState the 5.6.x track and the
> 5.8.x track. Both are considered current releases. I have 5.8.8 in
> my Windows installation but 5.6.1 in MSYS.
>
>> Bill Page wrote:
>> >
>> > My first guess is that your problem might have something to do
>> > with be the version of Perl that you are using. I have never
>> > used ActivePerl for buidling MSYS/MinGW apps.
>> >
>>
>> Maybe.  But, again, the idea of using ActivePerl for msys/mingw
>> came from mingw website.  I did not pull it out of my hat.
>>
>
> Well, it was only my first guess. But just be sure I renamed my
> MSYS /bin/perl to /bin/old_perl and restarted MSYS so that it
> picks up ActivePerl-5.8.8.820 from my Windows installation. Now
> I can reproduce the error that you reported:
>
> $ perl --version
>
> This is perl, v5.8.8 built for MSWin32-x86-multi-thread
>
> $ cd autoconf-2.61
>
> $ make clean
>
> $ ./configure
> ...
> $ make
> ...
> autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
>         ../bin/autom4te -B '..'/lib -B '..'/lib
>         --language M4sh --cache '' --melt ./autoconf.as -o autoconf.in
> The system cannot find the path specified.
> autom4te: need GNU m4 1.4 or later: /usr/local/bin/m4
> make[1]: *** [autoconf.in] Error 1
> make[1]: Leaving directory `/home/Administrator/autoconf-2.61/bin'
> make: *** [all-recursive] Error 1
>

yes.

> Administrator@ASUS ~/autoconf-2.61
>
>
>> >
>> >>
>> >> > Apparently you can also install autoconf-2.61 and m4-1.4.7
>> >> > binaries from:
>> >> >
>> >> > http://sourceforge.net/project/showfiles.php?group_id=148008
>> >> >
>> >>
>> >> yes, i donwloaded the autoconf package from there last night;
>> >> I've not tried that version yet.
>> >
>> > Let me know how it turns out.
>> >
>>
>> not well -- my Perl is not /bin/perl.
>>
>
> Do you mean that they assume that perl is in /bin/perl?
>

Yes. Have a look at autom4te.

>> >> ...
>> >> > Is there any particular reason you want to continue using
>> >> > the older version autoconf-2.60?
>> >> >
>> >>
>> >> my three main linux boxes are running that version,
>> >>
>> >
>> > I recommend that we go to autoconf-2.61 for all Axiom builds.
>> >
>>
>> As long as you prepare and commit all my patches, I'm fine with
>> that.
>>
>
> Gee, that sounds familiar. Where did I hear that before? Oh,
> sorry. I forgot. This is the Axiom open source project - the
> one where each developer chooses there own flavor and version
> of the basic tools ... I with draw my recommendation. Let's
> just all continue to do it our own way. ;)
>

I believe you got it wrong; even with a smiley.
There are several "rules" I've developed over the years, while
maintaining linux boxes, that include:
  (1) don't mess with "system" tools packaged by linux distros;
  (2) duplicating tools under /usr/local, sooner or later causes
      troubles.
  (3) install system tools under /usr/local only when they solve
      fundamental problems.

I suspect you'd have much more effective impact at explaining me
how automake-2.61 fare vis-a-vis the above three rules.

\start
Date: Mon, 16 Apr 2007 11:28:22 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: differences wh-sandbox andbuild-improvements

On April 16, 2007 3:32 AM Gaby wrote:

> 
> I have a functional development environment under windows
> -- cygwin -- but I cannot use it because GCL does not work under
> cygwin

What do you mean that GCL does not work under cygwin? It works
for me. You just can't compile it under cygwin.

> and I have been told on this list that windows people don't
> care about GCL under cygwin.

I think that in general windows people don't care much for
cygwin. period. What it does is foreign to them plus it is a
poor replacement for linux, if linux is what you really want.

> I guess the fact that windows people on this list don't help
> that much to make concrete forward progress is OK.

I think that is typical. Most "windows people" aren't that
interested in application development. According to the Windows
user model that is somebody else's problem. Of course there are
Windows developers, even Windows open source developers but the
ratio of users to developers is much higher for Windows than
linux (perhas by as much as several orders of magnitude).

> Now, I've been trying to set up a reasonable environment for
> working on Axiom with no good result so far and I'm told by
> non-implicative non-accusation that I would be suffering from
> trap known as "linux chauvinism" when nobody knows what I
> think of comparison of linux and windows.

Ok, that was gratuatous on my part, for which I do apologize.
It just turned out that I happened to be reading Nikolai's stuff
when you wrote: "my frustration with windows is only growing"
and it touched a nerve.

> I guess that is fair.

not. sorry.

> And my problems did not go away.  I guess that is forward
> progress.
>

not. 

I could repeat almost word-for-word a similar statement by Tim
Daly concerning svn. It turns out that I can reproduce both of
your problems and I discussed how to solve both of them and
still neither of you are interested. I guess that's progress.

not.

> ...
> > I can reproduce the error that you reported:
> > ...
> > The system cannot find the path specified.
> ... 
> yes.

So install MSYS from pre-packaged components and the problem goes
away. Just because other people get away with using ActivePerl
with minGW doesn't make it a "supported configuration" or good
idea.

> >> >
> >> > I recommend that we go to autoconf-2.61 for all Axiom builds.
> >> >
> >>
> >> As long as you prepare and commit all my patches, I'm fine
> >> with that.
> >>
> >
> > Gee, that sounds familiar. Where did I hear that before? Oh,
> > sorry. I forgot. This is the Axiom open source project - the
> > one where each developer chooses there own flavor and version
> > of the basic tools ... I with draw my recommendation. Let's
> > just all continue to do it our own way. ;)
> >
> 
> I believe you got it wrong; even with a smiley.
> There are several "rules" I've developed over the years, while
> maintaining linux boxes, that include:
>   (1) don't mess with "system" tools packaged by linux distros;
>   (2) duplicating tools under /usr/local, sooner or later causes
>       troubles.
>   (3) install system tools under /usr/local only when they solve
>       fundamental problems.
>

MSYS is not a linux distro by any imagination but I think the same
principle applies. Install MSYS from "standard" components as I
indicated here:

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

Then build autoconf-2.6x. Install it where ever you like.
 
> I suspect you'd have much more effective impact at explaining
> me how automake-2.61 fare vis-a-vis the above three rules.
> 

The current MSYS developer package does not contain autoconf-2.6x.
If you think you need at least 2.60 what other choice do you have?
If not revert the autoconf stuff to 2.59. (Waldek is still using
2.59 in wh-sandbox.)

\start
Date: Mon, 16 Apr 2007 11:22:00 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: differences wh-sandbox andbuild-improvements

Quoting Bill Page:

> On April 16, 2007 3:32 AM Gaby wrote:
>
>>
>> I have a functional development environment under windows
>> -- cygwin -- but I cannot use it because GCL does not work under
>> cygwin
>
> What do you mean that GCL does not work under cygwin? It works
> for me. You just can't compile it under cygwin.

That means the same thing for me: If I cannot compile it under cygwin,
it does not work for me as far as Axiom development is concerned.

>
>> and I have been told on this list that windows people don't
>> care about GCL under cygwin.
>
> I think that in general windows people don't care much for
> cygwin. period. What it does is foreign to them plus it is a
> poor replacement for linux, if linux is what you really want.
>

But, I do not mean linux.  My impression is that you're
completely missing the picture by micro-focusing on linux vs.
non-linux environment and drawing misplaced conclusions
characterizations.

What I want is to have a reasonable development under windows
-- whether it is mingw or cygwin, I don't care much.  The only
thing I care about is that the environment does not disrupt
me much from doing actual work.

>> I guess the fact that windows people on this list don't help
>> that much to make concrete forward progress is OK.
>
> I think that is typical.

OK; I believe the logical conclusion for me is probably that I
drop any work on Axiom on windows.

[...]

>
>> And my problems did not go away.  I guess that is forward
>> progress.
>>
>
> not.
>
> I could repeat almost word-for-word a similar statement by Tim
> Daly concerning svn. It turns out that I can reproduce both of
> your problems and I discussed how to solve both of them and
> still neither of you are interested. I guess that's progress.

Granted you can reproduce the problems, but the solution you suggested
did not work for me. I moved ActivePerl's path away from /bin and
/mingw/bin.  Now, I tried to install autoconf-2.60 -- I explained
why I cannot require autoconf-2.61; more on this below.  Except the
build goes into infinite loop, so that I never get a functional build.

>
> not.
>
>> ...
>> > I can reproduce the error that you reported:
>> > ...
>> > The system cannot find the path specified.
>> ...
>> yes.
>
> So install MSYS from pre-packaged components and the problem goes
> away.

But I already have MSYS pre-packaged components from mingw.org!

> Just because other people get away with using ActivePerl
> with minGW doesn't make it a "supported configuration" or good
> idea.

Definitely, my reading of the mingw documentation from mingw
website is that ActivePerl is a "supported configuration".
But again, that point is moot by now.  Even old Perl from
msys does not get me install Autoconf-2.60.

>> >> >
>> >> > I recommend that we go to autoconf-2.61 for all Axiom builds.
>> >> >
>> >>
>> >> As long as you prepare and commit all my patches, I'm fine
>> >> with that.
>> >>
>> >
>> > Gee, that sounds familiar. Where did I hear that before? Oh,
>> > sorry. I forgot. This is the Axiom open source project - the
>> > one where each developer chooses there own flavor and version
>> > of the basic tools ... I with draw my recommendation. Let's
>> > just all continue to do it our own way. ;)
>> >
>>
>> I believe you got it wrong; even with a smiley.
>> There are several "rules" I've developed over the years, while
>> maintaining linux boxes, that include:
>>   (1) don't mess with "system" tools packaged by linux distros;
>>   (2) duplicating tools under /usr/local, sooner or later causes
>>       troubles.
>>   (3) install system tools under /usr/local only when they solve
>>       fundamental problems.
>>
>
> MSYS is not a linux distro by any imagination but I think the same
> principle applies.

Which implies that I should not even try your suggestion of installing
Autoconf-2.61 from a non-officially supported third party.  I don't
think your statements are coherent.

> Install MSYS from "standard" components as I
> indicated here:
>
> http://wiki.axiom-developer.org/BuildAxiom
>

I'm very familiar with that webpage; it does not solve
the issues I'm facing.

> Then build autoconf-2.6x. Install it where ever you like.

Bill -- again, building Autoconf-2.60 does not work on the "virgin"
msys/mingw fails as an infinite loop.

>
>> I suspect you'd have much more effective impact at explaining
>> me how automake-2.61 fare vis-a-vis the above three rules.
>>
>
> The current MSYS developer package does not contain autoconf-2.6x.
> If you think you need at least 2.60 what other choice do you have?

I move from Autoconf-2.5x to Autoconf-2.60 because:
  (1) it does fix a bug, that turns out to be serious in later
      development for Axiom (partly because of some bugs in Axiom).
  (2) all my development machines have Autoconf-2.60 installed
      (prepackages with the linux distribution).

As I see this, I can the reasonable choice for me is to stop any
work related to Axiom on windows; that save me valuable time, and
probably spares me from unwarranted unhelpful characterizations
and moralization.  If people care about Axiom on windows, they
will find resources to get it happen.  I'm done.

> If not revert the autoconf stuff to 2.59. (Waldek is still using
> 2.59 in wh-sandbox.)


\start
Date: Mon, 16 Apr 2007 12:08:42 -0500
From: Tim Daly
To: Bill Page
Subject: comment

> I could repeat almost word-for-word a similar statement by Tim
> Daly concerning svn. It turns out that I can reproduce both of
> your problems and I discussed how to solve both of them and
> still neither of you are interested. I guess that's progress.

> not.

As I recall the whole Axiom project spent a considerable amount
of effort trying to resolve the SVN problem. You did a great job
trying to set up SVN on axiom-developer (successfully?) and Google
(unsuccessfully). 

I eventually experimented with other systems. You advocated darcs
and mercurial as I remember. I looked at darcs but my investigations,
and I believe your comments, left me with the impression that it is
not ready for a full, large projects. I did not try mercurial.

SVN times out on me and I have to do a checkout+12update cycle to
get a full axiom copy. Checkin takes over half an hour. SVN uses
twice the space of the Axiom distribution. It all feels slow,
ponderous, and heavy. And SVN wedges, demanding I "cleanup", which
never succeeds.

I eventually tried git. Checkout and checkin over the network take
about the same time as a local disk-to-disk copy. It uses only a tiny
amount of additional disk space. I like it so much that I've moved all
of my research work into git and use it for normal work purposes.

So, yes, you did reproduce my SVN problems and you discussed how to
solve my problems. However, SVN itself has problems (slow, unreliable,
and large) which have no solution. The question wasn't "can it be
made to work" but rather "why waste the time and space".

Git is the best technical solution, thus I use git. 
To me, that's progress.

\start
Date: Mon, 16 Apr 2007 13:19:01 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: differences wh-sandbox andbuild-improvements

On April 16, 2007 12:22 PM wrote:
>
> Quoting Bill Page:
>
> > On April 16, 2007 3:32 AM Gaby wrote:
> >
> >>
> >> I have a functional development environment under windows
> >> -- cygwin -- but I cannot use it because GCL does not work
> >> under cygwin
> >
> > What do you mean that GCL does not work under cygwin? It works
> > for me. You just can't compile it under cygwin.
>
> That means the same thing for me: If I cannot compile it under
> cygwin, it does not work for me as far as Axiom development is
> concerned.
>

Why not? It is not necessary to build gcl as part of the Axiom
build - just install the windows binary for gcl, like other users
Windows do.

> >
> >> and I have been told on this list that windows people don't
> >> care about GCL under cygwin.
> >
> > I think that in general windows people don't care much for
> > cygwin. period. What it does is foreign to them plus it is a
> > poor replacement for linux, if linux is what you really want.
> >
>
> But, I do not mean linux.  My impression is that you're
> completely missing the picture by micro-focusing on linux vs.
> non-linux environment and drawing misplaced conclusions
> characterizations.

Yes, perhaps. Sorry.

>
> What I want is to have a reasonable development under windows
> -- whether it is mingw or cygwin, I don't care much.  The only
> thing I care about is that the environment does not disrupt
> me much from doing actual work.
>

MSYS/minGW works for me.

> >> I guess the fact that windows people on this list don't
> >> help that much to make concrete forward progress is OK.
> >
> > I think that is typical.
>
> OK; I believe the logical conclusion for me is probably that
> I drop any work on Axiom on windows.

Your choice.

>
> Granted you can reproduce the problems, but the solution you
> suggested did not work for me. I moved ActivePerl's path away
> from /bin and /mingw/bin.

??? That doesn't sound right. Did you take a look at

$ echo $PATH
.:/usr/local/bin:/mingw/bin:/bin:/c/Perl/site/bin:/c/Perl/bin:
/c/watcom-1.3/binnt:/c/watcom-1.3/binw:/c/Perl/bin/:
/c/program files/imagemagick-6.2.6-q16:/c/Program Files/tla:
/c/program files/aldor/bin:/c/Program Files/Java/jdk1.5.0_04/bin:
/c/watcom-1.3/binnt:/c/watcom-.3/binw:/c/texmf/miktex/bin:
/c/WINXP/system32:/c/WINXP:/c/WINXP/System32/Wbem:
/c/Program Files/axiom/mnt/windows/bin:
/c/Program Files/Common Files/GTK/2.0/bin:
/c/Program Files/gs/gs8.51/bin:/c/Program Files/GnuWin32/bin:
/c/Program Files/QuickTime/QTSystem/:/d/smlnj/bin:
/c/Program Files/Moscow ML/bin:/c/Program Files/darcsdir-w32:
/c/Mercurial:/c/Program Files/Subversion/bin:
/c/Program Files/Aldor/bin:/c/Program Files/Aldor/bin:
.:/mingw/bin

MSYS looks in a lot of places besides /bin and /mingw/bin.
If ActivePerl is in your windows PATH, it will be accessible
to MSYS.

But if you have /bin/perl installed it will be found by MSYS
first before ActivePerl.

> Now, I tried to install autoconf-2.60 -- I explained
> why I cannot require autoconf-2.61; more on this below.

Ok.

> Except the build goes into infinite loop, so that I never
> get a functional build.
>

If your perl returns:

> > $ perl --version
> >
> > This is perl, v5.6.1 built for msys

then that seems very strange. It works for me. And if I rename
/bin/perl  to something else (and thereby use ActivePerl from
windows), it fails that way you said it does for you.

> ...
> But I already have MSYS pre-packaged components from mingw.org!
>

So you are running "perl, v5.6.1 built for msys" or not?

> > Just because other people get away with using ActivePerl
> > with minGW doesn't make it a "supported configuration" or good
> > idea.
>
> Definitely, my reading of the mingw documentation from mingw
> website is that ActivePerl is a "supported configuration".
> But again, that point is moot by now.  Even old Perl from
> msys does not get me install Autoconf-2.60.
>
> ...
> >
> > MSYS is not a linux distro by any imagination but I think the
> > same principle applies.
>
> Which implies that I should not even try your suggestion of
> installing Autoconf-2.61 from a non-officially supported third
> party.  I don't think your statements are coherent.

By your rules you would only do this if you had no other choice.
What choice do you have? If you want to abandon Windows development
for build-improvements, fine, it's your choice. But would still
try to encourage you to continue.

>
> Bill -- again, building Autoconf-2.60 does not work on the
> "virgin" msys/mingw fails as an infinite loop.
>

Very odd. I works fine for me:

--------
$ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz

$ tar xzvf autoconf-2.60.tar.gz
$ perl --version

This is perl, v5.6.1 built for msys

Copyright 1987-2001, Larry Wall

Perl may be copied only under the terms of either the Artistic License =
or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to =
the
Internet, point your browser at http://www.perl.com/, the Perl Home =
Page.

$ cd autoconf-2.60

$ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether /bin/sh -n is known to work... yes
checking for expr... /bin/expr
checking for gm4... no
checking for gnum4... no
checking for m4... /bin/m4
checking whether m4 supports frozen files... yes
checking for perl... /bin/perl
checking for emacs... no
checking for xemacs... no
checking for emacs... no
checking where .elc files should go... ${datadir}/emacs/site-lisp
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
configure: creating ./config.status
config.status: creating config/Makefile
config.status: creating tests/Makefile
config.status: creating tests/atlocal
config.status: creating man/Makefile
config.status: creating lib/emacs/Makefile
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating lib/Makefile
config.status: creating lib/Autom4te/Makefile
config.status: creating lib/autoscan/Makefile
config.status: creating lib/m4sugar/Makefile
config.status: creating lib/autoconf/Makefile
config.status: creating lib/autotest/Makefile
config.status: creating bin/Makefile
config.status: executing tests/atconfig commands

$ make
Making all in bin
make[1]: Entering directory `/home/Administrator/autoconf-2.60/bin'
rm -f autom4te autom4te.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e =
's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated =
from
autom4te.in; do not edit by hand.|g' `test -f ./autom4te.in || echo
./`autom4te.in >autom4te.tmp
chmod +x autom4te.tmp
chmod a-w autom4te.tmp
mv autom4te.tmp autom4te
cd ../lib && make  autom4te.cfg
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib'
rm -f autom4te.cfg autom4te.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e =
's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' ./autom4te.in >autom4te.tmp
chmod a-w autom4te.tmp
mv autom4te.tmp autom4te.cfg
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib'
cd ../lib/m4sugar && make  version.m4
make[2]: Entering directory =
`/home/Administrator/autoconf-2.60/lib/m4sugar'
{                                       \
  echo '# This file is part of -*- Autoconf -*-.'; \
  echo '# Version of Autoconf.'; \
  echo '# Copyright (C) 1999, 2000, 2001, 2002'; \
  echo '# Free Software Foundation, Inc.'; \
  echo ;\
  echo 'm4_define([m4_PACKAGE_NAME],      [GNU Autoconf])'; \
  echo 'm4_define([m4_PACKAGE_TARNAME],   [autoconf])'; \
  echo 'm4_define([m4_PACKAGE_VERSION],   [2.60])'; \
  echo 'm4_define([m4_PACKAGE_STRING],    [GNU Autoconf 2.60])'; \
  echo 'm4_define([m4_PACKAGE_BUGREPORT], [bug-autoconf@gnu.org])'; \
} >version.m4
make[2]: Leaving directory =
`/home/Administrator/autoconf-2.60/lib/m4sugar'
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
../bin/autom4te -B '..'/lib -B '..'/lib         --language M4sh --cache =
''
--melt ./autoconf.as -o autoconf.in
rm -f autoconf autoconf.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e =
's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated =
from
autoconf.in; do not edit by hand.|g' `test -f ./auto
conf.in || echo ./`autoconf.in >autoconf.tmp
chmod +x autoconf.tmp
chmod a-w autoconf.tmp
mv autoconf.tmp autoconf
rm -f autoheader autoheader.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e =
's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated =
from
autoheader.in; do not edit by hand.|g' `test -f ./autoheader.in || echo
./`autoheader.in >autoheader.tmp
chmod +x autoheader.tmp
chmod a-w autoheader.tmp
mv autoheader.tmp autoheader
rm -f autoreconf autoreconf.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e =
's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated =
from
autoreconf.in; do not edit by hand.|g' `test -f ./autoreconf.in || echo
./`autoreconf.in >autoreconf.tmp
chmod +x autoreconf.tmp
chmod a-w autoreconf.tmp
mv autoreconf.tmp autoreconf
rm -f ifnames ifnames.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e =
's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated =
from
ifnames.in; do not edit by hand.|g' `test -f ./ifnames.in || echo
./`ifnames.in >ifnames.tmp
chmod +x ifnames.tmp
chmod a-w ifnames.tmp
mv ifnames.tmp ifnames
rm -f autoscan autoscan.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e =
's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated =
from
autoscan.in; do not edit by hand.|g' `test -f ./autoscan.in || echo
./`autoscan.in >autoscan.tmp
chmod +x autoscan.tmp
chmod a-w autoscan.tmp
mv autoscan.tmp autoscan
rm -f autoupdate autoupdate.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e
's|@datadir[@]|/usr/local/share/autoconf|g' -e =
's|@prefix[@]|/usr/local|g'
-e 's|@autoconf-name[@]|'`echo autoconf | sed 's,x,x,'`'|g' -e
's|@autoheader-name[@]|'`echo autoheader | sed 's,x,x,'`'|g' -e
's|@autom4te-name[@]|'`echo autom4te | sed 's,x,x,'`'|g' -e
's|@M4[@]|/bin/m4|g' -e 's|@AWK[@]|gawk|g' -e 's|@VERSION[@]|2.60|g' -e
's|@PACKAGE_NAME[@]|GNU Autoconf|g' -e 's|@configure_input[@]|Generated =
from
autoupdate.in; do not edit by hand.|g' `test -f ./autoupdate.in || echo
./`autoupdate.in >autoupdate.tmp
chmod +x autoupdate.tmp
chmod a-w autoupdate.tmp
mv autoupdate.tmp autoupdate
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/bin'
Making all in .
make[1]: Entering directory `/home/Administrator/autoconf-2.60'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60'
Making all in lib
make[1]: Entering directory `/home/Administrator/autoconf-2.60/lib'
Making all in Autom4te
make[2]: Entering directory =
`/home/Administrator/autoconf-2.60/lib/Autom4te'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory =
`/home/Administrator/autoconf-2.60/lib/Autom4te'
Making all in m4sugar
make[2]: Entering directory =
`/home/Administrator/autoconf-2.60/lib/m4sugar'
autom4te_perllibdir='../..'/lib =
AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib
\
        --language=m4sugar                      \
        --freeze                        \
        --output=m4sugar.m4f
autom4te_perllibdir='../..'/lib =
AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib
\
        --language=m4sh                 \
        --freeze                        \
        --output=m4sh.m4f
make[2]: Leaving directory =
`/home/Administrator/autoconf-2.60/lib/m4sugar'
Making all in autoconf
make[2]: Entering directory =
`/home/Administrator/autoconf-2.60/lib/autoconf'
autom4te_perllibdir='../..'/lib =
AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib
\
        --language=autoconf                     \
        --freeze                        \
        --output=autoconf.m4f
make[2]: Leaving directory =
`/home/Administrator/autoconf-2.60/lib/autoconf'
Making all in autotest
make[2]: Entering directory =
`/home/Administrator/autoconf-2.60/lib/autotest'
autom4te_perllibdir='../..'/lib =
AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib
\
        --language=autotest                     \
        --freeze                        \
        --output=autotest.m4f
make[2]: Leaving directory =
`/home/Administrator/autoconf-2.60/lib/autotest'
Making all in autoscan
make[2]: Entering directory =
`/home/Administrator/autoconf-2.60/lib/autoscan'
echo '# Automatically Generated: do not edit this file' >autoscan.list
sed '/^[#]/!q' ./autoscan.pre                  >>autoscan.list
( \
  sed -n '/^[^#]/p' ./autoscan.pre; \
  autom4te_perllibdir='../..'/lib =
AUTOM4TE_CFG='../../lib/autom4te.cfg'
../../bin/autom4te -B '../..'/lib -B '../..'/lib         --cache '' -M =
-l
autoconf -t'AN_OUTPUT:$1: $2          $3' \
) | LC_ALL=C sort                                      >>autoscan.list
make[2]: Leaving directory =
`/home/Administrator/autoconf-2.60/lib/autoscan'
Making all in emacs
make[2]: Entering directory =
`/home/Administrator/autoconf-2.60/lib/emacs'
WARNING: Warnings can be ignored. :-)
if test "no" != no; then \
  set x; \
  list='autoconf-mode.el autotest-mode.el'; for p in $list; do \
    if test -f "$p"; then d=; else d="./"; fi; \
    set x "$@" "$d$p"; shift; \
  done; \
  shift; \
  EMACS="no" /bin/sh ../../config/elisp-comp "$@" || exit 1; \
else : ; fi
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib/emacs'
make[2]: Entering directory `/home/Administrator/autoconf-2.60/lib'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/home/Administrator/autoconf-2.60/lib'
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/lib'
Making all in config
make[1]: Entering directory `/home/Administrator/autoconf-2.60/config'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/config'
Making all in man
make[1]: Entering directory `/home/Administrator/autoconf-2.60/man'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/man'
Making all in doc
make[1]: Entering directory `/home/Administrator/autoconf-2.60/doc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/doc'
Making all in tests
make[1]: Entering directory `/home/Administrator/autoconf-2.60/tests'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/Administrator/autoconf-2.60/tests'

---------

>
> I move from Autoconf-2.5x to Autoconf-2.60 because:
>   (1) it does fix a bug, that turns out to be serious in later
>       development for Axiom (partly because of some bugs in Axiom).
>   (2) all my development machines have Autoconf-2.60 installed
>       (prepackages with the linux distribution).
>
> As I see this, I can the reasonable choice for me is to stop any
> work related to Axiom on windows; that save me valuable time, and
> probably spares me from unwarranted unhelpful characterizations
> and moralization.

Your choice. Maybe you can wait until someone produces an MSYS
developer package with 2.60 pre-installed. Again I apologize for
my "unwarranted unhelpful characterizations and moralization".
I have no excuse except to observe that it is common human failing.

> If people care about Axiom on windows, they will find resources
> to get it happen.

I doubt that very much. All that is likely to happen is that they
will dismiss Axiom as uninteresting. Consider for example Martin's
recent experience with promotion of his guess package for Axiom.
My current goal is to produce a version of Axiom for windows that
has this (and other bug fixes by Waldek) pre-installed. Right now
build-improvements is the best tool to accomplish this. Porting
upstream build-improvement changes to wh-sandbox seems very
difficult, so I am currently looking at pulling what's needed from
wh-sandbox back into build-improvements. The changes in the
wh-sandbox algebra build makes this just a little tricky in the
case of the guess package. I would also like to pull the changes
for the algebra build since it avoids embedding Lisp into the
algebra files, but I think I'll tackle that second (or wait for
someone else to do it).

> I'm done.

I'm sorry to hear that. :-(

\start
Date: Mon, 16 Apr 2007 15:28:02 -0400
From: Bill Page
To: Tim Daly
Subject: RE: comment

On April 16, 2007 1:09 PM Tim Daly wrote:
> 
> As I recall the whole Axiom project spent a considerable amount
> of effort trying to resolve the SVN problem. You did a great
> job trying to set up SVN on axiom-developer (successfully?) and
> Google (unsuccessfully). 

I never completed the full setup of the SVN server component on
axiom-developer because that required an upgrade to Apache and
our current Apache configuration file does not work automatically
under the new version of Apache. Some small changes are required
and more testing, but I did not complete this yet. It no longer
seemed important once the problems with SourceForge were solved.

The problem with Google is different because we kept tripping
up on the repository size constraint even after they increased
the limit by about a factor of 4. This could be solved if we
decided to abandon a lot of the history which involves a lot
of unnecessary duplication etc. Again this could be done if any
really had any interest in it.

> 
> I eventually experimented with other systems. You advocated
> darcs and mercurial as I remember. I looked at darcs but my
> investigations, and I believe your comments, left me with the
> impression that it is not ready for a full, large projects.
> I did not try mercurial.

In fact both are used on projects about the size of Axiom and we
have both darcs and mercurial mirrors of the build-improvements
branch on axiom-developer.org.

> 
> SVN times out on me and I have to do a checkout+12update cycle
> to get a full axiom copy. Checkin takes over half an hour. SVN
> uses twice the space of the Axiom distribution. It all feels
> slow, ponderous, and heavy. And SVN wedges, demanding I "cleanup",
> which never succeeds.
>

That was exactly my own experience with SVN up until December
of last year. At that time SourceForge provided a new url for
SVN access that solved the problem. See:

http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00156.html

I have no problems using SVN on Linux and on Windows for either
of the locations where I work on Axiom since that time.
 
> I eventually tried git. Checkout and checkin over the network
> take about the same time as a local disk-to-disk copy. It uses
> only a tiny amount of additional disk space. I like it so much
> that I've moved all of my research work into git and use it for
> normal work purposes.

>From my experience, git and mercurial are very similar in speed,
storage requirements and even commands. darcs is slower (not that
much slower) and provides much finer grain patch control for
merge and for cherry-picking.

> 
> So, yes, you did reproduce my SVN problems and you discussed how
> to solve my problems. However, SVN itself has problems (slow,
> unreliable, and large) which have no solution. The question
> wasn't "can it be made to work" but rather "why waste the time
> and space".
>

I do not think it is slow or unreliable since we got the new url
from SourceForge, but of course we cannot do anything about it's
size. The main reason to put up with the waste of time and space
is for the sake of cooperation with other developers who just as
unwilling to change. Somebody has to compromise or the result is
the current situation.
 
> Git is the best technical solution, thus I use git. 
> To me, that's progress.
> 

To me, progress occurs when we manage to cooperate and work
smoothly together to achieve a common goal.

\start
Date: Mon, 16 Apr 2007 15:43:08 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Axiom HyperDoc Replacement
Cc: Kai Kaminski

On April 16, 2007 5:44 AM Martin Rubey wrote:
>
> I'm a little frustrated with work, so I started to mess
> around with mangling docstrings.
>
> unfortunately, Kai is not answering... But maybe you can
> help.

I'll try.

>
> I need the following (please keep in mind that I know little
> html, and nearly no javascript, so I really depend on you)

Ok.

>
> I would like to communicate between a browser and axiom.
> More precisely, I would like to send a single command like
>
> getHtmlDocumentation("stretch")
>
> from the browser to axiom, and present the result in the
> browser, maybe in a separate frame, but that's probably a
> detail. The result will be a (long) string containing html code,
> like:
> ...
> (possibly I can modify tex4ht output a little in order to make
> it more concise...)
>
> I know of the email
>
> =
http://lists.nongnu.org/archive/html/axiom-developer/2005-04/msg00141.htm=
l
> but it looks rather complicated at the moment.

Running the web server code written in Lisp or Boot inside
Axiom is certainly a possibility. For ideal results we would
need someone (like Kai) who is sufficiently fluent in Lisp.
The interface with the rest of Axiom is quite simple using
some other details provided in an email form Tim Daly about
the same time.

I would rather like to work this one out in detail but I
would require some fairly direct help with the Lisp coding.

> Moreover, it is absolutely necessary that it runs on Windows.

Aw, the hard part ... ;-)

Another alternative would be to write a script in Python or
Perl which prepares the input from the browser, starts
Axiom, runs the input, collects the output and sends it to
the browser. This could either be a stand alone script that
includes built-in web server support or it could be written
as a cgi script to be called from a webserver such as apache.

The latter method is essentially the method used by the
MathAction interface on the Axiom wiki. I recall that there
is a small problem with the way Python starts AXIOMsys that
prevents this from running easily under Windows (since "pipe"
support on Windows is very different than Linux), but I think
this could be solved - which would also be interesting since
it would then permit us to run MathAction on Windows as one
option for user interface to Axiom with browser support
similar to hyperdoc. (This is possible now under linux).

\start
Date: 16 Apr 2007 21:49:19 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Bill Page writes:

> Another alternative would be to write a script in Python or Perl which
> prepares the input from the browser, starts Axiom, runs the input, collects
> the output and sends it to the browser. This could either be a stand alone
> script that includes built-in web server support or it could be written as a
> cgi script to be called from a webserver such as apache.

OK, if that's easier, could you tell me how to make something that looks like a
link in the browser, like "doit", starts a script which echoes some html code,
and renders this code again. 

This stuff should run without administrator or root privileges.

It's just to show that it works.  More elegant solutions can be implemented by
those who know later.

\start
Date: Mon, 16 Apr 2007 18:56:38 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: differences wh-sandbox andbuild-improvements

Quoting Bill Page:

> On April 16, 2007 12:22 PM wrote:
>> 
>> Quoting Bill Page:
>> 
>> > On April 16, 2007 3:32 AM Gaby wrote:
>> >
>> >>
>> >> I have a functional development environment under windows
>> >> -- cygwin -- but I cannot use it because GCL does not work
>> >> under cygwin
>> >
>> > What do you mean that GCL does not work under cygwin? It works
>> > for me. You just can't compile it under cygwin.
>> 
>> That means the same thing for me: If I cannot compile it under
>> cygwin, it does not work for me as far as Axiom development is
>> concerned.
>>
>
> Why not? It is not necessary to build gcl as part of the Axiom
> build - just install the windows binary for gcl, like other users
> Windows do.

  (1) but I'm not like other windows users;  I'm doing something
      to Axiom that most of them -- if I understand your previous
      postings correctly.  I'm doing changes to Axiom, and I need
      to make sure that what was previously working (build Axiom
      with or without bundled GCL) is still working.

  (2) you would have to assume that although I'm facing build issues, I'm
      not totally dumb and there are reasons why I need to do what I'm
      doing, i.e. building GCL.
      Otherwise, I feel like after wasting time fighting the build
      issues under windows itself, I'm wasting time at being convinced
      that I really do not have time to waste on windows issues.

      What I'm looking for is way to get forward, given the constraints
      I enounciated.  I need automake-2.60 working, I need the ability
      to compile GCL, among other things.  If you know of no way that would
      let me do those, that is fine.  But, please don't waste time arguing
      why I need to compile GCL.

      I need to compile GCL as long as that is the only supported Lisp
      system.


[...]

>> 
>> What I want is to have a reasonable development under windows
>> -- whether it is mingw or cygwin, I don't care much.  The only
>> thing I care about is that the environment does not disrupt
>> me much from doing actual work.
>>
>
> MSYS/minGW works for me.

yes, I believed you.  The trouble is that it is not working for
me at the moment.  So, the fact that it works for you is good,
but at moment it does not help me make forward progress.

> 
>> >> I guess the fact that windows people on this list don't
>> >> help that much to make concrete forward progress is OK.
>> >
>> > I think that is typical.
>> 
>> OK; I believe the logical conclusion for me is probably that
>> I drop any work on Axiom on windows.
>
> Your choice.

Indeed.  If I had infinite amount of time, I may continue this
"windows entertainment", but I haven't.  And I don't have time for
infinite argumentation either.

>
>> 
>> Granted you can reproduce the problems, but the solution you
>> suggested did not work for me. I moved ActivePerl's path away
>> from /bin and /mingw/bin.
>
> ??? That doesn't sound right. Did you take a look at

I hoped it does not sound right.  But, that is what I'm experiencing.
[...]

>
> MSYS looks in a lot of places besides /bin and /mingw/bin.

I know that; I may be clueless at how to solve the issue I'm
facing currently, but I'm exactly newbie in program and system
development.  I need a help that is more than "basic".

> If ActivePerl is in your windows PATH, it will be accessible
> to MSYS.

But, never used if its path is after /bin, where MSYS's perl resides.

>
> But if you have /bin/perl installed it will be found by MSYS
> first before ActivePerl.
>

I know that.  I need more than "101" stuff.

[...]

> If your perl returns:
>
>> > $ perl --version
>> >
>> > This is perl, v5.6.1 built for msys
>
> then that seems very strange. It works for me. And if I rename
> /bin/perl  to something else (and thereby use ActivePerl from
> windows), it fails that way you said it does for you.

I believed you when you said it worked for you.  I did believe there
was a way to get everything working -- that is why I originally said
that I was looking for a way to get a reasonable build environment
set up.  If you can't trust me, you can't help me :-)


>
>> ...
>> But I already have MSYS pre-packaged components from mingw.org!
>>
>
> So you are running "perl, v5.6.1 built for msys" or not?

yes -- if that was not clear, yes, yes, yes, yes.

[...]
>> >
>> > MSYS is not a linux distro by any imagination but I think the
>> > same principle applies.
>> 
>> Which implies that I should not even try your suggestion of
>> installing Autoconf-2.61 from a non-officially supported third
>> party.  I don't think your statements are coherent.
>
> By your rules you would only do this if you had no other choice.
> What choice do you have?

(1) stop sinking my time in this windows+axiom black hole
(2) get a way to get a reasonable build environment.

> If you want to abandon Windows development
> for build-improvements, fine, it's your choice. But would still
> try to encourage you to continue.

so far, I've seen more "discouragement"; sorry to put it that way.
But, I'm sure there people on this list that can sort this out, so
my not working anymore on windows+axiom is not a big deal.

>
>> 
>> Bill -- again, building Autoconf-2.60 does not work on the
>> "virgin" msys/mingw fails as an infinite loop.
>>
>
> Very odd. I works fine for me:
>
> --------
> $ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz
>

The "wget" that comes with msys/ming packaged does not work for me.
So I use ncftp to download tarballs.  I don't believe that changes
anything though.

> $ tar xzvf autoconf-2.60.tar.gz
> $ perl --version
>
> This is perl, v5.6.1 built for msys

as I said, I already have that.

>
> $ ./configure

this works fine.

> $ make

this step, attempts to install things for me (which I was
surprised of), and goes into infinite loop.  There is no way
to effectively stop the build, except killing the msys shell
itself.

>
>> 
>> I move from Autoconf-2.5x to Autoconf-2.60 because:
>>   (1) it does fix a bug, that turns out to be serious in later
>>       development for Axiom (partly because of some bugs in Axiom).
>>   (2) all my development machines have Autoconf-2.60 installed
>>       (prepackages with the linux distribution).
>> 
>> As I see this, I can the reasonable choice for me is to stop any
>> work related to Axiom on windows; that save me valuable time, and
>> probably spares me from unwarranted unhelpful characterizations
>> and moralization.
>
> Your choice. Maybe you can wait until someone produces an MSYS
> developer package with 2.60 pre-installed. Again I apologize for
> my "unwarranted unhelpful characterizations and moralization".
> I have no excuse except to observe that it is common human failing.

apologies accepted.
>
>> If people care about Axiom on windows, they will find resources
>> to get it happen.
>
> I doubt that very much. All that is likely to happen is that they
> will dismiss Axiom as uninteresting.

then, I'm afraid Axiom is effectively uninteresting to them.  If the
Axiom community coming from windows users cannot find developers from
that community that understands them better than I do, it is unlikely
that Axiom will ever be of use to them.  Interested people usually
put their money whether their month is.

> Consider for example Martin's
> recent experience with promotion of his guess package for Axiom.

I'm sorry for Martin.

What I've learnt over the years working on several projects (usually
open source) and the C++ language is that if something is of interest
to you better make sure that you invest enough effort to meet the
interest.  It is unlikely that just waiting for something to happen
will effectively make that thing happen.  That certainly partly
explains, apart from natural research curiosity, why I spend resources
working on Axiom.

> My current goal is to produce a version of Axiom for windows that
> has this (and other bug fixes by Waldek) pre-installed. Right now
> build-improvements is the best tool to accomplish this.

I was hoping to make it better, but I faced issues and I did not find
the kind of resources that would help me make progress.  I do hope
someone in this community has better chance that I.

\start
Date: Mon, 16 Apr 2007 21:03:37 -0500
From: Tim Daly
To: Bill Page, Alfredo Portes, Martin Rubey
Subject: browser

> Another alternative would be to write a script in Python or
> Perl which preparse the input from the browser, starts 
> Axiom, runs the input, collects the output and sends it to
> the browser.

Jose already has this working in Doyen.
I'm sure he could help.

\start
Date: Tue, 17 Apr 2007 00:52:04 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: differences wh-sandbox andbuild-improvements

On April 16, 2007 7:57 PM Gaby wrote:
> ... 
> > $ make
> 
> this step, attempts to install things for me (which I was
> surprised of), and goes into infinite loop.  There is no way
> to effectively stop the build, except killing the msys shell
> itself.
>

It would be very useful to me if you could include some actual
output cut-and-paste from your attempt.

Obviously this behaviour of make is very bizarre. I do not see
any attempt to install things when I run make (as the output
in my last email showed). Of course it does later if I run
'make install'.  Therefore something rather fundamental must
be different between your configuration and mine.

Does your Makefile start like this?

# Makefile.in generated by automake 1.9.6 from Makefile.am.
# Makefile.  Generated from Makefile.in by configure.
...

Does your output from make at least start like this (before
it goes into a loop)?

Making all in bin
make[1]: Entering directory `/home/Administrator/autoconf-2.60/bin'
rm -f autom4te autom4te.tmp
sed -e 's|@SHELL[@]|/bin/sh|g' -e 's|@PERL[@]|/bin/perl|g' -e
's|@bindir[@]|/usr/local/bin|g' -e

...

I.e. a normal recursive make?

So far I can only think of 3 possible causes:

1) Makefile is corrupt

   - What version of tar do you use?

     mine: 

     $ tar --version
     tar (GNU tar) 1.13.19

   - Windows line endings (cr)

     only Unix line endings are expected

2) Different version of make?

   mine:

   $ make --version
   GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.

3) Different shell?

   mine:

   $ sh --version    
   GNU bash, version 2.04.0(1)-release (i686-pc-msys)
   Copyright 1999 Free Software Foundation, Inc.

Perhaps 2 and 3 are already ruled out since apparently both you
and I can build gcl and Axiom from build-improvements without
any problem.

Stunned.

\start
Date: Tue, 17 Apr 2007 15:11:15 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: NE with bootsys (build-improvements)

Hello,

The file interop.boot is incorrectly translated by bootsys because of
the use of 'NE'. 'NE' is translated to '(not (equal' by depsys but
bootsys translate it to '(/='.

You can trigger this bug if you issue in the interpreter:

x^(1/7)

Don't know if there are similar bugs in other parts of the interpreter.


There is another thing with build-improvements, with this sequence of
commands:

-------------------------------------------------------------------------------------
mkdir /home/greg/axiom-build-improvements
lndir /home/greg/TDevel/axiom.build-improvements /home/greg/axiom-build-improvements/
cd /home/greg/axiom-build-improvements/
./configure --enable-checking --prefix=/home/greg/axiom.bi.debug
make && make install
-------------------------------------------------------------------------------------

the file /home/greg/axiom.bi.debug/bin is the axiom script (and not a
directory).

\start
Date: Wed, 18 Apr 2007 03:17:12 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Duplicate argument in testInterpolant

The function testInterpolant in guessing package has the following
header:

testInterpolant(resi: List SUP S,
                list: List F,
                testList: List UFPSSUPF,
                exprList: List EXPRR,
                initials: List EXPRR,
                guessDegree: NNI,
                D: HPSPEC,
                dummy: Symbol, op: BasicOperator, options: LGOPT,
                list: List F)
               : Union("failed", Record(function: EXPRR, order: NNI))

In particular the parameter 'list' is repeated twice.  AFAICS Spad
does not allow overloading of parameter names and even if such
overloading is allowed the header still have problem because
types are identical.

BTW: I found the problem because generated Lisp also have duplicate
argument and SBCL chokes on it (GCL did not complain).

\start
Date: 18 Apr 2007 06:53:34 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Duplicate argument in testInterpolant

Waldek Hebisch writes:

> The function testInterpolant in guessing package has the following
> header:
> 
> testInterpolant(resi: List SUP S,
>                 list: List F,
>                 testList: List UFPSSUPF,
>                 exprList: List EXPRR,
>                 initials: List EXPRR,
>                 guessDegree: NNI,
>                 D: HPSPEC,
>                 dummy: Symbol, op: BasicOperator, options: LGOPT,
>                 list: List F)
>                : Union("failed", Record(function: EXPRR, order: NNI))
> 
> In particular the parameter 'list' is repeated twice.  AFAICS Spad
> does not allow overloading of parameter names and even if such
> overloading is allowed the header still have problem because
> types are identical.
> 
> BTW: I found the problem because generated Lisp also have duplicate
> argument and SBCL chokes on it (GCL did not complain).

sorry, I thought this was already on the list (with the obvious patch).  I'll
send you an updated version of the package (I think Greg pointed out also some
other typos) within two hours or so.

Does this mean that you have axiom with sbcl running?

\start
Date: Wed, 18 Apr 2007 11:44:03 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Duplicate argument in testInterpolant

Martin Rubey wrote:
> Waldek Hebisch writes:
> 
> > The function testInterpolant in guessing package has the following
> > header:
> > 
> > testInterpolant(resi: List SUP S,
> >                 list: List F,
> >                 testList: List UFPSSUPF,
> >                 exprList: List EXPRR,
> >                 initials: List EXPRR,
> >                 guessDegree: NNI,
> >                 D: HPSPEC,
> >                 dummy: Symbol, op: BasicOperator, options: LGOPT,
> >                 list: List F)
> >                : Union("failed", Record(function: EXPRR, order: NNI))
> > 
> > In particular the parameter 'list' is repeated twice.  AFAICS Spad
> > does not allow overloading of parameter names and even if such
> > overloading is allowed the header still have problem because
> > types are identical.
> > 
> > BTW: I found the problem because generated Lisp also have duplicate
> > argument and SBCL chokes on it (GCL did not complain).
> 
> sorry, I thought this was already on the list (with the obvious patch).  I'll
> send you an updated version of the package (I think Greg pointed out also some
> other typos) within two hours or so.
> 

Could you commit updates to SVN archive?

> Does this mean that you have axiom with sbcl running?
> 
>

I am in the process of merging sbcl support into wh-sandbox.
ATM algebra compiled, but I am getting errors during database
build.  I did not try any serous tests yet, so I expect a lot
more problems.  And to have fully functional Axiom we need mere
code (especially sockets).

\start
Date: Wed, 18 Apr 2007 11:59:30 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: differences wh-sandbox andbuild-improvements
Cc: Gabriel Dos Reis

Bill Page wrote:
> Why not? It is not necessary to build gcl as part of the Axiom
> build - just install the windows binary for gcl, like other users
> Windows do.
>

Is there a binary version of gcl suitable for Axiom developement?
The latest binary I see is 2.6.6, but AFAIK with 2.6.6 we are
getting errors which vanish if we use 2.6.7 or 2.6.8.

Also, can one install gcl without affecting existing Mingw
installation (the gcl readme claims that on Windows gcl
need a specific, rather old Mingw version -- for me
downgrading Mingw is not an option)?

\start
Date: Wed, 18 Apr 2007 12:35:40 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: differences wh-sandbox andbuild-improvements
Cc: Camm Maguire, Gabriel Dos Reis

On April 18, 2007 6:00 AM Waldek Hebisch wrote:
> 
> Bill Page wrote:
> > Why not? It is not necessary to build gcl as part of the Axiom
> > build - just install the windows binary for gcl, like other
> > users Windows do.
> >
> 
> Is there a binary version of gcl suitable for Axiom developement?
> The latest binary I see is 2.6.6, but AFAIK with 2.6.6 we are
> getting errors which vanish if we use 2.6.7 or 2.6.8.

You are right and what I wrote above is wrong. Gaby also has
pointed out that it is not currently realistic to depend on the
GCL binaries on Windows for Axiom development.

As far as I can tell no one has posted any binaries for GCL on
windows newer than

  gcl_2.6.6.mingw32_cltl1_japi_20050210.exe 22-Mar-2005

at

  http://ftp.gnu.org/gnu/gcl/binaries/stable

And gcl-2.6.8pre is still a "pre-release". I guess the gcl
project is also critally lacking in resources. If it would be
helpful I could certainly upload a windows binary of this
pre-release to the Axiom Wiki web site. But I am discouraged
also by Gaby's observation that there does not seem to be much
interest in development of the Windows versions of GCL or
Axiom. :-(

> 
> Also, can one install gcl without affecting existing Mingw
> installation (the gcl readme claims that on Windows gcl
> need a specific, rather old Mingw version -- for me
> downgrading Mingw is not an option)?
> 

MinGW is required in order to compile Lisp to object code and
of course to compile the Lisp output of the SPAD compiler in
Axiom. Unlike Linux, it is not correct to assume that a C
compiler is available in the basic window installation. The
existing binary installer that I prepared for Axiom on Windows
includes the necessary parts of MinGW to permit GCL and Axiom
to compile object code. I think a similar binary installer
for GCL should include these same parts of MinGW so that the
GCL installation will be complete and fully functional.

\start
Date: Wed, 18 Apr 2007 18:32:40 -0400
From: Bill Page
To: Waldek Hebisch
Subject: Axiom sockets in SPAD
Cc: Gabriel Dos Reis

On April 18, 2007 5:44 AM Waldek Hebisch wrote:
> ... 
> I am in the process of merging sbcl support into wh-sandbox.
> ATM algebra compiled, but I am getting errors during database
> build.  I did not try any serous tests yet, so I expect a lot
> more problems.  And to have fully functional Axiom we need
> more code (especially sockets).
> 

I have been thinking about socket support in Axiom and
extending that to SPAD as described here:

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

If we could support sockets at the level of SPAD, it would
be very easy to write web server based interfaces such as
discussed recently by Martin.

I would be very interested in any help and advice you can
give me on how to make this work.

\start
Date: Wed, 18 Apr 2007 20:42:00 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Lisp macro fun...

--0-1783017166-1176954120=:28034

I have been attempting to generalize Waldek's finite state machine
using macros, and have essentially run up against the limits of my tiny
Lisp skills.  Can anybody tell me how to get this thing to expand into
something like Waldek's code?  (I can provide the whole file if it is
needed.)

Thanks,
Cliff

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-1783017166-1176954120=:28034

KGRlZm1hY3JvIGdlbmVyYXRlLXNjYW4tZnVuY3Rpb24gKCkKICBgKGRlZnVu
IHNjYW4tZm9yLWNodW5rcyAoYnVmZikKICAgIChkZWNsYXJlIChvcHRpbWl6
ZSAoc3BlZWQgMykpKQogICAgKHByb2cgKAoJICAgKHBvcyAtMSkKCSAgIChl
bmQtYnVmZiAoLSAoYXJyYXktZGltZW5zaW9uIGJ1ZmYgMCkgMSkpCgkgICAo
c3RhcnQtcG9zKQoJICAgKGNvZGUpCgkgICAoY2h1bmstbmFtZSkKCSAgIChj
b250ZW50IG5pbCkKCSAgIChjaHVuay1zdGFydC1wb3MpCgkgICAoY2h1bmst
ZW5kLXBvcykKCSAgIChsaW5lLW51bWJlciAwKSkKICAgICAgIChkZWNsYXJl
ICh0eXBlIChzaWduZWQtYnl0ZSAzMikgcG9zIGVuZC1idWZmIGxpbmUtbnVt
YmVyKQoJCSh0eXBlIChzaW1wbGUtYXJyYXkgKHVuc2lnbmVkLWJ5dGUgIDgp
ICgqKSkgYnVmZikpCiAgICAgICBub3JtYWwtc3RhcnQKICAgICAgIChpbmNm
IHBvcykKICAgICAgIChpbmNmIGxpbmUtbnVtYmVyKQogICAgICAgKGlmICg+
PSBwb3MgZW5kLWJ1ZmYpCgkgICAocmV0dXJuLWZyb20gc2Nhbi1mb3ItY2h1
bmtzKSkKICAgICAgIChzZXRmIGNvZGUgKGFyZWYgYnVmZiBwb3MpKQogICAg
ICAgLEAoaWYgKD0gMSAobGVuZ3RoIGNodW5rLXN0YXJ0LWRlbGltaXRlcikp
CgkgICAgIGAoKGlmIChlcWwgY29kZSBzdGFydC1jaHVuay1jaGFyLTEpCgkJ
ICAgKHByb2duCgkJICAgICAoc2V0ZiBzdGFydC1wb3MgKCsgcG9zIDEpKQoJ
CSAgICAgKGdvIGluLWNodW5rLW5hbWUpICkpKQoJICAgICBgKChpZiAoZXFs
IGNvZGUgc3RhcnQtY2h1bmstY2hhci0xKQoJCSAgIChnbyBjaHVuay1zdGFy
dC10YWctMSkpKSkKICAgICAgIChpZiAoZXFsIGNvZGUgbmV3bGluZS1jb2Rl
KQoJICAgKGdvIG5vcm1hbC1zdGFydCkpCiAgICAgICAoZ28gbm9ybWFsKQog
ICAgICAgbm9ybWFsCiAgICAgICAoaW5jZiBwb3MpCiAgICAgICAoc2V0ZiBj
b2RlIChhcmVmIGJ1ZmYgcG9zKSkKICAgICAgIChpZiAoZXFsIGNvZGUgbmV3
bGluZS1jb2RlKQoJICAgKGdvIG5vcm1hbC1zdGFydCkpCiAgICAgICAoZ28g
bm9ybWFsKQogICAgICAgLEAoaWYgKD4gKGxlbmd0aCBjaHVuay1zdGFydC1k
ZWxpbWl0ZXIpIDEpCgkgICAgIChsb29wIGZvciBpIGZyb20gMiB0byAobGVu
Z3RoIGNodW5rLXN0YXJ0LWRlbGltaXRlcikgYXBwZW5kCgkJICAgKGxpc3QK
CQkgICAgKGludGVybiAoZm9ybWF0IG5pbCAiQ0hVTkstU1RBUlQtVEFHLX5B
IiAoLSBpIDEpKSB3ZWJwa2cpCgkJICAgICcoaW5jZiBwb3MpCgkJICAgICco
c2V0ZiBjb2RlIChhcmVmIGJ1ZmYgcG9zKSkKCQkgICAgKGlmICg9IGkgKGxl
bmd0aCBjaHVuay1zdGFydC1kZWxpbWl0ZXIpKQoJCQlgKChpZiAoZXFsIGNv
ZGUgLChpbnRlcm4gKGZvcm1hdCBuaWwgIlNUQVJULUNIVU5LLUNIQVItfkEi
IGkpIHdlYnBrZykpCgkJCSAgICAgIChwcm9nbgoJCQkJKHNldGYgc3RhcnQt
cG9zICgrIHBvcyAxKSkKCQkJCShnbyBpbi1jaHVuay1uYW1lKSkpKQoJCQlg
KChpZiAoZXFsIGNvZGUgLChpbnRlcm4gKGZvcm1hdCBuaWwgIlNUQVJULUNI
VU5LLUNIQVItfkEiIGkpIHdlYnBrZyApKQoJCQkgICAgICAoZ28gLChpbnRl
cm4gKGZvcm1hdCBuaWwgIkNIVU5LLVNUQVJULVRBRy1+QSIgaSkgd2VicGtn
ICkpKSkpCgkJICAgICcoaWYgKGVxbCBjb2RlIG5ld2xpbmUtY29kZSkKCQkg
ICAgICAoZ28gbm9ybWFsLXN0YXJ0KSkKCQkgICAgJyhnbyBub3JtYWwpKSkp
CiAgICAgICBpbi1jaHVuay1uYW1lCiAgICAgICAoaW5jZiBwb3MpCiAgICAg
ICAoc2V0ZiBjb2RlIChhcmVmIGJ1ZmYgcG9zKSkKICAgICAgICxAKGlmICg9
IDEgKGxlbmd0aCBjaHVuay1uYW1lLWVuZC1kZWxpbWl0ZXIpKQoJICAgICBg
KChpZiAoZXFsIGNvZGUgZW5kLW5hbWUtY2hhci0xKQoJCSAgIChwcm9nbgoJ
CSAgICAgKHNldGYgY2h1bmstbmFtZSAoc3Vic2VxIGJ1ZmYgc3RhcnQtcG9z
ICgtIHBvcyAobGVuZ3RoIGNodW5rLXJlZi1lbmQtZGVsaW1pdGVyKSkpKQoJ
CSAgICAgKGdvIGFmdGVyLWNodW5rLW5hbWUpKSkpCgkgICAgIGAoKGlmIChl
cWwgY29kZSBlbmQtbmFtZS1jaGFyLTEpCgkJICAgKGdvIGNodW5rLW5hbWUt
ZW5kLXRhZy0xKSkpKQogICAgICAgKGlmIChlcWwgY29kZSBuZXdsaW5lLWNv
ZGUpCgkgICAoZ28gbm9ybWFsLXN0YXJ0KSkKICAgICAgIChnbyBpbi1jaHVu
ay1uYW1lKQogICAgICAgLEAoaWYgKD4gKGxlbmd0aCBjaHVuay1uYW1lLWVu
ZC1kZWxpbWl0ZXIpIDEpCgkgICAgIChsb29wIGZvciBpIGZyb20gMiB0byAo
bGVuZ3RoIGNodW5rLW5hbWUtZW5kLWRlbGltaXRlcikgYXBwZW5kCgkJICAg
KGxpc3QKCQkgICAgKGludGVybiAoZm9ybWF0IG5pbCAiQ0hVTkstTkFNRS1F
TkQtVEFHLX5BIiAoLSBpIDEpKSB3ZWJwa2cpCgkJICAgICcoaW5jZiBwb3Mp
CgkJICAgICcoc2V0ZiBjb2RlIChhcmVmIGJ1ZmYgcG9zKSkKCQkgICAgKGlm
ICg9IGkgKGxlbmd0aCBjaHVuay1uYW1lLWVuZC1kZWxpbWl0ZXIpKQoJCQlg
KChpZiAoZXFsIGNvZGUgLChpbnRlcm4gKGZvcm1hdCBuaWwgIkVORC1OQU1F
LUNIQVItfkEiIGkpIHdlYnBrZykpCgkJCSAgICAgIChwcm9nbgoJCQkJKHNl
dGYgY2h1bmstbmFtZSAoc3Vic2VxIGJ1ZmYgc3RhcnQtcG9zCgkJCQkJCQkg
KC0gcG9zIChsZW5ndGggY2h1bmstcmVmLWVuZC1kZWxpbWl0ZXIpKSkpCgkJ
CQkoZ28gYWZ0ZXItY2h1bmstbmFtZSkpKSkKCQkJJygoaWYgKGVxbCBjb2Rl
IChpbnRlcm4gKGZvcm1hdCBuaWwgIkVORC1OQU1FLUNIQVItfkEiIGkpIHdl
YnBrZykpCgkJCSAgICAgIChnbyAoaW50ZXJuIChmb3JtYXQgbmlsICJDSFVO
Sy1OQU1FLUVORC1UQUctfkEiIGkpIHdlYnBrZykpKSkpCgkJICAgICcoaWYg
KGVxbCBjb2RlIG5ld2xpbmUtY29kZSkKCQkgICAgICAoZ28gbm9ybWFsLXN0
YXJ0KSkKCQkgICAgJyhnbyBub3JtYWwpKSkpCiAgICAgICBhZnRlci1jaHVu
ay1uYW1lCiAgICAgICAoaW5jZiBwb3MpCiAgICAgICAoc2V0ZiBjb2RlIChh
cmVmIGJ1ZmYgcG9zKSkKICAgICAgIChpZiAoZXFsIGNvZGUgbmV3bGluZS1j
b2RlKQoJICAgKHByb2duCgkgICAgIChzZXRmIGNodW5rLXN0YXJ0LXBvcyAo
KyBwb3MgMSkpCgkgICAgIChnbyBpbi1jaHVuaykpKQogICAgICAgKGlmIChl
cWwgY29kZSBzcGFjZS1jb2RlKQoJICAgKGdvIGFmdGVyLWNodW5rLW5hbWUp
KQogICAgICAgKGdvIG5vcm1hbCkKICAgICAgIGluLWNodW5rCiAgICAgICAo
aW5jZiBwb3MpCiAgICAgICAoc2V0ZiBjb2RlIChhcmVmIGJ1ZmYgcG9zKSkK
ICAgICAgIChpZiAoZXFsIGNvZGUgbmV3bGluZS1jb2RlKQoJICAgKGdvIGNo
dW5rLXN0YXJ0KSkKICAgICAgIChpZiAoZXFsIGNvZGUgc3RhcnQtcmVmLWNo
YXItMSkKCSAgIChnbyBzdGFydC1yZWYtdGFnLTEpKQogICAgICAgKGdvIGlu
LWNodW5rKQogICAgICAgY2h1bmstc3RhcnQKICAgICAgIChzZXRmIGNodW5r
LWVuZC1wb3MgcG9zKQogICAgICAgKGluY2YgcG9zKQogICAgICAgKGlmICg+
PSBwb3MgZW5kLWJ1ZmYpCgkgICAoYnJlYWsgInVuZXhwZWN0ZWQgZW5kIG9m
IGZpbGUiKSkKICAgICAgIChzZXRmIGNvZGUgKGFyZWYgYnVmZiBwb3MpKQog
ICAgICAgKGluY2YgbGluZS1udW1iZXIpCiAgICAgICAoaWYgKGVxbCBjb2Rl
IG5ld2xpbmUtY29kZSkKCSAgIChnbyBjaHVuay1zdGFydCkpCiAgICAgICAs
QChpZiAoPSAxIChsZW5ndGggY2h1bmstcmVmLXN0YXJ0LWRlbGltaXRlcikp
CgkgICAgIGAoKGlmIChlcWwgY29kZSBzdGFydC1yZWYtY2hhci0xKQoJCSAg
IChwcm9nbgoJCSAgICAgKHNldGYgc3RhcnQtcG9zICgrIHBvcyAxKSkKCQkg
ICAgIChnbyBpbi1jaHVuay1yZWYpKSkpCgkgICAgIGAoKGlmIChlcWwgY29k
ZSBzdGFydC1yZWYtY2hhci0xKQoJCSAgIChnbyBzdGFydC1yZWYtdGFnLTEp
KSkpCiAgICAgICAsQChpZiAoPSAxIChsZW5ndGggY2h1bmstZW5kLWRlbGlt
aXRlcikpCgkgICAgIGAoKGlmIChlcWwgY29kZSBlbmQtY2h1bmstY2hhci0x
KQoJCSAgIChwcm9nbgoJCSAgICAgKHB1c2ggKGxpc3QgY2h1bmstc3RhcnQt
cG9zIGNodW5rLWVuZC1wb3MpIGNvbnRlbnQpCgkJICAgICAoc2V0ZiBjb250
ZW50IChyZXZlcnNlIGNvbnRlbnQpKQoJCSAgICAgKGFkZC10by1jaHVuay1j
b250ZW50cyAoYXJyYXktdG8tc3RyaW5nIGNodW5rLW5hbWUpCgkJCQkJICAg
IGNvbnRlbnQpCgkJICAgICAoc2V0ZiBjb250ZW50IG5pbCkKCQkgICAgIChn
byBhZnRlci1jaHVuay1ib2R5KSkpKQoJICAgICBgKChpZiAoZXFsIGNvZGUg
ZW5kLWNodW5rLWNoYXItMSkKCQkgICAoZ28gZW5kLWNodW5rLXRhZy0xKSkp
KQogICAgICAgKGdvIGluLWNodW5rKQogICAgICAgLEAoaWYgKD4gKGxlbmd0
aCBjaHVuay1lbmQtZGVsaW1pdGVyKSAxKQoJICAgICAobG9vcCBmb3IgaSBm
cm9tIDIgdG8gKGxlbmd0aCBjaHVuay1lbmQtZGVsaW1pdGVyKSBhcHBlbmQK
CQkgICAobGlzdAoJCSAgICAoaW50ZXJuIChmb3JtYXQgbmlsICJFTkQtQ0hV
TkstVEFHLX5BIiAoLSBpIDEpKSB3ZWJwa2cpCgkJICAgICcoaW5jZiBwb3Mp
CgkJICAgICcoc2V0ZiBjb2RlIChhcmVmIGJ1ZmYgcG9zKSkKCQkgICAgKGlm
ICg9IGkgKGxlbmd0aCBjaHVuay1lbmQtZGVsaW1pdGVyKSkKCQkJYChpZiAo
ZXFsIGNvZGUgLChpbnRlcm4gKGZvcm1hdCBuaWwgIkVORC1DSFVOSy1DSEFS
LX5BIiBpKSB3ZWJwa2cpKQoJCQkgIChwcm9nbgoJCQkgICAgKHB1c2ggKGxp
c3QgY2h1bmstc3RhcnQgcG9zIGNodW5rLWVuZC1wb3MpIGNvbnRlbnQpCgkJ
CSAgICAoc2V0ZiBjb250ZW50IChyZXZlcnNlIGNvbnRlbnQpKQoJCQkgICAg
KGFkZC10by1jaHVuay1jb250ZW50cyAoYXJyYXktdG8tc3RyaW5nIGNodW5r
LW5hbWUpCgkJCQkJCSAgIGNvbnRlbnQpCgkJCSAgICAoc2V0ZiBjb250ZW50
IG5pbCkKCQkJICAgIChnbyBhZnRlci1jaHVuay1ib2R5KSkpCgkJCWAoaWYg
KGVxbCBjb2RlICwoaW50ZXJuIChmb3JtYXQgbmlsICJFTkQtQ0hVTkstQ0hB
Ui1+QSIgaSkgd2VicGtnKSkKCQkJICAoZ28gLChpbnRlcm4gKGZvcm1hdCBu
aWwgIkVORC1DSFVOSy1UQUctfkEiIGkpIHdlYnBrZykpKSkKCQkgICAgJyhp
ZiAoZXFsIGNvZGUgbmV3bGluZS1jb2RlKQoJCSAgICAgIChnbyBjaHVuay1z
dGFydCkpCgkJICAgICcoZ28gaW4tY2h1bmspKSkpICAgCiAgICAgICBhZnRl
ci1jaHVuay1ib2R5CiAgICAgICAoaW5jZiBwb3MpCiAgICAgICAoc2V0ZiBj
b2RlIChhcmVmIGJ1ZmYgcG9zKSkKICAgICAgIChpZiAoZXFsIGNvZGUgbmV3
bGluZS1jb2RlKQoJICAgKGdvIG5vcm1hbC1zdGFydCkpCiAgICAgICAoaWYg
KGVxbCBjb2RlIHNwYWNlLWNvZGUpCgkgICAoZ28gYWZ0ZXItY2h1bmstYm9k
eSkpCiAgICAgICAoZm9ybWF0IHQgInBvczogfkEsIGNvZGU6IH5BfiYiIHBv
cyBjb2RlKQogICAgICAgKGJyZWFrICJnYXJiYWdlIGFmdGVyIGVuZCBvZiBj
aHVuayBtYXJrZXIiKQogICAgICAgLEAoaWYgKD4gKGxlbmd0aCBjaHVuay1y
ZWYtc3RhcnQtZGVsaW1pdGVyKSAxKQoJICAgICAobG9vcCBmb3IgaSBmcm9t
IDIgdG8gKGxlbmd0aCBjaHVuay1yZWYtc3RhcnQtZGVsaW1pdGVyKSBhcHBl
bmQKCQkgICAobGlzdAoJCSAgICAoaW50ZXJuIChmb3JtYXQgbmlsICJTVEFS
VC1SRUYtVEFHLX5BIiAoLSBpIDEpKSB3ZWJwa2cpCgkJICAgICcoaW5jZiBw
b3MpCgkJICAgICcoc2V0ZiBjb2RlIChhcmVmIGJ1ZmYgcG9zKSkKCQkgICAg
KGlmICg9IGkgKGxlbmd0aCBjaHVuay1yZWYtc3RhcnQtZGVsaW1pdGVyKSkK
CQkJYCgoaWYgKGVxbCBjb2RlICwoaW50ZXJuIChmb3JtYXQgbmlsICJTVEFS
VC1SRUYtQ09ERS1+QSIgaSkgd2VicGtnKSkKCQkJICAgICAgKHByb2duCgkJ
CQkoc2V0ZiBzdGFydC1wb3MgKCsgcG9zIDEpKQoJCQkJKGdvIGluLWNodW5r
LXJlZikpKSkKCQkJJygoaWYgKGVxbCBjb2RlIChpbnRlcm4gKGZvcm1hdCBu
aWwgIlNUQVJULVJFRi1DT0RFLX5BIiBpKSB3ZWJwa2cpKQoJCQkgICAgICAo
Z28gKGludGVybiAoZm9ybWF0IG5pbCAiU1RBUlQtUkVGLVRBRy1+QSIgaSkg
d2VicGtnKSkpKSkKCQkgICAgJyhpZiAoZXFsIGNvZGUgbmV3bGluZS1jb2Rl
KQoJCSAgICAgIChnbyBjaHVuay1zdGFydCkpCgkJICAgICcoZ28gaW4tY2h1
bmspKSkpCiAgICAgICBpbi1jaHVuay1yZWYKICAgICAgIChpbmNmIHBvcykK
ICAgICAgIChzZXRmIGNvZGUgKGFyZWYgYnVmZiBwb3MpKQogICAgICAgLEAo
aWYgKD0gMSAobGVuZ3RoIGNodW5rLXJlZi1lbmQtZGVsaW1pdGVyICkpCgkg
ICAgIGAoKGlmIChlcWwgY29kZSBlbmQtcmVmLWNoYXItMSkKCQkgICAocHJv
Z24KCQkgICAgIChwdXNoIChsaXN0IGNodW5rLXN0YXJ0LXBvcyAoLSBzdGFy
dC1wb3MgMikpIGNvbnRlbnQpCgkJICAgICAocHVzaCAoYXJyYXktdG8tc3Ry
aW5nIChzdWJzZXEgYnVmZiBzdGFydC1wb3MgKC0gcG9zIDEpKSkKCQkJICAg
Y29udGVudCkKCQkgICAgIChzZXRmIGNodW5rLXN0YXJ0LXBvcyAoKyBwb3Mg
MSkpCgkJICAgICAoZ28gaW4tY2h1bmspKSkpCgkgICAgIGAoKGlmIChlcWwg
Y29kZSBlbmQtcmVmLWNoYXItMSkKCQkgICAoZ28gZW5kLXJlZi10YWctMSkp
KSkKICAgICAgIChpZiAoZXFsIGNvZGUgbmV3bGluZS1jb2RlKQoJICAgKGdv
IGNodW5rLXN0YXJ0KSkKICAgICAgIChnbyBpbi1jaHVuay1yZWYpCiAgICAg
ICAsQChpZiAoPiAobGVuZ3RoIGNodW5rLXJlZi1lbmQtZGVsaW1pdGVyKSAx
KQoJICAgICAobG9vcCBmb3IgaSBmcm9tIDIgdG8gKGxlbmd0aCBjaHVuay1y
ZWYtZW5kLWRlbGltaXRlcikgYXBwZW5kCgkJICAgKGxpc3QKCQkgICAgKGlu
dGVybiAoZm9ybWF0IG5pbCAiRU5ELVJFRi1UQUctfkEiICgtIGkgMSkpIHdl
YnBrZykKCQkgICAgJyhpbmNmIHBvcykKCQkgICAgJyhzZXRmIGNvZGUgKGFy
ZWYgYnVmZiBwb3MpKQoJCSAgICAoaWYgKD0gaSAobGVuZ3RoIGNodW5rLXJl
Zi1lbmQtZGVsaW1pdGVyKSkKCQkJYCgoaWYgKGVxbCBjb2RlICwoaW50ZXJu
IChmb3JtYXQgbmlsICJFTkQtUkVGLUNIQVItfkEiIGkpIHdlYnBrZykpCgkJ
CSAgICAgIChwcm9nbgoJCQkJKHB1c2ggKGxpc3QgY2h1bmstc3RhcnQtcG9z
ICgtIHN0YXJ0LXBvcyAyKSkgY29udGVudCkKCQkJCShwdXNoIChhcnJheS10
by1zdHJpbmcKCQkJCSAgICAgICAoc3Vic2VxIGJ1ZmYgc3RhcnQtcG9zICgt
IHBvcyAxKSkpCgkJCQkgICAgICBjb250ZW50KQoJCQkJKHNldGYgY2h1bmst
c3RhcnQtcG9zICgrIHBvcyAxKSkKCQkJCShnbyBpbi1jaHVuaykpKSkKCQkJ
JygoaWYgKGVxbCBjb2RlIChpbnRlcm4gKGZvcm1hdCBuaWwgIkVORC1SRUYt
Q0hBUi1+QSIgaSkgd2VicGtnKSkKCQkJICAgICAgKGdvIChpbnRlcm4gKGZv
cm1hdCBuaWwgIkVORC1SRUYtVEFHLX5BIiBpKSB3ZWJwa2cpKSkpKQoJCSAg
ICAnKGlmIChlcWwgY29kZSBuZXdsaW5lLWNvZGUpCgkJICAgICAgKGdvIGNo
dW5rLXN0YXJ0KSkKCQkgICAgJyhnbyBpbi1jaHVuaykpKSkKICAgICAgICkp
KQo=

--0-1783017166-1176954120=:28034--

\start
Date: Thu, 19 Apr 2007 13:55:41 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: Lisp macro fun...

> I have been attempting to generalize Waldek's finite state machine
> using macros, and have essentially run up against the limits of my tiny
> Lisp skills.  Can anybody tell me how to get this thing to expand into
> something like Waldek's code?  (I can provide the whole file if it is
> needed.)
> 

I must admit that I do not understand what you are tring to do now
-- what you posted looks like macro definition, but it contains
(hardcodes) most of had written version.

Have you looked at <http://ll1.ai.mit.edu/shriram-talk.pdf> (it
contains Scheme example of macro-generating finite state
machine)?

Low level macro version of finite state machine may look like:

(automaton
  (setup_code)
  (state normal-start
     (normal_start_setup)
     (-> start-tag-code-1 chunk-start-tag-1)
     (-> newline-code normal-start)
     (default normal))
  (state normal
     (-> newline-code normal-start)
     (default normal))
  (state chunk-start-tag-1
     (-> start-tag-code-2 in-chunk-start-tag
         ;;; Action
         (setf start-pos (+ pos 1)))
  ....

To generate our  code from the above one has to define macros
automaton, state, defalut and ->.  state, defalut and -> may
be local to automaton.  In the above I assumend that we use
chacter codes, but we could also use characters and write:

   (-> #\< chunk-start-tag-1)

A higher level version may do transitions on strings, so you
could write:

   (-> "<<"  in-chunk-start-tag
         ;;; Action
         (setf start-pos (+ pos 1)))

and the macros would automatically generate intermediate states.

\start
Date: Thu, 19 Apr 2007 07:24:27 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: Lisp macro fun...

--- Waldek Hebisch wrote:

> I must admit that I do not understand what you are tring to do now
> -- what you posted looks like macro definition, but it contains
> (hardcodes) most of had written version.

Extending your code to automatically handle any set of delimiters (not
just the <<chunkname>>= we currently use) was the goal.  I would like
to write notangle in lisp once and be done with it ;-).

> Have you looked at <http://ll1.ai.mit.edu/shriram-talk.pdf> (it
> contains Scheme example of macro-generating finite state
> machine)?

No.  Thanks for the link, I'll check it out.  Kai sent me some finite
state machine code as well, and I am working on trying to understand
it.  I was trying to deviate from your code as little as possible
because your code has proven itself fast and I didn't want to
accidentally introduce any performance hits.

> A higher level version may do transitions on strings, so you
> could write:
> 
>    (-> "<<"  in-chunk-start-tag
>          ;;; Action
>          (setf start-pos (+ pos 1)))
> 
> and the macros would automatically generate intermediate states.

That's what I'm trying to achieve.  I guess I need to think more about
how to set up the macros.

\start
Date: Fri, 20 Apr 2007 05:07:26 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Issue 330.
Cc: Camm Maguire

Issue 330 just happened to me -- working in Axiom I left gazonk0.fn
file.  Later working as another user I got failures because this
file was present. 

AFAICS to root cause is GCL bug, namely the following sequence:

(defun foo(x) x) (compiler::emit-fn t) (compile 'foo)

leaves trash gazonk0.fn file (the other gazonk files are
correctly erased, but .fn file is left in place).

You may say that the gazonk-name function should prevent the
problem.  But Axiom gazonk-name (and gcl too) checks only if
the gazonk0.lsp (or generally gazonkn.lsp) file is present, it
ignores other gazonk files.  Axiom gazonk-name generates repeatable
names making conflicts extremally likely (gcl-2.6.8 embeds
process id in the name reducing chance for conflict).

We could easily provide better gazonk-name, but it seems that
gazonk files really are a can worms from security point of view.
Trying to find simple and safe way to create temporary files
the best thing (exluding special OS support) probably is
to create (in exclusive mode) temporary directory (using random
names to reduce denial of service attacks) and create gazonk files
inside.  Unfortunatly,  apropriate functions are system specific.

\start
Date: Fri, 20 Apr 2007 06:11:41 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch, Gabriel Dos Reis

Martin Rubey wrote:
> 2) and install *.spad.pamphlet instead of *.spad into
>    target/i686-pc-linux/src/algebra/
>  
>    That this didn't happen in the first place is *really* strange in my
>    opinion.
>

I suspect that even people advocating literate progammining do not
consider _unprocessed_ pamphlets as human readable (to say the truth
current Axiom sources contain many examples of using noweb for
obfuscation).  For pamphlets to enhance readability we will need
specialized editor/viewer (and considering our resouces I am not
sure if 25 years is enough to develop a good one).

> 3) apart of that, install the SPADEDIT script into target/i686-pc-linux/lib/
> 
>    I'll have to modify it a tiny little bit if you agree on (2).  In
>    particular, it may make sense to make it obey an environment variable, say,
>    AXIOMEDITOR, that contains the name of an editor to be called with two
>    arguments, namely line-number and filename.
> 
>    However, I believe that any script is better than no script, because many
>    people will not have write access to the target/i686-pc-linux/lib/
>    directory, so they cannot use the HyperDoc functionality.
> 
> 
> Well, I do not insist on (3). But (1) and (2) would be important to me.
> 

Hmm, 2 is easy to do.  But I wonder why you consider it important
(I personally do not care very much one way or another because I
typically have the whole build tree at hand).

Concering 3: you solve nicely part of the problem (that is finding
correct place in source files).  When I first saw you script I had
doubts because user may have quite different preferences for
editor/viewer and passing line numbers to editors can be quite
compicated (I am affraid that there are still editors with no
support for passing line numbers).  But now I think that the only
way to "solve" problem of correct way to invoke editor is
to make it user responsibility.  More precisely, I think that
user should have possibility to effectively replace SPADEDIT
by own program.  Of course, most user will benefit from finding
the correct place, so IMHO correct way is to provide in SPADEDIT
escape to user code.  Your AXIOMEDITOR variable (or maybe call it
SPADEDIT_ACTION) could do this if you pass to it just file name
and line number (as two separate arguments).  In such case we
probably should provide a few example editors -- that is
shell functions which call say emacs, vi, maybe kdvi.

\start
Date: 20 Apr 2007 09:29:23 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: re: Request for wh-sandbox and	build-improvements
Cc: Waldek Hebisch, Gabriel Dos Reis

Waldek Hebisch writes:

> Martin Rubey wrote:
> > 2) and install *.spad.pamphlet instead of *.spad into
> >    target/i686-pc-linux/src/algebra/
> >  
> >    That this didn't happen in the first place is *really* strange in my
> >    opinion.
>
> I suspect that even people advocating literate progammining do not consider
> _unprocessed_ pamphlets as human readable (to say the truth current Axiom
> sources contain many examples of using noweb for obfuscation).

Well, meanwhile I *do* prefer the pamphlet files, since several of them contain
a lot more information than the spad files.  Furthermore, I guess it might
encourage people to add documentation notes, even if they would only be for
themselves.

Since item 1) was the request to install "document", in whatever form, it is
easy to generate dvi or spad files.

So really, I beg that you adapt the change.

> > 3) apart of that, install the SPADEDIT script into target/i686-pc-linux/lib/
> > 
> >    I'll have to modify it a tiny little bit if you agree on (2).  In
> >    particular, it may make sense to make it obey an environment variable, say,
> >    AXIOMEDITOR, that contains the name of an editor to be called with two
> >    arguments, namely line-number and filename.
> > 
> >    However, I believe that any script is better than no script, because many
> >    people will not have write access to the target/i686-pc-linux/lib/
> >    directory, so they cannot use the HyperDoc functionality.
> > 
> > 
> > Well, I do not insist on (3). But (1) and (2) would be important to me.
>
> Hmm, 2 is easy to do.  But I wonder why you consider it important
> (I personally do not care very much one way or another because I
> typically have the whole build tree at hand).

There are two reasons:

* because of the hierarchy in our department, I maintain the "up to date"
  version of axiom, which currently is wh-sandbox.  I cannot place the build
  tree on the network file system, because of quota restrictions.  Thus,
  everytime I recompile, I would have to move the pamphlet files myself, move
  document and SPADEDIT into place.  It's simply a nuisance.  Another nuisance
  is having to manually make the aldor compatibility files.  It takes me about
  an hour every time I have to do it, since I tend to forget little things
  (eg., make 3.81beta does not work), and some bits change (eg., out of source
  build is preferred now).

* In my opinion, documenting the algebra is one of the most important goals of
  the project.  It is superb that I can ask you some things about Risch etc.,
  but most people I know do not want to ask "silly questions", and, maybe even
  more importantly, what are we going to do when you become broker on wall
  street?

  I consider installing the spad files as a very effective way to loose
  information and motivation to collect information.
 
> Concering 3: you solve nicely part of the problem (that is finding correct
> place in source files).  When I first saw you script I had doubts because
> user may have quite different preferences for editor/viewer and passing line
> numbers to editors can be quite compicated (I am affraid that there are still
> editors with no support for passing line numbers).  But now I think that the
> only way to "solve" problem of correct way to invoke editor is to make it
> user responsibility.

Great! We agree!

> More precisely, I think that user should have possibility to effectively
> replace SPADEDIT by own program.  Of course, most user will benefit from
> finding the correct place, so IMHO correct way is to provide in SPADEDIT
> escape to user code.  Your AXIOMEDITOR variable (or maybe call it
> SPADEDIT_ACTION) could do this if you pass to it just file name and line
> number (as two separate arguments).  In such case we probably should provide
> a few example editors -- that is shell functions which call say emacs, vi,
> maybe kdvi.

Yes. Furthermore, I'd default it to some editor or pager which is usually
installed. (mabe "less"?) Note that SPADEDIT is also called via )edit, so it is
also a MS Windows question.  I should also rename $number to $line.

emacs +$line $spadname
emacsclient +$line $spadname
xemacs +$line $spadname
gnuclient +$line $spadname
vi +$line $spadname
less +$line $spadname


kwrite --line $line $spadname
kate --line $line $spadname


any windows guis out there ;-) ?


Below you find the appropriate SPADEDIT, in case you are (which I hope)
implementing my request 1).



For kdvi, the case is a little more complicated, but not too much: most
importantly, we would need to find the right file number in the spad.tex file,
and the latter would have to be latex'ed with --src-specials enabled.  Then one
can say

kdvi file:mantepse.spad.dvi#src:34mantepse.spad.tex

But really, I'd leave this as a future project.


Martin

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\documentclass{article}
\usepackage{axiom}
\begin{document}
\title{SPADEDIT}
\author{Martin Rubey}
\maketitle
\begin{abstract}
  \verb|SPADEDIT| is a shell script that handles features to display or edit
  source files.
\end{abstract}

The script described here is called (at least) in two different situations:
\begin{itemize}
\item it is called by HyperDoc, when the user clicks on a link like
  \verb|INT.spad|. In this case it receives two arguments, namely 
  \begin{enumerate}
  \item the file in which HyperDoc believes the constructur is defined, which
    is currently of the form \verb|$AXIOM/../../src/algebra/INT.spad|, i.e.,
    the path to the source directory, then the abreviation of the constructor,
    and finally \verb|.spad| appended,

  \item the long name of the constructor.
  \end{enumerate} 

\item it is called from the interpreter, when the usser issues \verb|)edit|. In
  this case it receives exactly one argument, even if it \verb|)edit| had  no
  or several arguments supplied. 

  \begin{itemize}
  \item if several arguments were supplied, only the first is passed to
    \verb|SPADEDIT| and all the others are ignored.
  \item if no arguments were supplied, \verb|SPADEDIT| receives the last
    argument it received, or \verb|NIL| if so far \verb|)edit| was always
    called with no arguments. Furthermore, if the argument of \verb|)edit|
    starts with a dot, it is also not passed to \verb|SPADEDIT|.
  \end{itemize}
\end{itemize}

<<*>>=
#! /bin/bash

if [ $# -eq 1 ]; then
@

Thus, we were called by \verb|)edit| and can simply call the text editor of our
choice:

<<*>>=
 gnuclient $1 &

else
@

We are now in the case where we were called by HyperDoc. Since filenames
supplied by HyperDoc do not correspond to the filenames in the current Axiom
distribution as of [[patch-50]], we have to find the right file ourselves. We
simply ask grep the directory containing the source files to return file and
line number within that file. Note that, if only spad files are installed, we
should replace \verb|.spad.pamphlet| by \verb|.spad|.

<<*>>=
  f=$(basename $1 .spad)
  h=$(grep -n ")abb.* $f " $AXIOM/src/algebra/*.spad.pamphlet)
@

Note that we rather extract the abbreviation of the domain, instead of using
the full name. The reason is best explained by example. Consider the following
two lines in \verb|integer.spad|:

\begin{verbatim}
)abbrev package INTSLPE IntegerSolveLinearPolynomialEquation
\end{verbatim}

and

\begin{verbatim}
)abbrev domain INT Integer
\end{verbatim}

Note that the abreviated domain name is nicely delimited by two spaces, while
we do not know what follows the long domain name. There might be spaces and a
carriage return, maybe even comments are allowed\dots.

We assume that grep produces only one result. There is no way in Axiom to deal
with several domains having the same name anyway.

The next step is to obtain the name of the source file:
<<*>>=
  spadname=${h%%:*}
@

Since pamphlets are currently not installed, and {\LaTeX} is not called with
\verb|source-specials| enabled, displaying \verb|dvi| doesn't really work yet.

<<NOTYET *>>=
  name=$(basename $spadname)
  dviname=$AXIOM/doc/src/algebra/$name.dvi
@

Finally, we obtain the line number.

<<*>>=
  lineaux=${h#*:}
  line=${lineaux%:*}
@

Now we have everything to call our favorite editor:

<<*>>=
  gnuclient +$line $spadname
@

If \verb|dvi|'s were compiled with \verb|-source-specials|, we could also call
a \verb|dvi| viewer, for example

\begin{verbatim}
  kdvi file:$dviname#src:$line$name.tex
\end{verbatim}

but that doesn't work yet.  Furthermore, we would have to find the line number
in the \verb|.spad.tex| file.

<<*>>=  
fi
@

\end{document}

\start
Date: Fri, 20 Apr 2007 10:44:51 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Request for wh-sandbox and build-improvements
Cc: Gabriel Dos Reis, Waldek Hebisch

> For kdvi, the case is a little more complicated, but not too much: most
> importantly, we would need to find the right file number in the spad.tex file,
> and the latter would have to be latex'ed with --src-specials enabled.  Then one
> can say
> 
> kdvi file:mantepse.spad.dvi#src:34mantepse.spad.tex
> 
> But really, I'd leave this as a future project.

Yes it's probably a future project, but not too much in the future I guess.

And remember, you *don't* want to call

   latex --src-special file.spad.tex

because then all you get is \specials that lead you from kdvi to the 
.tex file and not to the .pamphlet file. The trick is to use srcltx.sty 
and a good naming scheme for the .pamphlet - .tex relation. I could 
convince the current maintainer of srcltx.sty to include an appropriate 
hook for filename translation into srcltx.sty version 1.6.

\start
Date: Fri, 20 Apr 2007 11:03:27 -0400
From: Bill Page
To: Cliff Yapp, Gabriel Dos Reis
Subject: Building GCL and Axiom on Nexenta OpenSolaris

On April 7, 2007 5:58 PM C Y wrote:

> 
> --- Gabriel Dos Reis wrote:
> > I tried to install openSolaris nevada build 60 on my Dell
> > Optiplex 745, but eventually I gave up and installed SuSE
> > instead. :-( The reason being that openSolaris 64bit seems
> > to be largely unsupported by GNU tool chains, and openSolaris
> > seems to ignore many of GNU software. :-(
> 
> I've only installed it in a plex86 environment and haven't
> really worked with it, but you might want to try Nexenta and
> see if that works:  http://www.gnusolaris.org
> 
> I don't know that 64bit support will be any better, but the
> GNU toolchain support in Nexenta may be in better shape.
> 

Thanks to this recommendation for Cliff, I recently installed
nexenta OpenSolaris from the free OpenSolaris <starter kit> DVD.

http://get.opensolaris.org

I installed OpenSolaris under Microsoft Virtual PC 2007 on my
Windows XP box. It works great! Nexenta OpenSolaris is the first
Solaris distribution that I have been able to install on Virtual
PC, although I routinely run a 2nd copy of Windows and SuSE 10.2
virtual machines.

I had a small problem with the screen resolution (at first limited
to 640x480) but this was easily cured by a creating and modifying
the default xorg.conf to include horizontal and vertical sync,
default depth and monitor modes. Details on request.

I particularlly like the integration of the Debian work-a-like
'apt-get'. This makes it easy do things like this:

  # apt-get install subversion gcc m4 autoconf
  # apt-get install libxt-dev libx11-dev tetex-extra

(just like on Debian) to satisfy build requirements for Axiom.

Performance under Microsoft Virtual PC on my AMD 4200+ dual
core machine is quite fast.

\start
Date: 20 Apr 2007 12:14:43 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: differences wh-sandbox andbuild-improvements
Cc: Gabriel Dos Reis

Greetings!

Bill Page writes:

> On April 18, 2007 6:00 AM Waldek Hebisch wrote:
> > 
> > Bill Page wrote:
> > > Why not? It is not necessary to build gcl as part of the Axiom
> > > build - just install the windows binary for gcl, like other
> > > users Windows do.
> > >
> > 
> > Is there a binary version of gcl suitable for Axiom developement?
> > The latest binary I see is 2.6.6, but AFAIK with 2.6.6 we are
> > getting errors which vanish if we use 2.6.7 or 2.6.8.
> 
> You are right and what I wrote above is wrong. Gaby also has
> pointed out that it is not currently realistic to depend on the
> GCL binaries on Windows for Axiom development.
> 
> As far as I can tell no one has posted any binaries for GCL on
> windows newer than
> 
>   gcl_2.6.6.mingw32_cltl1_japi_20050210.exe 22-Mar-2005
> 
> at
> 
>   http://ftp.gnu.org/gnu/gcl/binaries/stable
> 
> And gcl-2.6.8pre is still a "pre-release". I guess the gcl
> project is also critally lacking in resources. If it would be
> helpful I could certainly upload a windows binary of this
> pre-release to the Axiom Wiki web site. But I am discouraged
> also by Gaby's observation that there does not seem to be much
> interest in development of the Windows versions of GCL or
> Axiom. :-(
> 

Thanks so much for this update.  GCL development, like most open
source projects run by volunteers, usually proceeds in bursts, most
frequently during the summer months.  But I think it is also true, as
we've discussed personally in the past, that the community dynamics of
Windows computer users are by in large quite different from BSD/Linux
users, in that relatively speaking there are far fewer people
interested in actually contributing work than in simply downloading
the work done by others.  Mike Thomas was of course the heroic
exception in this regard, and his determination of the superiority of
the mingw environment vis a vis the cygwin environment coupled with
his more than ample contributions of time and skill have given us the
mingw system we have today.  I do think we need to discuss the way
forward, for unless we find his equivalent somewhere, it can be argued
that it would be better for us to migrate to a system that can be well
emulated and/or remotely accessed under Linux using familiar tools,
even if those are deficient in other regards with respect to customary
Windows usage.

>From my own perspective, I feel most able to support (in descending
order) Linux, BSD, Solaris, MacOSX, and lastly mingw, and alas it is
likely to remain that way.  We therefore are first in needs of a
Windows porter, and next a MacOSX porter.  I feel that GCL has also
accumulated a certain degree of mingw experimental code which no one
uses to my understanding and should be removed on conceptual grounds.
I.e. japi and anything related to java, the separate windows main
routines, and perhaps some alternative tk stuff if memory serves.  I
think we need to consolidate around unix concepts to the degree
possible given our resources, and provide minimal well centralized
emulations where required, e.g. sbrk.  This means in all likelihood
fork(), unix sockets, etc., which to my limited understanding point
more in the direction of cygwin than mingw.  (2.7.0 has parallel
processing primitives based on fork.  pargcl, an mpi extension, is
also likely to be built by default in 2.7 and higher.  This latter
facility of course just requires a uniform external mpi interface
which I hope we can avoid including with the gcl source as gmp and bfd
are done now.) I don't think we should discontinue mingw so much as
investigate a cygwin alternative which, if proven over time to be
accessible within unix and adequate from the user's perspective, might
eventually become the windows port of choice.

This said, I will turn 180 degrees if anyone would like to step
forward and fill Mike Thomas' shoes. 

Finally, I'm not even familiar with the windows package format
concept, so if anyone would like a binary posted, we need a
volunteer.  I'd be quite happy to provide access to any qualified
individual with interest.

> > 
> > Also, can one install gcl without affecting existing Mingw
> > installation (the gcl readme claims that on Windows gcl
> > need a specific, rather old Mingw version -- for me
> > downgrading Mingw is not an option)?
> > 
> 
> MinGW is required in order to compile Lisp to object code and
> of course to compile the Lisp output of the SPAD compiler in
> Axiom. Unlike Linux, it is not correct to assume that a C
> compiler is available in the basic window installation. The
> existing binary installer that I prepared for Axiom on Windows
> includes the necessary parts of MinGW to permit GCL and Axiom
> to compile object code. I think a similar binary installer
> for GCL should include these same parts of MinGW so that the
> GCL installation will be complete and fully functional.
> 

How big will this be?  Who can tell me exactly what that means in
terms of files shipped?

\start
Date: 21 Apr 2007 09:49:07 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Dear Bill, Kai!

I just tried bar and foo from

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

and with the information

| then access with the url: 
| 
|  http://localhost:8085/directory/or/file

I got it actually to work.  I have two problems, though:

* The stuff I write after "http://localhost:8085" is received by foo in
  all-uppercase always, but I need to preserve case.  Is there a case
  preserving character as "|" in lisp?

* How can I close the socket?

And finally, does this work in MS Windows, too?

\start
Date: 21 Apr 2007 09:56:27 +0200
From: Martin Rubey
To: Bill Page, Kai Kaminski
Subject: re: Axiom HyperDoc Replacement

Martin Rubey writes:

> I got it actually to work.  I have two problems, though:
> 
> * The stuff I write after "http://localhost:8085" is received by foo in
>   all-uppercase always, but I need to preserve case.  Is there a case
>   preserving character as "|" in lisp?

oh, the case preserving character is "|"!  Remains:
 
> * How can I close the socket?
> 
> And finally, does this work in MS Windows, too?

\start
Date: 21 Apr 2007 10:03:08 +0200
From: Martin Rubey
To: Bill Page, Kai Kaminski
Subject: re: Axiom HyperDoc Replacement

Sorry, yet another question: How do I have to modify foo

(defun foo (s)
  (let* ((get (read s nil 'eof))
         (fn (and (eq get 'get) (read s nil 'eof))))
    (format t "Got ~S~%~%" fn)
    (format s "HTTP/1.1 ~S~%~%" (if fn 200 403))
    (format t "HTTP/1.1 ~S~%~%" (if fn 200 403))
    (format t "~S~%~%" (SPADCALL fn *docfun*))
    (format s "~S~%~%" (SPADCALL fn *docfun*))
    (close s)))

to make the browser render the html in fn.  I.e., so far I just displayed
strings, which were obtained by applying *docfun* to fn.  But now, 
(SPADCALL fn *docfun*) will actually result in a path like binomial-COMBF.html,
and I want the browser to display that page.

> > * How can I close the socket?
> > 
> > And finally, does this work in MS Windows, too?

\start
Date: Sat, 21 Apr 2007 06:24:03 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Axiom HyperDoc Replacement
Cc: Kai Kaminski

On April 21, 2007 3:49 AM Martin Rubey wrote:
> 
> I just tried bar and foo from
> 
> http://wiki.axiom-developer.org/SandBoxSocketsInSPAD
> 
> and with the information
> 
> | then access with the url: 
> | 
> |  http://localhost:8085/directory/or/file
> 
> I got it actually to work.  I have two problems, though:
> 
> * The stuff I write after "http://localhost:8085" is received 
>   by foo in all-uppercase always, but I need to preserve case.
>   Is there a case preserving character as "|" in lisp?

I think it is only because this simple example is using the
READ function which treats the input like a Lisp symbol.
There are other functions for handling the input from
streams like READ-LINE. See a GCL language reference such as

http://www.ugcs.caltech.edu/manuals/libs/gcl-si-2.6.7/gcl-si_5.html

> 
> * How can I close the socket?
>

Does control-C work? If not, then perhaps there needs to be
a little more code to handle signals. Otherwise for now just
use 'kill' to stop the process from another session.
 
> And finally, does this work in MS Windows, too?
> 

Yes it works in gcl-2.6.8pre. Unfortunately the current Axiom
binaries for Windows use an older version so you would need
to build Axiom on Windows using build-improvements or by
subsituting gcl-2.6.7pre into the source code from the
axiom--windows--1 tla archive.

\start
Date: Sat, 21 Apr 2007 07:14:14 -0400
From: Bill Page
To: Martin Rubey
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

On April 21, 2007 4:03 AM Martin Rubey wrote:
> 
> Sorry, yet another question: How do I have to modify foo
> 
> (defun foo (s)
>   (let* ((get (read s nil 'eof))
>          (fn (and (eq get 'get) (read s nil 'eof))))
>     (format t "Got ~S~%~%" fn)
>     (format s "HTTP/1.1 ~S~%~%" (if fn 200 403))
>     (format t "HTTP/1.1 ~S~%~%" (if fn 200 403))
>     (format t "~S~%~%" (SPADCALL fn *docfun*))
>     (format s "~S~%~%" (SPADCALL fn *docfun*))
>     (close s)))
> 
> to make the browser render the html in fn. I.e., so far I 
> just displayed strings, which were obtained by applying
> *docfun* to fn.

You got SPADCALL to work for you - Cool! To bad you have
to write this in Lisp, I would really like to get this
working from SPAD.

> But now, (SPADCALL fn *docfun*) will actually result in
> a path like binomial-COMBF.html, and I want the browser
> to display that page.

What you need to do is to send an HTTP 'Content-type:'
header as the first two lines of what is sent to the
browser. By default the browser is just treating all
output as text. Try this:

 (defun foo (s)
   (let* ((get (read s nil 'eof))
          (fn (and (eq get 'get) (read-line s nil 'eof))))
     (format s "HTTP/1.1 ~S~%" (if fn 200 403))
     (format s "Content-type: text/html~%~%")
     (format s "<a href='~S'>click here</a>~%" (SPADCALL fn *docfun*))
     (close s)))

You will need to include the same header when sending HTML
data from a file.

(Warning: I haven't actually tested it yet.)

Google for more HTTP references like this one:

http://www.jmarshall.com/easy/http

There are also lot of references to HTML such as the link

 <a href='url'> link </a>

generated in the example above. 

HTTP is the low level protocol for sending and receiving
data from a web server. HTML is the mark-up language in which
the data content usually encoded for web browsers.

The (format t ... ) are just for debugging to send some
output to the console so you can see what is happening on
the server.

> ...

\start
Date: Sat, 21 Apr 2007 09:15:52 -0400
From: Bill Page
To: Bill Page, Martin Rubey
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

On April 21, 2007 7:14 AM I wrote:
> 
> On April 21, 2007 4:03 AM Martin Rubey wrote:
> > 
> > Sorry, yet another question: How do I have to modify foo
> > 
> > (defun foo (s)
> >   (let* ((get (read s nil 'eof))
> >          (fn (and (eq get 'get) (read s nil 'eof))))
> >     (format t "Got ~S~%~%" fn)
> >     (format s "HTTP/1.1 ~S~%~%" (if fn 200 403))
> >     (format t "HTTP/1.1 ~S~%~%" (if fn 200 403))
> >     (format t "~S~%~%" (SPADCALL fn *docfun*))
> >     (format s "~S~%~%" (SPADCALL fn *docfun*))
> >     (close s)))
> > 
> > to make the browser render the html in fn. I.e., so far I 
> > just displayed strings, which were obtained by applying
> > *docfun* to fn.
> 
> You got SPADCALL to work for you - Cool! To bad you have
> to write this in Lisp, I would really like to get this
> working from SPAD.
> 
> > But now, (SPADCALL fn *docfun*) will actually result in
> > a path like binomial-COMBF.html, and I want the browser
> > to display that page.
>

Oh ... Now that I have had a cup of coffee and woken up a
little, I think that's so typically **brilliant** of you!
That is an excellent idea.

Instead of 'foo' let's just call this little Lisp function
the 'server' and 'bar' is called the 'socket'.

Since what we want is a browser interface for the desktop
why not just use the local file system? We don't need any
kind of especially fast web server because the browser can
read are we can write locally stored files much faster than
anything can be transferred over the Internet.

And this can be made transparent to the user because there
is a particular kind of HTTP response called a "redirection"
which does precisely what you want it to do: It tells the
browser to display a page from some place else. See response
status code 303 at http://jmarshall.com/easy/http

So all your *docfun* Spad function has to do is take the
input from fn, parse it to separate the data fields, do some
calculation, prepare the page, save it on disk in a known
location, and then return the location information to the
server, i.e. the path 'binomial-COMBF-001.html' in your
example. The server forwards this path to the browser as a
redirection and the browser automatically loads your newly
written page. Very Simple.
 
> What you need to do is to send an HTTP 'Content-type:'
> header as the first two lines of what is sent to the
> browser. By default the browser is just treating all
> output as text. Try this:
> 
>  (defun foo (s)
>    (let* ((get (read s nil 'eof))
>           (fn (and (eq get 'get) (read-line s nil 'eof))))
>      (format s "HTTP/1.1 ~S~%" (if fn 200 403))
>      (format s "Content-type: text/html~%~%")
>      (format s "<a href='~S'>click here</a>~%" (SPADCALL fn *docfun*))
>      (close s)))
>

For an automatic redirection all you really need is something
like this:

  (defun server (s)
    (let* ((get (read s nil 'eof))
           (fn (and (eq get 'get) (read-line s nil 'eof))))
      (format s "HTTP/1.1 ~S~%" (if fn 303 403))
      (format s "Location: ~S~%~%" (SPADCALL fn *docfun*))
      (close s))) 


> You will need to include the same header when sending HTML
> data from a file.
>

Actually what I wrote is not true in the case of a file that
is accessed locally by a web browser. No header is needed in
this case because the browser choices the content-type based
on the file extension. So a page that ends in .html will
automatically treated as mime-type 'text/html'. No problem.
 
> (Warning: I haven't actually tested it yet.)
> 
> Google for more HTTP references like this one:
> 
> http://www.jmarshall.com/easy/http
> 
> There are also lot of references to HTML such as the link
> 
>  <a href='url'> link </a>
> 
> generated in the example above. 
>

If you use automatic redirection, then you don't need this
in the server, but of course your Spad routines will have to
generate a lot of different HTML commands with embedded data
and graphics. This can even include LaTeX output if we use
the jsMath javascript on the browser.
 
> HTTP is the low level protocol for sending and receiving
> data from a web server. HTML is the mark-up language in which
> the data content usually encoded for web browsers.
> 

Actualy with your brilliantly simple idea, we only need to
know a little of the HTTP protocol. You will probably want
to read about the 'POST' command that allows you to send data
from a form or a text area displayed on the browser. This
information can be passed on to *docfun* as input. 

With this simple approach I think it should be quite easy
to implement the HyperDoc functionaliy using a standard web
browser. 

\start
Date: 21 Apr 2007 16:20:26 +0200
From: Martin Rubey
To: Bill Page
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Bill Page writes:

> Oh ... Now that I have had a cup of coffee and woken up a
> little, [...censored...]
> That is an excellent idea.

Thanks.

> Instead of 'foo' let's just call this little Lisp function
> the 'server' and 'bar' is called the 'socket'.

OK, that makes sense.

> Since what we want is a browser interface for the desktop
> why not just use the local file system?

Yes, that's the idea.  In fact, I also want to do some caching, since tex4ht is
rather slow: every function has - by design of axiom - a unique identifier,
namely its signature.  I will use this as the name of the file.  Now, if the
file is there, it can be displayed immediately, otherwise I'll generate it.

> For an automatic redirection all you really need is something like this:
> 
>   (defun server (s)
>     (let* ((get (read s nil 'eof))
>            (fn (and (eq get 'get) (read-line s nil 'eof))))
>       (format s "HTTP/1.1 ~S~%" (if fn 303 403))
>       (format s "Location: ~S~%~%" (SPADCALL fn *docfun*))
>       (close s))) 

that's what I wanted.  


Unfortunately, it doesn't work.  Neither does  

(defun server (s)
   (let* ((get (read s nil 'eof))
          (fn (and (eq get 'get) (read-line s nil 'eof))))
     (format s "HTTP/1.1 ~S~%" (if fn 200 403))
     (format s "Content-type: text/html~%~%")
     (format s "<a href='~S'>click here</a>~%" (SPADCALL fn *docfun*))
     (close s)))

The latter just makes the browser display


<a href='"stretch.html"'>click here</a>

i.e., it doesn't interpret the html.  The former doesn't find "stretch.html" in
the local directory.  Very likely it is looking for

localhost:8080/stretch.html

or some such.

\start
Date: 21 Apr 2007 16:43:48 +0200
From: Martin Rubey
To: list
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Martin Rubey writes:

> > For an automatic redirection all you really need is something like this:
> > 
> >   (defun server (s)
> >     (let* ((get (read s nil 'eof))
> >            (fn (and (eq get 'get) (read-line s nil 'eof))))
> >       (format s "HTTP/1.1 ~S~%" (if fn 303 403))
> >       (format s "Location: ~S~%~%" (SPADCALL fn *docfun*))
> >       (close s))) 
> 
> that's what I wanted.  

OK, I got it to work now. The important bit was to send

  (format s "HTTP/1.1 ~S~%" blah)

(as you wrote, in fact) instead of

  (format s "HTTP/1.1 ~S~%~%" blah)


The second thing is to send

   file:/absolute/path/to/stretch.html

which is a nuisance.  Isn't there a way to make it read just the local
directory?  Oh well, maybe its even better that way.

\start
Date: 21 Apr 2007 16:57:46 +0200
From: Martin Rubey
To: list
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Martin Rubey writes:

> OK, I got it to work now. 

Oh dear, no it doesn't work. Only the "click here" variant does.  I tried

(defun server (s)
  (let* ((get (read s nil 'eof))
         (fn (and (eq get 'get) (read s nil 'eof))))
    (format t "Got ~S~%~%" fn)
    (format s "HTTP/1.1 ~S~%" (if fn 303 403))
;    (format s "HTTP/1.1 ~S~%" (if fn 200 403))
;    (format s "Content-type: text/html~%~%")
    (format s "Location: ~S~%" 
            "file:/users/rubey/martin/Axiom/hyperdoc-replacement/stretch.html")
;    (format s "<a href='~S'>click here</a>~%" 
;           "file:/home/martin/martin/Axiom/hyperdoc-replacement/stretch.html")
    (close s)))

but that only keeps displaying in the Axiom shell window

Got /

Got /

Got /


...


The other variant works fine, however is quite useless for my purpose.

\start
Date: 21 Apr 2007 17:20:21 +0200
From: Martin Rubey
To: list
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Martin Rubey writes:

A typo:

> (defun server (s)
>   (let* ((get (read s nil 'eof))
>          (fn (and (eq get 'get) (read s nil 'eof))))
>     (format t "Got ~S~%~%" fn)
>     (format s "HTTP/1.1 ~S~%" (if fn 303 403))
> ;    (format s "HTTP/1.1 ~S~%" (if fn 200 403))
> ;    (format s "Content-type: text/html~%~%")
  ;    (format s "Content-type: text/html~%")
>     (format s "Location: ~S~%" 
>             "file:/users/rubey/martin/Axiom/hyperdoc-replacement/stretch.html")
> ;    (format s "<a href='~S'>click here</a>~%" 
> ;           "file:/home/martin/martin/Axiom/hyperdoc-replacement/stretch.html")
>     (close s)))
> 
> but that only keeps displaying in the Axiom shell window
> 
> Got /
> 
> Got /
> 
> Got /

Is the problem that "Location:" expects a http: specification?  I'm quite
clueless...

\start
Date: 21 Apr 2007 17:45:26 +0200
From: Martin Rubey
To: list
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

There appear to be at least two different errors in the code below.

(defun server (s)
  (let* ((get (read s nil 'eof))
         (fn (and (eq get 'get) (read s nil 'eof))))
    (format t "Got ~S~%~%" fn)
    (format s "HTTP/1.1 ~S~%" (if fn 303 403))
    (format s "Location:
  file:/users/rubey/martin/Axiom/hyperdoc-replacement/stretch.html~%")
    (close s)))

gives

An error occurred while loading http://localhost:8080/x:
Access denied to 
file:///users/rubey/martin/Axiom/hyperdoc-replacement/stretch.html.

(defun server (s)
  (let* ((get (read s nil 'eof))
         (fn (and (eq get 'get) (read s nil 'eof))))
    (format t "Got ~S~%~%" fn)
    (format s "HTTP/1.1 ~S~%" (if fn 303 403))
    (format s "Location: http://mat.univie.ac.at")
    (close s)))

seems to work

(defun server (s)
  (let* ((get (read s nil 'eof))
         (fn (and (eq get 'get) (read s nil 'eof))))
    (format t "Got ~S~%~%" fn)
    (format s "HTTP/1.1 ~S~%" (if fn 303 403))
    (format s "Location: ~S~% "http://mat.univie.ac.at")
    (close s)))

gives "Got /" forever.

Please Help!

Martin




\start
Date: 21 Apr 2007 19:01:17 +0200
From: Martin Rubey
To: Martin Rubey
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Dear http experts,

(defun server (s)
  (let* ((get (read s nil 'eof))
         (fn (and (eq get 'get) (read s nil 'eof))))
    (format t "Got ~S~%~%" fn)
    (format s "HTTP/1.1 ~S~%" (if fn 303 403))
    (format s "Location: file://localhost/home/martin/martin/Axiom/hyperdoc-replacement/stretch.html~%~%")
    (close s)))

now works with lynx, but gives the acces denied message in konqueror. :-(

I do not have any other browser to try, and I really want it to work with
konqueror anyway.  Whom could I ask?

\start
Date: Sat, 21 Apr 2007 13:05:01 -0400
From: Bill Page
To: Martin Rubey
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Martin,

On April 21, 2007 11:45 AM you wrote:
>
> There appear to be at least two different errors in the code below.
>
> (defun server (s)
>   (let* ((get (read s nil 'eof))
>          (fn (and (eq get 'get) (read s nil 'eof))))
>     (format t "Got ~S~%~%" fn)
>     (format s "HTTP/1.1 ~S~%" (if fn 303 403))
>     (format s "Location:
>   file:/users/rubey/martin/Axiom/hyperdoc-replacement/stretch.html~%")
>     (close s)))
>
> gives
>
> An error occurred while loading http://localhost:8080/x:
> Access denied to
> file:///users/rubey/martin/Axiom/hyperdoc-replacement/stretch.html.

Don't be too easily discouraged. Because it is a communications
protocol it is necessary to get it *exactly* right for everything
to function. But once it is working, you wont have to change it.

I think file:///... (with 3 slashes) is the correct form.

http://en.wikipedia.org/wiki/File:_URL

The "host name" goes between the 2nd and 3rd / just like in a
normal http://goggle.com/... the hostname part is omitted in the
case of localhost (but keep the extra /).

To find out the exactly correct local path for this file, try
opening using the the top menu File/Open File. Select the file
by browsing and then open it. The url displayed in the address
line is what you need to send from the server. Here an example
that works with FireFox on my system:

file:///C:/Documents%20and%20Settings/Administrator.ASUS/My%20Documents/2=
519
4756_B_store.jpg

Notice that the drive letter C: is the first thing after ///
and also that spaces must be converted to %20 codes.

>
> (defun server (s)
>   (let* ((get (read s nil 'eof))
>          (fn (and (eq get 'get) (read s nil 'eof))))
>     (format t "Got ~S~%~%" fn)
>     (format s "HTTP/1.1 ~S~%" (if fn 303 403))
>     (format s "Location: http://mat.univie.ac.at")
>     (close s)))
>
> seems to work
>

Great.

> (defun server (s)
>   (let* ((get (read s nil 'eof))
>          (fn (and (eq get 'get) (read s nil 'eof))))
>     (format t "Got ~S~%~%" fn)
>     (format s "HTTP/1.1 ~S~%" (if fn 303 403))
>     (format s "Location: ~S~% "http://mat.univie.ac.at")
>     (close s)))
>
> gives "Got /" forever.
>
> Please Help!
>

That's a syntax error. The string "Location: ~S~%" is a
format. ~S is replaced with a string, ~% is replaced with
a line feed (new line). After the format string comes the
data for the substitutions. So you need:

     (format s "Location: ~S~%" "http://mat.univie.ac.at")

If you key the following at the Lisp (i.e. Boot prompt in
Axiom),

     (format t "Location: ~S~%" "http://mat.univie.ac.at")

You should get exactly the same result as this one with no
substitutions.

     (format t "Location: http://mat.univie.ac.at")

except for an extra blank like.

where t stands for the constand "true" and represents the
'standard out' stream. I recommend you test the format
first with t and later change it to s.

\start
Date: 21 Apr 2007 19:23:30 +0200
From: Martin Rubey
To: Bill Page
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Bill Page writes:


> > An error occurred while loading http://localhost:8080/x:
> > Access denied to 
> > file:///users/rubey/martin/Axiom/hyperdoc-replacement/stretch.html.
> 
> Don't be too easily discouraged. 

Haha ;-)  I spent all saturday on that stupid detail.  In fact, I'm giving up
now.

> I think file:///... (with 3 slashes) is the correct form.
> 
> http://en.wikipedia.org/wiki/File:_URL

Thanks.  In fact, that solves the riddle, at least possibly:  it seems that I
am not allowed in mozilla and firefox to do a file:// redirect from a http:
page.  So, it seems we are out of luck?

> > (defun server (s)
> >   (let* ((get (read s nil 'eof))
> >          (fn (and (eq get 'get) (read s nil 'eof))))
> >     (format t "Got ~S~%~%" fn)
> >     (format s "HTTP/1.1 ~S~%" (if fn 303 403))
> >     (format s "Location: ~S~% "http://mat.univie.ac.at")
> >     (close s)))
> > 
> > gives "Got /" forever.
> > 
> > Please Help!
> > 
> 
> That's a syntax error.

Yes. But the syntax error happened while pasting into my mail window.  Sorry
about that.  It still won't work.  But I guess, I will be able to solve that
one. The other one is a show-stopper, though.

\start
Date: Sat, 21 Apr 2007 19:30:45 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

> Yes, that's the idea.  In fact, I also want to do some caching, since tex4ht is
> rather slow: every function has - by design of axiom - a unique identifier,
> namely its signature.  I will use this as the name of the file.

Martin, don't forget that you also need the name of the category. There 
may be several foo: (%, %) -> % functions from different categories. And 
also think of something like

DomA: with {foo: Integer -> %} == add ...

\start
Date: Sat, 21 Apr 2007 15:02:41 -0400
From: Bill Page
To: Martin Rubey
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Martin,

On April 21, 2007 1:24 PM you wrote:
> 
> "Bill Page" writes:
> > ... 
> > Don't be too easily discouraged. 
> 
> Haha ;-)  I spent all saturday on that stupid detail.  In 
> fact, I'm giving up now.

Thank you very much for looking into this. I am sure that your
idea will prove very useful. Even if it turns out that for
compatibility reasons files have to be served by a web server,
it is not difficult to install one and use it only locally,
e.g. apt-get install apache or zope or even one of the "tiny"
servers like: http://shttpd.sourceforge.net that can be made
(mostly) transparent to a user on both Linux and Windows.

Or we could just add a couple of extra lisp commands to open
and send the contents of the file ourselves. It's not a big
deal. The main thing is that you found a way to call a Spad
routine from within a very small and single web server. That
was really what I was looking for in:

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

Do you have an explanation why you want/need to use the
*docfun* name format? I recall something about such mangled
names being "global" or in some other way special in scope.
Is that right? Is that why it works, incontrast to the
lambda function I tried? Perhaps rather than "semi-
hardwiring" the name, we could assign it to a local static
variable and use that?

> 
> > I think file:///... (with 3 slashes) is the correct form.
> > 
> > http://en.wikipedia.org/wiki/File:_URL
> 
> Thanks.  In fact, that solves the riddle, at least possibly:  
> it seems that I am not allowed in mozilla and firefox to do
> a file:// redirect from a http: page.  So, it seems we are out
> of luck?

There is a way to chage the configuration of FireFox:

http://kb.mozillazine.org/Links_to_local_pages_do_not_work

And Konqueror is supposed to just give a warning. Did you see
that?

\start
Date: 21 Apr 2007 21:37:56 +0200
From: Martin Rubey
To: Bill Page
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Bill Page writes:

> Or we could just add a couple of extra lisp commands to open
> and send the contents of the file ourselves. 

Well, that's what I have done now -- following the code in the sandboxsockets
page.  But it's nowhere as nice as the simple redirect.

> It's not a big deal. The main thing is that you found a way to call a Spad
> routine [...]

> Do you have an explanation why you want/need to use the *docfun* name format?

Oh, I didn't know that this was a problem.  Hm, you did it yourself with
MySort(L,<$Integer)$Lisp, so I do not really follow?

The only thing that was surprising is that the function needs to be compiled,
i.e., defining a function in the interpreter does not work, for some reason.

Thus, I modified bar as below. The only reason I made it a global was that I am
lazy.  You could just as well pass it to server as an argument.

;; try it with

;; )lisp (load "http-test.lisp")
;; BAR(8080, getDocumentation$HyperDoc)$Lisp

(defvar *docfun*)

;; file: http-test.lisp
(defun bar (p docfun)
  (setq *docfun* docfun)
  (let ((s (si::socket p :server #'server)))
    (tagbody l
             (when (si::listen s)
               (let ((w (si::accept s)))
                 (server w)))
             (sleep 0.1)
             (go l))))

(defun server (s)
  (let* ((get (read s nil 'eof))
         (fn (and (eq get 'get) (subseq (string-downcase (read s nil 'eof)) 1))))
; subseq removes the leading "/"
    (format t "Got ~S~%~%" fn)
;;; NOTYET tested
    (when (string= (char fn 1) "?")
        (setq fn (SPADCALL fn *docfun*)))
; *docfun* should return the name of an html file
; in case of an error, it will also return the name of an html file, which will
; contain the error message
;;; END NOTYET tested

    (when (string= (subseq fn (- (length fn) 4)) "html")
        (format s "HTTP/1.1 ~S~%" (if fn 200 403)))

    (with-open-file  (q fn) (si::copy-stream q s))
    (close s)))


> I recall something about such mangled names being "global" or in some other
> way special in scope.

No, the stars are only a convention.  defvar makes a variable "global".

> Is that right? Is that why it works, incontrast to the lambda function I
> tried?

Huh? what lambda function did not work for you?

> There is a way to chage the configuration of FireFox:
> 
> http://kb.mozillazine.org/Links_to_local_pages_do_not_work
> 
> And Konqueror is supposed to just give a warning. Did you see that?

No, he says access denied.  But in any case, we cannot expect a user to fiddle
with security settings.

The "small" webservers, can they be installed without being root?


\start
Date: Sat, 21 Apr 2007 16:04:36 -0400
From: Bill Page
To: Martin Rubey
Subject: re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

On April 21, 2007 3:38 PM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> > Or we could just add a couple of extra lisp commands to
> > open and send the contents of the file ourselves. 
> 
> Well, that's what I have done now -- following the code in 
> the sandboxsockets page.  But it's nowhere as nice as the
> simple redirect.

Nice. Seems ok to me. Since this can be compiled, I expect
it to be pretty fast - for a single user it is probably
faster than the overhead of having more processes running.

> 
> > It's not a big deal. The main thing is that you found a way 
> > to call a Spad routine [...]
> 
> > Do you have an explanation why you want/need to use the 
> > *docfun* name format?
> 
> > Oh, I didn't know that this was a problem.  Hm, you did it 
> > yourself with MySort(L,<$Integer)$Lisp, so I do not really
> > follow?

It did not work they way I originally wrote it. See bottom of
the page:

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

> 
> The only thing that was surprising is that the function needs 
> to be compiled, i.e., defining a function in the interpreter
> does not work, for some reason.

Maybe a limitation of the SPADCALL macro?

> 
> Thus, I modified bar as below. The only reason I made it a 
> global was that I am lazy.  You could just as well pass it
> to server as an argument.

In my code that's what I tried but I did not use it the same
way you did below:

> 
> ;; try it with
> 
> ;; )lisp (load "http-test.lisp")
> ;; BAR(8080, getDocumentation$HyperDoc)$Lisp
> 
> (defvar *docfun*)
> 
> ;; file: http-test.lisp
> (defun bar (p docfun)
>   (setq *docfun* docfun)
>   (let ((s (si::socket p :server #'server)))
>     (tagbody l
>              (when (si::listen s)
>                (let ((w (si::accept s)))
>                  (server w)))
>              (sleep 0.1)
>              (go l))))
> 
> (defun server (s)
>   (let* ((get (read s nil 'eof))
>          (fn (and (eq get 'get) (subseq (string-downcase 
> (read s nil 'eof)) 1))))
> ; subseq removes the leading "/"
>     (format t "Got ~S~%~%" fn)
> ;;; NOTYET tested
>     (when (string= (char fn 1) "?")
>         (setq fn (SPADCALL fn *docfun*)))
> ; *docfun* should return the name of an html file
> ; in case of an error, it will also return the name of an 
> ; html file, which will contain the error message
> ;;; END NOTYET tested
> 
>     (when (string= (subseq fn (- (length fn) 4)) "html")
>         (format s "HTTP/1.1 ~S~%" (if fn 200 403)))
>

; You should probably send an HTTP Content-type: header here
: before the file contents rather than embedding it in the
; HTML file, since that would make the file not readable
; directly by local file access

          (format s "Content-type: text/html~%~%")
 
>     (with-open-file  (q fn) (si::copy-stream q s))
>     (close s)))
> 



> 
> > I recall something about such mangled names being "global" 
> > or in some other way special in scope.
> 
> No, the stars are only a convention.  defvar makes a variable 
> "global".
> 

Ok. Thanks.

> > Is that right? Is that why it works, incontrast to the 
> > lambda function I tried?
> 
> Huh? what lambda function did not work for you?
> 

No, it didn't work. See the bottom of the page. That is the
main reason why I created the page - so I could document this
problem. Maybe it's a bug in GCL? Or maybe it is just I do
not understand how socket function calls server function
internally and that this failure is expected.

> > There is a way to chage the configuration of FireFox:
> > 
> > http://kb.mozillazine.org/Links_to_local_pages_do_not_work
> > 
> > And Konqueror is supposed to just give a warning. Did you
> > see that?
> 
> No, he says access denied.  But in any case, we cannot expect
> a user to fiddle with security settings.

Agreed.

> 
> The "small" webservers, can they be installed without being
> root?
> 

Yes, so long as you assign a non-standard port number >1024 and
don't have an aggressive firewall policy.

\start
Date: 21 Apr 2007 22:52:30 +0200
From: Martin Rubey
To: Bill Page
Subject: Please join! re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Dear all,

I just uploaded a tiny toy hyperdoc replacement on MathAction:

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

Please try the code (better in a new directory)!  Especially on MS Windows!

Here is what's missing:

* a way to specify a function completely. The necessary information is:

  name constructor signature

  In libdb.text we find it as follows:
  
  ocount`2`x`(_$,ACMachineInteger)->ACInteger`dExponentialGeneratingSeries``

  (o is for operation, d for domain, c for category) I guess we should stick to
  the same conventions.

  The result of getDocumentation$HyperDoc should be a string which is a legal
  filename on all operating systems we want to support, and it should end with
  ".html"

  It is sufficient to support uniquely determined operations and constructors.
  Adding a search facility as in HyperDoc is easy.

* A LaTeX header file that provides commands supported by HyperTeX, like \spad,
  \spadfun, etc.  For example, \spadfun should transform its argument into the link

  http:\\localhost:8080\?argument

* same thing for ALLPROSE style documentation.

I hope that some of you not occupied with more important things -- like working
on build improvements, waldek sandbox, trunk, or multisort species :-) -- chime
in,

\start
Date: Sat, 21 Apr 2007 19:00:02 -0500
From: Jay Belanger
To: list
Subject: Re: Please join! re: Axiom HyperDoc Replacement

Martin Rubey writes:

> Dear all,
>
> I just uploaded a tiny toy hyperdoc replacement on MathAction:
>
> http://wiki.axiom-developer.org/SandBoxHyperDocReplacement

For knuckledraggers such as myself, could some more detail on how to
start this be added to the page?  How should I load the lisp code, for
example?  How should the spad code be loaded?

\start
Date: Sun, 22 Apr 2007 03:04:03 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Please join! re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Hi Martin,

I don't understand the LISP part but the SPAD part of

> http://wiki.axiom-developer.org/SandBoxHyperDocReplacement

looks as if you have achieved quite a lot. Congratulations.

> * A LaTeX header file that provides commands supported by HyperTeX, like \spad,
>   \spadfun, etc.  For example, \spadfun should transform its argument into the link
> 
>   http:\\localhost:8080\?argument

\def\spadfun#1{\href{http://localhost:8080/?#1}

However, that is not going to work if LaTeX special characters are involved.

In order to write a style file I would need to know what commands I 
would have to define. And if I look at the ++ comments of .spad files, I 
have the impression that the htlatex output will not always be perfect 
anyway.

> * same thing for ALLPROSE style documentation.

That is easier. See attachment for a first demo.

However, for full generality, you must be able to ask Axiom not only for 
the name of the function, but also its signature and the type where it 
is defined. The wrapper could be the same for any function/type, but as 
you see in copy.ad there are two definitions that I have added at the 
top (by hand) that do *not* appear in the +++ environment of the 
corresponding .as.nw file. In ALLPROSE this information is generated 
from the accompanying code chunk. Now that you use Axiom, you should get 
that information from somewhere else.

> I hope that some of you not occupied with more important things -- like working
> on build improvements, waldek sandbox, trunk, or multisort species :-) -- chime
> in,

I could probably only help you partially, the difficult part (taking the 
full signature into account and deal with LaTeX special characters) is 
still open.

Happy Sunday
Ralf

--------------050202030902080207010205
 name="allprose-hyperdoc.tar.gz"
 filename="allprose-hyperdoc.tar.gz"

H4sICLysKkYAA2FsbHByb3NlLWh5cGVyZG9jLnRhcgDsPP1z28aO+dl/xXYcTZOpRUvyR+48
L2+U57ite4mTiZ1LO6bn3opcSbzwQyUpWSqP/dsPwH5w+SHFbfPaublomkrcxQJYAIsFsEvz
MFykSSb6881CpH7iHT767J8BfJ4NBvg9fHYysr/159FwcDocnYxOh8+GjwbD49PR0SN28vlZ
aX+WWc5Txh7NRRQJ76PYBvep/v+jH97SPw/9BH84Wb75PDRQwadb9T8cDY+1/ocnR4MT0P+z
4cngERt8HvK7P//P9d/r/+HPXk//j7149ertuzfXF/LpPFls0mA2z9mT86fsHQ+n7HslRfYk
hcexFqrji6dyzDzPF2eHh/f3947VKY2yIvRHOd5zr4Twsxvx47dJGvG8eMXh90iUe+7bNFkF
vsjecu8jn4lCL4fydjQYnBzCf8N/h5lFEY/9jOUJg75lJOKcvUBINg1Ckd3tue/Ez8sgFRoN
La9UTMtWTzpf5yKNFP7h4HA4YquhMxzc9XYKw43FvYhXQZrESL7gfia8PEji8nZ4V/T2GHMX
gH+SCv7xdnQHD6kbJ0HsA7Cbi3U+mRb7wxLaDBjCyHGphBsscnzIPgYLN4vAV+AvHiXLOEe4
UEzziKezID4Sa5f7Kx57wg0D4Czw8znrWxAIryHGeZIDMtPHGnBIcs4XgrnjGP/XBtckyoLm
FYEygbOyt9chliAX0WcTzUQAA0UYZHlZlIQKP24m8lDEs3xeWFMpi1OxLu0+ZEWSKYs+yKzs
QoCzF4uyAOGXjfY8WZiurqF2f5PuzoEhn4hQSbQ5mPoao0sQvIh9KQhL/G3pLzMQIY0qlPAq
Qy3eU6fqRXxVX9mBCyTAIwGrJWsgtFVcvK2gSo3VBujCDAveS4OFtpEt7L60oGTvLE2WC5II
6D0HA8/nQRYDefiZzZM0189NmBz8gQ2DzwSzP0SWCS9q/MGyIUzbp/GvZdQDf4hGbZjVDcSo
J71lodFAwDEJRUSLkdaeWnLudJKsjcNl9zyNgfGSqP2ULBkMXoY+i5OcLTPwC/A/GKmxS3Zh
2TLwEJwRJWYJhNBkAfgfls9Fu58FGeNhliBuH3EkAJYyL4mRvYzdw5OceZAjLLLhhQKCh/s5
z7dzA04fTBF2CocmEUHAQVhmwUpywhcgkEUa8FyAUJlYL8LAC/Jw47B34j4F05U62T5d2IVa
vei/wIm5pVOSHXVqQiu9bOqmoNbtg9AK2oOotcs4gTFBQt65cG/maXK/c9FarCAXBi2xgtRb
Pd3zaIMUHTDEDRkpcoLePxWfxINyb3QUnTJJBewSH5sCMcJ4p7rLBy1+IdB0t+G6FoJMexsy
e0aoQrNLjoPpErarKWy3fpGOv4LJ9WBFQCCTLRIV/8j9ocA+xifJSlqrxnWdb0LSipcAHlhL
KKBS7SKFS2ER7OYfCz8/g55PDKNxLu6ga2gYu2B4OcykCddjbK9zZoSWpgdgXUZh7No2JvxN
ynXX2YJ7YutIZUk9WtbYwLAFnjh5DG8JgothYSu3MxF+FyaDhQYnU8KmxjLQB2mOJeSaIHmB
UKyuJ8Vk4UKD4rgAyw35uiQzx+YJBJ/oumMfbCEOFguRF52GJftkpKMM6zwJk1T4/zAoSgvQ
nSZJDq5RZMEvYlvAtC1cakYelDzYnR3Df2Pg8rsDrd8VZpXUZO3hMl7CX20ptsxK2zSoEreg
vL2dohqzkGfzsrZWXG/O03+6bhsl7BUijXloIilIO5R/u1VEYGmcsf1Reef+/POS+y0U2nYr
TwFbIUvI0/GQgbYoHULdz9DU6ssDF16v0Uft0NpBCi267pLIY0DKPgOLVT5DIqzc0IOcxP9I
5DeQer2lCBV8BqUo9vwkty2+Iu6liXETrW6eZcCivS1tmVmFR80U88Bu0DrOGnjEPwqeU7Sy
RYCUXpKm+HIdhAFPN0xB4ZwrqNuGkO52edk9QxuixRyJ7+BEG56kRS7u9vTutmEdHTrePwYd
n+2faDU37cbCDSEQNt3uo38fwVZ8BP+O4R8M3j+tbx6j7mkdlV891F4eYmTdyI46kPX6fXaV
3LMp+HXy9xwiXAg5YzRJ2ghwA8Es2Gf3QQ6RcA7B7Czm+TIVDD0WhqwBxKm0DswydJBNCClB
DXwKYnKD6dr1SHRnJFpG4bpMBWiTUAkArSYpfFgbkl+WxLB5JRBCS6C2nmjf6ga2mSAlbuFC
6Xka/B7zUiaww7Z+r/7/mML1FoDzTudriKW0aLfrBwGbymG9WEdcbM4zNhFgIbADSRFLS+mI
nbTx43ZoqY4Cr2qB7RxvtFIFQXXtyHVpEOwPKcb6q+ubXz67P+36v5csNg73PyON3fX/wWjw
zJz/HJ2MsP5/Ohwcf6n//xmfWpRVvN5gzZ5DMn8joxbdS44ZLeOrsye9A9Z72v8765VVfK/r
fORcfmFnz5m1Rz9ZH7DNU/I/lHwaUDPYKuxpT2aaivUZkGLsIhRUZqdsaqGq9CzLkxSwOe1h
m8awBJwlRD2LQPhOxUudsmHILqRBKg6bbJwxjsM3mJHhPgspNKTA1UZbVkjt0TZWnfITsx/m
QUgMbYJ4xh5vHsuylJyPLEJNNuzx+rEsTIXJPbTQLGg40MjTZANtEDGkAuEPWJboAWGS5Yx2
FIZqoNDB2ZOpzA3FF2HIlI9/3NLVYxZxCBE5ltkQoRSeISml/RrcP8sw/JjANgFfsB/gVIK4
vwhhh4CcQKScqj4QBoD0jKwRJ6EgXSqOsZ6WzfHkYcYiESUQo2Kgo8pwQqoxO6AISax5tAjF
ASGZbGg2ME4agSl/qJRUlbvXyiqNKZdP1k9VaCJrIjb8Fezikr0sgeBLp92gCZgoshoLT2QZ
sBtujBKB0yCl4doqAB5sxOMx9C1BC6nAKp+aHodIPBOZs0dDXnhekvqEJiFTkNaCYV2N6wMV
H4bhzunaOq2NZyu1Grsn7idC6iJK/GAKBrh6bC0XY8F/td/68vk8n67zf9nyZ53/j54Njp5Z
5/+neP4/Gp5+2f//jM+X8/9Pnv/L5VA7/8d9VB73vwpy3OQEg3Ez2N4idODXy8UCT5cuqlrq
3Z47TUXszTF5wq0KE9hgCuneZeyFS19o0b1U1wlo49xzd/VOOaZzlHgF004INdpXqe9uWq0s
fTwNUohHpvl9Uk8ea0AyDjJQlLfj8SFkr7NkAqHkc3csf1Rzvp4n98DBDxfnN+/evLnZcxsN
amYQfiyUGmIIfyZYG8NvWWzMCrvWjIFMRZnydBBM7Mb35rcUldWwP9wf7R9p4ZBCr5NlShUL
mq4q/VoFMqosyXnSgZBFCvNdXXdSZfZxOBfcN0Xuj6oZG0VqUnBIla18HORJVU0qsbmyYCDw
PK+QZZMxPVK37ClsMPjBl2FeqK4mqeIcjzMhLilZq+sSJ1JqoijbGo/7oxqXZzhTc1lihON6
7GWQYfJgS4wFU+auYXX8t/ByPOsUPM0wqMEoRhJxJMWlAirkycV4vMagBX7uA3FQFGhKnnKm
UbGPFA3aStyIsKgwwSxfXf7j3Yt3P/3nxbvryzdXRXmm4yPbiBuTdScJqcsdi2iRb9SXJpJK
InWNSeEVxS2aRJ74fPOrey7PbG6CSNwBJzDhBV13UMWrZZy7czC3rHoE77EEc96T7c/dHIYC
1QA9kmzDaPd0sKchn/dVsxuB1oNFuNE9ErC6c6ObNU5ZiBrDqvWDGeQzaF/BNF5G+8O/DQds
AAbuwtNEpK2jMmteaAJzxdpZHaHsUWRx0rr4RdIpuoChvewDF1j8dCOw1LmbYDz9A4/hB/tW
TPDrNU/x68UilU8b/PphGSvYZUi9yxl+XYsFfr3xcvy6Slb49VJ4MLu+mp67EXQ8LmuS6ohO
rquekRNag+0t8BmMZK5kxlwP/SD88sUin/8dQd053olhQxHJ0h2QxIK0JoH3xKyKdo1w5S96
0slUC3tPWeEiG+udSXKEjepUl5hFfSrGC/eXsVSUORHeJ++ihy0nW0eOY7FtKLracURi0B5e
7QE1hhWRceL7NDk8i4RVPMbKYu20UHlLdw6iCZWbU2VHjYBW3i4E+GgQ4IPFqliJmAhoVmo9
NFLTQCnjWs2oFGpCAPBwHwTd4NA1bunEMDmnxO0+0ecqWb2ST5nkFNNfH+NqQKQyXr7iQUg+
U7lEGTCtRJqBtJVnxEz7Wxps3+ZRlgCJmd2v7+Sg8V5OvwUru1gHGaywiro6zbV2V9lHIc7R
4eDZ4WjIVmzg/Bu/6+0paBUPfZCXciqZWHhpQlM6y9SHZvZpcvvE01xRqp1fV2fT6iyPbgrg
VGmO6u5lUe7oUxV0ZqOqSulqpJunwQoPZOn40xaydSOtasUnPaJ1ik5zIwdRWK1jatZxQWvQ
uBql3MqWM5It8wC5NThAUrBPYwCid6sWjyAc/DFJ8PahbQTmpquMonSQaBcIa9XCvdZ1mK7z
WhWHNA5TOrGrkKdOvH1w2HmaWN+h9HBo+41Hj7sIbztY3DZPOnVRE+qcyCfYbK2gb775Rlkm
XTxDD7XjToZWp3X9oPPSgWUC1i1l+gludrkoFv50AqhE+ryAwIANygM0KgB7nqdL9IoWilt5
JijWdxUyrFC6+pq0F/Iss6B4mgcwmxLzuhjdJ3BINa/6ESmEclQN1APVhYMa99tvUu8V9cND
Wlu1G3OwLrRTlAfhFNnq6xWk+OHNxY/VuV+jv9QRhI58m4jtQ/bfjlutZuAOHdINHbmqczpz
NUQB4ETlmSyQLnQrylENaCMpq7h6aDwHIApCe79xPZ6jcf/T/a/nIFmMEQjGpB/ykbIZUHuB
D3kib3WZqyVlWe1QOh+DPhHjdlfE96oxgyRMtyLCCgTv11VP9mjDuD0Q0k2KvsBvyigM0zpi
J5sWDiKjhNWyomUa1uJdCL9TUEqSbmxhgKWkoQwPsmnpvqdBFhbYwCeQVkd6+avtUjcH8WKZ
u7WnbkADU+8GGRoI67dyybbPMIz0YBG01n/VXY+kmmzQ6C3E205F6qE2O1t2u++S1YY12AIb
q3cb06s1o+I7JW5uH3U7Q9s0LV3iigr8tTrxpny/vnFGWcTzedlszDbRpOJwfP3m/bvzCyxv
dFyurDrxmpxbPR6WPTTcHG8Lg2fkkywJIaNiC6DYvJkEVK5T7xJn+n2SfFQXrKVTEf4YqxQ6
eSMgfR2vzh2TVyjngIGCWFiLYb5mQ+dUpR7gBuaADtrH47ESOEQdPUY99THHdAAydE5wxjhC
nhWNMf0ZI4miRX2kAjvYEKDrjF29YV87sGK/ZmZl62AZ3wORl04djV/pWSKhFgqnLIL6Tlct
OpYMU3Qst0tLlbKPtpVjKgCe4LZyfKekV9NjZsu/J+/AVDH+NE0iHHvKVL0NKeG6tmTZJV8d
fV9CmlKF3vpFDkDyVo6BCed4gFbDR9c18NRSKQV5d0z0XDFg+G7a0e+hXg3uIH+qyIOhb00r
znlM6QQsN1Ypx9FOPqM6HSoVFzsA4E+zvGsq+Wp/6NT2CW32EHvmiacKYkUIftysFlfWAdFA
dBNeplc/q/vLam1bF6Fksaqo342iW4paYmaAZrlooCiLrALflhM0Z2VfoCoLLaZAFnwraWXS
99RsH0SlgjPIAWHLpBVUa9SX78Z4WJKD0EhaikYlKtqp600X1VZ9/e1FtTM7jqA0USX3r/lm
Iq4/BgusPqC4sONlcgXxGpjF5dSMvMyKHAttCsSMK7ZBT4KJqqXWwccVj3bU041F+jdTLwEE
41pEoirI60ZXlxykUjHrSEDK/X7/jF3/x+XbtxcvwfPVNIo+TxtBS0a4K+gahIgWSUon0aYA
T0qoyRuQ7x/htof1a5ka1hVnB8hNC2nYmsVZUZ/K5dX5q/cvL1jXAFdvwU4japN4tnqC15fX
15dX33XiLKt4Edmtbp65KQ8yge8TDdFcamFEUQsvi9LGYnkUg7DoWLGm+lti/FdQ+bu6S3K2
12PDPkaZsvLTKHtTB+6L+EDxhAMDRn3baVDSZKgcQP9RP5ti62zKntAeS+qjF06pGSI/PIny
qeUpjjjuE3JGcarD3uBm1Lh6inWoVPAsiXGDcvZqHo2mqxwQnQVhVa7qMgVxq01WM/aPCypD
yOAfQxUZ+revT+o+SKdN+G7IyUMH8iho5Gi6tjvEWkj1VBCMxmJVWcmp43EAOkeyGp14YC82
6hxNtEbihrZIplPL7vRyh1nbGJz4nlyasqSucQBi3juhYzDrxMm1flvnek0isIrj+/0jpCQ3
H5wzN+GObpkUPCvJIVG/bLNJYOIuU6Em3epgi3y9FINds64iWgOg5TcPfF/E9s6XTc+Up96u
+s6b1VWB3a6Ml8bZdlRnezpLbrFhDtjGPPbmSUqMUyZpt1bag6VkLX6ZLFZd2kXUoXa6iJly
ERqFXKgNGpNpE8CWbdeoLTR1FIFUm8LVBTYyLMrBMKV3rd9WP73ISb3ql144BhjlsDWToyPZ
BiXrWNNgVQcO5rl44Bsy2TyB5YUn7dmWV9bwbZCiI46qhVHNq+fVK3Qdc7JpVhFw9fZ44/Un
1d35uuOFRIOhsVwjCthsk5pO1dV+L3KbpGR4rUWtT1Izy6K9Rh9qAYQXQx++PnSrKvO629yB
b7Td4pKu48cXR0z9uUJ/uz+66yp0W3XudaO8XaNkztY1agt3VUKv639tGUBVgStMjmn0pWpW
dEJnimGj8ozqPJLq7nicfbVum1IdGTJuJoTlWa8srPsuQTx1RD7/xfHmh7+ChceghbzsESBT
uaiFgBx3DQFVfJ0knZVNsJcNUhVk7ycgFGRfMw2HV2vxIkuD1bTJbet2juQ07WaWuiL0B7fm
Z9NsqKNPQHfV0mIPIeqIEPZFe9brIInqU8aWvi9WIsR7qS0xqVL8J+ZojdDV5k/wp8CMTKR7
Xb8KJiRxd/1C/jUPg5d68K9O8PJW/WhKSvffbdG+he0i4l5W43EWL5uT/7ENhbVcL2uhews7
Wg0Ot7gmuu9ev63BZPfJ2gGvfTiD+Kz33dV7Ji8rpMILKCWyhl69/xSzV3QTyAYSAjiFxbLi
qe8If3n4a5we6gtDZtyN+DFYfX9T3sKP43nelKkJS2T3VhP0MuEk8yDpQxCRC0lutsT061CN
tGhGkbR5+d0kCa3bzV13Oip3BykIJxY19C/enwPNLoEdZnghi6dghktPhrxmlDrs3Ta/nMeE
AUb1eerNg5U4pBcVs8MQZrw+xIpJGkwOoyDzDq1TZYuEqpj9FhJzES4Oz3nOw2S2FIcCaYjs
UJV+5nkU2gTAdlaBuCeGylv7qSlk1deXoNu0ulVs9Yjjw4cPLyAhDkWQQzRWE3wK0nCWcdCH
iO8Xh3sOzy1sTedBi/59HOC7vXWkEnaJXfYyXueXb9qwsFcHSSMqErOyEI57MHMaHQHk0gF0
iGaHB3GiNzWtSzyILDLx80W8OpdP0AXbWHdXMWigA36vxc9L0GDAQ+sKZBWjWWTGOqBvHFuo
5h2RGIbvKWpZLJrItr9hLq/rDP7mrni4FI2ZjIQ8HsK/ejQNNCZVJeycuiH3wL+YxKr7WFv/
ShJ78N9JYr/lLyXpwHaaCVxYtRO/jomiKIu+zpDki4JDN01AxdRXFo/x/gSPZ6FAeo+3IsG0
xFDlKZ8EnsRQL5HWke/A9hCO6BLN404N6olReCZNbJeGUQRbQ2wZiHYae3GTvEx29Z8n8Qpb
8RWherFNVSsghpiaQpuuyjb7VOeDquitsXi7GJDWiIeJx0N5SQi18FdfT//y+Rd/2u9/GAv4
bDQ+8f7n8NlgaN7/OD4e4Pufxydf3v/8Uz72OSfdvVHJde6tZZ2AGm/T2eSuu9ROkAPn+GBw
MKjKc43qu4Q5OVD/TJnlE1X57nKcpueM4N+znVW1btCqJGZV32ieRSp8DVW/NFOBTCBwsGDa
93GQqJlpqV+Mt/6qkS0x02+9ea8wwHgqijfv+NHOQhophgDzv+19aXsbN5LwfF3+CkQSIykj
UiTlI5FDh47tTLzrOHlsz2x20zma7KbYY5LNdDctKe32b3/rwNkHJdmK/WYfcTIWCRQKQKFQ
KBQKhSP8fw2YtcAY4Dv4/xpgMtUpsD61vApkQmESYK/7OYF+XgeqLxUq2LsEe7cGVvuYKNAv
DuT/NwCz+4ddAiqogXdshBVodVsENTfcMeDlEPXdzYWR1rn4Xd8lUeA0FZz5kve7hg9ypx77
xNFCWoNDzRrAZeFAYInjPed/Vf4jQ6NB+VrEC30ukP+9weBIx3/u0f2/O4Pbd2/k/4f4wPgf
C9xdt1rB6+iYrjKjdijGMMPiU/za+g/aO4vTBI8xE0pqYZEG6FlWA9/GP8ei3fWD1n+g/i6U
NBlARnc1FztfivtiZ9S60Tk/5Kc6/6XB8ho1wAvm/53+HaP/3R7cwvu/vTtHN/P/Q3za7/9p
wf+EMnPjTV90v77EdV8otfMkOBYWw3WXpwevRb/bHwj24e6jD3f/i+N+73jQF6q8eHy2EjtO
vazTYVQO0BD8efUaDgFEFDoRPS8oBgmUj6cYRhEDdaZd8SRTMWbRGolxGNARw0d3Q7zlOyEn
TBCTHJgLQ24AhiwGIAxRQf7pWJVyfFc2/y611LlsK5sVpQqGYkSMQ74+o/xETKRNvDGMcfZO
wzG5d3TFXsOxAxKaiHsdA3sdOMRL7OZpnLyioCIYRyRC94jxGn1VYCwOgRQUbCKC33h2J+9N
Ybdl9JBpi2Nq0jVtoS6T/rAez6OJeBpNYM8QHogwonGQd6eAjY44eiaGQ2EYHPBE7PmZOI/X
ibxDsA+NOBe4ZumyXYqRgkmpvoulcAEOiQ19Z6Il/Bb2tXVa/DrK2IJG5flqNe9mZ5lwP1AQ
OdFpbiLbQYyRZFgnBmrRFJPkYEIAAlWYLm71B4e9vsbRbV3L+DXflJdeIDj9Hv7rxZNHYme7
j/N5ewBzePtIbN8S27fF9h2erbm56ygLTV6nsvl4vlqXHUA/8KINWdrcqt5LcFQu+eubI+XK
C/G6prlF61lMs7giVFDSzc72f3aoA7vDXH1/Fn8vI2U+kCFiXEo+C08fqosjyufQMq7jgfvg
55+asf1snXYrKIw0vSSvSpmHjkF2ntVQob6/PI1fxi9nSRjSZWv5jz43Rzu5aPjUouhXUEyj
wu27gbcO9PHWt8x/kL1YzSNy7qY0E57AOOSWQaV3rRWkQMOaK3kOLqI7uWkpNydTlvMGRSkW
odUHWbF0acEU+v0g+x5Bt/sjdJfQsI+1y1ED8GC0feSAq2AF4tPto08dXwS3AU85Kp8ZqVpY
EEznIJ6TgL2+rJuK1dh+dfjZQc9tu8q5XE8NdLWr1WaWrlJW8iXf4H8asHRB4pE2/hQ/HTXH
lK0YiRDZhjizR3XxZKu1/zMtVf0+EbYdC5VqX31U7Qqo23jV2ooQyi2vmaJMv1p4ea5UON2t
HBDalKJbKhWbHPUBvfyUraQeg4nobT3cUYK2O8+g4WI1k4DOAFgue+xJ6IS/QLrltUWUx50p
pBwPNxajcBBWIfzNcTOpgLQ/ITkz9M6Np+qyglf6LW22bmKur/eEm+dAldcNM1UL2yxc4iu7
WG27399edfO53k91/y9NOdcYAfSC/f8RxvyS+/87dzj+562jm/hfH+RTjv/5dbT0k/MfYKOZ
yLdX6iJ8nh2LH+1wimNTqti7c/dADAYH4u6+2BHWLfu9Hw/EZzvwz7P9e4Tl/F2x/N1gebeQ
oj8eCwpwSts8eqgB9lQqxKQM+8iGANiu4vHBkg7wMwx9WcX22bHAVv24Lzr3xY+FeAC7gTSN
J5G8tanCYN7DXT8VV/ErpSMc7Cd99agDjAdvKOC/nR936up7dix4mJ6HKwyFgle0nlEsG+7U
A0Fhwf15hyPcdObRK9YZqKvKIqL6ZT9t0xRNkhzANtUqhkM2gOTGwYo+f4RJ/NWxaCNtvo7j
eegv75VAoBUXQLArj4T5zp/MgGGfQANOwqQMOo4yQIZBal24/Rr0kjNqomD+N7CFT4/w4FCu
1SMeGHybdIdleEKDWxiu8SkOe4pxW/2UqY3MhWqpDgdK2lwNt3fFk6WY+pOMgnsmIUeHISTS
OoUMWq4aIbsqwC2ZBXae7VA78NoplSbDFQwXmlrwQZv1yYyjlEqSqltIkACES3WE2PMVsOQc
jVJBhBthtqMp9Op9FEnaQvBDAkJnuKQvrhhvl9nMnndoktHTWEkC2JzrMMBoo8MZZQxsaDkR
TGM55Wxswp+fxAnw68IYCOOFH9GcY0Y20wNTn+1w0Fs9TuYlKbrjm/CjfjTIMVvv9LwXLe2I
ROF2XXnB8X21vIiyc4cJADPafiY6RJ8yaSnDIbDUvzEiEehoq3VGhkKC26kVq+sDcXYglvti
KNbCmwRxJs5+We6ogf/GCq6LkduQGsgiTSNPTV1qGqq4vlTkfIfvO9OWBR/NmsXzID0GoOGd
u1z1YPDL3WH/zt3+oP/F3c9vfXFnR7PSzjlA/X0wkI28OxwM+nYkWifG8sdeRf+6n+b3X+W5
3DXUcUH8197RHaP/9W7T+6+3b85/Psxn+xqiqW6rf0z8V/p1xfivVGZj/Fdd0fu2uLU4F3s7
0fIhiOOHs/Xy1f6wd08l/ku6mOwPd3d14gvWDpy0CH06ZcYLjHKQ7g87fc4eSXVCxdvcH+6B
vnqKMd/3vry/L9UkkLB7h798+WX3s/v3h4eQardp2L8HCxys4PcEXsq6V+giTsstjYvReaO9
nTdeul/B17tnrpLZiFtGF5IY0s88uTTv/fRL8fNnyuuGfuwXErMi1HBnU0sVFGSJ3V0ouQ3r
qUKIBz9huf1YOwp5q3ClShiGq3fGD/Zoo/BGDo7uiRzEzR2RQE4/JKKN3fADU5gqdDRWq3Zk
rVJWlcVg4UYes+GoxeLfcbTc2/K8BbrdFR5+llsHosKIoiu2IMdFUYYibq3U4SYZchuSW+Sq
afqXolfu/uEve0Co/cPL9ZyV1r2d/n5dxZMZqED3xDZGzkeVI0v8CJ8FgJaeoh+8KZPi8OS9
g9p6isNDCwnsFygoP4UxSQ3LrdNZhWoH4lPQjxJ/meIJ3AO1pXgJhNrb+dVqc5lTVcs3NpyH
2a7hKeQh4gM5okUrXY9hB0k+YqBIinxxvrcDsmf06z3oD75iIXbSewrMwSPHhUQbHRKgiojl
tsVp6GyCbOVUNlBwsgB2/8Sg4VA/B2IHtV74Ay2Af4NwDrIVkO/t7h6o/4A2VI4EpGqBGL4V
h57Umve6+87ckdgBz85vhrCMHROtOaKwiZ1d6M6uy6hcIPxd7OY4qTWC3cKWMDurGPmP7OWy
dbor91yEBImTtMzqPH4vXj56/Py52IJ/vn9+XPaCOlbdlc/LgmYWdCuz1cW08+tPvZ8rMEEU
iq2tumlCwwGdwbCvWaJ70zugXu7X0K0EiWB/t6cgjqzoDh3exB1CAlulEKNOqPfSDU94nxo2
vQDTAyKIOuDcU9xkE587d4VmyJ7UtEJNE/hrJlT9nLanDB4+yBljo3H6Qf4jpg1YBJsAGxl/
FcLOCxe3A1xb6uq1aWBX7FDjag3gopUGSFw1jXDK240A7oByjAeWHPySnKR2cwgM2oRpap1j
IQEFY/g/bivhD+5YUWLsWyA0616FsC/mr0RrK59PafCMTJY2CfqJPBuePDSY+ju1ACZ6Y1ku
QUeHbw/3cJbu4S58/6s9bPgbrHi/JKAMlrI8ov07pA1qGD+XZCz2dn6zSGlBQhug8NbO7hYK
5wXv/VfnJT2QK1G6CgBaD8LQ/tyypLhrr2yJ1X5XshB2agSI51/yqkpjtXKnpNLYFezmRSnX
yCi0q6XcDUNFFNLSALFbrtNt1F7+04PO//78k9/5A/72Ol/8/Bl+dxKK/fqGy9ZtebKqnf5W
TR/qu0fNDmuwuhK7cU4dV8R4tbBqV/7yf354XPD4LyjwXhKerOc+GnDQQEsBqC6DTiO8BM1q
EdJS8w06rh0TYbY2jmpI3IiGd/WyJUbI7ro8qHjcjH4NYmAORcbggMqgdLlI+hOblLRbw/Ma
YXnlLC0x1jQl4VeaqJtXkdpF6d3k6YHdZqVVCVKoEKxObmkT7Js9PvrZ/6pOfF1dIPVRJOnk
6xmdxpH5s8ejNBz/h9YyJSqBIX7ZxBB73k8XSwTv5/2v9vPLLnySU/INa5ehoiKfxTwpOg19
7c/xdnTwg49xofBlgpQHHTT4A1DbVT8ZWx3BD8zkvxTBbfh6guvGPQMkD5bBC5Vj1FaaY1bT
yqsbLVwIRDYJ5GvgrnUawjZEbFefuHVnyJBWRgWyC3t8nhnuKt5YN66smgsqa6teEnPT+yLf
AuxGdXz58ilm7dk06Yqtwt6B1C2OFm41UkVuRqrYqqw2AvHmpXEr8rpxay5t+lHZIlWaWb9v
2yw9jgWQp6Zy+Gw9i/lYDot06PBIDQM5f7vbPbdyGbyX495GJXWhtCuEGeFk2xvCwhaKah1h
wcvCsWmiOVIR5+kqXK4wGycq7Faj5Qn9JJNDjSUgVsByBk0Y2qxb6v+2CNPmiJ30niXBaMbs
mSZcyj7ADSjJpT23OQdCV2kNId6hf8hd1ASJQPLsbiJDLbkvoIauXg1Gfc3vPxQEWm4Cmhys
FuhyE6sBpOuRyVxnY9mVhN9RNFaLIyG3fmutpDyEb9yWV5YVVgV+w7UDzU3kIi/HGX+TGmyt
NsrkY4DVi6gV2Dq2YHMOZ0A7nbaRkK7QBE32cz/NLMuRJA3Or8vx08axvFclxxY3cSfbWTmz
m1pfbeEQTbAkC2TlYmXxlH7BZeteiWklf6hWpa6oaFr2NJPy+meD2HypV0f1c6OadEUtabOS
RGQqt40tj+lne93PvtqHv8f8Hb+6PIkFh66Ko3AM1fa+sqDIUuVKa5GoKSPVXUUXYX2G1jL8
nQpQ/1+hS1RDxotKsrXaLupSu1r0W3nfqalUashaW6o8JGa8GtqqlQ2rvo2a3lW0vEZuYXZ3
jGVlGVyxwsmVCvUrVKtsG7zONhZoR/MyluhPd23WgBQ+6mEAj95ZeMM/3tAP/r51wFNz75B/
Hx7ApK1bkLY8q9ROKktX+qvGy5rSqZnDLMtTmDSHhydu0p639ybfP/R+6lZz9t8U+4dd7+dy
Tvvwh8fPy4m/HnZ75TTvl8Nuv5z49rA7qAB6h90jJzE93D7s3lJJZmjKHXdmRnPvRY0uvO+0
QRx+cuhtfXKFGmEW11eorLsN07d2lu1XeVi29IIh9egQRj9II8qkzSE/LycWkFhUR9Dzfq0Z
Qs9DO2JlFD3vbTW5DcntcuI2JG6XEz+FxE9rqf2xvS7+//lU/X9MRL/rquMC/59bt/rq/efB
oNej+D93+jfxHz7Ip229SgizhF/9gy+Dfuc/1/MO3itttUuePP0vvhhQDr4x+ghvHwbiQZKG
y9Bf031f2Cmyx3CqrvxOkzCEjS7tmRdRRibBJATOC9YT/G5dAQYM0q0zUOfNrJhGEzp1xmhz
uIH2JxlGzb+OS65tuqf8MAnxIWemB7YonfnYiCQ8oWu31Bi6pg2ArwT1D90wT2BbvCZNGpBI
TxMZY1N0u112WFQJ8Ol0AHnAPq6ULMbxmdjDf3w05WPgvn2DilthoVIJjEo20sS9EXtAnNjC
Ax8si3QbA6vj9/IH8JBJIV4yeVOgvmmBeQOxyNMwQx/T1GqPlc211X2gBorQFE1kn+kJg2V4
KqyojylHBcCzgS0m2JadLVZr8s6XDyhQN7e8KRBuS1++h+KqiTIvWeMT1NTA5/B1iw6/OCsN
VzLnRbjaQm76n3hNQzyZ+csT2lSmofQ6ScUej/KWCS65tU/YzmPkeyyHL4lahe0LwvEUStqv
VG6h6+6aLqUv1vhukr+cRLA7hYaFKccMsL3CxRYPtUsScv1VT4Gk5RooPAFdS97Srz4y/3Cs
ry2xJ9svZv5r8iUO9MOm2CV6jW/LlNg6lteRObaSRgTMsM9NfkAzQs4R9GzGx1FxipOdEckT
LifxOgEgSLQ27zzggMHqHnDqkyk179Rn73k/g4k/E2m8kFyw59P0ySIYkn2E4JYTNumdrDnG
3OmIlik+IxigBHNIphlQXVljf2stFpQwQGdo5ZkdBsc49b+Zxz76AOmgZgdyEmKQTuo+PmHQ
oYkmw9sC287n2B7YipM023uBHeMqSYiS9AR+CuYhhYXwS4EK9lWABeUOThhxG08RF3RMCjMo
yMJQAd08gcFDwX/AcRHoNrNIz1OML8/iDh8XiJMFMsJ6seyMySIIGLqaTmb2O3wZxCFPVWwG
DiNQckvNzC19IQKnKw8K0hv97zEWgx8gW8vLOLEZP46XuuevYF+Dq0MsvBmGjjuQoRR4ftJc
8Qh2yxk9EWVpOJ/CnAXCh0Am+OuL33AYgQl3BTE8W2JBXHkjGDeUH5xN77GwFDEJyIb0WhBI
zEU09xNekTDMALCXDkKCz8FY78seCPdl2WNusklwpjiWtTn0WDcSZ2vin1od9HkFiOg6iqaw
0+xjoTpk5pAaF5iP60xMw1OykYE4K9HA4AJBeqyukOCUAJZJ7gktb+lCQMAPQGtR3tXFQdo2
lQaRfEHhb0NURB4QixyzmnEPZhZpJzDakhB052Dsw3gr97R4hdkrDvuiZg38l2Y4Y4APVknY
YY0E5fWujq0xDic+itAnJOFxuF/RBAJORUETkn0gPYwWqLbUXyFbgKCESfAMg9PAaM3DFGhN
r5BItYHmqaqw172N1yVM8fH6pIMaVPd64rqgulONgdH4BjQIN1jAK2qRnJHQbiNb0p9blUdr
VbhxOTvVwLpSF2+tW5Ik1yGQaX53eDa7jFz7SHNRrV+qS+b5rtJL0TXLIl+Od9pTqfniiqXC
1Vjza5op3LOjVYayDH1M835vldU14ZIkqWkYvueh65ewQ/Oc6xvRlnMOGK1lpVswbYDZI4Bj
uXiyR6y0qGvjwH6r/GQ5hsIAKdICBIvQT9EMiLd3AtlzXhdx9t6D+QUzEeYS8YfJ9ji/RVG9
Yai8P0beaxwy7zVG1+70MdD1jBJmOgF5tkRwBmGyeyMpMrp3sfQoCFfZrHtE37lmQKIe/eB6
oFr8g0nURQLLvdMAMgq+xE8ooaIMkxCOXpSajkfT5DT3YOZzocJKn3E6F8UybUVfkkch7K6y
KGT9AatPW8J6ShVpgk/OeXjqgN9aGBxktIxpOnLsDzJ/eIzp/Av4QBXrFd/qo3eUhLmUx7DR
NIgWlDWN5qDjhNlkNoQulXLsLGWg5J6N+Fkq6hm1zzwFQMFnON/Du6Gjk/k61M3rHPUMJmy8
HGLGYoOpQaEMbvY04v+cDqu2tcU/8DKuL2Sjz1lirWI8NCVxTZqTPz/1z1MUuhlwMD00CuMw
DRPQWkOJSKokqgZBNMVoYKRsE2VFia4g/EmpXAPiBPRDiQmWkT7aQA7hX3QuxnvAONb6XjBM
LYDpdQf927du8/LMh1dn0WK9EBINzJvJmnxjYCIGsA9I5bNuc9hzf97/YnBAGiFVBesON99U
IbFAEajoqNfvSpZRAkfSHsZ/NV+nne5tTy2szHGbYAdHfT19L4KzhnITGKzkoCUwXC13iP7n
vTJ/EFvgZffXLGQlFp6k8tVfnHv0sLqI16j6Utg1a3VrGaYafSfxi4FDDFWrllj2tJMlOrVF
OvVlSlOV4vu33ngLGGNctB+Q9KVGQ5sPLKAhTT79U2adxHYO/upSFHyURaB1S5loJC1NVPji
k8D1xpJOQmz32+I7stjw1fXUaONiD/Uk1JiqMnyfxCmqDpQlC3i8vbCSWoVcR5y1TC4kNPKv
wmRJIkmJBJxCbTQRCJLlbB7QNA2VuLSf8AbgEeuLhgeg4radg2IgVQHp9I7QEIZ6R4YJmG1k
yPLFKgontCkByEjfB17x9gwJomwgzgK1T9skmLaTdYKuFuslaKa4swGx5FY581FCyRCEwCBd
wGRyyauKtvMoX5kaXbUu647l/B56y5bpzB0gXCABsOs04FAaJphDb5D2ivuG7kc8RrcWmjPr
jHs4rPn88st/EhrRxJIHopmPJbsC3y2XwPm0SLAooDaPNBIjQzijY3AAm8gACVKHIZsXjBJt
DvT6x+W+LM1WlwL0hCYOB/nxUFNlOxgzyPoFob8nQooHKHQANQph6M47Mzottf61+brNbopv
iOKDSfSOtEZr8xYTVTdNPcbcKBHkIGAZC7RuOOoh9eqvgGVCA+J0Bl9fWdD0uwaY1aKh/NsV
TMqi1L2v4zN6VJoYkzSozJJWTP2/C4lEP71szf62/XAuboEVC6EkG4fdrvTfKvFR93Or9bhs
qrVYqsP6rW/DT1UkHdkunoOApFwY1XFiBBh4HeRJqkVWHDezcvESrrb2Vk9QC3D5xWqVzej3
HQoCstNZPGfbNBlzplGmx0qPwjTi+AgW52sW1xyMKEgogfJDR9JVPE42NhsQN+IVomF9ytto
hyFNSNkB0KtuHp5F4zneh5PWIKTAseWKo1ZmOSpo9gBtw+ZpSFpEy3XqjL6DAdej/tHddEXf
Ovy1qtUS7Hr52mm83TG1M6ChHEE3cw9AUCajHCd6WL9xckDPUJlBtYP0bSvBRmxjwXXTKWgU
eE3a7BR2WQRkcUUWy9GoB6cNluwdJBRa0HZwngbVcb/MLNY84TCDkRtCPJPS3FiBuAwyHmi1
CjG0yGGiNhqXkR8IugM1UDvuw2r6mvfYkjz70pCMQoKMzcCfa1iVax75tKZj3cRXGG2I5gld
naJKJlu917T8hm2coBpEJ2jA/CdMPpBzZB3E1rKS5VBAL5tRZFA3Nj6KRKeuAxWoqqFOKRu6
zxSUEqbrOl3hOphJY9xpEi9P7KnZOEbT0E8jtRb+Gi9/xfbjoSINeibo8S2MgtvY0Ka5LEnO
DHNf8bvFbi77ZjHsp6Cue6buMq86FLdpXppLRmSi9qx1FJvL3PLcRru83P2Wv7fF87CDrdNK
LB31pFECCiTPPoXUlK8ZfRaQjZPfyAfkgrHLym11pVrJ6MAS0qQcs6SOUFQbHlC7Jlc4d+qk
c6d+SC2JhN/VHk5/K082tKWgEB+yFHeWwlMZxQlvcFtaV4kvEJJFkI/LGsgFfJfrkxIjyE2J
cMS90gzbJIWw51oX4IE6BW0ziPB2S4A3fhyEtjZZmmwX1+wARNPXcRQ4+gD2BsQIrsxs9INf
zrRoIgDeCi/PgbolXI6R21CeD1GmzBlBFJSUiOaqU7wKF+IBXZcOoGiChsreuGlpcPjhNGBJ
8MeolA8QE4yDhiFCw7xkbVRrIMZW/eqrr2xQtNKIKAj9cn20m3lTrkP17H9xO8db6kXoLzGq
+Sv0qhjP/eWrLnpi7Gb6pEvsnayh3H6lU6wKlAktXHkhU2aOrbRKAObVCp46LpR5zg5HGey0
2a7Cdtb+bjOljS6lNlj4JLcswMrdEhfBNj8bHq8ztBTQ9zk+fFc4RkPLvqitTRivWm6i7Q6y
dV8Jv8rCl8Pw4yMCqwTDgZkTKZ7ZOjwWBbayjUul1reMratShVu04NUDVnyOygXNV+deKTSf
1Ettd2ULrbRrt1zTv31YgDYReV6EK8g0whdvyavBHHF60mtHppTGqMYTQ1R9MDipHCtXlyhy
PGOhBcZGo78OdTXVgLuqikKUkWC95mBSDI9UuxAJdPzb2rNFChhuxpNehJBSGs/10IjL24xa
ujgscmeVsdXJOV5Gq8LKT5S9yTmI7QrxIgSQ+BRnepSyIUi+GgGYak7aCYs2pQGCH/Bh3HiN
lqSZD98S9QSFrIN8I1rq2K58Gk5WCTJ3SeeTCPU26IMdONyNHux0Ly8hLEQ1pLoDz7G3w8w+
3oimU5/lg8mhM5JwovPaMhNq80ZYJ0pjVaLjjXApnZ2vZipp1xv5k0lE33/j7/xjKH9EhFI/
+Mo2SPniK88klCSP2PEHxXO8iLJPqBAe/54DbM5rAlWp3meVdk8EK7/iinKXuzHN7Go8cslz
UkblJNVYOq7B5NEUtKcZH7oo6QLSJkF1WQkbLGMbvWR+yervpfN4tTrXFPa8EcNNEraiCpj9
KxATrNHJs2LFdfKwOxV7ygxz/sn+MQe9xnk0Cob28SdXAZqEynMMw9fy1AUei39sd8wP/qn6
/9IjMx/u/c9+/85Rv2f8f/t3Kf7z3ds3/r8f4iMfFSL3305HPrCTrlf4YiIpEJSNzxd9/2z3
JSrh5AMSBpHctONrRJ8IMjZ0u12C7vCT9fi8+6FE1V2e4rF2BsW7rdyLx+E5B9TyHmRf4/5I
vY6UeyfzeOzPcbqLoScK1GdITwJs4zh+dSBW4ujzvno7MV5lIHVYTmb+SU5iYnmqE0Bqn8Tj
8Tws7BIGXvtmWGW20WVhHvqvw9cY182bz/0VvmDCZ04KEEUop6DKJB8YL96jGrIbWsgAFtZC
gwPfUKlWqOqzQQkxNbqmzfQ6gtu8ltGIbMiW82vYQ/cIXZ1/kvJDDfYbrt7zBfoA40quDgMj
1BFBbUzX02k0iVATQbb6/HNpj0pbciPYG0oHjSwT8sUIbhIW58XRfB1+0YdtGR74GUS4M8Yd
ULjEMMf3xBMR0I7oFTAl6GfnJZTyGXXr+7C3yhxS4FOdyKUt6/vQag9MnlCe+uNppz7WxE7n
Hs2lAnPZf1MQwVJaB+kxr2UHZM8ygI28dBSFxfARqGKB+DpZT0I8D3zk9AAjsZHLIbQP36FC
p9gwkJQG6MFd8WB9gqb0/hdf3O3ComiMOKYHqNd1uIw0y5FPhjmU1UpzS1yyvNylNQIb3LIA
7Pa0VxJpfMP+QD4vHGbrFZKY54wC8oa/eZ6dkENCbicUkEAxpfUmZmfIuJ3ET+sSt+sS23WJ
b+sSf61L/KUucUsmoooIci06A36A9Rfk04L1oxN8hmmJ4hjLWXLyZQZKVVuKt/k4IVbMdUoi
U7Q8AP3o9zVMS3nOC0M8IylD6NCpPAaa99BPAve1udXuX74bevKtOzmVHz7HANsyDekNX7lj
9GCXDAKYviMSZRoAVFCMzvg92kMh0sJ6GAz3FZC03Scw6hY9DQaKm1yeJGQtGpJEoMEKyMXD
1BC9ssmj2jtNQFOX7KdK5LQFJw2fnMosjT86AT035HHR9JZEyNGEQYTGOeHNYHn0eLNiSfoZ
h+hEwhuehxwK190u8fBRiX1vlTj3Tolp+7dKDNs/KjHr5yU+vev8FsAWLgCM5W21PVK85/Ef
k8wM6CVOcq7hVUqhQVs4A9AQBpRLBcb+dcQ13bWhFtA7jMg0GM2DVhgi2tMHuXXkArvHc9jI
GicVh6jek2zHm/uwjoU7svhzKH644yWcKA2i+vxFApEcskfOqlALKs3/slAIWnRuY8J+m+ZJ
CQiF8BeGjUfjkVoFdYJcDXc4YafQJdD6XSllJ+qSCz+bxUmQ/73QXxlbsVPQVj3Gtz9w278r
HUZwgip7gXJ75nCfC7KBjMlXJ8DDceomd5jxbNZlnj4otEOPgn/+ACbLgicLNounzHo5w5BA
mhBVsyRax3hO4fSaq1+yAiJFbSXN9HBrtol51donGGkZLYowj70wSfAh0fyJvBIUCJNPh0Sk
LlMSegi2nuzO5yJLzumiCxpCQWuaoDYxkRvpeSgxpcrYM12j93m34NqUpRi1ceVOYdUhD1Sl
Ik4WIQmkm6UVSlMq1wboL//bT8jQQ/ekSPdBOOSczplWg6r13new8qNjl0JKoLWIKQfxtoUK
R2vvWpA0MF86pHKhQ9oqyvw5nkHvQ/4y6xAZ0bClDJj0wqgPjcXqHmHtT/GlNVKNArk5IWyu
eoRz+/li6CUL/v4kG3qwNaLvL+F7pmIYtMVq7qO+SayGWNNwHk4ybM07o+Tt2vffvHjR2vgi
Y+mjCj7DgnJj8nyBSyqIkxG1CB9tkzlPMicnynTOSzcnMzlfT52c8bRoSSM/Pz5psnTXuYMm
ZyidY6iQZh5+sjWFHY7eUo1oNwOpNO3Uu3yAIzFZx0MXDIZUvY7mWIl5Y2Rgi9zyoBhRZAiY
ZvlLKwQyTVF+mZfL4LnTrkGxW3ijcOY7mCYchrNcGwpHzqKNpLUz6dPWRKnXegdC19cMmB5e
UrjI6QcnA6st+lkUhG81qOoVZHyxChRV61KWuqBziJcXlQJjCqqxqW1t592au2Fv4eC7sLnC
7uJwu9/Y0GtuZwldUzsrZ3XNU1j1yLE4pLNoKo+k+Bx+2Ol1P4+WfLY2yk5jvNpbg+1fPmzx
5WvZp3EnpevXFFEs0g4Zumt4jRMhZH+we9qTYZMccqqJl+F7VGPDwUrf2Jopm+slKB4yyBuZ
vFHvKFCppimDEtER5u1iBRsxSV/S/XAYFYOXHH7kUSGs6qcIZbupjwgUalUe6t5oBgqV7X8A
lS0DC6JTBpFISCO2d3mso8IXWB1fk2ahdU/s/py1E6D9qzBcpWyMweem2XuhcmsJF20AkbeW
TJ0tmWJVJFthYJRINS2BfdXip59lsj6/KB9wmKHUIJaFhsqacw3pMq5K6AwpCmbaXcY6lak5
r6k5EHHPY0rI6OyIv5KW6SeOwkuHy/KASZ/GMiPIX+pcGvf0tF2QeJfxPDpJheCbMephDE4e
0VqllydzGu58iHODeAj1jVBEsYWhDhW0PZYVer9V9Fp1c0bvbCAJ773QvTQ+BHxtLBItIfVX
Hg9dSKkwZseDL1JQyCHkNT5PsmaIO1/EkO7CoQou+t0BfCXPHtFfZXqvqSodynMpOUiWGARp
cq72bk4BzChcWNt+WVvGBiiV5SeoGkua7HI5PG2rL4I5JWjTy9oiJrtUbo5v0NYWoZwS9NNG
6Kd10A+e/+NxPTTmlKBn6wbUmFGC/bYJ9luC5fAD62Xmzi4h3N9DV3xK/GZ6oIlcWTi2+8P+
wMhUEmeg8qOSqa052hhERhteKkAUIthQbek5FZNACgy17G0pLTUNF5FKRNzk0NGT3L7d184n
g17PzRMdeo/cskwTDmy8tk+7KcNed4CaRhuXQ3nl9kCQvEKddcFH+HydGS8vSG8FW5XQCO3D
C9m5vNydnOqTxrrmpclYRVCBibLJjBzLJZ3wQWn/BLbJ4zjL4sVVTDC2YDISVo4UWiqGxrXW
0HEUw+oRAdFH2kAtbQjpiBhPLoJVsKExaSuxNFq8gnbP1HkTaFF6gwIKCgqRnG+JjlCv4d8q
XMqzWEzDMOs2qGnsBFtRy7pmOSKcGF6Cb7mScaGm2dYeRJAtjRzgcOS9339fY+mXmSfX5VcF
Wy+zOPDPC91U8RSvEcz4VRy7BdDJd2sA4qeqSrVTi1T7sAHPyQZlVV2naxKtqrrlR26p4hE1
TLoRLbXuUv5k5q/w2WzAqvhIZaUhhSWozVqPL8jdCIC3VE8SfzVrKN2Yz/McD4DJcG3PTNZI
PCNv4Rd6ekewUFUUGGNqzod961cxHKBUH6karIVCp9EhqpraqN3TJKSzUj4wZaGs4UlJohAq
GmvbbKHcHAc13bEkL2WrFqyEXpHnWkwlikoSL/YHDU2wgCBSUhPrtUTmFZAB5F/mlJR0k36J
ThYoTvXovBo8ymeKOE8qpTL0gL2bdgwWWsseqjWpLzVzbq/yVWzuk54DnjyQKp0bC1gAN9BF
WRBh3YHmx1IhRmI6faOFCQ39UBDBkX9w0FYJUIic2E7CdI6D1rUwovfcRlSTdXBJVNCjC7El
2aRrOQqQK+rm6k+hJyhzoFo0gq7wlGq7/xlZRFerMLCaYOdvDzRErjSIifLIhN4k4Wsos8qS
4qf+z7zWLdyjA9zK0QkJCrvCOzAZBMji4SRMwilNhGKnqNSCnvIX1VKPzK5OtYMYkapx6xlx
d2RlafHTgKvKLV+FltxjEf8Bu9Hq8fatQwmsWfsiK9CBBWq6k28P6AyvqLQEOCCNcdNGR4/Y
a7sZb9/uMfcs1wtmoP0aHHQQKVGgwAGdKTcnD7Th7Xdvhwu5VSodRZSQoaa6EZVtraINl5VQ
OuGQe4t4eXKGI6X9Mp2JWZqnBgYnh5pyJlXOGmsCmTx7WEvKlUZpqF1ev+oIqS8jWXp8TX7J
sBYn2cYOl+vlDpVTdU/LGW433d+NfS0lbOx0LU9tIEIN27gkWcYfjh4fdthLQ84hP2YYMYx8
NDDYzSl67Uxs/9ZPWiXzhlmbRSVlaIwcjokDUUTT+vW/bi3PEnLTUltiXDJiUuftpFlEegte
wKLAhPO4251FnX65IIYGLunSUiSjfXset0pYN8PPIr0oUrsxfbu/Pdg+yg0c/YM07qAbGpnD
ZA+G2wOhmyUN9RLdnBiPXOKOCueoYcRLNLWRDMEjnhSaCEOLRFYhSSFZQljLOXDg5RoeTUGc
WxVB81m1aq6mkl/XdtV6poKwtjGYahFCO2FRS7YHX5quNjVioaqofir9Mdg2nVG44X+WMd9t
rfniVa8lbfzwCso7LGgY/FovxmGiOaRwU+RG7Gp1iNzhrqIZQYMhVuXSGI6GFrWtMybMuoj6
mv4WJjmUGKNwCbu5NflR8bWeTX36vzUiVyn/gTpLU7NwU7iz79JXPaU3cJ8yfJg5yuT9st/v
XWG88+oAdTrVbuSoiW/kd92qKrd6QYR3nyy2xzA9now9de6mX1xB06T4iJ2+fLcvg0ouAtgR
R3xIfFb2FZBWqKZxtAUs653OPPTTTAxEEJ1EfN9sVvF6qketB/KdWmYfzDorU8fGdzlEfwYH
XEZIyKn40aqv+qe9A4w2BF2t+IZiTQQ5jc5GuIDZSWxKySU0TDwZHtDWHNnWNijqNJ37dQvt
jaazsZIbTefynxtN50bTKbXqRtO50XRuNJ0bTUd8GE1HWKawnmUQ6vHxsY6fUrgmOs1XlVT6
UbXPzdG1UdCzeGQ2s12jkxE2zBudsrt+/lxFRRa/bfd3VWBB7VAgwzYKjaBZxbBIpSnk5d54
Kr76CphDeRXW09luvjpBWvlRog9nNbErRr2/Zm9V6y/VWT6kpH4KcgBEQy69eog9PpGn3tyK
wmEO5i0E8OiM3WETc7TuDR2KFtv9skG2qoVfQuO+Fl3u2vW2Wq3ZDlF0NW34nTTfvwZlmrn/
2hv8Tlppgwb68bXNa9UsP74W+Y4a43trh9ekCV5J63snDe+DqFMfUHMrq1Dub+NwxC4W/PM6
NChnoaJYNlJUbKsLYXpSmyWur3x6TuMkUFTilBSToH1vPfKjmJ7nunJLk3Aq6m8PEGgmX1xl
dYE1uX6hQscZx4+6RVnQLeiQwlhEy8l8HdADWoH4jWrePeDriikF3voNKLJ7s4zfLOM3y/jN
Mn6zjN8s43/9ZbxdWaxKS7m1WOmFFCNIFmZ11ouzAwDo3lZXbBV/hXfSKdsD5Iqc5zK5yLUc
utJSe7G9AsF03116SzSbEWnvpG1ayBUxbxbvm8X7ZvG+Wbyv2J2bxftm8b6uPTgtcfE0O43/
1P23HwTk0pxfye3j6h4ff4ZrwZ/tVXAZF4/Gg9/3dOy4Dp+O/ws0v2TRP7931+G6cTmvjY+/
fJcb9Cf6anz8xf0dO3sBlvdd+i8k0ztpAmWs7+GScR3eGB/DE+Lj+WBc4FqxMbvJe6K2UD3w
Negn+vKa0jicK7azVwU9pYwBCw/okSXSB6wiaU2Z9KJCeFvYLhMtC+oPhqPlEvHSvq6JzQfp
HSbRBOQs3WLlYKj4Xld8IChuHEwPyCStjfrMb8dhyZEqqULMJSO8varCyoFutj1wL5u6xX46
wgrxkbAknguMgomHGAeVJrBCh5dozcNuHl3cPSraIkuik5OQozDqENe/mUh/ALgrFiHGYIzS
Repu4K0ubQ+2+11eAU2wXGgvR06Ml/JaFrC5NuXoXFQ9de6gpqwNoHxuSjdnzYVkc3W5esCD
fiLOqHmj8k1mdTdbJ+uaCafjeTKIl3RmNChKy7lqY30j0Q2EW0mxJpM4WE/CVJSMWJXayM+F
51ue9wr4T/1q6JNyNyl3CtMv7hVWgX3IN/SGjsIMwU3oF8Hx1jniOseYH43T1cyfvMJTsldU
qUzgoRrPo2VA4wXCfhYnudmMUESI9FRwmCEVBUVzM4eBSeIMmGWTiGVqudKJwkl7I399Fq8z
9Q6vFGl0R1T2kWiQF7mJHFIodGYO2OZB6+0bYUUm4ovc+iWtUcgkKN/Ej6u0VdT6uPSwiNH7
MNRwRkFOa3wCL0t8oELCzlH6HQobGkS5+UEktH5XLt5bWSogAZMGwy7RMgVQkwAEHQBHc8Wb
ZyafHiPkb0ZEAtIRb1z/UEEOFWINnhschW0NVmXt67Gsnhms6m04RYMRinzAjrPYQpsXbVP7
ChYZfHHK4u2yXYFMA4Zj9MBbEkipJqothd0NDtACRdQwSeOvrHqk6k6VHb6SkVfXPmvUQXR2
OiBJ8PQd5Ql6+fEzX8l6KSXaClgJ2jKP/QDDxQJdcHWQCkuuzwecZuIct1WsJjAShs6LWZX2
VeQq5MNqHcTTKWyoL67gkg0ti47wLOMI0a74aBCwpN7M4/hVKtI5xuvANwrjkzVHeV8mV5M8
lxMndfxndNo/Q4SUKtREqT+sYQ3UzIgqa5aBKRJJBUwtuzWszRmWAOAXEiznXzWr5Mrtz6Fb
cvlWDiwgifhWVR8djSlWNcHJuCja9BZXyums9eJCnF1AmvjjaOKi1dFXubx6zMfoQEO3Zq/y
/o+LSLekHpPdUKegTZjaoiXK6ZARdrrrdI05oyUHilI/5UhPoOFuxhhKmcyxNndi0BUEADkq
12+FeAiauGUC5UQQ8Z2+DUZ4hwN6MQLm58pYabjAl6UWGHtDLXLeLht4CWpvy00mwnPNsCMK
/ayhDQR7v8/LjzE31OCx+hUMTbvKhQK50JXb2RaBOB7CP58JxntPLEUHU+6pnEOZg1IrBSUU
33TUj9W16vvaVN1FBAxqe3xpbATYF3KummSWOJLiReFEzxyRSJc3AZyfQ1IMnCXgNGzSHf9S
mrZUL5zeXqxoSjXIRPa2StuhOq68nBiRA/TltuFlA7nvyfRuaKjpr1YYy4pBbSkqhgp+esGO
yKntEfRuWJuuIuAzCpC7zClQoo8vTFBQvDzCaKfR9Bzj/vLI5/SHQp1TjRaGdRq+CwJFAN0K
GWaFRjQ6yxVbkJkn0LdiCqcc1L2p2NoqptY9hNIRXXKM/gMDDg1W7VRBXqRSLzbpK9Q0GdJO
/V7/idxNFfhBYF8TuuaNEo8rVWJoU08aNRAIrCha0VExfz6CtirLQnlboQFyNFDp/gCka99S
tj79fAIXM/YtXd4cEWLsSwrDTPzITroq/Bz+ATL+mlOcuWThhqAbqHh26tpQXINLG56Ub5FV
jR0evNEt2I4x5qBP7chaIF1fhQGl/17tVS3cpAauqmddtsIycHOVFUinUkOjjdUZsOaKLJhS
vy5ZyXX1SefRg2vBlUevaVQui+4SFL8sqgto+j4tqoy/rSCTnmFdSpSH/vKlhZznPnrmEQzt
GqwyQyUb1kv5pByr0wQxCv3JbCjPUUH84RtwdmHtUmigvTipT5UaLjk65PKPsKz7KNGFXaZw
f1gKtYPjQNSfj2g1zzT3MufuNmn6pfa9JVnf2EI+kbElkxS6JNJgtaSHH3KPF4Y8nIcYho6O
kXMvgy1/b2gLbRopa03DkJkINXCh7P2x8FAVQFMRvk1PKIX+OhCF0zIMAkhem7leq3XmOve8
wlqjZYhAXnZQY5Hrh9tX+NKIMXAwrjdjtDRtizdNRZqbZW3odkrhBT2PqSmPS3tajWDfmho3
DIpZ1+aBU4urXetQAZdpp+ovzy9DXNvUr+izuRQSsFIqCgxh+VEvPC9okcmPwtpOMGCtZQQ1
/dVIRxyN1F6i6cqrqZVtqRIN8SQ+Xx9O13Phj+PX9JIgv58m3kIz4Be9pjpDFTXjFwdhW0ax
6NsyMj6/6ATf1kv1ClgY6LfxniDU8hWXwSYgpD8/9c9TQZFqKwH1uZ0Ot3G/chX3GKP/i6Ik
fS8o+5aeSY7ngXzcqVShHgiUu3rKKEdnMx78pkdTFOJ1mnpCyUV7VLWLlh0LmQDonZcLKmxk
dIdJ5diqwa3OAofhN02G2rkAPeFmspAjQhWWBHDbglKMJa2N+H5PKq3lx2xK7z/JBcClM00D
oN+BcCjeGHbanqGgqHYrftDQvtPRDDqyXmKAVRony3/kwlZeqoHL1+uu9ttV7oSFw2562jew
W107Xd6hNYQskTVagArV3DAYzdwcTNNjvc0oMZ3kBoHyRdkxqF8qOmtdk0spHGXd1sOc7Lxa
AmO5lqY9UbAcZVeTtRr0Vk/wyqvnI9yOUYh2qt1dcGhtOxByv6zQefJhE4WBZjmoKu6SSFTz
PI0+rwpojvquMNgWCahOli8VKpcxtoIR8Q+/A4yTtUUDyI+zCMWkx6LS5coiDXN45ScqkLj9
BBYoG+aNySI3b0cNO/gOn35YCo/fhFbDaicUwVdBzKNVAGNF1KdHi0ekE3GNFN/X6IuSRS0a
IIGV6d96XbN+E56OInMCpENbvJzVva2p3gpNBT2CZh0d0TMPJSK51MV6cFNeAqq+AjoKz6Cr
sOxJNV+pVn4QpKPJ0GJwwzGUF9VSol0BPIPkbdyLO+0jFPKJiIEyntR3K1qu0Pby73iMCLpQ
emPPkLXikzROsjCQiwnNs8DP/CY7klwPWHnmtQWkVRD5WbjZBJSy74lWk9mZ8x2NkIxRz6k6
5jHntLUWnJRDpnhsObm0BQeLWRYcVV4/qiEHcmgHAbeEpOIgi+/xAF2Vs0rho4tzoEJwDnre
fM4x5s2CWapNfXUzhm4oclVMc8KwjrlLgGyYHdo/bFBrBbXe4G0ak0nDhPYTeuip5jHexpks
s8tTeeIyvEJSbePGyRxtmMwTNZnjZUiornku645dNJlN32jENHcnoDbAnMJFl31U9hwdKNg3
859PBuoXW3PN/6+z7KpW6KHRZnO28muTPjtKEHNG/HLuRgWj7IQ2QM8DqUjKl9aePoCl/C05
wcmXM8rmWe/5A6G0XXk8KqfL2/qhwJBaIPx43W9a9iUXyPfZjvjhQWvJr+oDTSt/68Iln4rX
LPjucm/PC1rt9SsBdqdbnvNTKqDmVVOT5QJabwiwZwNyO9npRkhoz7Vc40Zz6Sd+2lAEOguC
pXQaeEEhQD6S3q5cG9oTcxqMrvITxL38MmkuDxXh0SSXz/DFwszCIH0hFJZ22/WzqWuJXetG
eFlzXQsrZv+qGNf9LeSCWc01tFeaZO54p5UqMbr/5aDt0S6K1hVKSGoVtY6xLfeJHq/mjPjP
oUa5movoUYW3mbmeIs1lJEcompQBW2UHNE7O4vKTwpd4Qu2id9MU6orPm8qgCaNfOJOSHp29
aGttAQL5G5FAHuIBJU696JW/CEPxz+dPBT2SmJFhkNCydUi+FUPFcRExj6UpsTbLFvOWh/86
Qiw6o/2tfm+TG4yvsaRzP53l+Hxe8oXx9Z6PEzKsYXJ/cKTTEyf9trPnDpcnsG7NnNflzXti
oFrBhsgscrg9Qmf5aLmWIf9KZSbrgMvQc7poRkzrAZNskj8H+vHRuNgDOhKsiOQbncr6uF9b
zenUrQb3DVm4RIMn7jJqy8xeSdeB+sy04kFg32JAH4KaDPQVUafZpax1mub/TMNafOs0yJso
s3y9zpfh6zBppF0AOtYjEhG1yEFBkwgCHZvRee4bnTijib90WcDmihUw+hrvlDSwBdUeeZMc
lOW3fqx4wg982D1Tm9piE+vUM85DbzcOopMYOu4HcQmTzVD17PRN4p8gx8RQKzDCKhZ7abiA
AjHuDBQ/xfsS6+W4r573HqdZKCaqudM4EiGe/mVU0zSazELQsupaX+LTei6dqo5IDNTIBp7V
sKkNnNay8DLeS1XvySxbw8yhzPeXNVRmlvYlCDJ3E2vD+Emo+vEiJl8vJ76wYQ3bb2J6CSxn
QAP/E27mvhJ6OSnc815+93vcxO8v1hEMeIBuICLwdo3S/86sHjJLhLBlCBereXwOWK/G7t/F
yST01yLBt8pDsbfyU4NKBP4SkIQlMfp+XG83GupAhud65iExfSQPIt6F5wHFgjt0Caafh6mC
PruY7bGJF3F9diHbZxEIyfBi1ic4bzeXF6k3TYB/+ws/MoNmilw4DwiY2K0yGdriob+UI0sX
0vzJBE3FoFCFx3VTRbYi0Dib1hQFGGqgmillVhmeUu78sqfcCb77u2xcYaIQ2v/IzKnTKAlA
0iYZLEth9kf2zlOPMCfiIXInIR2Hy3UJ4cWz71t/vQKujuYwjYD1MXyhCBDzQjyKX9EsUoiv
PPXaNXPPbnU6mSVhNM4E0E/8sV6Ib5pUnlLBk5Ab+siHlr/zVA2gjy9DeXBtJmql1ThTES6l
GxINUxkUXEIWLhXUxrkcLS+YyWupjG2Yyl874908lV2+2LCO0fi70JdayUBeVudv3WJGFQSl
IhtWs5updYVV7XIz610mSs0k2TBHLmT9xQ3rX7zqLJn3nYnQohMSxLrG+yu4BTd3s9uIx1/P
MxzWx3IrhKYMtKWxO0yayy0S1KSeYiodTWBlTg3S+JLX49G5zmmRBel6izmIoRHTqPW3m887
ffz5fJXEadghGxWIhsM0mcyzs26anV9XHT343On18G//7u2B/Re/9ge3Bn/r9+70B7cHg97t
23/r9e/c7Q3+JnrX1YBNnzU+FCzE32bhYhFOXoVNcBfl/0U/7XarLWU5/IeyW/xmOGD3AHMp
CoCPfm90moNKNDAKvSwvSL/PzrsthSgUcRKdREt/LtJ4DXsSQgorBOrbEkpWEGRnQuwRTjnN
jzHQNV2wPZhDhWe7+wiuWyjzsKW0mIVitR7Powk0B1TxZVc8yTBAdigP2JaxADGR+MssBHna
pnUAExNc4F5jHAo6k+mK/4nX5PqHW4Q4ga1UEE3PebFUVfqZOIfuIJb4dAkl01fYZ/G97Oz8
XK+B4/Nj8WAevkp9PHoSL6JFDGIbgR+ukwRXa2xsBv8Pk2PxIgNxuxT/nCcg2sWXKf1c0y90
QkrSLpMR9JGTsLsMs/tEEu9ZGAbpy/DHb2IQ6Vn+1IfvA/T3+SGJ8Q5Z+gO3PGdiFz8Ner1b
h/3eYe+2eN3v3hYveHSUSRkVHqAqLCRAhDT0E2gNqsb/esID+LMxz754/vD7/xIe/dGHR5QD
dY2CcLw+GZXSXken0bKUeIprBSwT1vcqNlzZzld+wmD6VwMgXuOwIOkngz4Pf19HSaiIEk3x
tA+o9SiczP0k/J74L/cnGJesyE3fKiAw2A4QWagrULB2UY8AyupePSwRTAIy8WorXsZ4bKnP
IRxyNDUCCVBThOiiyhir/mcEsfDPx6H0K5WqRCmZXYMq3aAxLvLaEuoq8uMzjP0mi6SK3sS0
kzBNZbp9ZRkQ4ZVmet7e7ohKHOp3zK0+EBmVW5ROwNNUm0e9DNY89Kt59PU/jsWb7f6bQrv5
aXTfwTxFrVdh07+1GwHIqVIZOc+fkLsB5NFleydRoymV/O9o+TjIVF38yzRbzRjV7mN9e9o6
mkHAB6gnfRPZFJBJeEwT5fB/urj0IPsaD5weyR2BOoCvxDkAETRXx/PamQWxvvj+n09HHv1r
MrFKSpLXN8xHCQ8nkTLMXDJ46RTKSBkHvjYUmt1RF02pGVbcKZlFwSxqZgOKR5uM9Fv5KZQ6
I91QycsEWXMZ33f512lDHS/bZV1ow9XVmyKQd0xeYFbpygy02a9MDrkG5O+DSNEU/1YZcozr
V0geb6NZHL/KqyCk27sQiujl0pqv1M3KMBidVeaYHnY1q778u6hrfe1I9JwhdijUd5HIDqu2
lrphmqoa0dlUbYUBynePbWi6Qd5X2Db0XzFuHYNPyeuuJuMkzLAXmD1CdQrdu1QQG4mzFgZD
dqFTlb7v6clF98lyGittJH9M+znQwVR5flcti8Vvplm79XOytlqbX5raxVdF5R1VGl3UAlCU
wM7z9zWML/khOZJO4ZzK+6VdjHAmRUbbnvp1qLaPug62CzCWsTaAD9wCsjW1pJKPyNSNr52n
xLlM8uRfpqj8YThZsxP9msxBWdSxc50dvF2Nu4N3ZhBzKvxnBlDXqVy8Rb0Y2R7Q8muBqF4Z
9qsTLlxjHb3kkl1DraYck2XICAk8lRUJadFXhMMFlmPq+Ik3Zu8LU4kn/5YIAilmCCpUlkUv
JLKFUuF0SVw7t5CXic68KUrDLBWGKTeMjwFyx4jk0xVHyHti0/mJTePSXoGxlgcqngcaJJcu
nmrE7DxPfdFo0LuawOD7yM1FBLpgPYjBaw8OLrPlmgtDDqexGthGrrmJDWCVbVBLSw8ZfatP
aDQACMMgnEeLCJuD7juaO0tgyh12msR/hEtTg3OFU8UAx7JlQFMPt7Q8MOMINvHxSeKvZue1
M6wMoEbNTvfsH8zldsqGqeNgucoEcvFfIKn0dmE8ntt87/Tt3YQW8gpsB0pCyKR6/KdVYWWV
jkUkaDlLJjeyLudDtaWG2Aq9zb0anuJXYRVsEnq8DNiLuGSA6t5Ydv/UT9X+q1K6t2bZ9dSx
2f7b6x/d7Sv77+27t2/9DXJ7d+/e2H8/xKfdee9Pq63+EQ+ePv3h+fcvHvOvh/HqnEysYu/h
vnjuz6fiW0lFsZfAz5EiajcI97nMLMtWx4eHp6enXSsTmDKIE1PR+7ZYhlm0vf8fxnMQ2MHX
sFdBhWwZYKQrFMa5uqw01ln2hSXBqoT3LR6Y5l8G0WsxgQ1aOtyazNPt/tZ9dmLJFcAhQNw3
sYgMUmqAXKacRYp2dhvbIANxPoyX0+hknYT5BHGNY6UY51LJlHsGkvcPjglo6Pn8ReWVkFgb
Dbbs+aqcRGCXeBFm3z4slcJyD9M0h253iSK56UOHMBx7XOheUdj3xqjF3DHVHXW0OcuOq8oa
03N0Ji/tqJhQMxmVOvfWoLaGyUJGHf7YE+/mc/O5+dx8bj43n5vPzefmc/O5+dx8PvDn/wFR
6F67AJABAA==
--------------050202030902080207010205--

\start
Date: Sat, 21 Apr 2007 21:09:23 -0400
From: Alfredo Portes
To: Jay Belanger
Subject: Re: Please join! re: Axiom HyperDoc Replacement

On 4/21/07, Jay Belanger wrote:

> > I just uploaded a tiny toy hyperdoc replacement on MathAction:
> >
> > http://wiki.axiom-developer.org/SandBoxHyperDocReplacement
>
> For knuckledraggers such as myself, could some more detail on how to
> start this be added to the page?  How should I load the lisp code, for
> example?  How should the spad code be loaded?

Yes, please Martin or Bill.

\start
Date: 22 Apr 2007 07:26:03 +0200
From: Martin Rubey
To: Alfredo Portes
Subject: Re: Please join! re: Axiom HyperDoc Replacement

Alfredo Portes writes:

> On 4/21/07, Jay Belanger wrote:
> 
> > > I just uploaded a tiny toy hyperdoc replacement on MathAction:
> > >
> > > http://wiki.axiom-developer.org/SandBoxHyperDocReplacement
> >
> > For knuckledraggers such as myself, could some more detail on how to
> > start this be added to the page?  How should I load the lisp code, for
> > example?  How should the spad code be loaded?
> 
> Yes, please Martin or Bill.

Make a new directory (for safety), for example

  mkdir HyperExp
  cd HyperExp

Click on "edit" in

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

Copy & paste everything between \begin{lisp}...\end{lisp} into a file, say

  hyper.lisp

Copy & paste everything between \begin{spad}...\end{spad} into a file, say

  hyper.spad

start axiom:

  axiom
  )co hyper.spad
  )lisp (load "hyper.lisp")

  SOCKET(8080, getDocumentation$HyperDoc)

start a WebBrowser and enter the url http://localhost/|?binomial|

Martin

(added also to the page)

\start
Date: 22 Apr 2007 07:48:00 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Please join! re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Ralf Hemmecke writes:

> looks as if you have achieved quite a lot. Congratulations.

thanks!

> > * A LaTeX header file that provides commands supported by HyperTeX, like \spad,
> >   \spadfun, etc.  For example, \spadfun should transform its argument into the link
> >   http:\\localhost:8080\?argument
> 
> \def\spadfun#1{\href{http://localhost:8080/?#1}

Oh, you even corrected the slashes...

> However, that is not going to work if LaTeX special characters are involved.

Yes.  Wouldn't it be possible to do something similar to \verb does?

> > * same thing for ALLPROSE style documentation.
> 
> That is easier. See attachment for a first demo.

it seems that wrapper.tex is missing.

> However, for full generality, you must be able to ask Axiom not only for the
> name of the function, but also its signature and the type where it is
> defined. The wrapper could be the same for any function/type, but as you see
> in copy.ad there are two definitions that I have added at the top (by hand)
> that do *not* appear in the +++ environment of the corresponding .as.nw
> file. In ALLPROSE this information is generated from the accompanying code
> chunk. Now that you use Axiom, you should get that information from somewhere
> else.

The reason why I embarked on all this is that I noticed that libdb.text
contains all the necessary information!  In particular,

\addefinetype{MyCopyableType}
\addefinename{copy!:(%, %)-> %}

contain just the information contained in the first two fields of the libdb
entry, and it can be retrieved using dbPart$Lisp.

Although it may be stupid from a "do it right" perspective, we can accomplish
something usable easily if we reuse libdb.text (or the databases, that's
roughly the same thing), generate the html and cache it.  This way we do not
need to touch the libdb and database generation at all.

By the way caching, I forgot one ToDo which is quite straightforward:

* remove unused files (like log files) after html generation.

> > I hope that some of you not occupied with more important things -- like
> > working on build improvements, waldek sandbox, trunk, or multisort species
> > :-) -- chime in,
> 
> I could probably only help you partially, the difficult part (taking the full
> signature into account and deal with LaTeX special characters) is still open.

You fall into the "occupied with more important things" category anyway. :-)
(just kidding, don't take this serious)

\start
Date: Sun, 22 Apr 2007 02:14:43 -0400
From: Alfredo Portes
To: Martin Rubey
Subject: Re: Please join! re: Axiom HyperDoc Replacement

Thank you Martin.

> Make a new directory (for safety), for example

[...]

> start axiom:
>
>   axiom
>   )co hyper.spad
>   )lisp (load "hyper.lisp")
>
>   SOCKET(8080, getDocumentation$HyperDoc)
>
> start a WebBrowser and enter the url http://localhost/|?binomial|

I know you wanted to test this on Windows also. I do not know if you
got to test it.
This is what I get when doing the last step:

(1) -> SOCKET(8080, getDocumentation$HyperDoc)
   Loading /Documents and Settings/alfredo/hyper/HYPER.NRLIB/code for
      package HyperDoc
   Loading e:/Program Files/axiom/mnt/windows/algebra/OPQUERY.o for
      package OperationsQuery

   >> System error:
   GREP is invalid as a function.

protected-symbol-warn called with (NIL)

\start
Date: 22 Apr 2007 08:33:57 +0200
From: Martin Rubey
To: Alfredo Portes
Subject: Re: Please join! re: Axiom HyperDoc Replacement

Alfredo Portes writes:
> I know you wanted to test this on Windows also. I do not know if you
> got to test it.

No, I do not have a Windows box.

> This is what I get when doing the last step:
> 
> (1) -> SOCKET(8080, getDocumentation$HyperDoc)
>    Loading /Documents and Settings/alfredo/hyper/HYPER.NRLIB/code for
>       package HyperDoc
>    Loading e:/Program Files/axiom/mnt/windows/algebra/OPQUERY.o for
>       package OperationsQuery
> 
>    >> System error:
>    GREP is invalid as a function.
> 
> protected-symbol-warn called with (NIL)

Oh dear.  Bill, PLEASE help!  Does GREP refer to the unix grep, maybe?

\start
Date: Sun, 22 Apr 2007 02:47:02 -0400
From: Alfredo Portes
To: Martin Rubey
Subject: Re: Please join! re: Axiom HyperDoc Replacement

> > (1) -> SOCKET(8080, getDocumentation$HyperDoc)
> >    Loading /Documents and Settings/alfredo/hyper/HYPER.NRLIB/code for
> >       package HyperDoc
> >    Loading e:/Program Files/axiom/mnt/windows/algebra/OPQUERY.o for
> >       package OperationsQuery
> >
> >    >> System error:
> >    GREP is invalid as a function.
> >
> > protected-symbol-warn called with (NIL)
>
> Oh dear.  Bill, PLEASE help!  Does GREP refer to the unix grep, maybe?

I was thinking the same, but I have a port of grep on my path and I
still get the error.
Maybe Bill knows if I am missing something.

\start
Date: 22 Apr 2007 09:14:30 +0200
From: Martin Rubey
To: Alfredo Portes
Subject: Re: Please join! re: Axiom HyperDoc Replacement

Alfredo Portes writes:

> > > (1) -> SOCKET(8080, getDocumentation$HyperDoc)
> > >    Loading /Documents and Settings/alfredo/hyper/HYPER.NRLIB/code for
> > >       package HyperDoc
> > >    Loading e:/Program Files/axiom/mnt/windows/algebra/OPQUERY.o for
> > >       package OperationsQuery
> > >
> > >    >> System error:
> > >    GREP is invalid as a function.
> > >
> > > protected-symbol-warn called with (NIL)

Alfredo, could you please try 

  getDocumentation "binomial"

in the axiom interpreter?  It should start htlatex, and after a while answer
with "binomial.html" Type: String

If this succeeds, then the problem is in the lisp code.  Otherwise, we have a
problem in the spad code.

\start
Date: Sun, 22 Apr 2007 03:38:59 -0400
From: Alfredo Portes
To: Martin Rubey
Subject: Re: Please join! re: Axiom HyperDoc Replacement

> Alfredo, could you please try
>
>   getDocumentation "binomial"
>
> in the axiom interpreter?  It should start htlatex, and after a while answer
> with "binomial.html" Type: String
>
> If this succeeds, then the problem is in the lisp code.  Otherwise, we have a
> problem in the spad code.

Same error:

(2) -> getDocumentation "binomial"

   >> System error:
   GREP is invalid as a function.

protected-symbol-warn called with (NIL)

\start
Date: Sun, 22 Apr 2007 11:13:40 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Please join!

Martin Rubey wrote:
> Alfredo Portes writes:
> > I know you wanted to test this on Windows also. I do not know if you
> > got to test it.
> 
> No, I do not have a Windows box.
> 
> > This is what I get when doing the last step:
> > 
> > (1) -> SOCKET(8080, getDocumentation$HyperDoc)
> >    Loading /Documents and Settings/alfredo/hyper/HYPER.NRLIB/code for
> >       package HyperDoc
> >    Loading e:/Program Files/axiom/mnt/windows/algebra/OPQUERY.o for
> >       package OperationsQuery
> > 
> >    >> System error:
> >    GREP is invalid as a function.
> > 
> > protected-symbol-warn called with (NIL)
> 
> Oh dear.  Bill, PLEASE help!  Does GREP refer to the unix grep, maybe?
> 

Greping sources for GREP indicates that it is indeed undefined.  The
call is in br-search.boot.pamphlet in function grepFile.  Unix version
calls grep, but apparently Alfredo has $standard set to nil, which
means that Axiom is trying to use Windows Saturn interface (and part
of it is removed).

\start
Date: Sun, 22 Apr 2007 05:56:38 -0400
From: Alfredo Portes
To: Waldek Hebisch
Subject: Re: Please join!

Hi Waldek,

> Greping sources for GREP indicates that it is indeed undefined.  The
> call is in br-search.boot.pamphlet in function grepFile.  Unix version
> calls grep, but apparently Alfredo has $standard set to nil, which
> means that Axiom is trying to use Windows Saturn interface (and part
> of it is removed).

Thank you for the detective work. I am using the windows version of
axiom. Is there any work around? or should I try to compile build-improvements
in windows?

\start
Date: Sun, 22 Apr 2007 12:01:25 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Please join! re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

This is a multi-part message in MIME format.
--------------020909070803070901090904

Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>> looks as if you have achieved quite a lot. Congratulations.
> 
> thanks!
> 
>>> * A LaTeX header file that provides commands supported by HyperTeX, like \spad,
>>>   \spadfun, etc.  For example, \spadfun should transform its argument into the link
>>>   http:\\localhost:8080\?argument
>> \def\spadfun#1{\href{http://localhost:8080/?#1}
> 
> Oh, you even corrected the slashes...
> 
>> However, that is not going to work if LaTeX special characters are involved.

I would go the script way. You call htlatex anyway so one could call a 
helper script that escapes the special characters before handing the 
text to htlatex. It is similar to the aldordoc2tex.pl script.

> Yes.  Wouldn't it be possible to do something similar to \verb does?
> 
>>> * same thing for ALLPROSE style documentation.
>> That is easier. See attachment for a first demo.
> 
> it seems that wrapper.tex is missing.

Oh sorry. You find it attached.

Currently I have only Internet access via Windows and all my work lives 
in the Linux partition. If somebody tells me how to access the Linux 
partition from within Windows (the other way round that's possible) 
without rebooting Linux and using a usbstick that would save me some time.

>> However, for full generality, you must be able to ask Axiom not only for the
>> name of the function, but also its signature and the type where it is
>> defined. The wrapper could be the same for any function/type, but as you see
>> in copy.ad there are two definitions that I have added at the top (by hand)
>> that do *not* appear in the +++ environment of the corresponding .as.nw
>> file. In ALLPROSE this information is generated from the accompanying code
>> chunk. Now that you use Axiom, you should get that information from somewhere
>> else.
> 
> The reason why I embarked on all this is that I noticed that libdb.text
> contains all the necessary information!  In particular,
> 
> \addefinetype{MyCopyableType}
> \addefinename{copy!:(%, %)-> %}
> 
> contain just the information contained in the first two fields of the libdb
> entry, and it can be retrieved using dbPart$Lisp.
> 
> Although it may be stupid from a "do it right" perspective, we can accomplish
> something usable easily if we reuse libdb.text (or the databases, that's
> roughly the same thing), generate the html and cache it.  This way we do not
> need to touch the libdb and database generation at all.

That is your problem. All I want is that the stuff after

   http://localhost:8080/?

should be designed to contain the full signature and the corresponding 
type where the signature comes from so that the lines

   \addefinetype{MyCopyableType}
   \addefinename{copy!:(%, %)-> %}

can be automatically generated

> By the way caching, I forgot one ToDo which is quite straightforward:
> 
> * remove unused files (like log files) after html generation.

Wrap the htlatex script with another script that does the remove. Or 
look in ALLPROSE for the html target in Makefile.nw. I copy the relevant 
.html and .png files to the doc/ direcory. After you have done this you 
can remove the whole direcory.

I just say the problem with "grep" not found. For aldordoc2tex.pl you 
need perl. That is probably not installed under Windows, actually, I 
guess, also tex4ht is not the most common program for a Windows user.

I hope you get this working somehow... The definition of \spadfun and 
\spadfunFrom should be done similar to the one in wrapper.tex. 
Unfortunately, I don't know where to look for the all the commands that 
cover the hypertex ++ documentation of the .spad files. So I cannot 
write an appropriate .sty file. I would suggest to use the AldorDoc 
style defined in ALLPROSE anyway. But that would mean transforming the 
++ documenation of all spad file (which nobody will do in the near future).

Ralf

--------------020909070803070901090904
 name="wrapper.tex"
 filename="wrapper.tex"

\documentclass{article}
\usepackage{allprose}
\def\xProject{no-project}
\def\LIBRARYVERSION{0.1.0}

\renewcommand{\adtype}[1]{
  \href{http://localhost/?#1}{\adtypeStyle{\adcodefont{#1}}}\xspace
}
\renewcommand{\adinternalusename}[6][\adthistypename]{%
%  \href{http://localhost/?#4:#1:#5}{\adnameStyle{\adcodefont{#6}}}\xspace
  \href{http://localhost:8080/?#4}{\adnameStyle{\adcodefont{#6}}}\xspace
}
\begin{document}
\begin{+++}
\input{binpow}
\end{+++}

\begin{+++}
\input{copy}
\end{+++}
\end{document}

--------------020909070803070901090904--

\start
Date: Sun, 22 Apr 2007 06:11:01 -0400
From: Alfredo Portes
To: Ralf Hemmecke
Subject: Re: Please join! re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

> Currently I have only Internet access via Windows and all my work lives
> in the Linux partition. If somebody tells me how to access the Linux
> partition from within Windows (the other way round that's possible)
> without rebooting Linux and using a usbstick that would save me some time.

I think this could work for you: http://www.chrysocome.net/explore2fs,
if your partitions are ext2 or ext3.

\start
Date: Sun, 22 Apr 2007 12:47:37 +0200 (CEST)
From: Waldek Hebisch
To: Alfredo Portes
Subject: Re: Please join!

Alfredo Portes wrote:
> Hi Waldek,
> 
> > Greping sources for GREP indicates that it is indeed undefined.  The
> > call is in br-search.boot.pamphlet in function grepFile.  Unix version
> > calls grep, but apparently Alfredo has $standard set to nil, which
> > means that Axiom is trying to use Windows Saturn interface (and part
> > of it is removed).
> 
> Thank you for the detective work. I am using the windows version of
> axiom. Is there any work around? or should I try to compile build-improvements
> in windows?
> 

You could try:

)lisp (setf |$standard| 't)
)lisp (setf |$saturn| 'nil)

\start
Date: Sun, 22 Apr 2007 13:15:35 +0200
From: Ralf Hemmecke
To: Alfredo Portes
Subject: Re: Please join! re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

Alfredo Portes wrote:
>> Currently I have only Internet access via Windows and all my work lives
>> in the Linux partition. If somebody tells me how to access the Linux
>> partition from within Windows (the other way round that's possible)
>> without rebooting Linux and using a usbstick that would save me some 
>> time.
> 
> I think this could work for you: http://www.chrysocome.net/explore2fs,
> if your partitions are ext2 or ext3.

Wonderful. Thank's a lot.

\start
Date: Sun, 22 Apr 2007 11:19:03 -0400
From: Alfredo Portes
To: Waldek Hebisch, Martin Rubey
Subject: Re: Please join!

> You could try:
>
> )lisp (setf |$standard| 't)
> )lisp (setf |$saturn| 'nil)

This removed the error of GREP on windows(thanks Waldek).

However doing getDocumentation("binomial") I get:

(2) -> getDocumentation "binomial"

   (2)  "error.html"
                                                                 Type: String

I look at the spad code:

            r := ops.eq.(doc::Symbol)
            if empty? r
            then "error.html"

but I do not know what ops.eq.(doc::Symbol) should had returned.

\start
Date: Sun, 22 Apr 2007 11:26:39 -0400
From: Alfredo Portes
To: Waldek Hebisch, Martin Rubey
Subject: Re: Please join!

I should also point out that I got this the first time I ran the command:

   Loading e:/Program Files/axiom/mnt/windows/algebra/OPQUERY.o for
      package OperationsQuery
Can't delete: '-f /tmp/target.txt.NIL' (error: -1)

On 4/22/07, Alfredo Portes wrote:
> > You could try:
> >
> > )lisp (setf |$standard| 't)
> > )lisp (setf |$saturn| 'nil)
>
> This removed the error of GREP on windows(thanks Waldek).
>
> However doing getDocumentation("binomial") I get:
>
> (2) -> getDocumentation "binomial"
>
>    (2)  "error.html"
>                                                                  Type: String
>
> I look at the spad code:
>
>             r := ops.eq.(doc::Symbol)
>             if empty? r
>             then "error.html"
>
> but I do not know what ops.eq.(doc::Symbol) should had returned.

\start
Date: Sun, 22 Apr 2007 11:32:21 -0400
From: Bill Page
To: Waldek Hebisch
Subject: re: Please join!

On April 22, 2007 6:48 AM Waldek Hebisch wrote:
> 
> Alfredo Portes wrote:
> > 
> > > Greping sources for GREP indicates that it is indeed 
> > > undefined.  The call is in br-search.boot.pamphlet in
> > > function grepFile.  Unix version calls grep, but apparently
> > > Alfredo has $standard set to nil, which means that Axiom is
> > > trying to use Windows Saturn interface (and part of it is
> > > removed).
> > 
> > Thank you for the detective work. I am using the windows
> > version of axiom. Is there any work around? or should I try
> > to compile build-improvements in windows?
> > 
> 
> You could try:
> 
> )lisp (setf |$standard| 't)
> )lisp (setf |$saturn| 'nil)
> 

Waldek, could you please explain (maybe a sentence or two)
about what you mean by "Windows Saturn interface"? What is
Saturn? Plus, assuming I did not know the answer, how would
I find out from the Axiom documentation and source code?

\start
Date: Sun, 22 Apr 2007 18:06:17 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: re: Please join!

Bill Page wrote:
> On April 22, 2007 6:48 AM Waldek Hebisch wrote:
> > 
> > Alfredo Portes wrote:
> > > 
> > > > Greping sources for GREP indicates that it is indeed 
> > > > undefined.  The call is in br-search.boot.pamphlet in
> > > > function grepFile.  Unix version calls grep, but apparently
> > > > Alfredo has $standard set to nil, which means that Axiom is
> > > > trying to use Windows Saturn interface (and part of it is
> > > > removed).
> > > 
> > > Thank you for the detective work. I am using the windows
> > > version of axiom. Is there any work around? or should I try
> > > to compile build-improvements in windows?
> > > 
> > 
> > You could try:
> > 
> > )lisp (setf |$standard| 't)
> > )lisp (setf |$saturn| 'nil)
> > 
> 
> Waldek, could you please explain (maybe a sentence or two)
> about what you mean by "Windows Saturn interface"? What is
> Saturn?

Saturn is a name of a user interface in Nag Axiom.  This interface
(or at least part of it) were used in Windows version.

> Plus, assuming I did not know the answer, how would
> I find out from the Axiom documentation and source code?
> 

Is it a trick question?  Souce code mention Saturn many times
without saying what it is.  One can deduce that it has something
to do with user interface and that it is probably a Windows thing,
for example in patches.lisp we had:

;; browser stuff:
#+:UNIX (defvar |$standard| 't)
#-:UNIX (defvar |$standard| 'nil)
#+:UNIX (defvar |$saturn| 'nil)
#-:UNIX (defvar |$saturn| 't)

But to find out more (and what I wrote is almost all that I know
about Saturn) you need to read this mailing list (Saturn were
mentioned few times during user interface discussions).

\start
Date: Sun, 22 Apr 2007 12:44:40 -0400
From: Bill Page
To: Waldek Hebisch
Subject: Saturn and Windows (was: Please join!)

On April 22, 2007 12:06 PM Waldek Hebisch wrote:
> 
> Bill Page wrote:
> > ... 
> > Waldek, could you please explain (maybe a sentence or two)
> > about what you mean by "Windows Saturn interface"? What is
> > Saturn?
> 
> Saturn is a name of a user interface in Nag Axiom.  This
> interface (or at least part of it) were used in Windows
> version.
> 

Thank you! :-)

I expect that the only reason for this is the people involved
in trying to get the open source version of Axiom to work had
little idea about this. I know I didn't know because I was one
of them. :-)

> > Plus, assuming I did not know the answer, how would
> > I find out from the Axiom documentation and source code?
> > 
> 
> Is it a trick question?

No, I certainly did not intend it as a "trick". I think it is
important for others to understand how to answer questions
like this about Axiom. At this point to learn how to find
answers is even more important that the actual answsers

> Souce code mention Saturn many times without saying what
> it is.

Yes, amazing and frustrating, no? I think we must do our best
to avoid this happening in the future!

> One can deduce that it has something to do with user interface
> and that it is probably a Windows thing, for example in
> patches.lisp we had:
> 
> ;; browser stuff:
> #+:UNIX (defvar |$standard| 't)
> #-:UNIX (defvar |$standard| 'nil)
> #+:UNIX (defvar |$saturn| 'nil)
> #-:UNIX (defvar |$saturn| 't)
>

Excellent.
 
> But to find out more (and what I wrote is almost all that
> I know about Saturn) you need to read this mailing list
> (Saturn were mentioned few times during user interface
> discussions).
> 

That's a good point. In fact this questions was originally
answered more than 3 years ago even before we knew what
question to ask. :-)

Greg (Vanuxem Gregory) originally pointed out the point
about the "saturn flag" in

http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00129.html

concerning comparison between output of windows version
and the linux version of Axiom. The original query about
the "saturn code" came from Mike Thomas

http://lists.nongnu.org/archive/html/axiom-developer/2004-11/msg00172.html

when he was working hard to get the first version of
open source Axiom to compile on Windows.

Tim Daly referred to the "Saturn interface (which is no
techexplorer)" here:

http://lists.nongnu.org/archive/html/axiom-developer/2004-06/msg00054.html

Even more relevant is the following post by Mike Dewar:

http://lists.nongnu.org/archive/html/axiom-developer/2003-10/msg00022.html

"The main file in question was br-saturn.boot ("saturn" was IBM's
pre-release name for TechExplorer) and we also used the $saturn
variable to test whether we were in TechExplorer or not in a few
places (this was so we could use the same CCL image files for both
the TechExplorer and shell interfaces of Axiom under Windows).
It might be worth somebody trying to resurrect this code - the only
hitch I can foresee is that we added a grep command to CCL (coded
in C) since Windows doesn't have a grep program, but you can always
spawn off a system command under Unix (which is what the original
IBM version of Axiom did) to get the same result."

http://lists.nongnu.org/archive/html/axiom-developer/2003-09/msg00234.html

"In particular we had a TeX-based browser interface which
you could wire in in place of )show, )what etc.  

The code for this lived in the file br-saturn.boot ("saturn" was
the codename for TechExplorer before IBM released it) and was not
included by default in the Unix build.  It modified the Lisp
commands kSearch, cSearch, dSearch etc. to produce TeX output
with embeded hyperlinks."

\start
Date: 22 Apr 2007 19:46:45 +0200
From: Martin Rubey
To: Alfredo Portes
Subject: Re: Please join!

Dear Alfredo,

it seems that your axiom is too old.  I remember that database access was also
broken in the Linux version, probably until Waldek entered the picture.

What is needed is the following:

  ops := getDatabase("o")$OperationsQuery

should return a number somewhat larger than 6000 (sixthousand)

  ops.(name="binomial").doc

should return a list of docstrings for the various implementations of binomial.

Anybody knows which version is the most windows friendly to support this?  DOes
it work in build-improvements or in patch-50?

\start
Date: Sun, 22 Apr 2007 14:02:29 -0400
From: Alfredo Portes
To: Waldek Hebisch, Martin Rubey
Subject: Re: Please join!

> it seems that your axiom is too old.  I remember that database access was also
> broken in the Linux version, probably until Waldek entered the picture.

Thanks Martin. That makes sense.

> Anybody knows which version is the most windows friendly to support this?  DOes
> it work in build-improvements or in patch-50?

Is Waldek branch able to compile in Windows or is it missing anything
significant from
build-improvements to achieve this?

\start
Date: Sun, 22 Apr 2007 14:11:37 -0400
From: Bill Page
To: Alfredo Portes, Waldek Hebisch, Martin Rubey
Subject: re: Please join!

On April 22, 2007 2:02 PM Alfredo Portes

Martin Rubey wrote:
> > it seems that your axiom is too old.  I remember that 
> > database access was also broken in the Linux version,
> > probably until Waldek entered the picture.
> 
> Thanks Martin. That makes sense.
> 

Alfredo, what version of Axiom on Windows are you using for
this test?

> > Anybody knows which version is the most windows friendly to 
> > support this?  Does it work in build-improvements or in
> > patch-50?
> 
> Is Waldek branch able to compile in Windows or is it missing
> anything significant from build-improvements to achieve this?
> 

It is not possible (yet) to compile wh-sandbox on Windows.
I am working on it. Any help would be appreciated.

\start
Date: 22 Apr 2007 20:23:47 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Versions with database support

I just checked. On Linux,

                        AXIOM Computer Algebra System
                     Version: Axiom 3.9 (September 2005)
             Timestamp: Thursday December 22, 2005 at 15:05:42

does *not* work.

                        AXIOM Computer Algebra System
                       Version: Axiom (September 2006)
              Timestamp: Friday November 17, 2006 at 16:54:07

seems to work

                        AXIOM Computer Algebra System
             Version: Axiom build-improvements branch 2006-11-26
              Timestamp: Wednesday March 14, 2007 at 02:25:47

seems to work

I write "seems", since I do not have a reliable set of axiom versions.  These
are just the versions which happen to be on my harddisk, except the first one.

\start
Date: Sun, 22 Apr 2007 14:47:01 -0400
From: Alfredo Portes
To: Bill Page
Subject: re: Please join!

Hi Bill,

> Alfredo, what version of Axiom on Windows are you using for
> this test?

                        AXIOM Computer Algebra System
               Version of Monday January 17, 2005 at 22:31:38

In http://wiki.axiom-developer.org/AxiomBinaries it says version 0.1.4.

> It is not possible (yet) to compile wh-sandbox on Windows.
> I am working on it. Any help would be appreciated.

Anything I can do to help just let me know. Martin just emailed that
build-improvements seems to have browsing the databases working.

\start
Date: Sun, 22 Apr 2007 15:00:15 -0400
From: Bill Page
To: Alfredo Portes
Subject: re: Please join!

Alfredo,

On April 22, 2007 2:47 PM you wrote:

> Bill Page wrote:
> > Alfredo, what version of Axiom on Windows are you using for
> > this test?
> 
>                         AXIOM Computer Algebra System
>                Version of Monday January 17, 2005 at 22:31:38
> 
> In http://wiki.axiom-developer.org/AxiomBinaries it says 
> version 0.1.4.
>

As you can see that version REALY old...
 
> > It is not possible (yet) to compile wh-sandbox on Windows.
> > I am working on it. Any help would be appreciated.
> 
> Anything I can do to help just let me know. Martin just emailed
> that build-improvements seems to have browsing the databases
> working.
> 

A good first step would be to re-compile a new version of
Axiom for Windows using the build-improvements sources.

\start
Date: Sun, 22 Apr 2007 16:23:03 -0400
From: Alfredo Portes
To: Bill Page
Subject: re: Please join!

Bill,

> A good first step would be to re-compile a new version of
> Axiom for Windows using the build-improvements sources.

I did steps 1, 2 and 3 from: http://wiki.axiom-developer.org/BuildAxiom
to build axiom on windows. I check out build-improvements branch.
What else do I need before I try to compile it. How would it affect that
build-improvements do not compile noweb anymore (hope I am correct
about that last statement), do i need to install it manually?

\start
Date: Sun, 22 Apr 2007 22:29:29 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: re: Please join!

Bill Page wrote:
> On April 22, 2007 2:02 PM Alfredo Portes
>
> > Is Waldek branch able to compile in Windows or is it missing
> > anything significant from build-improvements to achieve this?
> > 
> 
> It is not possible (yet) to compile wh-sandbox on Windows.
> I am working on it. Any help would be appreciated.
> 

Could you write what problems do you see?  Gaby wrote that on
Windows one needs realtive paths -- this part in not merged
into wh-sandbox (mechanical merge gives me build failures on
Linux and the changes conflict with other patches that I am
working on, so this will take some time).  

Algebra and interp directories in wh-sandbox are significantly
differenet than in build-improvements, but I hope that there
is little (or maybe no) differences (beyond paths issues) affecting
portability.

In other subdirectories of src the diff below summarizes unmerged parts:

Index: src/hyper/ChangeLog.build-improvements
===================================================================
--- src/hyper/ChangeLog.build-improvements	(wersja 509)
+++ src/hyper/ChangeLog.build-improvements	(kopia robocza)
@@ -1,3 +1,15 @@
+2007-04-09  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet (${HYPER}/pages/ht.db): Tell htadd that we're
+	building a system database.
+	* Makefile.in: Regenerate.
+
+2006-12-08  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet (${HYPER}/pages/ht.db): Beware of relative
+	directories. 
+	* Makefile.in: Regenerate.
+
 2006-11-26  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* ReadBitmap.pamphlet: Include axiom-c-macros.h

Index: src/doc/Makefile.pamphlet
===================================================================
--- src/doc/Makefile.pamphlet	(wersja 509)
+++ src/doc/Makefile.pamphlet	(kopia robocza)
@@ -136,11 +136,11 @@
 We need to document the commands.
 <<*>>=
 IN=$(axiom_src_srcdir)/doc
-MID=${INT}/doc
+MID=./$(top_builddir)/int/doc
 OUT=$(axiom_target_bindir)
 STY=${OUT}/tex
 DVI=$(axiom_target_docdir)
-DOC=${INT}/doc
+DOC=./$(top_builddir)/int/doc
 
 subdir = src/doc/
 

Index: src/doc/ChangeLog.build-improvements
===================================================================
--- src/doc/ChangeLog.build-improvements	(wersja 509)
+++ src/doc/ChangeLog.build-improvements	(kopia robocza)
@@ -1,3 +1,8 @@
+2006-12-09  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet (MID, DOC): Adjust definition.
+	* Makefile.in: Regenerate.
+
 2006-11-24  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* Makefile.pamphlet (all-doc): New phony target.
Index: src/lisp/Makefile.pamphlet
===================================================================
--- src/lisp/Makefile.pamphlet	(wersja 509)
+++ src/lisp/Makefile.pamphlet	(kopia robocza)
@@ -2,7 +2,7 @@
 \documentclass{article}
 \usepackage{axiom}
 
-\title{\File{src/lisp/Makefile}}
+\title{\File{src/lisp/Makefile} Pamphlet}
 \author{The Axiom Team}
 
 \begin{document}
@@ -18,49 +18,14 @@
 \section{The Makefile}
 
 The purpose of this Makefile is to create a fresh Lisp image, [[$(OUT)/lisp]],
-for use in make [[boot]].  To that end, it augments a existing Lisp
-image, at the moment GCL, with some specific C-routines.
+for use to make \Tool{interpsys} and \Tool{AXIOMsys}.  To that end, 
+it augments an existing Lisp image, at the moment \Tool{GCL}, with 
+some specific C-routines. 
 
-If GCL is not existing in the build environment, we build one and install
-it a separate directory and carry on the build process has if it had 
-existed.
-
-\section{Configure and Make GCL}
-We enable several features of GCL.
-The [[--enable-readline]] uses GNU readline for the prompts. It has been
-removed and replaced with clef which is Axiom's version of readline.
-The [[--enable-maxpage]] is set to allow the image to grow 4 times
-what it would by default.
-The [[--enable-vssize]] allows virtual stack to grow by twice the normal size.
-The [[--enable-statsysbfd]] uses a static system bfd library for loading and
-relocating object files.
-
-We would like to have the following done for all GCL (either built from Axiom 
-sources or system-installed).
-Finally we load some routines for performance reasons. [[lsp/sys-proclaim]]
-contains common lisp proclaim statements for the various GCL lisp routines.
-[[cmpnew/gcl_collectfn]] contains modifications to the common lisp compiler
-to collect compile-time type information which will be written to [[.fn]]
-files as common lisp structs. These [[.fn]] files can be loaded and turned
-into common lisp proclaim statements which the compiler can use to generate
-faster code, mostly fast-path function calls. The call to [[compiler::emit-fn]]
-enables the [[.fn]] file generation whenever compile-file is called. We
-default this code into the image so it is always avaiable.
-
-\begin{verbatim}
-	echo '(progn (load "cmpnew/gcl_collectfn.lsp")' \
-		   ' (load "lsp/sys-proclaim.lisp")' \
-		   ' (compiler::emit-fn t)' \
-                   ' (system::save-system "${OUT}/lisp"))' \
-             | $(GCL))
-\end{verbatim}
-
 \section{The Makefile}
 
-\subsection{GCL already installed or built}
-
-<<build lisp for boot>>=
-## Create a fresh image for building Boot
+<<build augmented lisp>>=
+## Create a fresh image for building interpsys and AXIOMsys
 ## These objects files are the C runtime support
 ## and must be compiled into the Lisp image,
 ## as they must be present in the final interpreter
@@ -70,8 +35,9 @@
 		$(build_libdir)/cfuns-c.o \
 		$(build_libdir)/sockio-c.o
 
-$(OUT)/lisp$(EXEEXT): $(AXIOM_LISP)
-	echo '(compiler::link nil "${OUT}/lisp" ' \
+$(OUT)/lisp$(EXEEXT):
+	@axiom_gcl_rsym_hack@
+	echo '(compiler::link (quote ("../boot/initial-env.lisp")) "lisp" ' \
               ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                         ' (si::*load-types* ~S))' \
                                        ' (compiler::emit-fn t))' \
@@ -79,8 +45,9 @@
                                         ' (si::sgc-on t))' \
                                   ' (setq compiler::*default-system-p* t))"' \
                       ' si::*system-directory* (quote (list ".lsp")))' \
-               '  "$(lisp_c_objects)")' \
+               '  "$(lisp_c_objects) @axiom_c_runtime_extra@")' \
             | $(AXIOM_LISP)
+	$(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
 
 @
 
@@ -91,7 +58,7 @@
 
 pamphlets = Makefile.pamphlet
 
-build_libdir = $(abs_top_builddir)/src/lib
+build_libdir = ./$(top_builddir)/src/lib
 
 lisp_DEPENDENCIES = $(build_libdir)/cfuns-c.o \
 		    $(build_libdir)/sockio-c.o \
@@ -102,14 +69,12 @@
 
 all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
 
-<<build lisp for boot>>
+<<build augmented lisp>>
 
-# Build GCL takes quite a while, so we don't remove the
-# diretcory in mostlyclean.  Rather, we do that in clean.
 mostlyclean-local:
+	-rm -f $(OUT)/lisp$(EXEEXT)
 
 clean-local: mostlyclean
-	-rm -f $(OUT)/lisp$(EXEEXT)
 
 distclean-local: clean-local
 	-rm -f Makefile
Index: src/lisp/ChangeLog.build-improvements
===================================================================
--- src/lisp/ChangeLog.build-improvements	(wersja 509)
+++ src/lisp/ChangeLog.build-improvements	(kopia robocza)
@@ -1,3 +1,35 @@
+2007-03-26  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet ($(OUT)/lisp$(EXEEXT)): Dont' depend on
+	$(AXIOM_LISP).  Load ../boot/initial-env.lisp before saving to
+	disk. Remove obsolete GCL build description.
+	(mostlyclean-local): Remove saved Lisp image.
+	* Makefile.in: Regenerate.
+
+2007-03-04  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet ($(OUT)/lisp$(EXEEXT)): Conditionally depend
+	on GCL.
+	* Makefile.in: Regenerate.
+
+2006-12-10  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet ($(OUT)/lisp$(EXEEXT)): Run GCL/rsym hack
+	work-around commands if necessary.
+	* Makefile.in: Regenerate.
+
+2006-12-09  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet ($(OUT)/lisp$(EXEEXT)): Add extra libraries if
+	necessary. 
+	* Makefile.in: Regenerate.
+
+2006-12-06  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet ($(OUT)/lisp$(EXEEXT)): Build "lisp" image in
+	the build directory, then copy over to the destination dir.
+	* Makefile.in: Regenerate.
+
 2006-12-02  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* Makefile.pamphlet (lisp_c_objects): New variable.
Index: src/etc/Makefile.pamphlet
===================================================================
--- src/etc/Makefile.pamphlet	(wersja 509)
+++ src/etc/Makefile.pamphlet	(kopia robocza)
@@ -2,7 +2,7 @@
 \documentclass{article}
 \usepackage{axiom}
 
-\title{\$SPAD/src/etc Makefile}
+\title{\File{src/etc/Makefile} Pamphlet}
 \author{Timothy Daly \and Gabriel Dos~Reis}
 
 \begin{document}
@@ -26,24 +26,26 @@
 @
 
 \section{The databases}
+
 The databases are built in this Makefile even though the prerequisits
 are actually made during the previous step in the algebra directory.
 This allows us to use a simple wildcard to express the fact that
-all of the [[algreba/*.NRLIB/code.$(OBJEXT)]] files are required in order to build
+all of the [[algreba/*.NRLIB/code.\$(OBJEXT)]] files are required in 
+order to build
 the databases. If any if any of these are changed, the databases must
 be re-built.
 <<dbcomplete>>=
 $(DATABASES): ${INT}/algebra/*.NRLIB/code.$(OBJEXT)
 	@ echo 4 rebuilding databases...
-	@ $(INSTALL_DATA) $(axiom_src_docdir)/gloss.text ${INT}/algebra
-	@ $(INSTALL_DATA) $(axiom_src_docdir)/gloss.text ${INT}/algebra
-	@ $(INSTALL_DATA) $(axiom_src_docdir)/topics.data ${INT}/algebra
-	@ $(INSTALL_DATA) $(axiom_src_docdir)/topics.data ${INT}/algebra
-	@ (cd ${INT}/algebra ; \
+	@ $(INSTALL_DATA) $(axiom_src_docdir)/gloss.text ../algebra
+	@ $(INSTALL_DATA) $(axiom_src_docdir)/gloss.text ../algebra
+	@ $(INSTALL_DATA) $(axiom_src_docdir)/topics.data ../algebra
+	@ $(INSTALL_DATA) $(axiom_src_docdir)/topics.data ../algebra
+	@ (cd ../algebra ; \
            echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
-	@ $(INSTALL_DATA) ${INT}/algebra/*.daase $(axiom_targetdir)/algebra
-	@ $(INSTALL_DATA) ${INT}/algebra/libdb.text $(axiom_targetdir)/algebra
-	@ $(INSTALL_DATA) ${INT}/algebra/comdb.text $(axiom_targetdir)/algebra
+	@ $(INSTALL_DATA) ../algebra/*.daase $(axiom_targetdir)/algebra
+	@ $(INSTALL_DATA) ../algebra/libdb.text $(axiom_targetdir)/algebra
+	@ $(INSTALL_DATA) ../algebra/comdb.text $(axiom_targetdir)/algebra
 	@ $(mkinstalldirs) $(axiom_targetdir)/algebra/USERS.DAASE \
              $(axiom_targetdir)/algebra/DEPENDENTS.DAASE
 	@ $(INSTALL_DATA) ${INT}/algebra/USERS.DAASE/index.KAF \
@@ -54,6 +56,7 @@
 @
 
 \section{\Tool{summary}}
+
 <<summary>>=
 $(axiom_target_libdir)/summary: $(srcdir)/summary
 	$(INSTALL_DATA) $< $@ 
@@ -61,6 +64,7 @@
 @
 
 \section{\File{copyright}}
+
 <<copyright>>=
 $(axiom_target_libdir)/copyright: $(srcdir)/copyright
 	$(INSTALL_DATA) $< $@ 
@@ -88,6 +92,7 @@
  e.g. %s -so Integer
  will give the source file name written to stdout
 \end{verbatim}
+
 <<asq>>=
 bin_PROGRAMS = asq$(EXEEXT)
 asq_sources = asq.c
@@ -104,7 +109,10 @@
 @
 
 <<*>>=
-INTERPSYS=$(axiom_build_bindir)/interpsys
+INTERPSYS= \
+	AXIOM="$(AXIOM)" \
+	DAASE="$(axiom_src_datadir)" \
+	../interp/interpsys$(EXEEXT)
 DATABASES_SHORT=compress.daase interp.daase browse.daase category.daase \
                 operation.daase libdb.text comdb.text USERS.DAASE/index.KAF \
                 DEPENDENTS.DAASE/index.KAF

Index: src/etc/ChangeLog.build-improvements
===================================================================
--- src/etc/ChangeLog.build-improvements	(wersja 509)
+++ src/etc/ChangeLog.build-improvements	(kopia robocza)
@@ -1,3 +1,24 @@
+2007-04-01  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet (INTERPSYS): Adjust path.
+	* Makefile.in: Regenerate.
+
+2007-03-24  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet: Fix typos.
+	* Makefile.in: Regenerate.
+
+2006-12-09  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet (INTERPSYS): Point DAASE to the databases
+	cached in source.
+	* Makefile.in: Regenerate.
+
+2006-12-09  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* Makefile.pamphlet (INT): Define here.
+	* Makefile.in: Regenerate.
+
 2006-11-26  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* asq.c.pamphlet: Include axiom-c-macros.h.

\start
Date: Mon, 23 Apr 2007 03:31:35 +0700 (NOVST)
From: Andrey G. Grozin
To: Ralf Hemmecke
Subject: Re: Please join! re: Axiom HyperDoc Replacement
Cc: Kai Kaminski

On Sun, 22 Apr 2007, Ralf Hemmecke wrote:
> Currently I have only Internet access via Windows and all my work lives in 
> the Linux partition. If somebody tells me how to access the Linux partition 
> from within Windows (the other way round that's possible) without rebooting 
> Linux and using a usbstick that would save me some time.
If your Linux partition is ext2 or ext3, use
http://ext2fsd.sourceforge.net/

\start
Date: Sun, 22 Apr 2007 16:39:19 -0400
From: Bill Page
To: Alfredo Portes
Subject: re: Please join!

Alfredo,

On April 22, 2007 4:23 PM you wrote:
> Bill Page wrote: 
> > A good first step would be to re-compile a new version of
> > Axiom for Windows using the build-improvements sources.
> 
> I did steps 1, 2 and 3 from: 
> http://wiki.axiom-developer.org/BuildAxiom
> to build axiom on windows. I check out build-improvements branch.
> What else do I need before I try to compile it.

That should be ok.

> How would it affect that build-improvements do not compile
> noweb anymore (hope I am correct about that last statement),

That is correct.

> do i need to install it manually?
>

Yes. See:

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

You can use the version of gcl that is in build-improvements but
you must now install noweb your self.

\start
Date: 22 Apr 2007 23:26:45 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: htlatex and links

Dear Ralf,

do you happen to know how to make htlatex generate links to style files
etc. enclosed in vertical bars?  For example, I have the following file:

 factorial`(_$)->_$`CombinatorialFunctionCategory.tex

sending it through htlatex, I get the following reference in
factorial`(_$)->_$`CombinatorialFunctionCategory.html:

<link rel="stylesheet" type="text/css" href="factorial`(_$)->_$`CombinatorialFunctionCategory.css">

but I'd rather have

<link rel="stylesheet" type="text/css" href="|factorial`(_$)->_$`CombinatorialFunctionCategory.css|">

Is there an easy way to accomplish this?

I would like to avoid having to replace all "bad" characters like $ and ` with
others, but I realize that, in fact, that's what you advised me to do anyway.

\start
Date: Sun, 22 Apr 2007 18:15:51 -0400
From: Alfredo Portes
To: Bill Page, Gabriel Dos Reis
Subject: re: Please join!

Bill, Gaby

> You can use the version of gcl that is in build-improvements but
> you must now install noweb your self.

When the build is compiling gcl, it stops with this error:

./libpre_gcl.a(gmp_wrappers.o)(.text+0x1061):gmp_wrappers.c: undefined reference
 to `__gmpn_popcount'
./libpre_gcl.a(gmp_wrappers.o)(.text+0x11aa):gmp_wrappers.c: undefined reference
 to `__gmpz_sizeinbase'
collect2: ld returned 1 exit status
make[2]: *** [raw_pre_gcl_map] Error 1
make[2]: Leaving directory `/e/axiom/gcl/unixport'
make[1]: *** [unixport/saved_pre_gcl] Error 2
make[1]: Leaving directory `/e/axiom/gcl'
make: *** [build/i686-pc-mingw32/bin/gcl.exe] Error 2

\start
Date: Sun, 22 Apr 2007 18:40:16 -0400
From: Bill Page
To: Alfredo Portes, Gabriel Dos Reis
Subject: re: Please join!

On April 22, 2007 6:16 PM Alfredo Portes wrote:
> Bill Page wrote:
> > You can use the version of gcl that is in build-improvements but
> > you must now install noweb your self.
> 
> When the build is compiling gcl, it stops with this error:
> 
> ./libpre_gcl.a(gmp_wrappers.o)(.text+0x1061):gmp_wrappers.c: 
> undefined reference
>  to `__gmpn_popcount'
> ./libpre_gcl.a(gmp_wrappers.o)(.text+0x11aa):gmp_wrappers.c: 
> undefined reference
>  to `__gmpz_sizeinbase'
> collect2: ld returned 1 exit status
> make[2]: *** [raw_pre_gcl_map] Error 1
> make[2]: Leaving directory `/e/axiom/gcl/unixport'
> make[1]: *** [unixport/saved_pre_gcl] Error 2
> make[1]: Leaving directory `/e/axiom/gcl'
> make: *** [build/i686-pc-mingw32/bin/gcl.exe] Error 2
> 

Hmmm...

Did you checkout build-improvements directly to your
windows system. What revision do you have?

I have

$ svn info
Path: .
URL:
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements
Repository Root: https://axiom.svn.sourceforge.net/svnroot/axiom
Repository UUID: 54bea96e-1511-0410-8851-aaeae44645fa
Revision: 512
Node Kind: directory
Schedule: normal
Last Changed Author: dos-reis
Last Changed Rev: 506
Last Changed Date: 2007-04-13 10:31:29 -0400 (Fri, 13 Apr 2007)

----

Are you doing an "out-of-source" build? E.g. If

  /e/build-improvements

is your build-improvements source checked out from svn,
then building out-of-source would look like this:

  $ mkdir /e/axiom
  $ cd /e/axiom
  $ ../build-improvements/configure
  $ make

Could you please try the following:

  $ cd/e/axiom/gcl
  $ make clean
  $ ./configure
  $ make

Do you get the same error? If this works you can do

  $ make install

that will install gcl in the '/usr/local/bin'. If

  $ echo $PATH

shows '/usr/local/bin' in the path, then build-improvements
will use that.

On my system I used the above procedure to put gcl in
/usr/local/bin because I am also working with wh-sandbox
which does not include even gcl.

\start
Date: Sun, 22 Apr 2007 19:36:28 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Mike Thomas' portability changes for Windows

Gaby,

In my email:

http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00167.html

I described Mike Thomas' portability changes for windows. I have
applied these to build-improvements and tested both the Windows
and Solaris 10 x86 builds but more extensive testing is probably
a good idea. The diff from SVN is attached to this email and
affects the files shown below:

$ svn status
...
M      src\interp\daase.lisp.pamphlet
M      src\interp\nlib.lisp.pamphlet
M      src\interp\sys-pkg.lisp.pamphlet
M      src\interp\construc.lisp.pamphlet
M      src\interp\cfuns.lisp.pamphlet
M      src\interp\i-syscmd.boot.pamphlet
M      src\lib\cfuns-c.c.pamphlet
...

Could you look especially at the patches to the file
'cfuns-c.c.pamphlet'? In this case had to merge autoconf-
related changes from build-improvements with Mike's changes.
Although I followed the pattern in the existing code, I am
less confident that I used the #ifdef S_ ... #endif
conditons properly.

I think these changes should be attributed to Mike Thomas
in the ChangeLog.

These changes are necessary in order to run Axiom on Windows
so I think they should go into build-improvements at your
convenience. (I am still using autoconf-2.61 so I prefer if
you commit rather than me.) Meanwhile as outlined in the above
email, I will continue to make similar portability changes in
other parts of the Axiom code.

Regards,
Bill Page.

------=_NextPart_000_00BC_01C78515.882286C0
	name="windows-mike.patch"
	filename="windows-mike.patch"

Index: src/interp/daase.lisp.pamphlet=0A=
==========================
==========================
==================0A=
--- src/interp/daase.lisp.pamphlet	(revision 512)=0A=
+++ src/interp/daase.lisp.pamphlet	(working copy)=0A=
@@ -1246,7 +1246,7 @@=0A=
     (setq filename  (concatenate 'string daase "/algebra/" name))=0A=
     (format t "   Using local database ~a.." filename))=0A=
    (setq filename (concatenate 'string $spadroot "/algebra/" name)))=0A=
-  (when erase? (system::system (concatenate 'string "rm -f " filename)))=0A=
+  (when erase? (delete-file filename))=0A=
   filename))=0A=
 =0A=
 ;; rewrite this so it works in mnt=0A=
Index: src/interp/nlib.lisp.pamphlet=0A=
==========================
==========================
==================0A=
--- src/interp/nlib.lisp.pamphlet	(revision 512)=0A=
+++ src/interp/nlib.lisp.pamphlet	(working copy)=0A=
@@ -94,7 +94,7 @@=0A=
              optionlist)))=0A=
 =0A=
 (defun directory? (filename) (|directoryp| filename))=0A=
-=0A=
+#+:AKCL(defun makedir (fname) (|makedir| fname))=0A=
 ;; (RDEFIOSTREAM ((MODE . IO) (FILE fn ft dir))) IO is I,O,INPUT,OUTPUT=0A=
 #+:AKCL=0A=
 (defun rdefiostream (options &optional (missing-file-error-flag t))=0A=
@@ -240,11 +240,6 @@=0A=
     (file-position stream :end)=0A=
     (write-indextable indextable stream)))=0A=
 =0A=
-;makedir (fname) fname is a directory name.=0A=
-#+:AKCL=0A=
-(defun makedir (fname)=0A=
-  (system (concat "mkdir " fname)))=0A=
-=0A=
 ;; (RREAD key rstream)=0A=
 (defun rread (key rstream &optional (error-val nil error-val-p))=0A=
   (if (equal (libstream-mode rstream) 'output) (error "not input =
stream"))=0A=
Index: src/interp/sys-pkg.lisp.pamphlet=0A=
==========================
==========================
==================0A=
--- src/interp/sys-pkg.lisp.pamphlet	(revision 512)=0A=
+++ src/interp/sys-pkg.lisp.pamphlet	(working copy)=0A=
@@ -92,7 +92,7 @@=0A=
 (lisp:export=0A=
     '(BOOT::|$FormalMapVariableList| BOOT::|$userModemaps|=0A=
 	 boot::restart boot::$IEEE=0A=
-	 BOOT::|directoryp| boot::help boot::|version| boot::|pp|=0A=
+	 BOOT::|directoryp| BOOT::|makedir| boot::help boot::|version| =
boot::|pp|=0A=
 	 BOOT::POP-STACK-4 BOOT::|$BasicDomains| BOOT::|$DomainFrame|=0A=
 	 BOOT::|$SideEffectFreeFunctionList|=0A=
 	 BOOT::ATOM2STRING BOOT::|$DoubleQuote| BOOT::|$genSDVar|=0A=
@@ -198,7 +198,7 @@=0A=
 	 BOOT::GETTAIL BOOT::|QuotientField| BOOT::CURRENT-TOKEN=0A=
 	 BOOT::|$suffix| BOOT::|$VariableCount| BOOT::COMPARE=0A=
 	 LISP:SEQUENCE BOOT::|$Exit| BOOT::BOOT-EQUAL BOOT::LT=0A=
-	 VMLISP::OBEY BOOT::|UnSizedBox| BOOT::|Integer| BOOT::|Nud|=0A=
+	 VMLISP::OBEY BOOT::TYPE-CONTENTS-OF-FILE BOOT::|UnSizedBox| =
BOOT::|Integer| BOOT::|Nud|=0A=
 	 BOOT::IOCLEAR BOOT::|$BigFloatOpt| BOOT::|$EmptyEnvironment|=0A=
 	 BOOT::|$forceDatabaseUpdate| BOOT::$LINESTACK BOOT::ULCASEFG=0A=
 	 BOOT::|$Boolean| BOOT::|$clamList| BOOT::COLLECT=0A=
@@ -305,12 +305,13 @@=0A=
 ;;; Definitions for package VMLISP of type EXPORT=0A=
 (lisp:in-package "VMLISP")=0A=
 (lisp:import '(=0A=
-	  BOOT:|directoryp|))=0A=
+	  BOOT:|directoryp| BOOT:|makedir|))=0A=
+=0A=
 (lisp:export=0A=
     '(VMLISP::SINTP VMLISP::$FCOPY =0A=
          VMLISP::PUT=0A=
 	 VMLISP::QVELT-1 VMLISP::QSETVELT-1 vmlisp::throw-protect=0A=
-	 VMLISP::|directoryp| VMLISP::EQCAR=0A=
+	 VMLISP::|directoryp| VMLISP::|makedir| VMLISP::EQCAR=0A=
 	 VMLISP::DEFIOSTREAM VMLISP::RDEFIOSTREAM VMLISP::MLAMBDA=0A=
 	 VMLISP::QSLESSP VMLISP::QSDIFFERENCE VMLISP::QSQUOTIENT=0A=
 	 VMLISP::ERROROUTSTREAM VMLISP::CREATE-SBC VMLISP::LASTPAIR=0A=
@@ -427,7 +428,7 @@=0A=
 (lisp:shadow '(BOOT::MAP))=0A=
 (lisp:import=0A=
     '(VMLISP::ERROROUTSTREAM LISP:COUNT VMLISP::NE VMLISP::FLUID=0A=
-	 LISP:SEQUENCE VMLISP::OBEY LISP::NUMBER VMLISP::|union|=0A=
+	 LISP:SEQUENCE VMLISP::OBEY BOOT::TYPE-CONTENTS-OF-FILE LISP::NUMBER =
VMLISP::|union|=0A=
 	 LISP:STEP VMLISP::OPTIONLIST VMLISP::EXIT VMLISP::LEXGREATERP))=0A=
 (lisp:import '(vmlisp::make-input-filename))=0A=
 (lisp:import '(vmlisp::libstream-dirname))=0A=
Index: src/interp/construc.lisp.pamphlet=0A=
==========================
==========================
==================0A=
--- src/interp/construc.lisp.pamphlet	(revision 512)=0A=
+++ src/interp/construc.lisp.pamphlet	(working copy)=0A=
@@ -147,8 +147,8 @@=0A=
    (concatenate 'string $spadroot "/../../int/algebra/" (string name) =
".NRLIB/code.lsp")))=0A=
  (let (masterindex blanks index newindex (space (* 22 (length =
innames))))=0A=
  (setq newindex space)=0A=
- (system::system (concatenate 'string "rm -r " (libname outname)))=0A=
- (system::system (concatenate 'string "mkdir " (libname outname)))=0A=
+ (delete-file (libname outname))=0A=
+ (ensure-directories-exist (libname outname))=0A=
  (with-open-file (out (indexname outname) :direction :output)=0A=
   (setq blanks (make-string space :initial-element #\ ))=0A=
   (write  blanks :stream out)       ; reserve space for the masterindex=0A=
@@ -171,10 +171,11 @@=0A=
      (write alist :stream out :level nil :length nil :escape t)))))=0A=
   (file-position out 0)=0A=
   (print masterindex out))=0A=
+  (with-open-file (out (lspname outname) :direction :output)=0A=
   (dolist (inname innames)=0A=
-   (format t "cat ~a >>~a~%" (fullcode inname) (lspname outname))=0A=
-   (system::system =0A=
-    (format nil "cat ~a >>~a" (fullcode inname) (lspname outname)))))))=0A=
+     (format t "Appending file ~a to ~a~%" (fullcode inname) (lspname =
outname))=0A=
+     (with-open-file (in (fullcode inname))=0A=
+      (si::copy-stream in out)))))))=0A=
 =0A=
 =0A=
 (defun |pathname| (p)=0A=
Index: src/lib/cfuns-c.c.pamphlet=0A=
==========================
==========================
==================0A=
--- src/lib/cfuns-c.c.pamphlet	(revision 512)=0A=
+++ src/lib/cfuns-c.c.pamphlet	(working copy)=0A=
@@ -49,11 +49,14 @@=0A=
 =0A=
 #include <sys/types.h>=0A=
 #include <sys/stat.h>=0A=
+#include <stdio.h>=0A=
 #include <unistd.h>=0A=
 #include <stdlib.h>=0A=
 #include <string.h>=0A=
-#include <stdio.h>=0A=
 #include "axiom-c-macros.h"=0A=
+#include <malloc.h>=0A=
+#include <sys/types.h>=0A=
+#include <sys/stat.h>=0A=
 =0A=
 #include "cfuns-c.H1"=0A=
 =0A=
@@ -79,6 +82,12 @@=0A=
 #endif=0A=
 =0A=
 int=0A=
+CLgetpid(void)=0A=
+{=0A=
+    return getpid();=0A=
+}=0A=
+=0A=
+int=0A=
 addtopath(char *dir)=0A=
 {=0A=
     char *path, *newpath;=0A=
@@ -91,7 +100,7 @@=0A=
     if (newpath == NULL)=0A=
         return -1;=0A=
 =0A=
-    sprintf(newpath, "PATH=%s:%s", path, dir);=0A=
+    sprintf(newpath, "PATH=%s;%s", path, dir); /* MSYS/MinGW ??? */=0A=
 =0A=
     return putenv(newpath);=0A=
 }=0A=
@@ -106,20 +115,39 @@=0A=
 directoryp(char *path)=0A=
 {=0A=
     struct stat buf;=0A=
-    int code = stat(path, &buf);=0A=
+    int code;=0A=
 =0A=
-    return code == -1 ? -1 : S_ISDIR(buf.st_mode);=0A=
+    code = stat(path, &buf);=0A=
+    if (code == -1) {=0A=
+        return (-1);=0A=
+    }=0A=
+    else {=0A=
+        return ((buf.st_mode & S_IFDIR) != 0);=0A=
+    }=0A=
 }=0A=
 =0A=
+=0A=
+/* Make a directory returning 0 for success and -1 for failure */=0A=
+=0A=
+int=0A=
+makedir(char *path)=0A=
+{=0A=
+#ifdef S_IRWXO=0A=
+   return ( mkdir (path,(S_IRWXU | S_IRWXO | S_IRWXG)) );=0A=
+#else=0A=
+   return ( mkdir (path) );=0A=
+#endif=0A=
+}=0A=
+=0A=
 int =0A=
 make_path_from_file(char *s, char *t)=0A=
 {=0A=
-    char *pos = "";=0A=
+    char *pos = NULL;=0A=
     char *c;=0A=
 =0A=
     /** simply copies the path name from t into s **/=0A=
     for (c = t + strlen(t); c != s; c--)=0A=
-        if (*c == '/') {=0A=
+        if ( ( *c == '/' ) || ( *c == '\\' ) ) {=0A=
             pos = c;=0A=
             break;=0A=
         }=0A=
@@ -202,22 +230,28 @@=0A=
     if (code == -1) {=0A=
         /** The file does not exist, so check to see=0A=
                  if the directory is writable                  *****/=0A=
-        if (make_path_from_file(newpath, path) == -1=0A=
-            || stat(newpath, &buf) == -1)=0A=
-           return -1;=0A=
-=0A=
-        return 2 * axiom_has_write_access(&buf);=0A=
+        if (make_path_from_file(newpath, path) == -1 ||=0A=
+            stat(newpath, &buf) == -1) {=0A=
+            return (-1);=0A=
+        }=0A=
     }=0A=
-=0A=
-    return axiom_has_write_access(&buf);=0A=
+    else if (geteuid() == buf.st_uid) {=0A=
+        return ((buf.st_mode & S_IWUSR) != 0);=0A=
+#ifdef S_IWGRP=0A=
+    }=0A=
+    else if (getegid() == buf.st_gid) {=0A=
+        return ((buf.st_mode & S_IWGRP) != 0);=0A=
+#endif=0A=
+#ifdef S_IWOTH=0A=
+    }=0A=
+    else {=0A=
+        return ((buf.st_mode & S_IWOTH) != 0);=0A=
+#endif=0A=
+    };=0A=
+    return ( 1 ); /* MSYS/MinGW */=0A=
 }=0A=
 =0A=
 =0A=
-/* Return=0A=
-     -1 if the file designated by PATH is inexistent.=0A=
-      0 if the file exists but process has no read access.=0A=
-      1 if the file exists and read access is granted.  */=0A=
-=0A=
 int=0A=
 readablep(char *path)=0A=
 {=0A=
@@ -225,26 +259,26 @@=0A=
     int code;=0A=
 =0A=
     code = stat(path, &buf);=0A=
-    if (code == -1)=0A=
-        return -1;=0A=
-=0A=
-    if (geteuid() == buf.st_uid) =0A=
+    if (code == -1) {=0A=
+        return (-1);=0A=
+    }=0A=
+    else if (geteuid() == buf.st_uid) {=0A=
         return ((buf.st_mode & S_IREAD) != 0);=0A=
-=0A=
-#ifdef S_IRGRP    =0A=
-     if (getegid() == buf.st_gid) =0A=
+#ifdef S_IRGRP=0A=
+    }=0A=
+    else if (getegid() == buf.st_gid) {=0A=
         return ((buf.st_mode & S_IRGRP) != 0);=0A=
 #endif=0A=
-=0A=
 #ifdef S_IROTH=0A=
+    }=0A=
+    else {=0A=
      return ((buf.st_mode & S_IROTH) != 0);=0A=
-#else=0A=
-     return 0;=0A=
 #endif=0A=
+    };=0A=
+    return ( 1 ); /* MSYS/MinGW */=0A=
 }=0A=
 =0A=
 =0A=
-=0A=
 long=0A=
 findString(char *file, char *string)=0A=
 {=0A=

------=_NextPart_000_00BC_01C78515.882286C0--

\start
Date: Mon, 23 Apr 2007 02:32:04 -0400
From: Bill Page
To: Waldek Hebisch
Subject: re: Please join!

On April 22, 2007 4:29 PM Waldek Hebisch wrote:
> 
> Bill Page wrote:
> > On April 22, 2007 2:02 PM Alfredo Portes
> >
> > > Is Waldek branch able to compile in Windows or is it missing
> > > anything significant from build-improvements to achieve this?
> > > 
> > 
> > It is not possible (yet) to compile wh-sandbox on Windows.
> > I am working on it. Any help would be appreciated.
> > 
> 
> Could you write what problems do you see?  Gaby wrote that on
> Windows one needs realtive paths -- this part in not merged
> into wh-sandbox (mechanical merge gives me build failures on
> Linux and the changes conflict with other patches that I am
> working on, so this will take some time).  
>

I am not convinced that it is necessary to use relative paths
but it does seem to be true that absolute paths can lead to
some trouble. The main cause of the trouble is the MSYS build
environment itself. The "base" of all paths in MSYS is the
root where MSYS was installed. So for example:

  $ cd /
  $ pwd
  /
  $ pwd -W
  C:/msys/1.0

The new option -W for pwd tells that actual Windows path using
/ where Windows normally uses \.

But if I pass a path beginning with / to a native Windows
application produced by MSYS then it does *not* treat / as
equivalent to 'C:\msys\1.0' but rather just 'C:\'. In MSYS it
is possible to specify an "absolute" path like this:

  $ cd /c/wspage
  $ pwd
  /c/wspage
  $ pwd -W
  c:/wspage

So that both MSYS and Windows agree on the "base", but of course
Windows applications do not understand '/c' as referring to
'c:\' unless there exists a link (windows short-cut) in the
root of the current drive with the name 'c' that points to 'c:\'.
This is possible, but awkard to create.

But in brief, this is kind of a mess in MSYS. There is a similar
situation in cygwin but in that case it does not cause problems
if you only build and use cygwin applications because the cygwin
library takes care of the path names. But this is not possible
in MSYS because the target applications are native windows apps.

The old axiom--windows--1 build for Axiom on Windows got around
this by very carefully using a combination of `pwd` and `pwd -W`
to get the right "absolute" path depending on whether it was a
path in an MSYS command or a path in the application code,
respectively.

Gaby's solution to this problem is to use only relative paths.
Occassionally this looks a little weird with paths involving
unresolved things like 'src/share/doc/../../algebra' but at
least both Windows and the MSYS build environment treat these
the same way.

Another solution would be add a new concept of "base path" to
the build machinery so that windows applications like gcl and
the Axiom intermediaries are always given Windows absolute paths
while the MSYS tools see only MSYS absolute paths. But maybe
this would seem overly obscure to most linux developers.

There is also a problem in GCL on Windows when passing
arguments via -exec that contain subdirectory paths that
forces the use of echo and pipe, i.e.

  echo '(compile "foo/bar"

> Algebra and interp directories in wh-sandbox are significantly
> differenet than in build-improvements, but I hope that there
> is little (or maybe no) differences (beyond paths issues)
> affecting portability.

I think that is true.

> 
> In other subdirectories of src the diff below summarizes 
> unmerged parts:
>  ...

I did not notice anything in the diff which might cause
problems (but then I often do not notice what the computer
seems to catch on almost every first attempt ... :)

In return I am sending you the following diff which shows the
current set of local changes that I have made to wh-sandbox
in an attempt to get it to compile under Windows. So far I am
still not successful. Some of these changes I may revert as
I find better ways to deal with the problems.

Index: src/Makefile.pamphlet
===================================================================
--- src/Makefile.pamphlet	(revision 512)
+++ src/Makefile.pamphlet	(working copy)
@@ -188,7 +188,7 @@
 
 <<lispdir>>=
 all-lisp: all-lib
-	cd lisp && $(MAKE) all-lisp
+	cd lisp && $(MAKE) $(AX_FLAGS) all-lisp
 @
 
 
Index: src/scripts/ChangeLog.build-improvements
===================================================================
--- src/scripts/ChangeLog.build-improvements	(revision 512)
+++ src/scripts/ChangeLog.build-improvements	(working copy)
@@ -1,3 +1,8 @@
+2007-04-10  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* document.in: Don't use full internal name of symbols in package
+	boottran.  Push into that package first, and use short name.
+
 2006-11-22  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* document.in (--tangle): Remove yucky hack.
Index: src/interp/Makefile.pamphlet
===================================================================
--- src/interp/Makefile.pamphlet	(revision 512)
+++ src/interp/Makefile.pamphlet	(working copy)
@@ -518,7 +518,7 @@
 
 In order for this information to be used during compiles we define
 <<environment>>=
-PROCLAIMS=(progn (load "sys-pkg.lisp") (load
"$(abs_srcdir)/interp-proclaims.lisp"))
+PROCLAIMS=(progn (load "sys-pkg.lisp") (load
"$(srcdir)/interp-proclaims.lisp"))
 
 @
 
@@ -1110,12 +1110,14 @@
 
 $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
     %.$(FASLEXT) : $(MID)/%.clisp
-	@ echo 10 making $@ from $<
-	@ ( B=`pwd`;\
+	@ echo 10 making $@ from $< hacked: WSP
+	@ ( \
+	  # hacked to avoid windows path problem WSP
+	  cp "$<" hacklocal.clisp ; \
 	  if [ -z "${NOISE}" ] ; then \
-	   echo '(progn  (compile-file "$<" :output-file "'$$B/'$@")
(${BYE}))' | ${DEPSYS} ; \
+	   echo '(progn  (compile-file "hacklocal.clisp" :output-file "$@")
(${BYE}))' | ${DEPSYS} ; \
 	  else \
-	   echo '(progn  (compile-file "$<" :output-file "'$$B/'$@")
(${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
+	   echo '(progn  (compile-file "hacklocal.clisp" :output-file "$@")
(${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
 	  fi )
 
 AUTO_from_MID=\
Index: src/interp/sys-pkg.lisp.pamphlet
===================================================================
--- src/interp/sys-pkg.lisp.pamphlet	(revision 512)
+++ src/interp/sys-pkg.lisp.pamphlet	(working copy)
@@ -29,8 +29,19 @@
 
 This is the boot to lisp compiler package which contains the
 src/boot files. Tt is the boot translator package.
+
+The following make-pkg command caused the error:
+\begin{verbatim}
+Loading sys-pkg.lisp
+
+Correctable error: A package error occurred on "BOOTTRAN":
+"A package with this name already exists.".
+Signalled by MAKE-PACKAGE.
+\end{verbatim}
+So I have commented it out of the build. ...
+Bill Page, 21 April 2007
 <<*>>=
-(make-package "BOOTTRAN" :use '("LISP"))
+;; (make-package "BOOTTRAN" :use '("LISP"))
 @
 
 Everything in axiom that the user references eventually shows
Index: src/lisp/Makefile.pamphlet
===================================================================
--- src/lisp/Makefile.pamphlet	(revision 512)
+++ src/lisp/Makefile.pamphlet	(working copy)
@@ -59,8 +59,8 @@
 
 \subsection{GCL already installed or built}
 
-<<build lisp for boot>>=
-## Create a fresh image for building Boot
+<<build augmented lisp>>=
+## Create a fresh image for building interpsys and AXIOMsys
 ## These objects files are the C runtime support
 ## and must be compiled into the Lisp image,
 ## as they must be present in the final interpreter
@@ -70,8 +70,9 @@
 		$(build_libdir)/cfuns-c.o \
 		$(build_libdir)/sockio-c.o
 
-$(OUT)/lisp$(EXEEXT): $(AXIOM_LISP)
-	echo '(compiler::link nil "${OUT}/lisp" ' \
+$(OUT)/lisp$(EXEEXT): initial-env.lisp
+	@axiom_gcl_rsym_hack@
+	echo '(compiler::link (quote ("initial-env.lisp")) "lisp" ' \
               ' (format nil "(progn (let ((*load-path* (cons ~S
*load-path*))'\
                                         ' (si::*load-types* ~S))' \
                                        ' (compiler::emit-fn t))' \
@@ -79,9 +80,13 @@
                                         ' (si::sgc-on t))' \
                                   ' (setq compiler::*default-system-p*
t))"' \
                       ' si::*system-directory* (quote (list ".lsp")))' \
-               '  "$(lisp_c_objects)")' \
+               '  "$(lisp_c_objects) @axiom_c_runtime_extra@")' \
             | $(AXIOM_LISP)
+	$(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
 
+initial-env.lisp: $(srcdir)/../boot/initial-env.lisp.pamphlet
+	$(axiom_build_document) --tangle $< --output=$@
+
 @
 
 <<*>>=
@@ -91,7 +96,7 @@
 
 pamphlets = Makefile.pamphlet
 
-build_libdir = $(abs_top_builddir)/src/lib
+build_libdir = ./$(top_builddir)/src/lib
 
 lisp_DEPENDENCIES = $(build_libdir)/cfuns-c.o \
 		    $(build_libdir)/sockio-c.o \
@@ -102,7 +107,7 @@
 
 all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
 
-<<build lisp for boot>>
+<<build augmented lisp>>
 
 # Build GCL takes quite a while, so we don't remove the
 # diretcory in mostlyclean.  Rather, we do that in clean.
Index: ChangeLog.wh
===================================================================
--- ChangeLog.wh	(revision 512)
+++ ChangeLog.wh	(working copy)
@@ -1,3 +1,10 @@
+2007-04-21  Bill Page
+
+	* use echo ... | $command instead of -eval for build-prog
+	in configure.ac.pamphlet
+	* apply revision 498 from build-improvements for LN_S
+        in configure.ac.pamphlet and conf/var-defs
+
 2007-04-21  Waldek Hebisch  Waldek Hebisch
 	    Gabriel Dos Reis  Gabriel Dos Reis
 	    Humberto Zuazaga
Index: config/var-def.mk
===================================================================
--- config/var-def.mk	(revision 512)
+++ config/var-def.mk	(working copy)
@@ -66,7 +66,12 @@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 INSTALL_SCRIPT = @INSTALL_SCRIPT@
-LN_S = @LN_S@
+## FIXME:  The test done with Autoconf-2.60 and later concludes
+##         that "ln -s" is unusable on msys, and therefore defaults to
+##         "cp -p", but that default is unusable for us.  For our
+##         purpose "ln -s" is just fine on that platform.  Consequently
+##         we are explicitly overrding that value here.
+LN_S = ln -s
 mkinstalldirs = $(top_srcdir)/config/mkinstalldirs
 PATCH = @PATCH@
 RANLIB = @RANLIB@
@@ -102,23 +107,35 @@
 ## Notice, this is the src/ directory within the toplevel source
 ## directory 
 
-axiom_top_srcdir = @axiom_top_srcdir@
-
-axiom_src_srcdir = $(axiom_top_srcdir)/src
+axiom_src_srcdir = $(top_srcdir)/src
 axiom_src_docdir = $(axiom_src_srcdir)/doc
 axiom_src_datadir = $(axiom_src_srcdir)/share
 axiom_src_algdir = $(axiom_src_srcdir)/algebra
 
 ## Where tools for the build machine are built
-axiom_top_builddir = @abs_top_builddir@/build
-axiom_builddir = @axiom_builddir@
+# Tools that we occasionally build don't know
+# much about Autoconf and related infrastructure.  Therefore
+# we do lot by "hand". For the moment, things work if we specify
+# paths as absolute, as opposed to relative.  Other parts of
+# Axiom also expect absolute paths.
+axiom_abs_top_builddir = $(abs_top_builddir)
+axiom_abs_builddir = $(abs_top_builddir)/build/$(build)
+axiom_abs_build_bindir = $(axiom_abs_builddir)/bin
+axiom_abs_build_libdir = $(axiom_abs_builddir)/lib
+axiom_abs_build_mandir = $(axiom_abs_builddir)/man
+axiom_abs_build_datadir = $(axiom_abs_builddir)/share
+axiom_abs_build_texdir = $(axiom_abs_build_datadir)/texmf/tex
+
+axiom_top_builddir = $(top_builddir)/build
+axiom_builddir = $(axiom_top_builddir)/$(build)
 axiom_build_bindir = $(axiom_builddir)/bin
 axiom_build_libdir = $(axiom_builddir)/lib
 axiom_build_mandir = $(axiom_builddir)/man
 axiom_build_docdir = $(axiom_builddir)/doc
-axiom_build_texdir = $(axiom_builddir)/share/texmf/tex
+axiom_build_datadir = $(axiom_builddir)/share
+axiom_build_texdir = $(axiom_build_datadir)/texmf/tex
 
-axiom_configdir = $(abs_top_builddir)/config
+axiom_configdir = $(top_builddir)/config
 axiom_c_macros = $(axiom_configdir)/axiom-c-macros.h
 
 LATEX = @LATEX@
Index: ChangeLog.build-improvements
===================================================================
--- ChangeLog.build-improvements	(revision 512)
+++ ChangeLog.build-improvements	(working copy)
@@ -1,3 +1,9 @@
+2007-04-10  Gabriel Dos Reis  Gabriel Dos Reis
+
+	* config/var-def.mk (LN_S): Override.
+	* configure.ac.pamphlet (<<file utils>>): Comment out test for
+	"ln -s".
+
 2006-12-03  Gabriel Dos Reis  Gabriel Dos Reis
 
 	* configure.ac.pamphlet (\subsubsection{Signals}): Ensure the
Index: configure.ac.pamphlet
===================================================================
--- configure.ac.pamphlet	(revision 512)
+++ configure.ac.pamphlet	(working copy)
@@ -636,10 +636,20 @@
 
 \paragraph{File utils}
 Then, check for a usable [[install]] program.  Also, find out
-way to hard- or soft-link files.
+way to hard- or soft-link files.  
+
+After a recent migration to
+\Tool{Autoconf-2.60}, it turns out that all possibilities of
+soft-linking are tried (to ``play safe''), and if any variation
+fails then, [[LN_S]] is defined to [[cp -p]], which works
+only for files as sources.  But, the only way we currently
+use [[LN_S]] is when the first argument is a directory.  So, the 
+``portability help'' we get from \Tool{Autoconf} is no help.  
+Consequently, the test for
+[[ln -s]] is commented out for the moment.
 <<file utils>>=
 AC_PROG_INSTALL
-AC_PROG_LN_S
+# AC_PROG_LN_S
 AC_CHECK_PROG([TOUCH], [touch],
               [touch], [AC_MSG_ERROR(['touch' program is missing.])])
 AC_CHECK_PROGS([MKTEMP], [mktemp])

\start
Date: 23 Apr 2007 10:38:00 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: htlatex and links
Cc: Ralf Hemmecke

Dear all,

I have now nearly everything working -- that is, in a very basic sense --
except I have one tiny problem:

I wanted to use things like

stretch`(_$,ACMachineInteger)->_$`dCycleIndexSeries.html

as filenames, but that turned out to be problematic.

Does somebody know an easy way to transform a given string bijectively into a
-- preferably short! -- string that can be used as a filename.  Of course, it
should also work well on windows.

I was thinking of creating an md5 checksum and use that, but it appears
suboptimal to me, since it is not really bijective and looks too complicated.

\start
Date: Mon, 23 Apr 2007 10:56:29 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: htlatex and links

Hi Martin, look into ALLPROSE. Compile a .dvi File and then hover over a 
link in the Exports part of a type.

My DviViewer shows something like

#.2=:MyPrimitiveType:[.PER,PER.]->Boolean

for something like

   ~=: (%, %) -> Boolean

I also had to translate round brackets into square ones, since hyperref 
forgot everything after the first closing (or was it opening) parenthesis.

This translation also happens in tools/aldordoc2tex.pl. I am sure you 
can adjust it.

Ah, and as you can see, I included the name of the type in the link.

And make sure you remove ">" from the filename. Otherwise it will be 
hard to remove that file.


On 04/23/2007 10:38 AM, Martin Rubey wrote:
> Dear all,
> 
> I have now nearly everything working -- that is, in a very basic sense --
> except I have one tiny problem:
> 
> I wanted to use things like
> 
> stretch`(_$,ACMachineInteger)->_$`dCycleIndexSeries.html
> 
> as filenames, but that turned out to be problematic.
> 
> Does somebody know an easy way to transform a given string bijectively into a
> -- preferably short! -- string that can be used as a filename.  Of course, it
> should also work well on windows.
> 
> I was thinking of creating an md5 checksum and use that, but it appears
> suboptimal to me, since it is not really bijective and looks too complicated.

Why do you need bijectivity at all? All you want is a cache, right? So 
md5 seems OK to me.

\start
Date: 23 Apr 2007 11:08:49 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: htlatex and links

Ralf Hemmecke writes:

> This translation also happens in tools/aldordoc2tex.pl. I am sure you can
> adjust it.

I don't speak perl.  Furthermore, I'd also like to have compression.

> Ah, and as you can see, I included the name of the type in the link.
> 
> And make sure you remove ">" from the filename. Otherwise it will be hard to
> remove that file.

Apart from this, I find it problematic that file names will become very long
this way.
 
> > I was thinking of creating an md5 checksum and use that, but it appears
> > suboptimal to me, since it is not really bijective and looks too complicated.
> 
> Why do you need bijectivity at all? All you want is a cache, right? So md5
> seems OK to me.

Well, for the moment I think it's ok, even though md5 is not even injective.
But I thought that it would be better to have something bijective to be remain
more flexible.


I would have thought that gzip -c | somesimpleencoder would be ideal for that
purpose.  But I couldn't find any encoder that uses only letters and digits.

\start
Date: 23 Apr 2007 11:20:15 +0200
From: Martin Rubey
To: list
Subject: Base32 encoder needed

The following message is a courtesy copy of an article
that has been posted to comp.lang.lisp as well.

Dear all,

finally I know what I want: a base32 encoder. Anybody has one available?

\start
Date: 23 Apr 2007 11:30:27 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Base32 encoder needed

Ralf,

could you teach me how to use

http://search.cpan.org/dist/MIME-Base32/Base32.pm

I want to do something like

echo "binomial`(_$,_$)->_$`OutputForm" | gzip -c | base32


Well, additionally I have the problem that I somehow need to get this into a
string variable within axiom.

\start
Date: Mon, 23 Apr 2007 11:39:07 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: wh-sandbox

As of revision 513 wh-sandbox should build both with CLtL1 gcl
and Ansi gcl.  There is good chance that it will build and run
in gcl (safety 3) mode -- 513 contains fixes for all problem that
I observed in such build, but I still have to do a clean run from
start to end (safe build take more than 16 hours).

In a private tree I also managed to build wh-sandbox using sbcl,
but there are problems in some tests and some changes does not
look good.  I commited most of obvious fixes to 513, but the
rest will take some time.

\start
Date: Mon, 23 Apr 2007 11:41:15 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: htlatex and links

On 04/23/2007 11:08 AM, Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>> This translation also happens in tools/aldordoc2tex.pl. I am sure you can
>> adjust it.
> 
> I don't speak perl.  Furthermore, I'd also like to have compression.

Compression of what? The filename? For ALLPROSE I wanted the Hyperlink 
(actually xdvik) to show a bit of information in a readable form (the 
type where the function comes from). That was the only reason why I made 
the link name human readable. I only had the restriction of hyperref and 
  perhaps TeX's memory, but not more.

>> Ah, and as you can see, I included the name of the type in the link.
>>
>> And make sure you remove ">" from the filename. Otherwise it will be hard to
>> remove that file.
> 
> Apart from this, I find it problematic that file names will become very long
> this way.
>  
>>> I was thinking of creating an md5 checksum and use that, but it appears
>>> suboptimal to me, since it is not really bijective and looks too complicated.
>> Why do you need bijectivity at all? All you want is a cache, right? So md5
>> seems OK to me.
> 
> Well, for the moment I think it's ok, even though md5 is not even injective.

Do you really think that you can find two signatures in Axiom that have 
the same md5 code? What is the probability of that?

> I would have thought that gzip -c | somesimpleencoder would be ideal for that
> purpose.  But I couldn't find any encoder that uses only letters and digits.

somesimpleencoder = base64encoder

http://de.wikipedia.org/wiki/Base64

\start
Date: 23 Apr 2007 13:07:57 +0200
From: Martin Rubey
To: list
Subject: HyperDoc replacement

Dear all,

I believe I've got it working now, at least on linux.  Maybe some Windows users
could try the new version, too.

prerequesites: 

I use

* tex4ht  to convert tex to html
* md5sum  to make a nice url out of a signature
  
     (does md5sum myspec > md5spec work on windows, when myspec contains some
      text to be md5summed?)

* rm      to remove a file
     (does rm *.{log,4tc,4ct,lg,tmp,aux,dvi,idv,xref,css} work on windows?)

otherwise, go to 

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

and follow the steps there.
 
I will not work on beautifying things.  Maybe, I will add support for links (a
la \spadfun and \spad) and maybe I will add support to search for Constructors.

Waldek, do you know how I get the lists of attributes, uses, users and
dependents?

\start
Date: Mon, 23 Apr 2007 14:29:18 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Duplicate argument in testInterpolant

Martin Rubey wrote:
> Waldek Hebisch writes:
> 
> > In particular the parameter 'list' is repeated twice.  AFAICS Spad
> > does not allow overloading of parameter names and even if such
> > overloading is allowed the header still have problem because
> > types are identical.
> > 
> > BTW: I found the problem because generated Lisp also have duplicate
> > argument and SBCL chokes on it (GCL did not complain).
> 
> sorry, I thought this was already on the list (with the obvious patch).  I'll
> send you an updated version of the package (I think Greg pointed out also some
> other typos) within two hours or so.
> 

I did not receive a new version from you.  But since you say that obvious
patch is OK in revision 513 I just removed the second copy of the
argument.

\start
Date: Mon, 23 Apr 2007 05:32:14 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: Base32 encoder needed

I don't know if this is what you're after (plus, it's GPL) but there is
this:

http://darcs.informatimago.com/darcs/public/lisp/common-lisp/rfc3548.lisp

--- Martin Rubey wrote:

> The following message is a courtesy copy of an article
> that has been posted to comp.lang.lisp as well.
> 
> Dear all,
> 
> finally I know what I want: a base32 encoder. Anybody has one
> available?

\start
Date: Mon, 23 Apr 2007 05:41:17 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: wh-sandbox

EXCELLENT news!  Very impressive work.

A question - is there a configure option at the Axiom toplevel to build
GCL in ANSI mode if using the in-tree GCL, or does this need GCL
installed externally?  Not a major problem, I'd just like to test
correctly.

Thanks for all your efforts!

--- Waldek Hebisch wrote:

> As of revision 513 wh-sandbox should build both with CLtL1 gcl
> and Ansi gcl.  There is good chance that it will build and run
> in gcl (safety 3) mode -- 513 contains fixes for all problem that
> I observed in such build, but I still have to do a clean run from
> start to end (safe build take more than 16 hours).
> 
> In a private tree I also managed to build wh-sandbox using sbcl,
> but there are problems in some tests and some changes does not
> look good.  I commited most of obvious fixes to 513, but the
> rest will take some time.

\start
Date: 23 Apr 2007 14:46:52 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Base32 encoder needed

Cliff Yapp writes:

> I don't know if this is what you're after (plus, it's GPL) but there is
> this:
> 
> http://darcs.informatimago.com/darcs/public/lisp/common-lisp/rfc3548.lisp


Yes, that's exactly what I was after.  I stick with md5sum for the moment,
since this has "compression" built in, but together with

http://common-lisp.net/project/gzip-stream/

it is certainly better than md5.

Note that my code is quite flexible with respect to this problem.  The function
in question is

        getSpecification(op: IndexCard): String == 
            s: String := concat([op.'name, "`", op.'type, "`", op.'origin])
            systemCommand("sys rm myspec")$MoreSystemCommands
            f: TextFile := open("myspec"::FileName, "output")
            writeLine!(f, s)
            close! f
            systemCommand("sys md5sum myspec > md5spec")$MoreSystemCommands
            f: TextFile := open("md5spec"::FileName, "input")
            r := readLine! f
            close! f
            r.(1..32)

It's sole purpose is to translate

            s: String := concat([op.'name, "`", op.'type, "`", op.'origin])

at least injectively into a filename.  As you can see it currently uses file IO
and md5sum, even though md5 is not injective, but nearly...

But it would be better to avoid file IO and call these two lisp utilities
instead.  And of course, the proper way would be to write a tiny wrapper
package for rfc3548.lisp and another one for gzip-stream, but I'm not going to
do it.

\start
Date: Mon, 23 Apr 2007 15:34:10 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: wh-sandbox

CY wrote:
> A question - is there a configure option at the Axiom toplevel to build
> GCL in ANSI mode if using the in-tree GCL, or does this need GCL
> installed externally?  Not a major problem, I'd just like to test
> correctly.
> 

ANSI GCL must be installed externally, use --with-lisp=/path/to/lisp
configure option to choose which Lisp is used for build.

\start
Date: Mon, 23 Apr 2007 16:38:31 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: Mike Thomas' portability changes for Windows
Cc: Gabriel Dos Reis

> Gaby,
> 
> In my email:
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00167.html
> 
> I described Mike Thomas' portability changes for windows. I have
> applied these to build-improvements and tested both the Windows
> and Solaris 10 x86 builds but more extensive testing is probably
> a good idea. The diff from SVN is attached to this email and
> affects the files shown below:
> 
> $ svn status
> ...
> M      src\interp\daase.lisp.pamphlet
> M      src\interp\nlib.lisp.pamphlet
> M      src\interp\sys-pkg.lisp.pamphlet
> M      src\interp\construc.lisp.pamphlet
> M      src\interp\cfuns.lisp.pamphlet
> M      src\interp\i-syscmd.boot.pamphlet
> M      src\lib\cfuns-c.c.pamphlet
> ...
> 
> Could you look especially at the patches to the file
> 'cfuns-c.c.pamphlet'? In this case had to merge autoconf-
> related changes from build-improvements with Mike's changes.
> Although I followed the pattern in the existing code, I am
> less confident that I used the #ifdef S_ ... #endif
> conditons properly.
> 
> I think these changes should be attributed to Mike Thomas
> in the ChangeLog.
> 
> These changes are necessary in order to run Axiom on Windows
> so I think they should go into build-improvements at your
> convenience. (I am still using autoconf-2.61 so I prefer if
> you commit rather than me.) Meanwhile as outlined in the above
> email, I will continue to make similar portability changes in
> other parts of the Axiom code.
> 

src/interp/construc.lisp.pamphlet is unused and probably will
be deleted, the changes to it are likely to be wrong.

The change to src/interp/daase.lisp.pamphlet looks good
(but one needs more changes for real portability).

The change to src/interp/nlib.lisp.pamphlet is reasonable, but
I probably would like to do it in a different way to have
varsion which is not gcl specific.

src/interp/sys-pkg.lisp.pamphlet of course have to be kept in sync
with other changes.

Changes to src/lib/cfuns-c.c.pamphlet look backwards: 
  CLgetpid is unused and was removed
  addtopath is unused and probably should be removed
  current code in directoryp should be more portable then Mike's
    version
  change to make_path_from_file should be conditional (Mike's
  version will mishandle Unix files which have backslashes in
  their name)
  in readablep and writeablep what matters for you is probably
  the final "return 1;" statement (which effectivly disables
  permission checking on Windows).

\start
Date: Mon, 23 Apr 2007 21:51:32 -0400
From: Cliff Yapp
To: Waldek Hebisch
Subject: Re: ANSI GCL build success confirmed

Confirmed on Gentoo Linux with latest checkouts:

                             ****
GCL (GNU Common Lisp)  2.6.8 ANSI    Apr 23 2007 08:44:17
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
                        AXIOM Computer Algebra System
                 Version: Axiom wh-sandbox branch 2006-03-28
                Timestamp: Monday April 23, 2007 at 08:54:19
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

(1) ->

\start
Date: Wed, 25 Apr 2007 00:41:07 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: Re: ANSI GCL build success confirmed

C Y wrote:
> Confirmed on Gentoo Linux with latest checkouts:
> 

Good.  Thanks for trying.

\start
Date: Wed, 25 Apr 2007 10:01:51 -0400
From: Jacques Carette
To: list
Subject: Programming Languages and Mechanised Mathematics
	-- deadline extension

[Extended deadline: submissions now due May 2nd, 2007]

Programming Languages for Mechanized Mathematics Workshop

As part of Calculemus 2007
<http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/>
Hagenbergs, Austria
June 29-30, 2007.

The intent of this workshop is to examine more closely the intersection
between
programming languages and mechanized mathematics systems (MMS). By MMS, w=
e
understand computer algebra systems (CAS), [automated] theorem provers
(TP/ATP), all heading towards the development of fully unified systems (t=
he
MMS), sometimes also called universal mathematical assistant systems
(MAS) (see
Calculemus 2007
<http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/>).

There are various ways in which these two subjects of /programming
languages/ and /systems for mathematics/ meet:

   * Many systems for mathematics contain a dedicated programming
     language. For instance, most computer algebra systems contain a
     dedicated language (and are frequently built in that same
     language); some proof assistants (like the Ltac language for Coq)
     also have an embedded programming language. Note that in many
     instances this language captures only algorithmic content, and
     /declarative/ or /representational/ issues are avoided.
   * The /mathematical languages/ of many systems for mathematics are
     very close to a functional programming language. For instance the
     language of ACL2 is just Lisp, and the language of Coq is very
     close to Haskell. But even the mathematical language of the HOL
     system can be used as a functional programming language that is
     very close to ML and Haskell. On the other hand, these languages
     also contain very rich specification capabilities, which are
     rarely available in most computation-oriented programming
     languages. And even then, many specification languages (B, Z,
     Maude, OBJ3, CASL, etc) can still teach MMSes a trick or two
     regarding representational power.
   * Conversely, functional programming languages have been getting
     "more mathematical" all the time. For instance, they seem to have
     discovered the value of dependent types rather recently. But they
     are still not quite ready to 'host' mathematics (the non-success
     of docon <http://www.haskell.org/docon/> being typical). There are
     some promising languages on the horizon (Epigram
     <http://www.e-pig.org/>, Omega
     <http://web.cecs.pdx.edu/%7Esheard/Omega/index.html>) as well as
     some hybrid systems (Agda <http://agda.sourceforge.net/>, Focal
     <http://focal.inria.fr/site/index.php>), although it is unclear if
     they are truly capable of expressing the full range of ideas
     present in mathematics.
   * Systems for mathematics are used to prove programs correct. (One
     method is to generate "correctness conditions" from a program that
     has been annotated in the style of Hoare logic and then prove
     those conditions in a proof assistant.) An interesting question is
     what improvements are needed for this both on the side of the
     mathematical systems and on the side of the programming languages.

We are interested in all these issues. We hope that a certain synergy wil=
l
develop between those issues by having them explored in parallel.

These issues have a very colourful history. Many programming language
innovations first appeared in either CASes or Proof Assistants, before
migrating towards more mainstream languages. One can cite (in no particul=
ar
order) type inference, dependent types, generics, term-rewriting,
first-class
types, first-class expressions, first-class modules, code extraction, and=
 so
on. However, a number of these innovations were never aggressively
pursued by
system builders, letting them instead be developped (slowly) by programmi=
ng
language researchers. Some, like type inference and generics have
flourished.
Others, like first-class types and first-class expressions, are not
seemingly
being researched by anyone.

We want to critically examine what has worked, and what has not. Why are =
all
the current ``popular''[1] computer algebra systems untyped? Why are the
(strongly typed) proof assistants so much harder to use than a typical
CAS? But
also look at question like what forms of polymorphism exists in mathemati=
cs?
What forms of dependent types exist in mathematics? How can MMS regain th=
e
upper hand on issues of 'genericity'? What are the biggest barriers to
using a
more mainstream language as a host language for a CAS or an ATP?

This workshop will accept two kinds of submissions: full research papers =
as
well as position papers. Research papers should be nore more than 15
pages in
length, and positions papers no more than 3 pages. Submission will be
through
_EasyChair_. An informal version of the proceedings will be available at =
the
workshop, with a more formal version to appear later. We are looking into
having the best papers completed into full papers and published as a spec=
ial
issue of a Journal (details to follow).


Important Dates

May 02, 2007: Submission Deadline (Extended!)
May 30, 2007: Notification
June 29-30, 2007: Workshop


Program Committee

Lennart Augustsson [Credit Suisse]
Wieb Bosma [Radboud University Nijmegen, Netherlands]
Jacques Carette (co-Chair) [McMaster University, Canada]
David Delahaye [CNAM, France]
Jean-Christophe Filli=E2tre [CNRS and Universit=E9 de Paris-Sud, France]
John Harrison [Intel Corporation, USA]
Josef Urban [Charles University, Czech Republic]
Markus (Makarius) Wenzel [Technische Universit=E4t M=FCnchen, Germany]
Freek Wiedijk (co-Chair) [Radboud University Nijmegen, Netherlands]
Wolfgang Windsteiger [University of Linz, Austria]


   Location and Registration

Location and registration information can be found on the Calculemus
<http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/> web si=
te.

-------------------------------------------------------------------------=
----
[1] by popular we mean > 1 million users.

\start
Date: Thu, 26 Apr 2007 08:16:15 -0400
From: Bill Page
To: Waldek Hebisch
Subject: building wh-sandbox on Windows
Cc: Waldek Hebisch

Waldek,

I have finally succeeded in building wh-sandbox on Windows. 
I have attached the patch set with diffs against revision 515. 
My approach was to introduce a "BASE" variable as I discussed
in a previous email to allow the Windows applications to have
a different absolute path than the MSYS tools used during the
build. This is in contrast to Gaby's approach of making all paths
relative. In the end this seemed like the shortest path to getting
wh-sandbox to compile under Windows. 

Please let me know what you think about this approach. 

I will continue to test this patchset to make sure that it does
not break the linux build. 

Regards,
Bill Page. 

--=_5q2nu2tulpts
	charset=UTF-8;
	name="windows2.patch"
	filename="windows2.patch"

This is a set of patches against revision 515 of wh-sandbox. 

Index: README.build-improvements
===================================================================
--- README.build-improvements	(revision 515)
+++ README.build-improvements	(working copy)
@@ -77,17 +77,11 @@
 * Properly document the new build in a very intelligible way
 * Document src/scripts/document.in
 
-* Reorganize the makefile pamphlets so that Axiom can build without
-  LaTeX or X11. 
-
 * Support cross-compilation.  Work with Camm to enhance GCL in that
   respect. This is better done when we integrate GCL to GCC. 
 
 * cleanup the Makefile pamphlets
 
-* Support standard "clean", "mostlyclean", and "distclean" Makefile
-  targets
-
 * Improve Boot documentation
 
 * Have Axiom use bootsys compile all Boot codes in src/interp. This
@@ -127,3 +121,9 @@
 
 * Fix fall-outs of missed DVI files. 
   This is believed to be fixed with the recursive rule support. 
+
+* Reorganize the makefile pamphlets so that Axiom can build without
+  LaTeX or X11. 
+
+* Support standard "clean", "mostlyclean", and "distclean" Makefile
+  targets
Index: src/scripts/document.in
===================================================================
--- src/scripts/document.in	(revision 515)
+++ src/scripts/document.in	(working copy)
@@ -37,14 +37,23 @@
 #       Anything that comes after is treated as an argument, even
 #       if it looks like an option
 
+## 2007-04-10:
+##   After moving to a recent version of MSYS, and GCL-2.6.8pre, I
+##   noticed that double-colon ('::' in boottran::boottocl) will be
+##   translated to semi-colon (';') as if interpreted for path
+##   separator.  I don't who is doing that, and I have no time to
+##   investigate it, and even if I do, it would not help much.  
+##   Therefore, I've changed the script not to use double-colon. 
+##      -- Gaby
 
+
 # set -x
 
-latex=@LATEX@
-index=@MAKEINDEX@
+latex="@LATEX@"
+index="@MAKEINDEX@"
 
-notangle=@NOTANGLE@
-noweave=@NOWEAVE@
+notangle="@NOTANGLE@"
+noweave="@NOWEAVE@"
 
 # Flags used to invoke the Lisp compiler in batch mode
 quiet="@axiom_quiet_flags@"
@@ -103,16 +112,16 @@
     case $lisp_flavor in
 	gcl|sbcl|clisp)
 	   if [ -z "$output" ] ; then 
-	       $command $quiet $eval_flags \
-	         "(progn (compile-file \"$1\") (quit))"
+	       # $command $quiet $eval_flags \
+	       echo "(progn (compile-file \"$1\") (quit))" | $command
 	   else
                # argument to:output-file has implementation defined
                # default -- we use merge-patnames to pick defaults
                # from *default-pathname-defaults*
 
-	       $command $quiet $eval_flags \
-	         "(progn (compile-file \"$1\" :output-file \
-                 (merge-pathnames \"$output\")) (quit))"
+	       # $command $quiet $eval_flags 
+	       echo "(progn (compile-file \"$1\" :output-file \
+                 (merge-pathnames \"$output\")) (quit))" | $command
 	   fi
 	   ;;
 	# ECL makes the saved image executable only if :system-p it true. 
@@ -136,7 +145,8 @@
            ## image.  Consequently, we don't supply the $quiet flags
            ## when loading-and-saving. 
            $command $eval_flags "(load \"$1\")" \
-	       $eval_flags "(boottran::save-core \"$output\")"
+	       $eval_flags "(in-package \"boottran\")" \
+	       $eval_flags "(save-core \"$output\")"
 	   ;;
 	*)
 	   error "don't know how to compile with '$lisp_flavor' Lisp"
@@ -149,8 +159,9 @@
 make_program() {
     case $lisp_flavor in
 	gcl|sbcl|clisp)
-           $command $eval_flags \
-	       "(boottran::make-program \"$output\" (quote ($*)))"
+           ## $command $eval_flags \
+	   echo "(in-package \"boottran\") \
+	         (make-program \"$output\" (quote ($*)))" | $command
 	   ;;
 	*)
 	   error "don't know how to build program with '$lisp_flavor' Lisp"
@@ -165,8 +176,8 @@
 translate_boot_file() {
     case $lisp_flavor in
 	gcl|sbcl|clisp)
-	   $command $quiet $eval_flags \
-	       "(progn (boottran::boottoclc \"$1\") (quit))" | tee $2 
+	   # $command $quiet $eval_flags "(in-package \"boottran\")" \
+	   echo "(in-package \"boottran\") (progn (boottoclc \"$1\")) (quit)" | $command | tee $2 
 	   ;;
 	*)
 	   error "don't know how to translate with '$lisp_flavor' Lisp"
Index: src/algebra/Makefile.pamphlet
===================================================================
--- src/algebra/Makefile.pamphlet	(revision 515)
+++ src/algebra/Makefile.pamphlet	(working copy)
@@ -376,8 +376,8 @@
 	for A in ${CATLIST} ; do \
 	     echo ')compile "'$$A'.spad"' >> boo1.input ; \
 	done; \
-	{ echo ')read "boo1.input"' | \
-	    ${INTERPSYS} ${CTRACE} } || exit 1 ; \
+	( echo ')read "boo1.input"' | \
+	    ${INTERPSYS} ${CTRACE} ) || exit 1 ; \
 	echo "Stage 1 copy" ; \
 	for A in ${CATLIST} ; do \
 	    cp $$A.NRLIB/code.$(FASLEXT) ${OUT}/$$A.$(FASLEXT) || exit 1 ; \
@@ -387,8 +387,8 @@
 	for A in ${CATLIST} ${DOMLIST} ; do \
 	    echo ')compile "'$$A'.spad"' >> boo2.input ; \
 	done; \
-	{ echo ')read "boo2.input"' | \
-	    ${INTERPSYS} ${CTRACE} } || exit 1 ; \
+	( echo ')read "boo2.input"' | \
+	    ${INTERPSYS} ${CTRACE} ) || exit 1 ; \
 	echo "Stage 2 copy" ; \
 	for A in ${CATLIST} ${DOMLIST} ; do \
 	    cp $$A.NRLIB/code.$(FASLEXT) ${OUT}/$$A.$(FASLEXT) || exit 1 ; \
@@ -400,8 +400,8 @@
 	for A in ${CATLIST} ${DOMLIST} ; do \
 	    echo ')compile "'$$A'.spad"' >> boo3.input ; \
 	done; \
-	{ echo ')read "boo3.input"' | \
-	    ${INTERPSYS} ${CTRACE} } || exit 1 ; \
+	( echo ')read "boo3.input"' | \
+	    ${INTERPSYS} ${CTRACE} ) || exit 1 ; \
 	echo "Stage 3 object copy" ; \
 	for A in ${CATLIST} ${DOMLIST} ; do \
 	   cp $$A.NRLIB/code.$(FASLEXT) ${OUT}/$$A.$(FASLEXT) || exit 1 ; \
Index: src/interp/patches.lisp.pamphlet
===================================================================
--- src/interp/patches.lisp.pamphlet	(revision 515)
+++ src/interp/patches.lisp.pamphlet	(working copy)
@@ -64,8 +64,12 @@
 ;;patches for now
 
 ;; browser stuff:
-(defvar |$standard| 't)
-(defvar |$saturn| 'nil)
+;; gdr NOTES: it is WRONG to test for platforms, when in fact
+;; gdr NOTES: one should test for functionalities. 
+#+:UNIX (defvar |$standard| 't)
+#-:UNIX (defvar |$standard| 'nil)
+#+(or :UNIX :winnt) (defvar |$saturn| 'nil)
+#-(or :UNIX :winnt) (defvar |$saturn| 't)
 
 (defun CATCHALL (a &rest b) a) ;; not correct but ok for now
 (defvar |$demoFlag| nil)
@@ -360,25 +364,25 @@
            "A structure to hold XDR streams. The stream is printed out."
            (handle ) ;; this is what is used for xdr-open xdr-read xdr-write
            (name ))  ;; this is used for printing
-#+:akcl
+#+(and :gcl (not (or :dos :win32)))
 (defun |xdrOpen| (str dir) (make-xdr-stream :handle (system:xdr-open str) :name str))
 #+:CCL
 (defun |xdrOpen| (str dir) (xdr-open str dir) )
-#+:dos
+#+(and :gcl (or :dos :win32))
 (defun |xdrOpen| (str dir) (format t "xdrOpen called"))
 
-#+:akcl
+#+(and :akcl (not (or :dos :win32)))
 (defun |xdrRead| (xstr r) (system:xdr-read (xdr-stream-handle xstr) r) )
 #+:CCL
 (defun |xdrRead| (xstr r) (xdr-read xstr r) )
-#+:dos
+#+(and :gcl (or :dos :win32))
 (defun |xdrRead| (str) (format t "xdrRead called"))
 
-#+:akcl
+#+(and :akcl (not (or :dos :win32)))
 (defun |xdrWrite| (xstr d) (system:xdr-write (xdr-stream-handle xstr) d) )
 #+:CCL
 (defun |xdrWrite| (xstr d) (xdr-write xstr d) )
-#+:dos
+#+(and :gcl (or :dos :win32))
 (defun |xdrWrite| (str) (format t "xdrWrite called"))
 
 ;; here is a test for XDR
Index: src/interp/Makefile.pamphlet
===================================================================
--- src/interp/Makefile.pamphlet	(revision 515)
+++ src/interp/Makefile.pamphlet	(working copy)
@@ -518,7 +518,7 @@
 
 In order for this information to be used during compiles we define
 <<environment>>=
-PROCLAIMS=(progn (load "sys-pkg.lisp") (load "$(abs_srcdir)/interp-proclaims.lisp"))
+PROCLAIMS=(progn (load "sys-pkg.lisp") (load "$(srcdir)/interp-proclaims.lisp"))
 
 @
 
@@ -991,10 +991,10 @@
 	@ echo '(in-package "BOOT")' >> makeint.lisp
 	@ touch ${TIMESTAMP}
 	@ echo '${YEARWEEK}' >> makeint.lisp
-	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${AXIOM}")' >> makeint.lisp
+	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "$(BASE)%", ${OPOBJS}))) (quote ($(patsubst %, "$(BASE)%", ${OCOBJS}))) (quote ($(patsubst %, "$(BASE)%", ${BROBJS}))) (quote ($(patsubst %, "$(BASE)%", ${TRANOBJS}))) (quote ($(patsubst %, "$(BASE)%", ${NAGBROBJS}))) (quote ($(patsubst %, "$(BASE)%", ${ASAUTO})))  "${AXIOM}")' >> makeint.lisp
 	@ echo '(boot::set-restart-hook)' >> makeint.lisp
 	@ echo '(in-package "BOOT")' >> makeint.lisp
-	@ echo '(load "${INT}/algebra/warm.data")' >> makeint.lisp
+	@ echo '(load "$(BASE)${INT}/algebra/warm.data")' >> makeint.lisp
 	@ echo '(|clearClams|)' >> makeint.lisp
 	@ echo '(load "obey")' >> makeint.lisp
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> makeint.lisp
@@ -1025,7 +1025,7 @@
 	@echo '(progn (gbc t) (load "makeint.lisp") (gbc t)' \
 	   '#+:gcl(setf compiler::*default-system-p* nil)' \
 	   '#+:gcl(compiler::emit-fn nil)' \
-	   '(user::spad-save "$@"))' | DAASE=$(axiom_targetdir) ${LISPSYS}
+	   '(user::spad-save "$@"))' | DAASE="$(BASE)$(axiom_targetdir)" ${LISPSYS}
 	@ echo 6a ${AXIOMSYS} created
 @
 
@@ -1109,26 +1109,29 @@
 
 $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
     %.$(FASLEXT) : $(MID)/%.clisp
-	@ echo 10 making $@ from $<
-	@ ( B=`pwd`;\
+	@ echo 10a making $@ from $< # hack 1 by Bill Page
+	# avoid paths in file names for Windows compatibility
+	@ (cd ${MID} ; \
 	  if [ -z "${NOISE}" ] ; then \
-	   echo '(progn  (compile-file "$<" :output-file "'$$B/'$@") (${BYE}))' | ${DEPSYS} ; \
+	   echo '(progn  (compile-file "$(notdir $<)" :output-file "$(notdir $@)") (${BYE}))' | ${DEPSYS} ; \
 	  else \
-	   echo '(progn  (compile-file "$<" :output-file "'$$B/'$@") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
-	  fi )
+	   echo '(progn  (compile-file "$(notdir $<)" :output-file "$(notdir $@)") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
+	  fi ; )
+	@ mv "${MID}/$(notdir $@)" $@ 
 
 AUTO_from_MID=\
 mark pspad1 pspad2 wi1 wi2
 
 $(addprefix $(AUTO)/, $(addsuffix .$(FASLEXT), $(AUTO_from_MID))): \
     $(AUTO)/%.$(FASLEXT) : $(MID)/%.clisp
-	@ echo 10 making $@ from $<
+	@ echo 10b making $@ from $< # hack 2 by Bill Page
 	@ (cd ${MID} ; \
 	  if [ -z "${NOISE}" ] ; then \
-	   echo '(progn  (compile-file "$<" :output-file "$@") (${BYE}))' | ${DEPSYS} ; \
+	   echo '(progn  (compile-file "$(notdir $<)" :output-file "$(notdir $@)") (${BYE}))' | ${DEPSYS} ; \
 	  else \
-	   echo '(progn  (compile-file "$<" :output-file "$@") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
-	  fi )
+	   echo '(progn  (compile-file "$(notdir $<)" :output-file "$(notdir $@)") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
+	  fi ; )
+	@ mv "${MID}/$(notdir $@)" $@
 
 MID_from_IN=\
  apply as ax bc-matrix bc-misc bc-solve bc-util br-con br-data \
@@ -1182,11 +1185,9 @@
 	@ echo 79 making newaux.$(FASLEXT) from newaux.lisp
 	( \
 	  if [ -z "${NOISE}" ] ; then \
-	   echo '(progn  (compile-file "newaux.lisp" :output-file' \
-	        ' "newaux.$(FASLEXT)") (${BYE}))' | ${DEPSYS} ; \
+	   echo '(progn  (compile-file "newaux.lisp" :output-file "newaux.$(FASLEXT)") (${BYE}))' | ${DEPSYS} ; \
 	  else \
-	   echo '(progn  (compile-file "newaux.lisp" :output-file' \
-	     ' "newaux.$(FASLEXT)") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
+	   echo '(progn  (compile-file "newaux.lisp" :output-file "newaux.$(FASLEXT)") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
 	  fi )
 
 @
@@ -1249,11 +1250,11 @@
 	@ echo 616 making $@ from exposed.lsp
 	if [ -z "${NOISE}" ] ; then \
 	   echo '(progn  (compile-file "exposed.lsp" :output-file' \
-	      ' "$(axiom_targetdir)/algebra/exposed.$(FASLEXT)") (${BYE}))' \
+	      ' "$(BASE)$(axiom_targetdir)/algebra/exposed.$(FASLEXT)") (${BYE}))' \
 		| ${DEPSYS} ; \
 	  else \
 	   echo '(progn  (compile-file "exposed.lsp" :output-file' \
-	      ' "$(axiom_targetdir)/algebra/exposed.$(FASLEXT)") (${BYE}))' \
+	      ' "$(BASE)$(axiom_targetdir)/algebra/exposed.$(FASLEXT)") (${BYE}))' \
 	        | ${DEPSYS} >> ${TMP}/trace ; \
 	  fi
 
Index: src/interp/bookvol5.pamphlet
===================================================================
--- src/interp/bookvol5.pamphlet	(revision 515)
+++ src/interp/bookvol5.pamphlet	(working copy)
@@ -1078,7 +1078,7 @@
 Prefix a filename with the {\bf AXIOM} shell variable. 
 <<defun make-absolute-filename>>=
 (defun make-absolute-filename (name)
- (concatenate 'string $spadroot name))
+  (concatenate 'string $spadroot name))
 
 @
 \subsection{defun makeInitialModemapFrame}
Index: src/interp/sys-pkg.lisp.pamphlet
===================================================================
--- src/interp/sys-pkg.lisp.pamphlet	(revision 515)
+++ src/interp/sys-pkg.lisp.pamphlet	(working copy)
@@ -29,8 +29,21 @@
 
 This is the boot to lisp compiler package which contains the
 src/boot files. Tt is the boot translator package. 
+
+The following make-pkg command caused the error:
+\begin{verbatim}
+Loading sys-pkg.lisp
+
+Correctable error: A package error occurred on "BOOTTRAN":
+"A package with this name already exists.". 
+Signalled by MAKE-PACKAGE. 
+\end{verbatim}
+Perhaps this is related to the rsym_hack for windows??
+
+Anyway I have commented it out of the build for now. 
+Bill Page, 21 April 2007
 <<*>>=
-(make-package "BOOTTRAN" :use '("LISP"))
+;;(make-package "BOOTTRAN" :use '("LISP"))
 @
 
 Everything in axiom that the user references eventually shows
Index: src/lisp/Makefile.pamphlet
===================================================================
--- src/lisp/Makefile.pamphlet	(revision 515)
+++ src/lisp/Makefile.pamphlet	(working copy)
@@ -59,8 +59,8 @@
 
 \subsection{GCL already installed or built}
 
-<<build lisp for boot>>=
-## Create a fresh image for building Boot
+<<build augmented lisp>>=
+## Create a fresh image for building interpsys and AXIOMsys
 ## These objects files are the C runtime support
 ## and must be compiled into the Lisp image,
 ## as they must be present in the final interpreter
@@ -70,8 +70,9 @@
 		$(build_libdir)/cfuns-c.o \
 		$(build_libdir)/sockio-c.o
 
-$(OUT)/lisp$(EXEEXT): $(AXIOM_LISP)
-	echo '(compiler::link nil "${OUT}/lisp" ' \
+$(OUT)/lisp$(EXEEXT): initial-env.lisp
+	@axiom_gcl_rsym_hack@
+	echo '(compiler::link (quote ("initial-env.lisp")) "lisp" ' \
               ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                         ' (si::*load-types* ~S))' \
                                        ' (compiler::emit-fn t))' \
@@ -79,9 +80,13 @@
                                         ' (si::sgc-on t))' \
                                   ' (setq compiler::*default-system-p* t))"' \
                       ' si::*system-directory* (quote (list ".lsp")))' \
-               '  "$(lisp_c_objects)")' \
+               '  "$(lisp_c_objects) @axiom_c_runtime_extra@")' \
             | $(AXIOM_LISP)
+	$(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
 
+initial-env.lisp: $(srcdir)/../boot/initial-env.lisp.pamphlet
+	$(axiom_build_document) --tangle $< --output=$@
+
 @
 
 <<*>>=
@@ -91,7 +96,7 @@
 
 pamphlets = Makefile.pamphlet
 
-build_libdir = $(abs_top_builddir)/src/lib
+build_libdir = $(top_builddir)/src/lib
 
 lisp_DEPENDENCIES = $(build_libdir)/cfuns-c.o \
 		    $(build_libdir)/sockio-c.o \
@@ -102,7 +107,7 @@
 
 all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
 
-<<build lisp for boot>>
+<<build augmented lisp>>
 
 # Build GCL takes quite a while, so we don't remove the
 # diretcory in mostlyclean.  Rather, we do that in clean. 
Index: ChangeLog.wh
===================================================================
--- ChangeLog.wh	(revision 515)
+++ ChangeLog.wh	(working copy)
@@ -1,3 +1,15 @@
+2007-04-25  Bill Page
+
+	Changes relating to building on Windows MSYS/MinGW
+	* use echo ... | $command instead of -eval for build-prog
+	in configure.ac.pamphlet to avoid bug in GCL for Windows
+	* avoid paths in file names when calling Lisp in
+	src/interp/Makefile.pamphlet
+	* apply revision 498 from build-improvements for LN_S
+        in configure.ac.pamphlet and conf/var-defs
+	* apply revisions 394 and 411 from build-improvements for
+	Windows specific changes re XDR-OPEN etc. 
+
 2007-04-25  Waldek Hebisch  Waldek Hebisch
 
 	* src/doc/Makefile.pamphlet: Build Axion book with the rest
Index: config/var-def.mk
===================================================================
--- config/var-def.mk	(revision 515)
+++ config/var-def.mk	(working copy)
@@ -66,7 +66,12 @@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 INSTALL_SCRIPT = @INSTALL_SCRIPT@
-LN_S = @LN_S@
+## FIXME:  The test done with Autoconf-2.60 and later concludes
+##         that "ln -s" is unusable on msys, and therefore defaults to
+##         "cp -p", but that default is unusable for us.  For our
+##         purpose "ln -s" is just fine on that platform.  Consequently
+##         we are explicitly overrding that value here. 
+LN_S = ln -s
 mkinstalldirs = $(top_srcdir)/config/mkinstalldirs
 PATCH = @PATCH@
 RANLIB = @RANLIB@
@@ -102,23 +107,35 @@
 ## Notice, this is the src/ directory within the toplevel source
 ## directory 
 
-axiom_top_srcdir = @axiom_top_srcdir@
-
-axiom_src_srcdir = $(axiom_top_srcdir)/src
+axiom_src_srcdir = $(top_srcdir)/src
 axiom_src_docdir = $(axiom_src_srcdir)/doc
 axiom_src_datadir = $(axiom_src_srcdir)/share
 axiom_src_algdir = $(axiom_src_srcdir)/algebra
 
 ## Where tools for the build machine are built
-axiom_top_builddir = @abs_top_builddir@/build
-axiom_builddir = @axiom_builddir@
+# Tools that we occasionally build don't know
+# much about Autoconf and related infrastructure.  Therefore
+# we do lot by "hand". For the moment, things work if we specify
+# paths as absolute, as opposed to relative.  Other parts of
+# Axiom also expect absolute paths. 
+axiom_abs_top_builddir = $(abs_top_builddir)
+axiom_abs_builddir = $(abs_top_builddir)/build/$(build)
+axiom_abs_build_bindir = $(axiom_abs_builddir)/bin
+axiom_abs_build_libdir = $(axiom_abs_builddir)/lib
+axiom_abs_build_mandir = $(axiom_abs_builddir)/man
+axiom_abs_build_datadir = $(axiom_abs_builddir)/share
+axiom_abs_build_texdir = $(axiom_abs_build_datadir)/texmf/tex
+
+axiom_top_builddir = $(top_builddir)/build
+axiom_builddir = $(axiom_top_builddir)/$(build)
 axiom_build_bindir = $(axiom_builddir)/bin
 axiom_build_libdir = $(axiom_builddir)/lib
 axiom_build_mandir = $(axiom_builddir)/man
 axiom_build_docdir = $(axiom_builddir)/doc
-axiom_build_texdir = $(axiom_builddir)/share/texmf/tex
+axiom_build_datadir = $(axiom_builddir)/share
+axiom_build_texdir = $(axiom_build_datadir)/texmf/tex
 
-axiom_configdir = $(abs_top_builddir)/config
+axiom_configdir = $(top_builddir)/config
 axiom_c_macros = $(axiom_configdir)/axiom-c-macros.h
 
 LATEX = @LATEX@
@@ -144,6 +161,8 @@
 ## Where the staging build directory is found
 AXIOM = @AXIOM@
 export AXIOM
+BASE = @BASE@
+export BASE
 
 ## Where to find Axiom data bases. 
 DAASE = $(axiom_src_datadir)
Index: configure.ac.pamphlet
===================================================================
--- configure.ac.pamphlet	(revision 515)
+++ configure.ac.pamphlet	(working copy)
@@ -117,7 +117,7 @@
 axiom_builddir=`pwd`/build/$build
 AC_SUBST(axiom_builddir)
 
-## Prefix for the staging target inistallation directory
+## Prefix for the staging target installation directory
 axiom_targetdir=`pwd`/target/$target
 AC_SUBST(axiom_targetdir)
 @
@@ -636,10 +636,20 @@
 
 \paragraph{File utils}
 Then, check for a usable [[install]] program.  Also, find out
-way to hard- or soft-link files. 
+way to hard- or soft-link files.  
+
+After a recent migration to
+\Tool{Autoconf-2.60}, it turns out that all possibilities of
+soft-linking are tried (to ``play safe''), and if any variation
+fails then, [[LN_S]] is defined to [[cp -p]], which works
+only for files as sources.  But, the only way we currently
+use [[LN_S]] is when the first argument is a directory.  So, the 
+``portability help'' we get from \Tool{Autoconf} is no help.  
+Consequently, the test for
+[[ln -s]] is commented out for the moment. 
 <<file utils>>=
 AC_PROG_INSTALL
-AC_PROG_LN_S
+# AC_PROG_LN_S
 AC_CHECK_PROG([TOUCH], [touch],
               [touch], [AC_MSG_ERROR(['touch' program is missing.])])
 AC_CHECK_PROGS([MKTEMP], [mktemp])
@@ -909,8 +919,22 @@
 pervasive way.   That variable needs to be set before the
 build start --- or else, it will fail. 
 
+BASE contains the operating system root of the build environment. 
+In the case of MSYS/MinGW build environment on Windows it is
+necessary that the AXIOM variable be a Windows absolute path. 
+Therefore BASE is set to the MSYS root or otherwise empty. 
+
 <<define AXIOM>>=
-AXIOM=$axiom_targetdir
+case $host in
+    *mingw*)
+        BASE=`(cd /;pwd -W)`
+        ;;
+    *)
+        BASE=""
+        ;;
+esac
+AC_SUBST(BASE)
+AXIOM=${BASE}${axiom_targetdir}
 AC_SUBST(AXIOM)
 @
 

\start
Date: 26 Apr 2007 15:24:14 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: building wh-sandbox on Windows

Bill Page writes:

> Waldek,
> 
> I have finally succeeded in building wh-sandbox on Windows. I have attached
> the patch set with diffs against revision 515. My approach was to introduce a
> "BASE" variable as I discussed in a previous email to allow the Windows
> applications to have a different absolute path than the MSYS tools used
> during the build. This is in contrast to Gaby's approach of making all paths
> relative. In the end this seemed like the shortest path to getting wh-sandbox
> to compile under Windows. Please let me know what you think about this
> approach. I will continue to test this patchset to make sure that it does not
> break the linux build. Regards, Bill Page.

WOW! It remains to get the graphics working, I guess.  I had a small
presentation today, but people where dismayed by the fact that there is no
help, no graphics under MS windows.

And of course, they really want a better expression domain, i.e., provisos.

I guess, both is out of reach for the moment?

\start
Date: Thu, 26 Apr 2007 16:13:26 -0400
From: Bill Page
To: Waldek Hebisch
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Quoting Bill Page:

> ... 
> I will continue to test this patchset to make sure that it does
> not break the linux build. 
>

My test build of wh-sandbox (rev. 515) plus the patches for
Windows just completed normally and runs simple confidence
tests. with errors on the axiom-developer.org Linux server
(RedHat 9+). 

I have also checked that this patch set is independent of the
earlier changes for portability and they both can be applied
simultaneously. 

Waldek, I have modified the portability patch set, as you
suggested in your previous email, to remove the regression
of the cfuns-c socket code and drop the patch to the obsolete
'construc' function. Would you like me to commit either or
both of these patch sets to wh-sandbox? Note: One of the
revisions that I pulled from build-improvements triggers the
requirement for autoconf >= 2.60. 

Gaby, the portability changes are also applicable to the
build-mprovements branch. Would you like me to make an
initial commit? There will be more (less critical) changes
like this to follow. 

\start
Date: Thu, 26 Apr 2007 16:16:04 -0400
From: Bill Page
To: list
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Quoting Bill Page:

> Quoting Bill Page:
>
>> ... I will continue to test this patchset to make sure that it does
>> not break the linux build. 
>
> My test build of wh-sandbox (rev. 515) plus the patches for
> Windows just completed normally and runs simple confidence
> tests. with errors on the axiom-developer.org Linux server
> (RedHat 9+). 
>
> ... 

Of course I meant to write "without errors" ... 

\start
Date: Thu, 26 Apr 2007 23:17:58 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Windows

Bill Page wrote:
> Waldek,
> 
> I have finally succeeded in building wh-sandbox on Windows. 
> I have attached the patch set with diffs against revision 515. 
> My approach was to introduce a "BASE" variable as I discussed
> in a previous email to allow the Windows applications to have
> a different absolute path than the MSYS tools used during the
> build. This is in contrast to Gaby's approach of making all paths
> relative. In the end this seemed like the shortest path to getting
> wh-sandbox to compile under Windows. 
> 
> Please let me know what you think about this approach. 
>

Congratulations.  Few quick remarks about the diff:

1) It does not apply cleanly to 515 (I had problem with
   README.build-improvements, configure.ac.pamphlet and
   src/interp/sys-pkg.lisp.pamphlet)
2) Some parts seem to be whitespace-only diff (differnces
   in whitespace probably are responsible for failures in 1)
3) Use of '(in-package \"boottran\")' in document.in is wrong,
   because in Ansi Lisp the package name here is case sensitive,
   so we want '(in-package \"BOOTTRAN\")'
4) Do you really need subshells in src/algebra/Makefile.pamphlet?
5) In src/interp/patches.lisp.pamphlet the first hunk inroduces
   conditionals for |$saturn| etc.  I prefer to set those
   variables unconditionally, because ATM there is _no_ platform
   on which choosing Saturn works.
6) We can avoid using pathnames during interpreter build by
   eliminationg int/interp subdirectory -- one reason for
   keeping this directory is that we want sane pathname handling
   at user level, so have to solve the underlying problem.  The
   same solution should work for build.  But if we have to use
   gross hacks to get around build problems then I prefer to
   move files to single directory.
7) In config/var-def.mk I ommited a few unused variables that Gaby
   added -- I feel that we should not slavishy copy the bloat
   created by autotools.  More preciesly, I do not like bloat
   in machine generated files but as long as thing are handled
   automatically such bloat is acceptable.  But we are
   maintaning var-def.mk by hand and bloat is a problem.  So
   I would like to have only usefull stuff in config/var-def.mk
   -- it looks that your patch copies a bunch of unused variables
   from build-improvements.
8) Concerning BASE variable: it does not look nice, but I do not
   think that other solutions would look better.
  
\start
Date: Thu, 26 Apr 2007 18:56:42 -0400
From: Bill Page
To: Waldek Hebisch
Subject: Re: building wh-sandbox on Windows
Cc: Martin Rubey, Gabriel Dos Reis

Quoting Waldek Hebisch:

>
> Congratulations.  Few quick remarks about the diff:
>
> 1) It does not apply cleanly to 515 (I had problem with
>    README.build-improvements, configure.ac.pamphlet and
>    src/interp/sys-pkg.lisp.pamphlet)
> 2) Some parts seem to be whitespace-only diff (differnces
>    in whitespace probably are responsible for failures in 1)

Perhaps one cause of the apparent whitespace differences
has to do with the annoyance of different line endings between
Linux and Windows. SVN for Windows automatically terminates
lines with CR+LF, but the MSYS tools assume normal Unix
convention of just newline (LF). 

I would prefer if we set the EOL attributes on the SourceForge
SVN repository so that SVN does not mangle line endings
in this way. But this is just an inconvenient a fact-of-life for
Windows developers. Most Windows and MSYS tools are
tolerant for these differences but some are not. When I
produced the patch file I sent you, I filtered it by tr -d '\r' to
convert back to Unix line endings. 

A significant thing to remember about MSYS is that it is really
a cross-compilation/porting environment intended to produce
native Windows applications from Unix-oriented sources. It is
not quite a native development environment for Windows (like
Visual C, for example). 

> 3) Use of '(in-package \"boottran\")' in document.in is wrong,
>    because in Ansi Lisp the package name here is case sensitive,
>    so we want '(in-package \"BOOTTRAN\")'

Ok. BTW, the build I did of wh-sandbox on Windows was using
the ANSI mode of GCL. I have compiled the same sources under
Linux using CLtL1. Thank you very much for resolving the
differences that make it possible to use GCL in ANSI mode. 
I did not realize that it would also be possible to use a dialect
of GCL that was compatible with *both*. This is a nice feature to
try to retain at least during the transition to full ANSI compliance. 

> 4) Do you really need subshells in
>          src/algebra/Makefile.pamphlet?

Subshells make it easier to make local changes to the current
directory to avoid some path issues. But, no they are probably
not needed in a more careful design. 

> 5) In src/interp/patches.lisp.pamphlet the first hunk inroduces
>    conditionals for |$saturn| etc.  I prefer to set those
>    variables unconditionally, because ATM there is _no_    platform 
> on which choosing Saturn works. 

Ok. I am in favour of eliminating as much of this cruft as
possible (before we start adding more of our own ;). 

> 6) We can avoid using pathnames during interpreter build
>    by eliminationg int/interp subdirectory -- one reason for
>    keeping this directory is that we want sane pathname
>    handling at user level, so have to solve the underlying
>    problem. 

I am not sure if I understand what you call the "underlying
problem". Do you mean the fact that Axiom's pamphlet
files group code into "chunks" that may not correspond to
files at the lowest level? I suppose the model that we want
to present to the user is: "Axiom's source code as a set
of literate documents...". How these documents are woven
from text and code chunks is (mostly) our problem. But
what the build machinery needs is the chunks of various
pamphlets organized into files. I worry that the tools we
have for doing this right now (e.g. noweb, make stanzas,
and even awk scripts) are a little too primitive. 

>    The same solution should work for build. 

Again, I am not sure exactly sure to what "solution" you
are referring, but if you mean continuing the use of an
intermediate file system-oriented view of the source code,
then I suppose that right now we have no other option. 

>    But if we have to use gross hacks to get around build
>    problems then I prefer to move files to single directory. 

I don't view the introduction of a "BASE" variable as a gross
hack. But this is different than what I did in two cases marked
"hack #1 billpage in the Makefile.pamphlet source. In that
case I made use of the intermediate directory as a temporary
staging area for both the input and output files. A 'cd' to change
the current directory eliminates one absolute path and the use
of a 'mv' command moves the other path out of the native
environment (Windows) and back into the development
environment (MSYS). But as you say this could have been
handled by the use of $(BASE) instead. So can I assume
that you would be in favor of the latter option?

> 7) In config/var-def.mk I ommited a few unused variables
>    that Gaby added -- I feel that we should not slavishy
>    copy the bloat created by autotools.  More preciesly,
>    I do not like bloat in machine generated files but as
>    long as thing are handled automatically such bloat is
>    acceptable.  But we are maintaning var-def.mk by
>    hand and bloat is a problem. 

I understand your point. What I tried to do was to use
'svn merge' just to pull as much as possible an entire
revision from build-improvements into wh-sandbox. My
thinking was that this might prevent problems in the future
in the case of an eventual merge of both build-improvements
and wh-sandbox back into the "Axiom Silver" trunk. But
where we are going with this is not clear to me yet. 

>   So I would like to have only usefull stuff in config/var-def.mk
>    -- it looks that your patch copies a bunch of unused
>     variables from build-improvements. 

That is correct. I think there are advantages and disadvantages
of either choice. In favor of retaining the unused (but "standard")
autoconf variables is in the eventual move to a complete
automated make environment. (I think that was Gaby's original
intent.) In which case, as you say, this complexity would be
hidden by the machinery. The question is then: how much of
this can we tolerate now? Maybe the answer is different
between build-improvements and wh-sandbox... For now I will
try to eliminate the unused variables in my patch wh-sandbox,
but doing so requires a little more analysis. 

> 8) Concerning BASE variable: it does not look nice, but
>    I do not think that other solutions would look better. 
>

I agree. If we can afford the divergence of the code between
wh-sandbox and build-improvements then it makes sense
to experiment with two rather opposite solutions to the same
problem. 

\start
Date: Fri, 27 Apr 2007 04:51:09 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Bill Page wrote:
> Quoting Waldek Hebisch:
> 
> >
> > Congratulations.  Few quick remarks about the diff:
> >
> > 1) It does not apply cleanly to 515 (I had problem with
> >    README.build-improvements, configure.ac.pamphlet and
> >    src/interp/sys-pkg.lisp.pamphlet)
> > 2) Some parts seem to be whitespace-only diff (differnces
> >    in whitespace probably are responsible for failures in 1)
> 
> Perhaps one cause of the apparent whitespace differences
> has to do with the annoyance of different line endings between
> Linux and Windows. SVN for Windows automatically terminates
> lines with CR+LF, but the MSYS tools assume normal Unix
> convention of just newline (LF). 
> 

No, AFAICS differences are due to trailing spaces -- actually it
seems that we have hundreds of lines with trailing whitespece
while IMHO such lines should be extremally rare (that is all
useless trailing whitespece should be stripped).

> I would prefer if we set the EOL attributes on the SourceForge
> SVN repository so that SVN does not mangle line endings
> in this way. But this is just an inconvenient a fact-of-life for
> Windows developers. Most Windows and MSYS tools are
> tolerant for these differences but some are not. When I
> produced the patch file I sent you, I filtered it by tr -d '\r' to
> convert back to Unix line endings. 
> 

This setting is intended as a convenience for Windows developers...
And it seems to work -- at least it seems that the repository
is free from unwanted carriage returns.

> > 4) Do you really need subshells in
> >          src/algebra/Makefile.pamphlet?
> 
> Subshells make it easier to make local changes to the current
> directory to avoid some path issues. But, no they are probably
> not needed in a more careful design. 
>

I appreciate advantages of subshells.  But on some platforms
(including Windows) subshells are rather slow to create, so
we probably want to avoid them in performance critical parts.

The shell code in question is _not_ performance critical, but
since the only change to src/algebra/Makefile.pamphlet I see 
(or did I overlook something?) is introduction of subshells
I would like to know if there is a special problem here that
braces have but subshells avoid.
 
> > 6) We can avoid using pathnames during interpreter build
> >    by eliminationg int/interp subdirectory -- one reason for
> >    keeping this directory is that we want sane pathname
> >    handling at user level, so have to solve the underlying
> >    problem. 
> 
> I am not sure if I understand what you call the "underlying
> problem". Do you mean the fact that Axiom's pamphlet
> files group code into "chunks" that may not correspond to
> files at the lowest level? I suppose the model that we want

No.  Extraction from pamphlets is a different problem.

> >    The same solution should work for build. 
> 
> Again, I am not sure exactly sure to what "solution" you
> are referring, but if you mean continuing the use of an
> intermediate file system-oriented view of the source code,
> then I suppose that right now we have no other option. 
>

I am specifically referring to:

 $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
     %.$(FASLEXT) : $(MID)/%.clisp
-       @ echo 10 making $@ from $<
-       @ ( B=`pwd`;\
+       @ echo 10a making $@ from $< # hack 1 by Bill Page
+       # avoid paths in file names for Windows compatibility

(and the hack 2).  The `pwd` command I put there is already a hack
to work around fact that meaning of relative :output parameter to
compile-file is implementation dependent.  In principle using

:output (merge-pathnames "$@") 

should help but I still had problems after doing that, so
I used `pwd` as temporary hack before I get :output working
in consistent way.  

But if using separate directory here causes extra problems, 
I think that we can just put all .clisp in single directory.
 
> >    But if we have to use gross hacks to get around build
> >    problems then I prefer to move files to single directory. 
> 
> I don't view the introduction of a "BASE" variable as a gross
> hack. But this is different than what I did in two cases marked
> "hack #1 billpage in the Makefile.pamphlet source. In that
> case I made use of the intermediate directory as a temporary
> staging area for both the input and output files. A 'cd' to change
> the current directory eliminates one absolute path and the use
> of a 'mv' command moves the other path out of the native
> environment (Windows) and back into the development
> environment (MSYS). But as you say this could have been
> handled by the use of $(BASE) instead. So can I assume
> that you would be in favor of the latter option?
> 

Above I used wrong words.  Given problem $(BASE) is a logical
solution.  Your 'cd'  + 'notdir' + 'mv' combination is also a
logical solution, if we _have to_ keep current files loctions.
But it is getting heavy, and we may put .clisp files in current
directory which should solve problem in 'IN_from_MID' rule
and simplify solution to 'AUTO_from_MID' rule

> > 7) In config/var-def.mk I ommited a few unused variables
> >    that Gaby added -- I feel that we should not slavishy
> >    copy the bloat created by autotools.  More preciesly,
> >    I do not like bloat in machine generated files but as
> >    long as thing are handled automatically such bloat is
> >    acceptable.  But we are maintaning var-def.mk by
> >    hand and bloat is a problem. 
> 
> I understand your point. What I tried to do was to use
> 'svn merge' just to pull as much as possible an entire
> revision from build-improvements into wh-sandbox. My
> thinking was that this might prevent problems in the future
> in the case of an eventual merge of both build-improvements
> and wh-sandbox back into the "Axiom Silver" trunk. But
> where we are going with this is not clear to me yet. 
> 

I am trying to avoid unnecessary differences.  But IMHO global
variables (even unused ones) significantly increase complexity and
consequently we should limit use of them.  In particular
I think that we should decide at merge time if we really
want the variables in question.  Of course the problem may
solve itself earlier: the variables may turn out to be
usefull ones.  But ATM the difference is to remind us about
the problem.

> >   So I would like to have only usefull stuff in config/var-def.mk
> >    -- it looks that your patch copies a bunch of unused
> >     variables from build-improvements. 
> 
> That is correct. I think there are advantages and disadvantages
> of either choice. In favor of retaining the unused (but "standard")
> autoconf variables is in the eventual move to a complete
> automated make environment. (I think that was Gaby's original
> intent.) In which case, as you say, this complexity would be
> hidden by the machinery. The question is then: how much of
> this can we tolerate now? Maybe the answer is different
> between build-improvements and wh-sandbox... For now I will
> try to eliminate the unused variables in my patch wh-sandbox,
> but doing so requires a little more analysis. 
> 

Please do.  I would probably first add no new variables and
then look which new variables are used by the rest of the patch and
which exisiting values changed.

\start
Date: Fri, 27 Apr 2007 05:06:08 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Bill Page wrote:
> My test build of wh-sandbox (rev. 515) plus the patches for
> Windows just completed normally and runs simple confidence
> tests. with errors on the axiom-developer.org Linux server
> (RedHat 9+). 
> 
> I have also checked that this patch set is independent of the
> earlier changes for portability and they both can be applied
> simultaneously. 
> 
> Waldek, I have modified the portability patch set, as you
> suggested in your previous email, to remove the regression
> of the cfuns-c socket code and drop the patch to the obsolete
> 'construc' function. Would you like me to commit either or
> both of these patch sets to wh-sandbox? Note: One of the
> revisions that I pulled from build-improvements triggers the
> requirement for autoconf >= 2.60. 
>

ATM I use autoconf 2.59 and I would prefer to stay with this
version.  AFAICS the problem is that autoconf 2.59 does not
set value of 'top_builddir'.  So the following changes to
variable settings are problematic:

-build_libdir = $(abs_top_builddir)/src/lib
+build_libdir = $(top_builddir)/src/lib

+axiom_top_builddir = $(top_builddir)/build
+axiom_builddir = $(axiom_top_builddir)/$(build)
-axiom_configdir = $(abs_top_builddir)/config
+axiom_configdir = $(top_builddir)/config
 
\start
Date: Fri, 27 Apr 2007 05:09:49 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Mike Thomas' portability changes for Windows

Quoting Bill Page:

> Gaby,
>
> In my email:
>
> http://lists.nongnu.org/archive/html/axiom-developer/2006-12/msg00167.html
>
> I described Mike Thomas' portability changes for windows. I have
> applied these to build-improvements and tested both the Windows
> and Solaris 10 x86 builds but more extensive testing is probably
> a good idea. The diff from SVN is attached to this email and
> affects the files shown below:

Thanks.  I had had no reliable connection in Europe (UK+France) for
almost 10 days so I could not read your message.  I'll come back to this
this when I'm done with the 13K+ messages in the queue.

\start
Date: 27 Apr 2007 06:34:22 -0500
From: Gabriel Dos Reis
To: Juergen Weiss
Subject: re: [Axiom-commit] SF.net SVN: axiom:

Juergen Weiss writes:

| > dos-reis@users.sourceforge.net writes:
| > As of revision 491, I added a configure option --enable-checking for
| > requesting runtime checking of Lisp codes, e.g. (proclaim '(optimize
| > (safety 3))). 
| > That has the side effect of dramatically increasing the overall
| > compilation time.  In return, you get to know about bugs you did not
| > suspect or did not want to know about.
| > 
| This is not too suprising, when you consider all the mails in this
| newsgroup about errors with the following message
| >> System error:
|     Caught fatal error [memory may be damaged]
| I always wondered why nobody recompiled the system with better error
| checking, to localize these bugs. I'm glad you did that.

Thanks.  
I wish more people will build Axiom with checking on and help
fix some of the "obvious" type error bugs.

\start
Date: 27 Apr 2007 07:15:40 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [517] branches/wh-sandbox

Waldek Hebisch writes:

| Revision: 517
|           http://svn.sourceforge.net/axiom/?rev=517&view=rev
| Author:   whebisch
| Date:     2007-04-26 03:56:16 -0700 (Thu, 26 Apr 2007)
| 
| Log Message:
| -----------
| Add back support for noweb tarball.

I reluctantly removed this, at the very insistance of people here.
I'm curious of what changed your mind.

\start
Date: Fri, 27 Apr 2007 14:51:49 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: noweb tarball

> Waldek Hebisch writes:
> 
> | Revision: 517
> |           http://svn.sourceforge.net/axiom/?rev=517&view=rev
> | Author:   whebisch
> | Date:     2007-04-26 03:56:16 -0700 (Thu, 26 Apr 2007)
> | 
> | Log Message:
> | -----------
> | Add back support for noweb tarball.
> 
> I reluctantly removed this, at the very insistance of people here.
> I'm curious of what changed your mind.
> 

First note a subtle differences of former noweb support and the thing
I added back:

1) I added back support for tarball (which in the past seemed to work
   resonably well)
2) The tarball itself is optional: by default configure will use installed
   noweb.  If there is no installed noweb configure will look for tarball
   and if the tarball is present then noweb will be built.  If there is
   no installed noweb and no tarball then configure will stop with error
   message.

Why I added back this code?  I belive that noweb itself should not be
part of Axiom svn repository.  But it is reasonable to create Axiom
"source distribution" which bundles Axiom and all troublesome
prerequisites to make build easier.  The added back code is intended
to help create such distribution.

Let me restate my position: in general I am against putting souces of
prerequisities (especially as tarballs, but unpacked form is also bad)
in Axiom svn repositiry.  Of course, sometimes we want to make an
exception but I do not see any reason in case of noweb.  But this does
not exclude having helper code which make use of prerequisities easier.

\start
Date: 27 Apr 2007 08:55:25 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox

Waldek Hebisch writes:

| Revision: 508
|           http://svn.sourceforge.net/axiom/?rev=508&view=rev
| Author:   whebisch
| Date:     2007-04-18 13:25:00 -0700 (Wed, 18 Apr 2007)
| 
| Log Message:
| -----------
| Eradicate ENV.

ENV disappeared from Axiom.build-improvements long time ago.
I'm glad to see that is populating down.  I wish the propagation to
wh-sandbox is properly labelled to facilitate review when it comes to
merging.  

\start
Date: Fri, 27 Apr 2007 16:00:49 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Bill Page wrote:
> I have also checked that this patch set is independent of the
> earlier changes for portability and they both can be applied
> simultaneously. 
> 
> Waldek, I have modified the portability patch set, as you
> suggested in your previous email, to remove the regression
> of the cfuns-c socket code and drop the patch to the obsolete
> 'construc' function. Would you like me to commit either or
> both of these patch sets to wh-sandbox? Note: One of the
> revisions that I pulled from build-improvements triggers the
> requirement for autoconf >= 2.60. 
>

Please go on with portability patch.  

Concerning Windows build, attached you will find modified version
of your patch (diff with respect to revision 517).  I eliminated extra
variable settings from config/var-def.mk -- this is likely to break
Windows build, but fixed autoconf 2.59 problem.  Also, 517 changes
one of the variable setting differently than your original patch.
So there is probably some work to find out which settings in 
config/var-def.mk are needed for Windows.

I eliminated use of MID directory from src/interp/Makefile.pamhlet
-- this should make path problems easier.

One extra comment: change to src/lisp/Makefile.pamhlet loads 
initial-env.lisp which in turn creates BOOTTRAN package -- that
is why change to src/interp/sys-pkg.lisp.pamphlet is needed.

Could you merge the attached patch with your original one (and if
possible consider also comments from other mails) so that it works
both of Windows and Linux?  Assuming new version works OK please
go on and commit.

BTW.  I will be leaving out town for few days, so I will probably be
unable to immediatly look at your final version.

\start
Date: Fri, 27 Apr 2007 16:09:35 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

I wrote:
> Concerning Windows build, attached you will find modified version
> of your patch (diff with respect to revision 517).

I forget to attach the patch, so I attach it to this mail.

-- 
                              Waldek Hebisch
Waldek Hebisch 

--ELM1177682975-4906-0_

diff -ru --exclude=.svn /home/s/test/tt/axiom2/wh-sandbox2/config/var-def.mk wh-sandbox.bp3/config/var-def.mk
--- /home/s/test/tt/axiom2/wh-sandbox2/config/var-def.mk	2007-04-26 12:03:06.000000000 +0200
+++ wh-sandbox.bp3/config/var-def.mk	2007-04-27 13:19:25.000000000 +0200
@@ -66,11 +66,15 @@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
 INSTALL_SCRIPT = @INSTALL_SCRIPT@
-LN_S = @LN_S@
+## FIXME:  The test done with Autoconf-2.60 and later concludes
+##         that "ln -s" is unusable on msys, and therefore defaults to
+##         "cp -p", but that default is unusable for us.  For our
+##         purpose "ln -s" is just fine on that platform.  Consequently
+##         we are explicitly overrding that value here. 
+LN_S = ln -s
 mkinstalldirs = $(top_srcdir)/config/mkinstalldirs
 PATCH = @PATCH@
 RANLIB = @RANLIB@
-TAR = @TAR@
 TOUCH = @TOUCH@
 
 # The list of make targets made recursively, by walking sub-directories
@@ -145,6 +156,8 @@
 ## Where the staging build directory is found
 AXIOM = @AXIOM@
 export AXIOM
+BASE = @BASE@
+export BASE
 
 ## Where to find Axiom data bases.
 DAASE = $(axiom_src_datadir)
diff -ru --exclude=.svn /home/s/test/tt/axiom2/wh-sandbox2/configure.ac.pamphlet wh-sandbox.bp3/configure.ac.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox2/configure.ac.pamphlet	2007-04-26 12:03:06.000000000 +0200
+++ wh-sandbox.bp3/configure.ac.pamphlet	2007-04-27 00:54:36.000000000 +0200
@@ -641,7 +639,7 @@
 way to hard- or soft-link files.
 <<file utils>>=
 AC_PROG_INSTALL
-AC_PROG_LN_S
+# AC_PROG_LN_S
 AC_CHECK_PROG([TOUCH], [touch],
               [touch], [AC_MSG_ERROR(['touch' program is missing.])])
 AC_CHECK_PROGS([MKTEMP], [mktemp])
@@ -950,8 +909,22 @@
 pervasive way.   That variable needs to be set before the
 build start --- or else, it will fail.
 
+BASE contains the operating system root of the build environment. 
+In the case of MSYS/MinGW build environment on Windows it is
+necessary that the AXIOM variable be a Windows absolute path. 
+Therefore BASE is set to the MSYS root or otherwise empty. 
+
 <<define AXIOM>>=
-AXIOM=$axiom_targetdir
+case $host in
+    *mingw*)
+        BASE=`(cd /;pwd -W)`
+        ;;
+    *)
+        BASE=""
+        ;;
+esac
+AC_SUBST(BASE)
+AXIOM=${BASE}${axiom_targetdir}
 AC_SUBST(AXIOM)
 @
 
diff -ru --exclude=.svn /home/s/test/tt/axiom2/wh-sandbox2/src/algebra/Makefile.pamphlet wh-sandbox.bp3/src/algebra/Makefile.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox2/src/algebra/Makefile.pamphlet	2007-04-26 01:46:39.000000000 +0200
+++ wh-sandbox.bp3/src/algebra/Makefile.pamphlet	2007-04-27 00:54:21.000000000 +0200
@@ -376,8 +376,8 @@
 	for A in ${CATLIST} ; do \
 	     echo ')compile "'$$A'.spad"' >> boo1.input ; \
 	done; \
-	{ echo ')read "boo1.input"' | \
-	    ${INTERPSYS} ${CTRACE} } || exit 1 ; \
+	( echo ')read "boo1.input"' | \
+	    ${INTERPSYS} ${CTRACE} ) || exit 1 ; \
 	echo "Stage 1 copy" ; \
 	for A in ${CATLIST} ; do \
 	    cp $$A.NRLIB/code.$(FASLEXT) ${OUT}/$$A.$(FASLEXT) || exit 1 ; \
@@ -387,8 +387,8 @@
 	for A in ${CATLIST} ${DOMLIST} ; do \
 	    echo ')compile "'$$A'.spad"' >> boo2.input ; \
 	done; \
-	{ echo ')read "boo2.input"' | \
-	    ${INTERPSYS} ${CTRACE} } || exit 1 ; \
+	( echo ')read "boo2.input"' | \
+	    ${INTERPSYS} ${CTRACE} ) || exit 1 ; \
 	echo "Stage 2 copy" ; \
 	for A in ${CATLIST} ${DOMLIST} ; do \
 	    cp $$A.NRLIB/code.$(FASLEXT) ${OUT}/$$A.$(FASLEXT) || exit 1 ; \
@@ -400,8 +400,8 @@
 	for A in ${CATLIST} ${DOMLIST} ; do \
 	    echo ')compile "'$$A'.spad"' >> boo3.input ; \
 	done; \
-	{ echo ')read "boo3.input"' | \
-	    ${INTERPSYS} ${CTRACE} } || exit 1 ; \
+	( echo ')read "boo3.input"' | \
+	    ${INTERPSYS} ${CTRACE} ) || exit 1 ; \
 	echo "Stage 3 object copy" ; \
 	for A in ${CATLIST} ${DOMLIST} ; do \
 	   cp $$A.NRLIB/code.$(FASLEXT) ${OUT}/$$A.$(FASLEXT) || exit 1 ; \
diff -ru --exclude=.svn /home/s/test/tt/axiom2/wh-sandbox2/src/interp/Makefile.pamphlet wh-sandbox.bp3/src/interp/Makefile.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox2/src/interp/Makefile.pamphlet	2007-04-23 11:04:39.000000000 +0200
+++ wh-sandbox.bp3/src/interp/Makefile.pamphlet	2007-04-27 13:07:14.000000000 +0200
@@ -39,7 +39,6 @@
 in the \File{\$(axiom_target_docdir)/src/interp/} directory.
 
 <<environment>>=
-MID=${INT}/interp
 DOC=$(axiom_target_docdir)/src/interp
 BOOK=$(axiom_target_docdir)
 
@@ -518,7 +517,7 @@
 
 In order for this information to be used during compiles we define
 <<environment>>=
-PROCLAIMS=(progn (load "sys-pkg.lisp") (load "$(abs_srcdir)/interp-proclaims.lisp"))
+PROCLAIMS=(progn (load "sys-pkg.lisp") (load "$(srcdir)/interp-proclaims.lisp"))
 
 @
 
@@ -979,7 +978,6 @@
 	@ echo PART= ${PART} 
 	@ echo SRC= $(axiom_src_srcdir) 
 	@ echo INT= ${INT}
-	@ echo MID= ${MID} 
 	@ echo LISP=${LISP} BYE=${BYE}
 	$(mkinstalldirs) $(axiom_target_datadir)/msgs
 	$(INSTALL_DATA) $(axiom_src_docdir)/msgs/s2-us.msgs \
@@ -991,10 +989,10 @@
 	@ echo '(in-package "BOOT")' >> makeint.lisp
 	@ touch ${TIMESTAMP}
 	@ echo '${YEARWEEK}' >> makeint.lisp
-	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${AXIOM}")' >> makeint.lisp
+	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "$(BASE)%", ${OPOBJS}))) (quote ($(patsubst %, "$(BASE)%", ${OCOBJS}))) (quote ($(patsubst %, "$(BASE)%", ${BROBJS}))) (quote ($(patsubst %, "$(BASE)%", ${TRANOBJS}))) (quote ($(patsubst %, "$(BASE)%", ${NAGBROBJS}))) (quote ($(patsubst %, "$(BASE)%", ${ASAUTO})))  "${AXIOM}")' >> makeint.lisp
 	@ echo '(boot::set-restart-hook)' >> makeint.lisp
 	@ echo '(in-package "BOOT")' >> makeint.lisp
-	@ echo '(load "${INT}/algebra/warm.data")' >> makeint.lisp
+	@ echo '(load "$(BASE)${INT}/algebra/warm.data")' >> makeint.lisp
 	@ echo '(|clearClams|)' >> makeint.lisp
 	@ echo '(load "obey")' >> makeint.lisp
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> makeint.lisp
@@ -1025,7 +1023,7 @@
 	@echo '(progn (gbc t) (load "makeint.lisp") (gbc t)' \
 	   '#+:gcl(setf compiler::*default-system-p* nil)' \
 	   '#+:gcl(compiler::emit-fn nil)' \
-	   '(user::spad-save "$@"))' | DAASE=$(axiom_targetdir) ${LISPSYS}
+	   '(user::spad-save "$@"))' | DAASE="$(BASE)$(axiom_targetdir)" ${LISPSYS}
 	@ echo 6a ${AXIOMSYS} created
 @
 
@@ -1034,9 +1032,9 @@
 files are known to exist and be up to date. We don't list any of
 the preconditions here. 
 <<debugsys>>=
-${DEBUGSYS}: ${MID}/debugsys.lisp
+${DEBUGSYS}: debugsys.lisp
 	@ echo 7 building debugsys
-	@ echo '(progn (gbc t) (load "${MID}/debugsys.lisp") (user::spad-save "$@"))' | ${LISPSYS}
+	@ echo '(progn (gbc t) (load "debugsys.lisp") (user::spad-save "$@"))' | ${LISPSYS}
 	@ echo 8 ${DEBUGSYS} created
 
 @
@@ -1108,27 +1106,29 @@
  template termrw topics trace
 
 $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
-    %.$(FASLEXT) : $(MID)/%.clisp
-	@ echo 10 making $@ from $<
-	@ ( B=`pwd`;\
+    %.$(FASLEXT) : %.clisp
+	@ echo 10a making $@ from $< # hack 1 by Bill Page
+	# avoid paths in file names for Windows compatibility
+	@ (\
 	  if [ -z "${NOISE}" ] ; then \
-	   echo '(progn  (compile-file "$<" :output-file "'$$B/'$@") (${BYE}))' | ${DEPSYS} ; \
+	   echo '(progn  (compile-file "$<" :output-file "$@") (${BYE}))' | ${DEPSYS} ; \
 	  else \
-	   echo '(progn  (compile-file "$<" :output-file "'$$B/'$@") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
-	  fi )
+	   echo '(progn  (compile-file "$<" :output-file "$@") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
+	  fi ; )
 
 AUTO_from_MID=\
 mark pspad1 pspad2 wi1 wi2
 
 $(addprefix $(AUTO)/, $(addsuffix .$(FASLEXT), $(AUTO_from_MID))): \
-    $(AUTO)/%.$(FASLEXT) : $(MID)/%.clisp
-	@ echo 10 making $@ from $<
-	@ (cd ${MID} ; \
+    $(AUTO)/%.$(FASLEXT) : %.clisp
+	@ echo 10b making $@ from $< # hack 2 by Bill Page
+	@ ( \
 	  if [ -z "${NOISE}" ] ; then \
-	   echo '(progn  (compile-file "$<" :output-file "$@") (${BYE}))' | ${DEPSYS} ; \
+	   echo '(progn  (compile-file "$<" :output-file "$(notdir $@)") (${BYE}))' | ${DEPSYS} ; \
 	  else \
-	   echo '(progn  (compile-file "$<" :output-file "$@") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
-	  fi )
+	   echo '(progn  (compile-file "$<" :output-file "$(notdir $@)") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
+	  fi ; )
+	@ mv "$(notdir $@)" $@
 
 MID_from_IN=\
  apply as ax bc-matrix bc-misc bc-solve bc-util br-con br-data \
@@ -1145,11 +1145,10 @@
  pspad2 record rulesets server setvars setvart simpbool template \
  termrw topics trace wi1 wi2
 
-$(addprefix $(MID)/, $(addsuffix .clisp, $(MID_from_IN))): \
-    $(MID)/%.clisp : $(srcdir)/%.boot.pamphlet
+$(addsuffix .clisp, $(MID_from_IN)): \
+    %.clisp : $(srcdir)/%.boot.pamphlet
 	@ echo 11 making $@ from $<
-	@( $(axiom_build_document) --tangle --output=$(MID)/$*.boot $<; \
-	   cd ${MID} ; \
+	( $(axiom_build_document) --tangle --output=$*.boot $<; \
 	   if [ -z "${NOISE}" ] ; then \
 	   echo '(progn (boottran::boottocl "$*.boot") (${BYE}))' | ${DEPSYS} ; \
 	   else \
@@ -1172,7 +1171,7 @@
 We simply captured that temporary file, replaced the .o files with .lisp
 files (or .lsp or .clisp) and saved it here.
 <<debugsys.lisp (MID from IN)>>=
-${MID}/debugsys.lisp: $(srcdir)/debugsys.lisp.pamphlet
+debugsys.lisp: $(srcdir)/debugsys.lisp.pamphlet
 	$(axiom_build_document) --tangle --output=$@ $<
 @
 
@@ -1182,11 +1181,9 @@
 	@ echo 79 making newaux.$(FASLEXT) from newaux.lisp
 	( \
 	  if [ -z "${NOISE}" ] ; then \
-	   echo '(progn  (compile-file "newaux.lisp" :output-file' \
-	        ' "newaux.$(FASLEXT)") (${BYE}))' | ${DEPSYS} ; \
+	   echo '(progn  (compile-file "newaux.lisp" :output-file "newaux.$(FASLEXT)") (${BYE}))' | ${DEPSYS} ; \
 	  else \
-	   echo '(progn  (compile-file "newaux.lisp" :output-file' \
-	     ' "newaux.$(FASLEXT)") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
+	   echo '(progn  (compile-file "newaux.lisp" :output-file "newaux.$(FASLEXT)") (${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
 	  fi )
 
 @
@@ -1249,11 +1246,11 @@
 	@ echo 616 making $@ from exposed.lsp
 	if [ -z "${NOISE}" ] ; then \
 	   echo '(progn  (compile-file "exposed.lsp" :output-file' \
-	      ' "$(axiom_targetdir)/algebra/exposed.$(FASLEXT)") (${BYE}))' \
+	      ' "$(BASE)$(axiom_targetdir)/algebra/exposed.$(FASLEXT)") (${BYE}))' \
 		| ${DEPSYS} ; \
 	  else \
 	   echo '(progn  (compile-file "exposed.lsp" :output-file' \
-	      ' "$(axiom_targetdir)/algebra/exposed.$(FASLEXT)") (${BYE}))' \
+	      ' "$(BASE)$(axiom_targetdir)/algebra/exposed.$(FASLEXT)") (${BYE}))' \
 	        | ${DEPSYS} >> ${TMP}/trace ; \
 	  fi
 
diff -ru --exclude=.svn /home/s/test/tt/axiom2/wh-sandbox2/src/interp/patches.lisp.pamphlet wh-sandbox.bp3/src/interp/patches.lisp.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox2/src/interp/patches.lisp.pamphlet	2007-04-07 19:25:44.000000000 +0200
+++ wh-sandbox.bp3/src/interp/patches.lisp.pamphlet	2007-04-27 13:00:40.000000000 +0200
@@ -360,25 +360,25 @@
            "A structure to hold XDR streams. The stream is printed out."
            (handle ) ;; this is what is used for xdr-open xdr-read xdr-write
            (name ))  ;; this is used for printing
-#+:akcl
+#+(and :gcl (not (or :dos :win32)))
 (defun |xdrOpen| (str dir) (make-xdr-stream :handle (system:xdr-open str) :name str))
 #+:CCL
 (defun |xdrOpen| (str dir) (xdr-open str dir) )
-#+:dos
+#+(and :gcl (or :dos :win32))
 (defun |xdrOpen| (str dir) (format t "xdrOpen called"))
 
-#+:akcl
+#+(and :akcl (not (or :dos :win32)))
 (defun |xdrRead| (xstr r) (system:xdr-read (xdr-stream-handle xstr) r) )
 #+:CCL
 (defun |xdrRead| (xstr r) (xdr-read xstr r) )
-#+:dos
+#+(and :gcl (or :dos :win32))
 (defun |xdrRead| (str) (format t "xdrRead called"))
 
-#+:akcl
+#+(and :akcl (not (or :dos :win32)))
 (defun |xdrWrite| (xstr d) (system:xdr-write (xdr-stream-handle xstr) d) )
 #+:CCL
 (defun |xdrWrite| (xstr d) (xdr-write xstr d) )
-#+:dos
+#+(and :gcl (or :dos :win32))
 (defun |xdrWrite| (str) (format t "xdrWrite called"))
 
 ;; here is a test for XDR
diff -ru --exclude=.svn /home/s/test/tt/axiom2/wh-sandbox2/src/interp/sys-pkg.lisp.pamphlet wh-sandbox.bp3/src/interp/sys-pkg.lisp.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox2/src/interp/sys-pkg.lisp.pamphlet	2007-04-10 20:03:29.000000000 +0200
+++ wh-sandbox.bp3/src/interp/sys-pkg.lisp.pamphlet	2007-04-27 00:54:24.000000000 +0200
@@ -30,7 +30,7 @@
 This is the boot to lisp compiler package which contains the
 src/boot files. Tt is the boot translator package.
 <<*>>=
-(make-package "BOOTTRAN" :use '("LISP"))
+;; (make-package "BOOTTRAN" :use '("LISP"))
 @
 
 Everything in axiom that the user references eventually shows
diff -ru --exclude=.svn /home/s/test/tt/axiom2/wh-sandbox2/src/lisp/Makefile.pamphlet wh-sandbox.bp3/src/lisp/Makefile.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox2/src/lisp/Makefile.pamphlet	2007-04-07 19:25:44.000000000 +0200
+++ wh-sandbox.bp3/src/lisp/Makefile.pamphlet	2007-04-27 13:14:35.000000000 +0200
@@ -59,8 +59,8 @@
 
 \subsection{GCL already installed or built}
 
-<<build lisp for boot>>=
-## Create a fresh image for building Boot
+<<build augmented lisp>>=
+## Create a fresh image for building interpsys and AXIOMsys
 ## These objects files are the C runtime support
 ## and must be compiled into the Lisp image,
 ## as they must be present in the final interpreter
@@ -70,8 +70,9 @@
 		$(build_libdir)/cfuns-c.o \
 		$(build_libdir)/sockio-c.o
 
-$(OUT)/lisp$(EXEEXT): $(AXIOM_LISP)
-	echo '(compiler::link nil "${OUT}/lisp" ' \
+$(OUT)/lisp$(EXEEXT): initial-env.lisp
+	@axiom_gcl_rsym_hack@
+	echo '(compiler::link (quote ("initial-env.lisp")) "lisp" ' \
               ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                         ' (si::*load-types* ~S))' \
                                        ' (compiler::emit-fn t))' \
@@ -79,8 +80,12 @@
                                         ' (si::sgc-on t))' \
                                   ' (setq compiler::*default-system-p* t))"' \
                       ' si::*system-directory* (quote (list ".lsp")))' \
-               '  "$(lisp_c_objects)")' \
+               '  "$(lisp_c_objects) @axiom_c_runtime_extra@")' \
             | $(AXIOM_LISP)
+	$(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
+
+initial-env.lisp: $(srcdir)/../boot/initial-env.lisp.pamphlet
+	$(axiom_build_document) --tangle $< --output=$@
 
 @
 
@@ -102,7 +107,7 @@
 
 all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
 
-<<build lisp for boot>>
+<<build augmented lisp>>
 
 # Build GCL takes quite a while, so we don't remove the
 # diretcory in mostlyclean.  Rather, we do that in clean.
Tylko w wh-sandbox.bp3/src/lisp: Makefile.pamphlet.orig
diff -ru --exclude=.svn /home/s/test/tt/axiom2/wh-sandbox2/src/scripts/document.in wh-sandbox.bp3/src/scripts/document.in
--- /home/s/test/tt/axiom2/wh-sandbox2/src/scripts/document.in	2007-04-10 20:00:25.000000000 +0200
+++ wh-sandbox.bp3/src/scripts/document.in	2007-04-27 12:56:36.000000000 +0200
@@ -37,14 +37,23 @@
 #       Anything that comes after is treated as an argument, even
 #       if it looks like an option
 
+## 2007-04-10:
+##   After moving to a recent version of MSYS, and GCL-2.6.8pre, I
+##   noticed that double-colon ('::' in boottran::boottocl) will be
+##   translated to semi-colon (';') as if interpreted for path
+##   separator.  I don't who is doing that, and I have no time to
+##   investigate it, and even if I do, it would not help much.  
+##   Therefore, I've changed the script not to use double-colon. 
+##      -- Gaby
+
 
 # set -x
 
-latex=@LATEX@
-index=@MAKEINDEX@
+latex="@LATEX@"
+index="@MAKEINDEX@"
 
-notangle=@NOTANGLE@
-noweave=@NOWEAVE@
+notangle="@NOTANGLE@"
+noweave="@NOWEAVE@"
 
 # Flags used to invoke the Lisp compiler in batch mode
 quiet="@axiom_quiet_flags@"
@@ -103,16 +112,16 @@
     case $lisp_flavor in
 	gcl|sbcl|clisp)
 	   if [ -z "$output" ] ; then 
-	       $command $quiet $eval_flags \
-	         "(progn (compile-file \"$1\") (quit))"
+	       # $command $quiet $eval_flags \
+	       echo "(progn (compile-file \"$1\") (quit))" | $command
 	   else
                # argument to:output-file has implementation defined
                # default -- we use merge-patnames to pick defaults
                # from *default-pathname-defaults*
 
-	       $command $quiet $eval_flags \
-	         "(progn (compile-file \"$1\" :output-file \
-                 (merge-pathnames \"$output\")) (quit))"
+	       # $command $quiet $eval_flags 
+	       echo "(progn (compile-file \"$1\" :output-file \
+                 (merge-pathnames \"$output\")) (quit))" | $command
 	   fi
 	   ;;
 	# ECL makes the saved image executable only if :system-p it true. 
@@ -136,7 +145,8 @@
            ## image.  Consequently, we don't supply the $quiet flags
            ## when loading-and-saving.
            $command $eval_flags "(load \"$1\")" \
-	       $eval_flags "(boottran::save-core \"$output\")"
+	       $eval_flags "(in-package \"BOOTTRAN\")" \
+	       $eval_flags "(save-core \"$output\")"
 	   ;;
 	*)
 	   error "don't know how to compile with '$lisp_flavor' Lisp"
@@ -149,8 +159,9 @@
 make_program() {
     case $lisp_flavor in
 	gcl|sbcl|clisp)
-           $command $eval_flags \
-	       "(boottran::make-program \"$output\" (quote ($*)))"
+           ## $command $eval_flags \
+	   echo "(in-package \"BOOTTRAN\") \
+	         (make-program \"$output\" (quote ($*)))" | $command
 	   ;;
 	*)
 	   error "don't know how to build program with '$lisp_flavor' Lisp"
@@ -165,8 +176,8 @@
 translate_boot_file() {
     case $lisp_flavor in
 	gcl|sbcl|clisp)
-	   $command $quiet $eval_flags \
-	       "(progn (boottran::boottoclc \"$1\") (quit))" | tee $2 
+	   # $command $quiet $eval_flags "(in-package \"BOOTTRAN\")" \
+	   echo "(in-package \"BOOTTRAN\") (progn (boottoclc \"$1\")) (quit)" | $command | tee $2 
 	   ;;
 	*)
 	   error "don't know how to translate with '$lisp_flavor' Lisp"

--ELM1177682975-4906-0_--

\start
Date: Fri, 27 Apr 2007 16:20:28 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox

Gabriel Dos Reis wrote:
> Waldek Hebisch writes:
> 
> | Revision: 508
> |           http://svn.sourceforge.net/axiom/?rev=508&view=rev
> | Author:   whebisch
> | Date:     2007-04-18 13:25:00 -0700 (Wed, 18 Apr 2007)
> | 
> | Log Message:
> | -----------
> | Eradicate ENV.
> 
> ENV disappeared from Axiom.build-improvements long time ago.
> I'm glad to see that is populating down.  I wish the propagation to
> wh-sandbox is properly labelled to facilitate review when it comes to
> merging.  
> 

One remark: I dislike both ENV and AX_FLAGS (to say the truth I dislike
AX_FLAGS more than ENV).  So, the change to wh-sandbox is _not_ a
mechanical merge from build-improvements -- wh-sandbox moves remaininig
part of ENV (most could be dropped after other changes) to 'var-def.mk'.
This causes some breakage (the NOISE variable does not work as originally
intended) which ATM I consider tolerable (and I intend to fix when
re-working NOISE).

\start
Date: Fri, 27 Apr 2007 09:27:04 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox

Quoting Waldek Hebisch:

> Gabriel Dos Reis wrote:
>> Waldek Hebisch writes:
>>
>> | Revision: 508
>> |           http://svn.sourceforge.net/axiom/?rev=508&view=rev
>> | Author:   whebisch
>> | Date:     2007-04-18 13:25:00 -0700 (Wed, 18 Apr 2007)
>> |
>> | Log Message:
>> | -----------
>> | Eradicate ENV.
>>
>> ENV disappeared from Axiom.build-improvements long time ago.
>> I'm glad to see that is populating down.  I wish the propagation to
>> wh-sandbox is properly labelled to facilitate review when it comes to
>> merging.
>>
>
> One remark: I dislike both ENV and AX_FLAGS (to say the truth I dislike
> AX_FLAGS more than ENV).

Ah, it is a matter of dislike :-/

I'll very much appreciate to be enlightened about where all this is
going.  If you plan a merge back to build-improvements, then I suspect
it is more productive to refrain from gratuitous incompatibilities
based on dislike.  If you don't plan merge back to build-improvements,
please let us know.

> So, the change to wh-sandbox is _not_ a
> mechanical merge from build-improvements -- wh-sandbox moves remaininig
> part of ENV (most could be dropped after other changes) to 'var-def.mk'.
> This causes some breakage (the NOISE variable does not work as originally
> intended) which ATM I consider tolerable (and I intend to fix when
> re-working NOISE).

\start
Date: Fri, 27 Apr 2007 17:34:58 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox

Gabriel Dos Reis wrote:
> > One remark: I dislike both ENV and AX_FLAGS (to say the truth I dislike
> > AX_FLAGS more than ENV).
> 
> Ah, it is a matter of dislike :-/
>

Of course: I am not payed for working on Axiom, so I do this because
I like it :-).  And I think that other Axiom developers care how
the code looks like for the same reason...
 
> I'll very much appreciate to be enlightened about where all this is
> going.  If you plan a merge back to build-improvements, then I suspect
> it is more productive to refrain from gratuitous incompatibilities
> based on dislike.  If you don't plan merge back to build-improvements,
> please let us know.
> 

I wrote you few months ago that IMHO AX_FLAGS potentially has the similar
problems to ENV.  You do not consider AX_FLAGS problematic so you call
my change gratuitous.  But since I do not agree with your opinion about
AX_FLAGS I also do not agree with calling it gratuitous.  I am trying to
avoid unnecessary differences, but since I am maintaining wh-sandbox
I feel that ultimatly it is to me to judge what is necessary.

Concerning merge: I did a substantial work to reduce differnces between
build-improvements and wh-sandbox and I will help doing merge.  But
the outcame will largely depend on you: AFAIK you object to many
changes in wh-sandbox so there I problem with wholesale merge.  I am
willing to help identify idependent parts or modify offending code.
But if we find too many places where our opinions differ than the
merge will turn into cherry picking and it is only you who can
cherry pick to build-improvements.

\start
Date: 27 Apr 2007 10:46:02 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox

Waldek Hebisch writes:

| Gabriel Dos Reis wrote:
| > > One remark: I dislike both ENV and AX_FLAGS (to say the truth I dislike
| > > AX_FLAGS more than ENV).
| > 
| > Ah, it is a matter of dislike :-/
| >
| 
| Of course: I am not payed for working on Axiom, so I do this because
| I like it :-).  And I think that other Axiom developers care how
| the code looks like for the same reason...

Of course, everybody cares about how the code looks like.  However, it
had seemed to me that we introduced incompatibilities on technical
grounds, not just because we disliked the spelling of something.

ENV presents far more *technical* problems than AX_FLAGS does, because ENV
does already have a meaning for most POSIX environments.  

| > I'll very much appreciate to be enlightened about where all this is
| > going.  If you plan a merge back to build-improvements, then I suspect
| > it is more productive to refrain from gratuitous incompatibilities
| > based on dislike.  If you don't plan merge back to build-improvements,
| > please let us know.
| > 
| 
| I wrote you few months ago that IMHO AX_FLAGS potentially has the similar
| problems to ENV. 

If you did and I did not address your objections, then I must have missed
the message.  

| You do not consider AX_FLAGS problematic so you call
| my change gratuitous.  

AX_FLAGS presents far less technical problems than ENV does; in fact,
I would be very much interested in the problems you see with AX_FLAGS
that is not present with ENV.  

I asked for technical reasons, the serious reason I have been offered
is that "you dislike it more than ENV".  THAT reads "gratuituous"
difference in my book.

| But since I do not agree with your opinion about
| AX_FLAGS I also do not agree with calling it gratuitous.  I am trying to
| avoid unnecessary differences, but since I am maintaining wh-sandbox
| I feel that ultimatly it is to me to judge what is necessary.
| 
| Concerning merge: I did a substantial work to reduce differnces between
| build-improvements and wh-sandbox and I will help doing merge.  But
| the outcame will largely depend on you: AFAIK you object to many
| changes in wh-sandbox so there I problem with wholesale merge.  I am
| willing to help identify idependent parts or modify offending code.
| But if we find too many places where our opinions differ than the
| merge will turn into cherry picking and it is only you who can
| cherry pick to build-improvements.

Well, I do no insist that you merge back to build-improvements if your
taste dictates you refrain from doing so.  However, I do appreciate to
know where the changes are going.

\start
Date: 27 Apr 2007 11:06:25 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: building wh-sandbox on Windows

Bill Page writes:

| Gaby, the portability changes are also applicable to the
| build-mprovements branch. Would you like me to make an
| initial commit? There will be more (less critical) changes
| like this to follow. Regards,

Which parts of your patch is the "protability changes"?

\start
Date: 27 Apr 2007 11:12:47 -0500
From: Gabriel Dos Reis
To: Alfredo Portes
Subject: re: Please join!

Alfredo Portes writes:

| Bill, Gaby
| 
| > You can use the version of gcl that is in build-improvements but
| > you must now install noweb your self.
| 
| When the build is compiling gcl, it stops with this error:
| 
| ./libpre_gcl.a(gmp_wrappers.o)(.text+0x1061):gmp_wrappers.c: undefined reference
|  to `__gmpn_popcount'
| ./libpre_gcl.a(gmp_wrappers.o)(.text+0x11aa):gmp_wrappers.c: undefined reference
|  to `__gmpz_sizeinbase'
| collect2: ld returned 1 exit status
| make[2]: *** [raw_pre_gcl_map] Error 1
| make[2]: Leaving directory `/e/axiom/gcl/unixport'
| make[1]: *** [unixport/saved_pre_gcl] Error 2
| make[1]: Leaving directory `/e/axiom/gcl'
| make: *** [build/i686-pc-mingw32/bin/gcl.exe] Error 2


Alfredo --

  I don't know what this means; I've not seen it before.
Do you have the gcl config.log around?  It might be a good idea to
have Camm look at it.

\start
Date: Fri, 27 Apr 2007 18:25:07 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: building wh-sandbox on Windows

> Bill Page writes:
> 
> | Gaby, the portability changes are also applicable to the
> | build-mprovements branch. Would you like me to make an
> | initial commit? There will be more (less critical) changes
> | like this to follow. Regards,
> 
> Which parts of your patch is the "protability changes"?
> 
> -- Gaby
> 

IIUC Bill writes about patch attached to:

http://lists.nongnu.org/archive/html/axiom-developer/2007-04/msg00329.html

\start
Date: Fri, 27 Apr 2007 19:57:10 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

I wrote:
> I wrote:
> > Concerning Windows build, attached you will find modified version
> > of your patch (diff with respect to revision 517).
> 
> I forget to attach the patch, so I attach it to this mail.
> 
> -- 
>                               Waldek Hebisch
> Waldek Hebisch 

Axiom build with this patch fails numerous tests, for example
calculus2.input.  AFAICS runtime compilation is broken: the comiler
can not read back intermediate files it wrote.  ATM I do not see what
is the reason, but the only Lisp related change seems to be to 
src/lisp/Makefile.pamphlet, my first guess is that initial-env.lisp
is causing the problem.

\start
Date: Fri, 27 Apr 2007 20:19:31 +0200 (CEST)
From: Waldek Hebisch
To: list
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

I wrote:
> Axiom build with this patch fails numerous tests, for example
> calculus2.input.  AFAICS runtime compilation is broken: the comiler
> can not read back intermediate files it wrote.  ATM I do not see what
> is the reason, but the only Lisp related change seems to be to 
> src/lisp/Makefile.pamphlet, my first guess is that initial-env.lisp
> is causing the problem.
> 

It is probably false alarm: I just noticed that I made a mistake
and build Axiom based on gcl-2.6.6 -- this is likely the reason
for test failures.

\start
Date: Fri, 27 Apr 2007 18:24:40 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: building wh-sandbox on Windows

On April 27, 2007 12:06 PM Gaby wrote:
> 
> Bill Page writes:
> 
> | Gaby, the portability changes are also applicable to the
> | build-mprovements branch. Would you like me to make an
> | initial commit? There will be more (less critical) changes
> | like this to follow. Regards,
> 
> Which parts of your patch is the "protability changes"?
> 

Those originally done by Mike Thomas. That is that patch
that I sent you earlier. My point is just that those
changes and the patches I made more recently to wh-sandbox
to build on Windows are orthogonal.

\start
Date: Sat, 28 Apr 2007 00:32:20 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox

Gabriel Dos Reis wrote:
> 
> Well, I do no insist that you merge back to build-improvements if your
> taste dictates you refrain from doing so.  However, I do appreciate to
> know where the changes are going.
> 

I hope that it is clear that I intend to continue to work on wh-sandbox
independently of possible merge.  In particular work in progress
includes:
 - sbcl port (bootstraps in private tree but fails some tests)
 - database bootstrap (database seem to build correctly, but
   has some problems which needs to be resolved)
 - removals of unused code from compiler/interpreter (I have
   sizable hunks waiting for removal).

I consider current wh-sandbox "almost ready" for merge (there are some
cleanups worth doing but they should be relatively small).  

svn diff between wh-sandbox and build-improvements is probably quite
large, mostly due to file removals.  If we do not take into account
files which are entirely (or almost entirely) removed and algebra
files (where wh-sandbox removed bootstrap Lisp) we get a diff of
780 kb (20456 lines).  The bulk of this is in interp directory
(about 11000 lines).  The second large piece is graph subdirectory
(about 3000 lines).  The next is new asq program.  Other changes
are relatively small.

Graph subdirectory should be a no brainer -- beside not having
AX_FLAGS in the Makefile.pamphlet the rest is prototype conversion
and one or two rather trivial bug fixes.

New asq has slightly different output compared to old one but in general
should work better.

Both graph and asq should be independent of other changes.

Well, enough for today: I will summarize other changes later.

\start
Date: Fri, 27 Apr 2007 18:33:12 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: building wh-sandbox on Windows

Quoting Bill Page:

> On April 27, 2007 12:06 PM Gaby wrote:
>>
>> Bill Page writes:
>>
>> | Gaby, the portability changes are also applicable to the
>> | build-mprovements branch. Would you like me to make an
>> | initial commit? There will be more (less critical) changes
>> | like this to follow. Regards,
>>
>> Which parts of your patch is the "protability changes"?
>>
>
> Those originally done by Mike Thomas. That is that patch
> that I sent you earlier. My point is just that those
> changes and the patches I made more recently to wh-sandbox
> to build on Windows are orthogonal.

Aha, OK; thanks for the clarification.

\start
Date: Sat, 28 Apr 2007 01:17:57 -0400
From: Bill Page
To: Waldek Hebisch, Gabriel Dos Reis
Subject: RE: noweb tarball

On April 27, 2007 8:52 AM Waldek Hebisch wrote:
> 
> > Waldek Hebisch writes:
> > 
> > | Revision: 517
> > |           http://svn.sourceforge.net/axiom/?rev=517&view=rev
> > | Author:   whebisch
> > | Date:     2007-04-26 03:56:16 -0700 (Thu, 26 Apr 2007)
> > | 
> > | Log Message:
> > | -----------
> > | Add back support for noweb tarball.
> > 
>
> Gabriel Dos Reis wrote:
> > I reluctantly removed this, at the very insistance of
> > people here. I'm curious of what changed your mind.
> > 
> ...
> 
> Let me restate my position: in general I am against putting
> souces of prerequisities (especially as tarballs, but
> unpacked form is also bad) in Axiom svn repositiry.  Of
> course, sometimes we want to make an exception but I do not
> see any reason in case of noweb.  But this does not exclude
> having helper code which make use of prerequisities easier.
> 

In principle I agree with this, however where should this
"helper code" look for the tarball? And what name?

Your revision 517 uses:

+	  $(TAR) -zxf $(axiom_optional_srcdir)/noweb-2.10a.tgz && \

...

+                yes) if test -f $axiom_top_srcdir/zips/noweb-2.10a.tgz ;
then
+                         axiom_build_noweb=yes
+                     else
+                         { { echo "$as_me:$LINENO: error:
--with-included-noweb specified, but no noweb sources is present" >&5
+echo "$as_me: error: --with-included-noweb specified, but no noweb sources
is present" >&2;}
+   { (exit 1); exit 1; }; }

and we have:

I suppose it is better to write:

+                yes) if test -f $axiom_optional_srcdir/noweb-2.10a.tgz ;
then

In config/var-def.mk we have:

  axiom_optional_srcdir = $(abs_top_srcdir)/zips

"with-included-noweb" implies to me that it is included, but
you expect someone to copy 'noweb-2.10a.tgz' into the Axiom
source distribution which seems awkward to me. Of course
there is no "standard" place to look for such source files
on Linux, but varies from one Linux distribution to the next
and apparently from one project to the next.

Also, note the 'noweb-2.10a.tgz' is not the current version
of noweb. See:

http://www.eecs.harvard.edu/~nr/noweb/dist

I suppose that these problems might be solved by an appropriate
configure parameter, e.g.

  --with-noweb-src=/home/bpage/noweb-2.11b.tgz

But should we be concerned about supporting different releases
of noweb if Norman Ramsey should decide to slightly change
the method of building noweb with a new release?

So in spite of the "convenience" I do not like this very much.

I would very much prefer if we simply expect developers to
resolve build dependencies in the manner that is usual for
their platform, e.g. 'apt-get build-dep axiom' on Debian.

And of course this also applies to gcl.

\start
Date: Sat, 28 Apr 2007 01:46:33 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

On April 26, 2007 10:51 PM Waldek Hebisch wrote:
> 
> Bill Page wrote:
> ...
> > I would prefer if we set the EOL attributes on the SourceForge
> > SVN repository so that SVN does not mangle line endings
> > in this way. But this is just an inconvenient a fact-of-life
> > for Windows developers. Most Windows and MSYS tools are
> > tolerant for these differences but some are not. When I
> > produced the patch file I sent you, I filtered it by
> > tr -d '\r' to convert back to Unix line endings. 
> > 
> 
> This setting is intended as a convenience for Windows developers...
> And it seems to work -- at least it seems that the repository
> is free from unwanted carriage returns.

Do you mean that it is intended to protect the repository from
commits by Windows developers of source code containing Windows
line endings? I suppose. I never thought of it that way before.

But as a "Windows developer" I only consider it a pain that SVN
corrupts the linux sources in this manner. If I check-out code
from a "linux" project, I expect it to be valid linux source.
And the "corruption" can be subtle, for example the format of
the Axiom database files look like text files but contains byte
offsets encoded as text. These offsets are wrong if the line
endings are changed by SVN.

Windows porting tools like MSYS and the cygwin linux emulation
environment assume that source files will have unix line endings.
Even most native Windows text editors support unix line endings
as an option.

> 
> > > 4) Do you really need subshells in
> > >          src/algebra/Makefile.pamphlet?
> > 
> > Subshells make it easier to make local changes to the current
> > directory to avoid some path issues. But, no they are probably
> > not needed in a more careful design. 
> >
> 
> I appreciate advantages of subshells.  But on some platforms
> (including Windows) subshells are rather slow to create, so
> we probably want to avoid them in performance critical parts.
> 
> The shell code in question is _not_ performance critical, but
> since the only change to src/algebra/Makefile.pamphlet I see 
> (or did I overlook something?) is introduction of subshells
> I would like to know if there is a special problem here that
> braces have but subshells avoid.
>  

Braces like { } in the Makefile caused the make to fail.
Replacing these with ( ) worked. I have not encountered this
problem before.

I have

$ make --version
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.

Perhaps I need to upgrade it?

> ... 
> I am specifically referring to:
> 
>  $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
>      %.$(FASLEXT) : $(MID)/%.clisp
> -       @ echo 10 making $@ from $<
> -       @ ( B=`pwd`;\
> +       @ echo 10a making $@ from $< # hack 1 by Bill Page
> +       # avoid paths in file names for Windows compatibility
> 
> (and the hack 2).  The `pwd` command I put there is already a
> hack to work around fact that meaning of relative :output
> parameter to compile-file is implementation dependent.  In
> principle using
> 
> :output (merge-pathnames "$@") 
> 
> should help but I still had problems after doing that, so
> I used `pwd` as temporary hack before I get :output working
> in consistent way.  

After reading the Common Lisp documentation here:

http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_1130.html

It is not clear to me how I could specify something like

  C:/msys/1.0

to be added to a pathname by this method. How can I expect GCL
to know this BASE component of native Windows paths when called
from which an MSYS build environment?

> ... 
> Above I used wrong words.  Given problem $(BASE) is a logical
> solution.  Your 'cd'  + 'notdir' + 'mv' combination is also a
> logical solution, if we _have to_ keep current files loctions.
> But it is getting heavy, and we may put .clisp files in current
> directory which should solve problem in 'IN_from_MID' rule
> and simplify solution to 'AUTO_from_MID' rule
>

Ok, I will try.
 
\start
Date: Sat, 28 Apr 2007 02:42:59 -0400
From: Bill Page
To: Waldek Hebisch, Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom:	[508]branches/wh-sandbox

On April 27, 2007 6:32 PM Waldek Hebisch wrote:
> ... 
> svn diff between wh-sandbox and build-improvements is probably
> quite large, mostly due to file removals.  If we do not take
> into account files which are entirely (or almost entirely)
> removed and algebra files (where wh-sandbox removed bootstrap
> Lisp) we get a diff of 780 kb (20456 lines).  The bulk of this
> is in interp directory (about 11000 lines).  The second large
> piece is graph subdirectory (about 3000 lines).  The next is
> new asq program.  Other changes are relatively small.
>

Although everything else is very nice, I think the single
must significant achievement is wh-sandbox is the new algebra
bootstrap method and the removal of the Lisp from the algebra
files. In my opinion this is of great importance to the future
of Axiom.

When time permits, I would like to revisit the issue of cyclic
dependencies in the algebra files and look for evidence that
this new procedure solves the "fixed point" problem that was
never properly addressed in the old method:

http://wiki.axiom-developer.org/17AlgebraBOOTSTRAPFixedPoint

> ... 
> Both graph and asq should be independent of other changes.
> 
> Well, enough for today: I will summarize other changes later.
> 

What about the changes to HyperDoc?

\start
Date: Sat, 28 Apr 2007 07:09:05 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: building wh-sandbox on Windows

On Sat, 28 Apr 2007, Bill Page wrote:

> But as a "Windows developer" I only consider it a pain that SVN
> corrupts the linux sources in this manner. If I check-out code
> from a "linux" project, I expect it to be valid linux source.

I agree.

\start
Date: 28 Apr 2007 09:20:58 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: NE with bootsys (build-improvements)

Gregory Vanuxem writes:

| Hello,
|
| The file interop.boot is incorrectly translated by bootsys because of
| the use of 'NE'. 'NE' is translated to '(not (equal' by depsys but
| bootsys translate it to '(/='.
|
| You can trigger this bug if you issue in the interpreter:
|
| x^(1/7)
|
| Don't know if there are similar bugs in other parts of the interpreter.

Hi Gr=E9gory,

  Bootsys has a finer grained notion of types than depsys.  I
forgot about the ^= vs. /= issue -- there used to be similar issue for
when to use "eq" and "equal".

  In short: in Bootsys "^=" is for comparing numbers, whereas "/=" is
general comparison on objects.   In practice, Bootsys demands that we
have a better understanding of types in Boot programs -- depsys
has no such requirements.  All this will be much easier to work with
if and when we use typing in Boot codes.

  Patch pending.

[...]

| There is another thing with build-improvements, with this sequence of
| commands:
|
| -------------------------------------------------------------------------=
------------
| mkdir /home/greg/axiom-build-improvements
| lndir /home/greg/TDevel/axiom.build-improvements /home/greg/axiom-build-i=
mprovements/
| cd /home/greg/axiom-build-improvements/
| ./configure --enable-checking --prefix=/home/greg/axiom.bi.debug
| make && make install
| -------------------------------------------------------------------------=
------------
|
| the file /home/greg/axiom.bi.debug/bin is the axiom script (and not a
| directory).

I was unable to reproduce this, but I'll start from a fresh check out
again.

\start
Date: Sat, 28 Apr 2007 09:51:12 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Waldek Hebisch
Subject: re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Perhaps I am missing something, but shouldn't it be possible for the
person doing a checkout to use the svn:eol-style property flag to get
the desired behavior on a per-client basis?  In this case, perhaps that
means unix style eol for all platforms?

http://svnbook.red-bean.com/en/1.1/ch07s02.html

\start
Date: Sat, 28 Apr 2007 19:57:37 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Bill Page wrote:
> On April 26, 2007 10:51 PM Waldek Hebisch wrote:
> > 
> > Bill Page wrote:
> > ...
> > > I would prefer if we set the EOL attributes on the SourceForge
> > > SVN repository so that SVN does not mangle line endings
> > > in this way. But this is just an inconvenient a fact-of-life
> > > for Windows developers. Most Windows and MSYS tools are
> > > tolerant for these differences but some are not. When I
> > > produced the patch file I sent you, I filtered it by
> > > tr -d '\r' to convert back to Unix line endings. 
> > > 
> > 
> > This setting is intended as a convenience for Windows developers...
> > And it seems to work -- at least it seems that the repository
> > is free from unwanted carriage returns.
> 
> Do you mean that it is intended to protect the repository from
> commits by Windows developers of source code containing Windows
> line endings? I suppose. I never thought of it that way before.
> 

My point was that the the current setting is intended to work
for Windows developers -- if it causes problem we can change it.
We could try setting svn:eol-style to LF or remove this property.  
But we should check first if this gives desired consequences.
BTW:  Same files have no svn:eol-style property on them, are
they transferred as is?

> But as a "Windows developer" I only consider it a pain that SVN
> corrupts the linux sources in this manner. If I check-out code
> from a "linux" project, I expect it to be valid linux source.
> And the "corruption" can be subtle, for example the format of
> the Axiom database files look like text files but contains byte
> offsets encoded as text. These offsets are wrong if the line
> endings are changed by SVN.
> 

AFAICS there are no properties on database files -- were they
corrupted?

> Windows porting tools like MSYS and the cygwin linux emulation
> environment assume that source files will have unix line endings.
> Even most native Windows text editors support unix line endings
> as an option.
>

svn should allow user control of line convertion but the documentation
leaves impression that the settings are hardwired.  I consider this
as a design (or maybe documentation) bug.  MSYS and cygwin svn
are runninig in Unix environment so should use Unix line conventions.
 
> > 
> > > > 4) Do you really need subshells in
> > > >          src/algebra/Makefile.pamphlet?
> > > 
> > > Subshells make it easier to make local changes to the current
> > > directory to avoid some path issues. But, no they are probably
> > > not needed in a more careful design. 
> > >
> > 
> > I appreciate advantages of subshells.  But on some platforms
> > (including Windows) subshells are rather slow to create, so
> > we probably want to avoid them in performance critical parts.
> > 
> > The shell code in question is _not_ performance critical, but
> > since the only change to src/algebra/Makefile.pamphlet I see 
> > (or did I overlook something?) is introduction of subshells
> > I would like to know if there is a special problem here that
> > braces have but subshells avoid.
> >  
> 
> Braces like { } in the Makefile caused the make to fail.
> Replacing these with ( ) worked. I have not encountered this
> problem before.
> 
> I have
> 
> $ make --version
> GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
> 
> Perhaps I need to upgrade it?
> 

Could you say what is the error message and post corresponding fragment
of the build log.  The log should contain (rather longish) shell
command.  If this command is garbled, then we have make problem.
Othewise it may be some shell weirdness.

> > ... 
> > I am specifically referring to:
> > 
> >  $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
> >      %.$(FASLEXT) : $(MID)/%.clisp
> > -       @ echo 10 making $@ from $<
> > -       @ ( B=`pwd`;\
> > +       @ echo 10a making $@ from $< # hack 1 by Bill Page
> > +       # avoid paths in file names for Windows compatibility
> > 
> > (and the hack 2).  The `pwd` command I put there is already a
> > hack to work around fact that meaning of relative :output
> > parameter to compile-file is implementation dependent.  In
> > principle using
> > 
> > :output (merge-pathnames "$@") 
> > 
> > should help but I still had problems after doing that, so
> > I used `pwd` as temporary hack before I get :output working
> > in consistent way.  
> 
> After reading the Common Lisp documentation here:
> 
> http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_1130.html
> 
> It is not clear to me how I could specify something like
> 
>   C:/msys/1.0
> 
> to be added to a pathname by this method. How can I expect GCL
> to know this BASE component of native Windows paths when called
> from which an MSYS build environment?
>

Ansi Lisp has no concept of current directory, so is of no help here
(and almost anyting about files is implementation dependent anyway).
But I think that I have reasonable solution, just the solution
depends on implementation.  For clisp, cmucl, gcl and sbcl the following
works:

(merge-pathnames "$@" (truename ""))

But Poplog clisp needs:

(merge-pathnames "$@" (truename "."))

which works incorrectly in gcl, and gives error in clisp and other
implementations may need something entirely different.

So, the full solution to relative name problem will be too large
for Makefile -- we should put it in separate portability library.

\start
Date: Sat, 28 Apr 2007 13:22:09 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: building wh-sandbox on Windows

On Sat, 28 Apr 2007, Waldek Hebisch wrote:

> svn should allow user control of line convertion but the documentation
> leaves impression that the settings are hardwired.  I consider this
> as a design (or maybe documentation) bug.  MSYS and cygwin svn
> are runninig in Unix environment so should use Unix line conventions.

They let you set it to whatever you want.

[...]

> > After reading the Common Lisp documentation here:
> > 
> > http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_1130.html
> > 
> > It is not clear to me how I could specify something like
> > 
> >   C:/msys/1.0
> > 
> > to be added to a pathname by this method. How can I expect GCL
> > to know this BASE component of native Windows paths when called
> > from which an MSYS build environment?
> >
> 
> Ansi Lisp has no concept of current directory,

check default-pathname-defaults.

\start
Date: Sat, 28 Apr 2007 20:42:14 +0200
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

 > AFAICS there are no properties on database files -- were they
 > corrupted?

No. I think I removed a lot of properties in particular from the 
databases (revisions 137 and 136). But that happened in trunk and not in 
build-improvements.

\start
Date: Sat, 28 Apr 2007 20:46:54 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: building wh-sandbox on Windows

Gabriel Dos Reis wrote:
> On Sat, 28 Apr 2007, Waldek Hebisch wrote:
> > Ansi Lisp has no concept of current directory,
> 
> check default-pathname-defaults.
> 

I know about it:

1) content of *default-pathname-defaults* is implementation dependent
2) on some implementations *default-pathname-defaults* is a relative
   path
3) on Poplog clisp:

== *default-pathname-defaults*
#P"temp.lsp"

which if you use merge-patnames nicely defaults name to "temp" and
type to "lsp".
   
\start
Date: Sat, 28 Apr 2007 15:25:17 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: building wh-sandbox on Windows

On Sat, 28 Apr 2007, Waldek Hebisch wrote:

> Gabriel Dos Reis wrote:
> > On Sat, 28 Apr 2007, Waldek Hebisch wrote:
> > > Ansi Lisp has no concept of current directory,
> > 
> > check default-pathname-defaults.
> > 
> 
> I know about it:
> 
> 1) content of *default-pathname-defaults* is implementation dependent

So what?

> 2) on some implementations *default-pathname-defaults* is a relative
>    path

only if set to relative path.  
But, again I don't see why that is a problem.

Having read this thread many times, it appears to me that the
whole thread is confused.

First, I think people should state clearly and unambigously what
is the problem they are trying to solve.

Second, people should state very clearly what is the problem they 
are trying to avoid with relative paths.

> 3) on Poplog clisp:
> 
> == *default-pathname-defaults*
> #P"temp.lsp"
> 
> which if you use merge-patnames nicely defaults name to "temp" and
> type to "lsp".

Yes.  As expected.  What is the real problem?

\start
Date: Sat, 28 Apr 2007 23:10:51 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: building wh-sandbox on Windows

Gabriel Dos Reis wrote:
> Having read this thread many times, it appears to me that the
> whole thread is confused.
> 
> First, I think people should state clearly and unambigously what
> is the problem they are trying to solve.
> 
> Second, people should state very clearly what is the problem they 
> are trying to avoid with relative paths.
> 

If you missed it we are trying to solve the following exercise:

Given make variables $< and $@ write a make rule which compiles
Lisp file from $< and puts the results in $@.

You can easily check that

echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}

does not work with relative paths (it works fine with absolute
paths).

Related problem is handling '--output' parameter to 'document'
script when compiling.

When I am writing about underlying problem I mean that we call
'compile-file' in Axiom and we want output in specific place
(ATM what we get is "implementation dependent").

Note that compilation is part of user interface.  We can
choose crippled interface (say only names in current directory),
accept inconsincy between Lisps or we resolve this problem in
general (for arbitrary paths).  I feel that we should resolve
the problem.

\start
Date: 28 Apr 2007 23:21:04 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Waldek Hebisch writes:

[...]

> we are trying to solve the following exercise:
> 
> Given make variables $< and $@ write a make rule which compiles
> Lisp file from $< and puts the results in $@.
> 
> You can easily check that
> 
> echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}
> 
> does not work with relative paths (it works fine with absolute
> paths).

Don't you think you should forward that to comp.lang.lisp?

\start
Date: Sat, 28 Apr 2007 16:24:24 -0500 (CDT)
From: Gabriel Dos Reis
To: Martin Rubey
Subject: re: building wh-sandbox on Windows

On Sat, 28 Apr 2007, Martin Rubey wrote:

> Waldek Hebisch writes:
> 
> [...]
> 
> > we are trying to solve the following exercise:
> > 
> > Given make variables $< and $@ write a make rule which compiles
> > Lisp file from $< and puts the results in $@.
> > 
> > You can easily check that
> > 
> > echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}
> > 
> > does not work with relative paths (it works fine with absolute
> > paths).
> 
> Don't you think you should forward that to comp.lang.lisp?

I just received his mail.  He could of course send the message
to comp.lang.lisp, but I also believe that he is confusing the
medium with the message.

\start
Date: Sat, 28 Apr 2007 23:53:11 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Martin Rubey wrote:
> Waldek Hebisch writes:
> 
> [...]
> 
> > we are trying to solve the following exercise:
> > 
> > Given make variables $< and $@ write a make rule which compiles
> > Lisp file from $< and puts the results in $@.
> > 
> > You can easily check that
> > 
> > echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}
> > 
> > does not work with relative paths (it works fine with absolute
> > paths).
> 
> Don't you think you should forward that to comp.lang.lisp?
> 

I do not think it make any sense:

1) 'compile-file' works as specified -- the "only" problem is some
   aspect of specified behaviour are implementation dependent and
   impementation as doing something else compared to what we need
   (and different implementation and doing different something else).

2) We could complain about this implementation dependent behaviour
   but the problem is well-known and such message would be treated
   as an attempt to start a flame war.

3) We could ask how to archive what we want.  Again, there is a
   library (cl-fad), which solves bunch of similar exercises.
   cl-fad does not work on gcl, but it is IMHO unreasonable to
   ask a newsgroup to do a port for us.

\start
Date: Sun, 29 Apr 2007 00:06:23 +0200 (CEST)
From: Waldek Hebisch
To: Waldek Hebisch
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

> Gabriel Dos Reis wrote:
> > Having read this thread many times, it appears to me that the
> > whole thread is confused.
> > 
> > First, I think people should state clearly and unambigously what
> > is the problem they are trying to solve.
> > 
> > Second, people should state very clearly what is the problem they 
> > are trying to avoid with relative paths.
> > 
> 
> If you missed it we are trying to solve the following exercise:
> 
> Given make variables $< and $@ write a make rule which compiles
> Lisp file from $< and puts the results in $@.
> 
> You can easily check that
> 
> echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}
> 
> does not work with relative paths (it works fine with absolute
> paths).
>

In case you did not notice: I wrote earlier that we want to solve
inderlying problem, but in the Makefile we can arrange "$<" to
be in current directory, which solves the immediate problem.
 
\start
Date: Sat, 28 Apr 2007 17:15:02 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: building wh-sandbox on Windows

On Sat, 28 Apr 2007, Waldek Hebisch wrote:

> 3) We could ask how to archive what we want.  Again, there is a
>    library (cl-fad), which solves bunch of similar exercises.
>    cl-fad does not work on gcl, but it is IMHO unreasonable to
>    ask a newsgroup to do a port for us.

Indeed, if you ask the newsgroup to do a port for you, it would not
make much sense.  But, again, I understood something different
from Martin's suggestion.

\start
Date: Sat, 28 Apr 2007 17:16:27 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: building wh-sandbox on Windows

On Sun, 29 Apr 2007, Waldek Hebisch wrote:

> > Gabriel Dos Reis wrote:
> > > Having read this thread many times, it appears to me that the
> > > whole thread is confused.
> > > 
> > > First, I think people should state clearly and unambigously what
> > > is the problem they are trying to solve.
> > > 
> > > Second, people should state very clearly what is the problem they 
> > > are trying to avoid with relative paths.
> > > 
> > 
> > If you missed it we are trying to solve the following exercise:
> > 
> > Given make variables $< and $@ write a make rule which compiles
> > Lisp file from $< and puts the results in $@.
> > 
> > You can easily check that
> > 
> > echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}
> > 
> > does not work with relative paths (it works fine with absolute
> > paths).
> >
> 
> In case you did not notice: I wrote earlier that we want to solve
> inderlying problem, but in the Makefile we can arrange "$<" to
> be in current directory, which solves the immediate problem.

And many of us have been using that and building with relative paths.

\start
Date: Sat, 28 Apr 2007 18:32:10 -0400
From: Bill Page
To: Waldek Hebisch, Gabriel Dos Reis
Subject: RE: building wh-sandbox on Windows

On April 28, 2007 5:11 PM Waldek Hebisch wrote:
> 
> Gabriel Dos Reis wrote:
> > Having read this thread many times, it appears to me
> > that the whole thread is confused.
> > 

I agree.

> > First, I think people should state clearly and
> > unambigously what is the problem they are trying to
> > solve.
> > 
> > Second, people should state very clearly what is the
> > problem they are trying to avoid with relative paths.
> > 
> 
> If you missed it we are trying to solve the following
> exercise:
> 
> Given make variables $< and $@ write a make rule which
> compiles Lisp file from $< and puts the results in $@.
> 

>From my point of view, I do not think that completely
describes the problem - at least not the problem that
we need to solve in the Windows build of wh-sandbox.

> You can easily check that
> 
> echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}
> 
> does not work with relative paths (it works fine with
> absolute paths).
> 

Waldek claims that the various Lisps do not implement a
uniform concept of "current directory", so therefore
relative paths behave differently in different Lisps
because it is not clear what is relative to what. This
does however work as expected (i.e. in the sense of
"current directory" implemented by both Linux and Windows)
when building Axiom from build-improvements using GCL on
both Linux and Windows.

In MSYS on Windows absolute paths do to work as you might
expect, but this has anything to do with Lisp. The problem
is that MSYS is a porting environment and so there are
really two *different* concepts of absolute path: one that
applies exclusively to the MSYS environment and associated
tools, and another one that applies in the native Windows
applications. During the Axiom build we need to use both
of these because we are building Axiom and its intermediate
phases as a native apps. If we choose to use absolute paths,
as is (mostly) done in wh-sandbox, then we must be careful
when we specify paths that must be interpreted by these
native windows programs.

Alternatively when compile Axiom on MSYS using GCL, as is
done in build-improvements, we can code things carefully so
that all paths are relative and this works because the
concept of current path is the same between MSYS and native
Windows.

> Related problem is handling '--output' parameter to
> 'document' script when compiling.
> 
> When I am writing about underlying problem I mean that
> we call 'compile-file' in Axiom and we want output in
> specific place (ATM what we get is "implementation
> dependent").
> 
> Note that compilation is part of user interface.  We
> can choose crippled interface (say only names in current
> directory), accept inconsincy between Lisps or we resolve
> this problem in general (for arbitrary paths).  I feel
> that we should resolve the problem.
> 

I do not think that resolving this problem for multiple
Lisp targets needs to be much of a priority for Axiom
right now. From my point of view it is enough that we
now have a version of the Axiom source that compiles
using GCL in ANSI mode. Being able also to compile
Axiom using other common lisps like SBCL and CLisp is
interesting but if their behaviour differs a little
because of implementation differences allowed by the
standard, I don't think that is such a big deal.

Perhaps you can convince me otherwise.

\start
Date: Sat, 28 Apr 2007 17:53:54 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: RE: building wh-sandbox on Windows

On Sat, 28 Apr 2007, Bill Page wrote:

[...]

> > You can easily check that
> > 
> > echo '(compile-file "$<" :output-file "$@") (quit)' | ${DEPSYS}
> > 
> > does not work with relative paths (it works fine with
> > absolute paths).
> > 
> 
> Waldek claims that the various Lisps do not implement a
> uniform concept of "current directory", so therefore
> relative paths behave differently in different Lisps
> because it is not clear what is relative to what. This
> does however work as expected (i.e. in the sense of
> "current directory" implemented by both Linux and Windows)
> when building Axiom from build-improvements using GCL on
> both Linux and Windows.
> 
> In MSYS on Windows absolute paths do to work as you might
> expect, but this has anything to do with Lisp. The problem
> is that MSYS is a porting environment and so there are
> really two *different* concepts of absolute path: one that
> applies exclusively to the MSYS environment and associated
> tools, and another one that applies in the native Windows
> applications. During the Axiom build we need to use both
> of these because we are building Axiom and its intermediate
> phases as a native apps. If we choose to use absolute paths,
> as is (mostly) done in wh-sandbox, then we must be careful
> when we specify paths that must be interpreted by these
> native windows programs.
> 
> Alternatively when compile Axiom on MSYS using GCL, as is
> done in build-improvements, we can code things carefully so
> that all paths are relative and this works because the
> concept of current path is the same between MSYS and native
> Windows.

You have adequately summarized my findings while working last 
december on Axiom builds on Windows.  An important point is
to understand what MSYS/MinGW are.  From there, following
proven build techniques, one should be able to build without
much trouble.

The key to the solution, as I've found it is to code 
file manipulations in Axiom *as if* working with relative
paths.  That does not necessarily implies that everything
will be relative.  In fact, what that means is that
during the build, files are relative to the current directory
(for output files) and $AXIOM.  At installation time, we
always set $AXIOM to an absolute path, so magically everything
(after installation) becomes absolute.  

There is no need to insist that everything must be absolute
while building Axiom.  That mistake was made in what 
Axiom.build-improvements branched from.  And if I understand
Mike Thomas' work correctly (judging from what you pointed
me to), he has been trying to solve those same problems
on windows.  My claim is that we don't need to.  
Axiom.build-improvements is a "proof of concept".  Granted it
is not perfect, and there are plenty of room for improvement,
but I suspect that it provides a good starting point.


There are most (minor) issues with file manipulation in Axiom,
but I don't believe they change the problem you're trying to
solve.

[...]

> using GCL in ANSI mode. Being able also to compile
> Axiom using other common lisps like SBCL and CLisp is
> interesting but if their behaviour differs a little
> because of implementation differences allowed by the
> standard, I don't think that is such a big deal.

If you can compile with SBCL, then you can make Axiom
compilable on Windows without requiring GCL.  That, as we have
found recently may be of importance for Axiom developers
working in windows environment.

\start
Date: Sat, 28 Apr 2007 18:09:19 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Axiom and ANSI GCL

On Sat, 28 Apr 2007, Bill Page wrote:

[...]

>            From my point of view it is enough that we
> now have a version of the Axiom source that compiles
> using GCL in ANSI mode.

I've read in some of the mails that 

    (in-package "boottran")

found in document.in is wrong in ANSI CL.

Why?

\start
Date: Sun, 29 Apr 2007 01:57:21 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: Axiom and ANSI GCL

> On Sat, 28 Apr 2007, Bill Page wrote:
> 
> [...]
> 
> >            From my point of view it is enough that we
> > now have a version of the Axiom source that compiles
> > using GCL in ANSI mode.
> 
> I've read in some of the mails that 
> 
>     (in-package "boottran")
> 
> found in document.in is wrong in ANSI CL.
> 
> Why?
> 

In Ansi Lisp string argument to in-package is case sensitive (as
all other strings).  Normal reader converts symbols to upper case.
So if you want to access boottran::boottocl

you have to write

(in-package "BOOTTRAN")
(boottocl ...)

Writing 

(in-package "boottran")
(boottocl ...)

calls |boottran|::boottocl

BTW: It is intersting to compare sbcl and GCL on:

(make-package "BOOTTRAN")
(in-package "boottran")

Apparently even Ansi GCL stil is does not handle this correctly.

\start
Date: Sat, 28 Apr 2007 20:20:38 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: Axiom and ANSI GCL

On Sun, 29 Apr 2007, Waldek Hebisch wrote:

> > On Sat, 28 Apr 2007, Bill Page wrote:
> > 
> > [...]
> > 
> > >            From my point of view it is enough that we
> > > now have a version of the Axiom source that compiles
> > > using GCL in ANSI mode.
> > 
> > I've read in some of the mails that 
> > 
> >     (in-package "boottran")
> > 
> > found in document.in is wrong in ANSI CL.
> > 
> > Why?
> > 
> 
> In Ansi Lisp string argument to in-package is case sensitive (as
> all other strings). 

OK, got it.  Thanks.

\start
Date: Sat, 28 Apr 2007 20:39:50 -0500
From: Tim Daly
To: Cliff Yapp
Subject: source for literate lisp noweb

Cliff,

Where can I find the source for the literate lisp noweb?
I'm trying to incorporate it into the release.

\start
Date: Sun, 29 Apr 2007 06:17:08 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Bill Page wrote:
> On April 26, 2007 10:51 PM Waldek Hebisch wrote:
> > ... 
> > I am specifically referring to:
> > 
> >  $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
> >      %.$(FASLEXT) : $(MID)/%.clisp
> > -       @ echo 10 making $@ from $<
> > -       @ ( B=`pwd`;\
> > +       @ echo 10a making $@ from $< # hack 1 by Bill Page
> > +       # avoid paths in file names for Windows compatibility
> > 

> > Above I used wrong words.  Given problem $(BASE) is a logical
> > solution.  Your 'cd'  + 'notdir' + 'mv' combination is also a
> > logical solution, if we _have to_ keep current files loctions.
> > But it is getting heavy, and we may put .clisp files in current
> > directory which should solve problem in 'IN_from_MID' rule
> > and simplify solution to 'AUTO_from_MID' rule
> >
> 
> Ok, I will try.
>  

I now commited a change that keeps all lisp files in src/interp directory.

\start
Date: 29 Apr 2007 04:37:19 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: [Axiom-commit] SF.net SVN: axiom: [518] branches/wh-sandbox

Waldek Hebisch writes:

| Revision: 518
|           http://svn.sourceforge.net/axiom/?rev=518&view=rev
| Author:   whebisch
| Date:     2007-04-28 21:13:51 -0700 (Sat, 28 Apr 2007)
| 
| Log Message:
| -----------
| Do not use int/interp.

This change has been in Axiom.build-improvements for a long time; any
reason why it did not propagate to wh-sandbox before?

\start
Date: Sun, 29 Apr 2007 11:08:41 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: source for literate lisp noweb

I responded to Tim privately, but I should say something on the list
too - here's the latest.

This morning I have managed to get back to a point where the notangle
operation is succeeding again on SBCL and CMUCL.  The previously
mentioned problems with running on GCL have not vanished, unfortunately
- so if this work is ever to be incorporated into Axiom we need to
either get GCL up to par or figure out how to conditionalize for GCL.

Performance wise, things look pretty good - this is the time report for
notangle on boot, interp and algebra directories running on sbcl:

Standard noweb:

Evaluation took:
  14.045 seconds of real time
  2.212138 seconds of user run time
  1.524095 seconds of system run time
  [Run times include 0.044 seconds GC run time.]
  0 calls to %EVAL
  0 page faults and
  37,579,008 bytes consed.
T

Lisp implementation:

Evaluation took:
  1.723 seconds of real time
  1.392087 seconds of user run time
  0.332021 seconds of system run time
  [Run times include 0.032 seconds GC run time.]
  0 calls to %EVAL
  0 page faults and
  39,882,408 bytes consed.
T

Which is all well and good, but the correctness does not seem to be
quite complete yet.  I ran a recursive diff on the two results with my
latest iteration - most of the differences immediately attributable are
due to a lack of an ending return character at the end of file, and I
don't know how critical that is - it can be added if need be.  There is
a great deal of whitespace difference, but filtering that out the key
remaining difficulties seem to be in some instances in the code where
line returns are not present - I don't know if they are critical to
functionality or not, and with any luck inserting the returns in the
files will cure it.  The only really serious difference that is
obviously serious is found in numtheor.spad:

diff -r -w notangle/algebra/numtheor.spad lispnt/algebra/numtheor.spad
56,59c56
<   chineseRemainder: (I,I,I,I) -> I
<     ++ \spad{chineseRemainder(x1,m1,x2,m2)} returns w, where w is
such that
<     ++ \spad{w = x1 mod m1} and \spad{w = x2 mod m2}. Note: \spad{m1}
and
<     ++ \spad{m2} must be relatively prime.
---
> <<chineseRemainder: (I,I,I,I) -> I>>
174c171
<   inverse : (I,I) -> I
---
> <<inverse : (I,I) -> I>>
483d479

I have to go back and examine that file to figure out what is going on.
 Beyond that, the literate part of the documentation needs to be fixed
to correspond to the current code structure, various parts need to be
written, and a lot of basic cleanup, testing, and other such fun jobs
remain.  I'm not quite sure if it will be ready for this next release -
it depends on how much time I can spend on it.  Being functional is a
major boost to moral, so that could help ;-).

My hunch is that with a working scanner, being able to output legal
latex files for noweb should be relatively basic (famous last words...)
in which case we would be in a position to bootstrap the pamphlet files
only from lisp.

--- Tim Daly wrote:

> Cliff,
> 
> Where can I find the source for the literate lisp noweb?
> I'm trying to incorporate it into the release.
> 
> Tim
> 

\start
Date: Sun, 29 Apr 2007 20:14:41 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: building wh-sandbox on Windows
Cc: Gabriel Dos Reis

Bill Page wrote:
> On April 28, 2007 5:11 PM Waldek Hebisch wrote:
> > Note that compilation is part of user interface.  We
> > can choose crippled interface (say only names in current
> > directory), accept inconsincy between Lisps or we resolve
> > this problem in general (for arbitrary paths).  I feel
> > that we should resolve the problem.
> > 
> 
> I do not think that resolving this problem for multiple
> Lisp targets needs to be much of a priority for Axiom
> right now. From my point of view it is enough that we
> now have a version of the Axiom source that compiles
> using GCL in ANSI mode. Being able also to compile
> Axiom using other common lisps like SBCL and CLisp is
> interesting but if their behaviour differs a little
> because of implementation differences allowed by the
> standard, I don't think that is such a big deal.
> 
> Perhaps you can convince me otherwise.
> 

First, Axiom works with ANSI GCL largely due to work with other
lisps -- cmucl port by Jurgen Weiss, Greg Vanuxem sbcl work,
Gaby changes to Shoe translator.  I took subset of patches
developed for sbcl and basicaly it worked -- sbcl catched all
or almost all problems which affected ANSI GCL.

For me sbcl port is of high priority.  Some reasons:

 - Seems to work better then gcl on some targets (like Mac OSX
   or Windows)
 - There is mature code which runs on sbcl but has problems
   on gcl (like web servers)
 - sbcl compiler is much more picky then gcl so we have chance to
   clean our code
 - sbcl seem to catch more errors at runtime than gcl
 - sbcl profiler works for me, but I was unable to use gcl
   profiler
 - performance with sbcl seem to be better

For delivery on Windows I besides using gcl I consider sbcl, clisp
(may be slow but supposedly is quite stable on Windows), Poplog clisp
(the compiler does not optimize as well as sbcl, but compiles very
quickly, compiled code should beat interprters and it works on Windows),
corman (not free but licence seem to allow non-commercial binary
redistribution).

I do not give high priority to other ports (besides sbcl), but once
we have things working in sbcl it should be relatively little extra
work to support other Lisps.  And now is a logical time to do this.

\start
Date: Sun, 29 Apr 2007 22:13:32 +0200 (CEST)
From: Waldek Hebisch
To: Cliff Yapp
Subject: re: source for literate lisp noweb

> I responded to Tim privately, but I should say something on the list
> too - here's the latest.
> 
> This morning I have managed to get back to a point where the notangle
> operation is succeeding again on SBCL and CMUCL.  The previously
> mentioned problems with running on GCL have not vanished, unfortunately
> - so if this work is ever to be incorporated into Axiom we need to
> either get GCL up to par or figure out how to conditionalize for GCL.
> 
> Performance wise, things look pretty good - this is the time report for
> notangle on boot, interp and algebra directories running on sbcl:
> 
> Standard noweb:
> 
> Evaluation took:
>   14.045 seconds of real time
>   2.212138 seconds of user run time
>   1.524095 seconds of system run time
>   [Run times include 0.044 seconds GC run time.]
>   0 calls to %EVAL
>   0 page faults and
>   37,579,008 bytes consed.
> T
>

I wonder why there is so much consing (and run time) here: all you
have to do in Lisp is to create a few thousends of processes.  And
most of the run time should be in system calls (system time looks
just OK for that work).  IIUC actual noweb run time contibutes to real
time, but does not show as Lisp run time, so I wonder what else
is Lisp doing.
 
> Lisp implementation:
> 
> Evaluation took:
>   1.723 seconds of real time
>   1.392087 seconds of user run time
>   0.332021 seconds of system run time
>   [Run times include 0.032 seconds GC run time.]
>   0 calls to %EVAL
>   0 page faults and
>   39,882,408 bytes consed.
> T
> 
> Which is all well and good,

It seems that doing the work takes similar time like creating
worker processes...

> but the correctness does not seem to be
> quite complete yet.  I ran a recursive diff on the two results with my
> latest iteration - most of the differences immediately attributable are
> due to a lack of an ending return character at the end of file, and I
> don't know how critical that is - it can be added if need be.  There is
> a great deal of whitespace difference, but filtering that out the key
> remaining difficulties seem to be in some instances in the code where
> line returns are not present - I don't know if they are critical to
> functionality or not, and with any luck inserting the returns in the
> files will cure it.  The only really serious difference that is
> obviously serious is found in numtheor.spad:
> 
> diff -r -w notangle/algebra/numtheor.spad lispnt/algebra/numtheor.spad
> 56,59c56
> <   chineseRemainder: (I,I,I,I) -> I
> <     ++ \spad{chineseRemainder(x1,m1,x2,m2)} returns w, where w is
> such that
> <     ++ \spad{w = x1 mod m1} and \spad{w = x2 mod m2}. Note: \spad{m1}
> and
> <     ++ \spad{m2} must be relatively prime.
> ---
> > <<chineseRemainder: (I,I,I,I) -> I>>
> 174c171
> <   inverse : (I,I) -> I
> ---
> > <<inverse : (I,I) -> I>>
> 483d479
> 

This discrepancy is in version that I posted in:

http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00158.html

namely the fragment below (which searches for chunk start) assumed that
'>' can not occur in chunk name, if it is allowed one should use the
following code:

       in-chunk-start-tag-3
         (incf pos)
         (setf code (aref buff pos))
         (if (eql code end-tag-code-2)
             (go in-chunk-start-tag-4))
         (if (eql code newline-code)
             (go normal-start))
         (go in-chunk-start-tag)
             ^^^^^^^^^^^^^^^^^^^
    was  (go normal)

Incidentally, the other part (which scans for <<...>> markers)
allows '>' in the name.

\start
Date: Sun, 29 Apr 2007 22:19:51 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [518] branches/wh-sandbox

> Waldek Hebisch writes:
> 
> | Revision: 518
> |           http://svn.sourceforge.net/axiom/?rev=518&view=rev
> | Author:   whebisch
> | Date:     2007-04-28 21:13:51 -0700 (Sat, 28 Apr 2007)
> | 
> | Log Message:
> | -----------
> | Do not use int/interp.
> 
> This change has been in Axiom.build-improvements for a long time; any
> reason why it did not propagate to wh-sandbox before?
> 
> -- Gaby
> 

Simple: it was part of large set of changes which had multiple conflicts
with work on wh-sandbox.

\start
Date: Sun, 29 Apr 2007 14:06:37 -0700 (PDT)
From: Cliff Yapp
To: Waldek Hebisch
Subject: re: source for literate lisp noweb

--- Waldek Hebisch wrote:

> I wonder why there is so much consing (and run time) here: all you
> have to do in Lisp is to create a few thousends of processes.  And
> most of the run time should be in system calls (system time looks
> just OK for that work).  IIUC actual noweb run time contibutes to
> real time, but does not show as Lisp run time, so I wonder what else
> is Lisp doing.

Most likely something about the way I set up the test was incorrect. 
FWIW, I've attached the code I'm using to run both tests.  I'm
certainly all for a fair comparison, so if I've goofed it would be good
to know.

In essense Waldek, aside from some changing of name labels and
switching to using defstruct, the functional output of the macros
should be the same as the code you posted - that's what I was shooting
for.  I'll be glad to post it in a bit but first I need to clean up the
literate part so it's not so embarrassing.
 
> This discrepancy is in version that I posted in:
> 
>
http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00158.html
> 
> namely the fragment below (which searches for chunk start) assumed
> that
> '>' can not occur in chunk name, if it is allowed one should use the
> following code:
> 
>        in-chunk-start-tag-3
>          (incf pos)
>          (setf code (aref buff pos))
>          (if (eql code end-tag-code-2)
>              (go in-chunk-start-tag-4))
>          (if (eql code newline-code)
>              (go normal-start))
>          (go in-chunk-start-tag)
>              ^^^^^^^^^^^^^^^^^^^
>     was  (go normal)

Good catch!
 
> Incidentally, the other part (which scans for <<...>> markers)
> allows '>' in the name.

OK.  Was there any conclusion about whether the end-of-file line return
and white spaces pose a problem?  I wouldn't expect them to in lisp,
but perhaps SPAD isn't so forgiving.

KGlmIChub3QgKGZpbmQtcGFja2FnZSA6YXhpb20uc2V0dXApKQooZGVmcGFj
a2FnZSBheGlvbS5zZXR1cAogICAgICg6dXNlIDpjbCA6Y2wtd2ViKQogICAg
ICg6ZXhwb3J0ICJwYXRobmFtZS10by1zdHJpbmciICJydW4tZXh0LXByb2dy
YW0iKSkpCgooaW4tcGFja2FnZSA6YXhpb20uc2V0dXApCgooZGVmdW4gcGF0
aG5hbWUtdG8tc3RyaW5nIChmaWxlKQogIytzYmNsIChzYi1leHQ6bmF0aXZl
LW5hbWVzdHJpbmcgZmlsZSkKICAgKQoKKGRlZnVuIHJ1bi1leHQtcHJvZ3Jh
bSAoc3RyaW5nIGFyZ3Mgb3V0KQogIytzYmNsIChzYi1leHQ6cnVuLXByb2dy
YW0gc3RyaW5nIGFyZ3MgOmlucHV0IG5pbCA6b3V0cHV0IG91dCA6d2FpdCB0
KQogICApCgooZGVmdW4gcGFtcGhsZXRuYW1lLXRvLWZpbGVuYW1lIChmaWxl
KQogICAoc3Vic2VxIChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkgMCAKICAg
ICAgICAgICAocG9zaXRpb24gI1wuIChwYXRobmFtZS10by1zdHJpbmcgZmls
ZSkgOmZyb20tZW5kIHQpKSkKCjs7KioqKioqKioqY2xlYW51cCoqKioqKioq
CgkgICAKOzsgYm9vdCBwYW1waGxldCBmaWxlcwoKKGRvbGlzdCAoZmlsZSAo
ZGlyZWN0b3J5ICIuLi9ib290LyouYm9vdCIpKQogICAocnVuLWV4dC1wcm9n
cmFtICIvdXNyL2Jpbi9ybSIgKGxpc3QgKHBhdGhuYW1lLXRvLXN0cmluZyBm
aWxlKSkgbmlsKSkKCihkb2xpc3QgKGZpbGUgKGRpcmVjdG9yeSAiLi4vYm9v
dC8qLmwqc3AiKSkKICAgKHJ1bi1leHQtcHJvZ3JhbSAiL3Vzci9iaW4vcm0i
IChsaXN0IChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkpIG5pbCkpCgojK3Ni
Y2woZG9saXN0IChmaWxlIChkaXJlY3RvcnkgIi4uL2Jvb3QvKi5mYXNsIikp
CiAgICAgICAgKHJ1bi1leHQtcHJvZ3JhbSAiL3Vzci9iaW4vcm0iIChsaXN0
IChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkpIG5pbCkpCgo7OyBpbnRlcnAg
cGFtcGhsZXQgZmlsZXMKCiMrc2JjbChkb2xpc3QgKGZpbGUgKGRpcmVjdG9y
eSAiLi4vaW50ZXJwLyouZmFzbCIpKQogICAgICAgIChydW4tZXh0LXByb2dy
YW0gIi91c3IvYmluL3JtIiAobGlzdCAocGF0aG5hbWUtdG8tc3RyaW5nIGZp
bGUpKSBuaWwpKQoKKGRvbGlzdCAoZmlsZSAoZGlyZWN0b3J5ICIuLi9pbnRl
cnAvKi5ib290IikpCiAgIChydW4tZXh0LXByb2dyYW0gIi91c3IvYmluL3Jt
IiAobGlzdCAocGF0aG5hbWUtdG8tc3RyaW5nIGZpbGUpKSBuaWwpKQoKKGRv
bGlzdCAoZmlsZSAoZGlyZWN0b3J5ICIuLi9pbnRlcnAvKi5sKnNwIikpCiAg
IChydW4tZXh0LXByb2dyYW0gIi91c3IvYmluL3JtIiAobGlzdCAocGF0aG5h
bWUtdG8tc3RyaW5nIGZpbGUpKSBuaWwpKQogCjs7IGFsZ2VicmEgZmlsZXMK
ICAgCiMrc2JjbChkb2xpc3QgKGZpbGUgKGRpcmVjdG9yeSAiLi4vYWxnZWJy
YS8qLmZhc2wiKSkKICAgICAgICAocnVuLWV4dC1wcm9ncmFtICIvdXNyL2Jp
bi9ybSIgKGxpc3QgKHBhdGhuYW1lLXRvLXN0cmluZyBmaWxlKSkgbmlsKSkK
IAooZG9saXN0IChmaWxlIChkaXJlY3RvcnkgIi4uL2FsZ2VicmEvKi5zcGFk
IikpCiAgIChydW4tZXh0LXByb2dyYW0gIi91c3IvYmluL3JtIiAobGlzdCAo
cGF0aG5hbWUtdG8tc3RyaW5nIGZpbGUpKSBuaWwpKQogCgo7OyAqKioqKipz
dGFydCB1bnRhbmdsaW5nKioqKiogICAKCjs7IGJvb3QgcGFtcGhsZXQgZmls
ZXMKCih0aW1lCihwcm9nbgoKKGRvbGlzdCAoZmlsZSAoZGlyZWN0b3J5ICIu
Li9ib290LyoubCpzcC5wYW1waGxldCIpKQogICAocnVuLWV4dC1wcm9ncmFt
ICIvdXNyL2Jpbi9ub3RhbmdsZSIgKGxpc3QgKHBhdGhuYW1lLXRvLXN0cmlu
ZyBmaWxlKSkgKHBhbXBobGV0bmFtZS10by1maWxlbmFtZSBmaWxlKSkpCgoo
ZG9saXN0IChmaWxlIChkaXJlY3RvcnkgIi4uL2Jvb3QvKi5ib290LnBhbXBo
bGV0IikpCiAgIChydW4tZXh0LXByb2dyYW0gIi91c3IvYmluL25vdGFuZ2xl
IiAobGlzdCAocGF0aG5hbWUtdG8tc3RyaW5nIGZpbGUpKSAocGFtcGhsZXRu
YW1lLXRvLWZpbGVuYW1lIGZpbGUpKSkKCjs7IEluIHRoZSBjYXNlIG9mIGJv
b3QsIHRoZXJlIGFyZSBzcGVjaWFsIHN0ZXBzIHdoaWNoIG5lZWQgdG8gYmUg
dGFrZW4gaW4gb3JkZXIgdG8gYm9vdHN0cmFwIHRoZSBsYW5ndWFnZS4KOzsg
QmVjYXVzZSBvZiB0aGF0LCB0aGUgLmJvb3QgZmlsZXMgaW4gdGhpcyBkaXJl
Y3RvcnkgYWxzbyBjb250YWluIGxpc3AgY29kZSwgd2hpY2ggd2lsbCBiZSBu
ZWVkZWQuCihydW4tZXh0LXByb2dyYW0gIi91c3IvYmluL25vdGFuZ2xlIiAo
bGlzdCAiLVJwdHlvdXQuY2xpc3AiICIuLi9ib290L3B0eW91dC5ib290LnBh
bXBobGV0IikgIi4uL2Jvb3QvcHR5b3V0Lmxpc3AiKQoocnVuLWV4dC1wcm9n
cmFtICIvdXNyL2Jpbi9ub3RhbmdsZSIgKGxpc3QgIi1SYnRpbmNsMi5jbGlz
cCIgIi4uL2Jvb3QvYnRpbmNsMi5ib290LnBhbXBobGV0IikgIi4uL2Jvb3Qv
YnRpbmNsMi5saXNwIikKKHJ1bi1leHQtcHJvZ3JhbSAiL3Vzci9iaW4vbm90
YW5nbGUiIChsaXN0ICItUnR5cHJvcHMuY2xpc3AiICIuLi9ib290L3R5cHJv
cHMuYm9vdC5wYW1waGxldCIpICIuLi9ib290L3R5cHJvcHMubGlzcCIpCihy
dW4tZXh0LXByb2dyYW0gIi91c3IvYmluL25vdGFuZ2xlIiAobGlzdCAiLVJi
dHBpbGUyLmNsaXNwIiAiLi4vYm9vdC9idHBpbGUyLmJvb3QucGFtcGhsZXQi
KSAiLi4vYm9vdC9idHBpbGUyLmxpc3AiKQoocnVuLWV4dC1wcm9ncmFtICIv
dXNyL2Jpbi9ub3RhbmdsZSIgKGxpc3QgIi1SYnRzY2FuMi5jbGlzcCIgIi4u
L2Jvb3QvYnRzY2FuMi5ib290LnBhbXBobGV0IikgIi4uL2Jvb3QvYnRzY2Fu
Mi5saXNwIikKKHJ1bi1leHQtcHJvZ3JhbSAiL3Vzci9iaW4vbm90YW5nbGUi
IChsaXN0ICItUnR5cGFycy5jbGlzcCIgIi4uL2Jvb3QvdHlwYXJzLmJvb3Qu
cGFtcGhsZXQiKSAiLi4vYm9vdC90eXBhcnMubGlzcCIpCjsocnVuLWV4dC1w
cm9ncmFtICIvdXNyL2Jpbi9ub3RhbmdsZSIgKGxpc3QgIi1SdHlleHRyYS5j
bGlzcCIgIi4uL2Jvb3QvdHlleHRyYS5ib290LnBhbXBobGV0IikgIi4uL2Jv
b3QvdHlleHRyYS5saXNwIikKKHJ1bi1leHQtcHJvZ3JhbSAiL3Vzci9iaW4v
bm90YW5nbGUiIChsaXN0ICItUnR5dHJlZTEuY2xpc3AiICIuLi9ib290L3R5
dHJlZTEuYm9vdC5wYW1waGxldCIpICIuLi9ib290L3R5dHJlZTEubGlzcCIp
Cgo7OyBpbnRlcnAgcGFtcGhsZXQgZmlsZXMKCihkb2xpc3QgKGZpbGUgKGRp
cmVjdG9yeSAiLi4vaW50ZXJwLyoubCpzcC5wYW1waGxldCIpKQogICAocnVu
LWV4dC1wcm9ncmFtICIvdXNyL2Jpbi9ub3RhbmdsZSIgKGxpc3QgKHBhdGhu
YW1lLXRvLXN0cmluZyBmaWxlKSkgKHBhbXBobGV0bmFtZS10by1maWxlbmFt
ZSBmaWxlKSkpCgooZG9saXN0IChmaWxlIChkaXJlY3RvcnkgIi4uL2ludGVy
cC8qLmJvb3QucGFtcGhsZXQiKSkKICAgKHJ1bi1leHQtcHJvZ3JhbSAiL3Vz
ci9iaW4vbm90YW5nbGUiIChsaXN0IChwYXRobmFtZS10by1zdHJpbmcgZmls
ZSkpIChwYW1waGxldG5hbWUtdG8tZmlsZW5hbWUgZmlsZSkpKQoKKHJ1bi1l
eHQtcHJvZ3JhbSAiL3Vzci9iaW4vbm90YW5nbGUiIChsaXN0ICItUkludGVy
cHJldGVyIiAiLi4vaW50ZXJwL2Jvb2t2b2w1LnBhbXBobGV0IikgIi4uL2lu
dGVycC9ib29rdm9sNS5saXNwIikgCgo7OyBhbGdlYnJhIGZpbGVzCgooZG9s
aXN0IChmaWxlIChkaXJlY3RvcnkgIi4uL2FsZ2VicmEvKi5zcGFkLnBhbXBo
bGV0IikpCiAgIChydW4tZXh0LXByb2dyYW0gIi91c3IvYmluL25vdGFuZ2xl
IiAobGlzdCAocGF0aG5hbWUtdG8tc3RyaW5nIGZpbGUpKSAocGFtcGhsZXRu
YW1lLXRvLWZpbGVuYW1lIGZpbGUpKSkgICkpCgoKCg==

--0-202770926-1177880797=:36990

KGlmIChub3QgKGZpbmQtcGFja2FnZSA6YXhpb20uc2V0dXApKQooZGVmcGFj
a2FnZSBheGlvbS5zZXR1cAogICAgICg6dXNlIDpjbCA6Y2wtd2ViKQogICAg
ICg6ZXhwb3J0ICJwYXRobmFtZS10by1zdHJpbmciICJydW4tZXh0LXByb2dy
YW0iKSkpCgooaW4tcGFja2FnZSA6YXhpb20uc2V0dXApCgooZGVmdW4gcGF0
aG5hbWUtdG8tc3RyaW5nIChmaWxlKQogIytzYmNsIChzYi1leHQ6bmF0aXZl
LW5hbWVzdHJpbmcgZmlsZSkKICAgKQoKKGRlZnVuIHJ1bi1leHQtcHJvZ3Jh
bSAoc3RyaW5nIGFyZ3Mgb3V0KQogIytzYmNsIChzYi1leHQ6cnVuLXByb2dy
YW0gc3RyaW5nIGFyZ3MgOmlucHV0IG5pbCA6b3V0cHV0IG91dCA6d2FpdCB0
KQogICApCgooZGVmdW4gcGFtcGhsZXRuYW1lLXRvLWZpbGVuYW1lIChmaWxl
KQogICAoc3Vic2VxIChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkgMCAKICAg
ICAgICAgICAocG9zaXRpb24gI1wuIChwYXRobmFtZS10by1zdHJpbmcgZmls
ZSkgOmZyb20tZW5kIHQpKSkKCjs7KioqKioqKioqY2xlYW51cCoqKioqKioq
CgkgICAKOzsgYm9vdCBwYW1waGxldCBmaWxlcwoKKGRvbGlzdCAoZmlsZSAo
ZGlyZWN0b3J5ICIuLi9ib290LyouYm9vdCIpKQogICAocnVuLWV4dC1wcm9n
cmFtICIvdXNyL2Jpbi9ybSIgKGxpc3QgKHBhdGhuYW1lLXRvLXN0cmluZyBm
aWxlKSkgbmlsKSkKCihkb2xpc3QgKGZpbGUgKGRpcmVjdG9yeSAiLi4vYm9v
dC8qLmwqc3AiKSkKICAgKHJ1bi1leHQtcHJvZ3JhbSAiL3Vzci9iaW4vcm0i
IChsaXN0IChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkpIG5pbCkpCgojK3Ni
Y2woZG9saXN0IChmaWxlIChkaXJlY3RvcnkgIi4uL2Jvb3QvKi5mYXNsIikp
CiAgICAgICAgKHJ1bi1leHQtcHJvZ3JhbSAiL3Vzci9iaW4vcm0iIChsaXN0
IChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkpIG5pbCkpCgo7OyBpbnRlcnAg
cGFtcGhsZXQgZmlsZXMKCiMrc2JjbChkb2xpc3QgKGZpbGUgKGRpcmVjdG9y
eSAiLi4vaW50ZXJwLyouZmFzbCIpKQogICAgICAgIChydW4tZXh0LXByb2dy
YW0gIi91c3IvYmluL3JtIiAobGlzdCAocGF0aG5hbWUtdG8tc3RyaW5nIGZp
bGUpKSBuaWwpKQoKKGRvbGlzdCAoZmlsZSAoZGlyZWN0b3J5ICIuLi9pbnRl
cnAvKi5ib290IikpCiAgIChydW4tZXh0LXByb2dyYW0gIi91c3IvYmluL3Jt
IiAobGlzdCAocGF0aG5hbWUtdG8tc3RyaW5nIGZpbGUpKSBuaWwpKQoKKGRv
bGlzdCAoZmlsZSAoZGlyZWN0b3J5ICIuLi9pbnRlcnAvKi5sKnNwIikpCiAg
IChydW4tZXh0LXByb2dyYW0gIi91c3IvYmluL3JtIiAobGlzdCAocGF0aG5h
bWUtdG8tc3RyaW5nIGZpbGUpKSBuaWwpKQoKOzsgYWxnZWJyYSBmaWxlcwog
ICAKIytzYmNsKGRvbGlzdCAoZmlsZSAoZGlyZWN0b3J5ICIuLi9hbGdlYnJh
LyouZmFzbCIpKQogICAgICAgIChydW4tZXh0LXByb2dyYW0gIi91c3IvYmlu
L3JtIiAobGlzdCAocGF0aG5hbWUtdG8tc3RyaW5nIGZpbGUpKSBuaWwpKQog
Cihkb2xpc3QgKGZpbGUgKGRpcmVjdG9yeSAiLi4vYWxnZWJyYS8qLnNwYWQi
KSkKICAgKHJ1bi1leHQtcHJvZ3JhbSAiL3Vzci9iaW4vcm0iIChsaXN0IChw
YXRobmFtZS10by1zdHJpbmcgZmlsZSkpIG5pbCkpCgoKOzsgKioqKioqKioq
KipzdGFydCB1bnRhbmdsaW5nKioqKioqKioqKioKCih0aW1lCihwcm9nbgoK
KGRvbGlzdCAoZmlsZSAoZGlyZWN0b3J5ICIuLi9ib290LyoubCpzcC5wYW1w
aGxldCIpKQogICAobm90YW5nbGUgKHBhdGhuYW1lLXRvLXN0cmluZyBmaWxl
KSAocGFtcGhsZXRuYW1lLXRvLWZpbGVuYW1lIGZpbGUpKSkKCihkb2xpc3Qg
KGZpbGUgKGRpcmVjdG9yeSAiLi4vYm9vdC8qLmJvb3QucGFtcGhsZXQiKSkK
ICAgKG5vdGFuZ2xlIChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkgKHBhbXBo
bGV0bmFtZS10by1maWxlbmFtZSBmaWxlKSkpCgo7OyBJbiB0aGUgY2FzZSBv
ZiBib290LCB0aGVyZSBhcmUgc3BlY2lhbCBzdGVwcyB3aGljaCBuZWVkIHRv
IGJlIHRha2VuIGluIG9yZGVyIHRvIGJvb3RzdHJhcCB0aGUgbGFuZ3VhZ2Uu
Cjs7IEJlY2F1c2Ugb2YgdGhhdCwgdGhlIC5ib290IGZpbGVzIGluIHRoaXMg
ZGlyZWN0b3J5IGFsc28gY29udGFpbiBsaXNwIGNvZGUsIHdoaWNoIHdpbGwg
YmUgbmVlZGVkLgoobm90YW5nbGUgIi4uL2Jvb3QvcHR5b3V0LmJvb3QucGFt
cGhsZXQiICIuLi9ib290L3B0eW91dC5saXNwIiAicHR5b3V0LmNsaXNwIiAp
Cihub3RhbmdsZSAiLi4vYm9vdC9idGluY2wyLmJvb3QucGFtcGhsZXQiICIu
Li9ib290L2J0aW5jbDIubGlzcCIgImJ0aW5jbDIuY2xpc3AiKQoobm90YW5n
bGUgIi4uL2Jvb3QvdHlwcm9wcy5ib290LnBhbXBobGV0IiAiLi4vYm9vdC90
eXByb3BzLmxpc3AiICJ0eXByb3BzLmNsaXNwIikKKG5vdGFuZ2xlICIuLi9i
b290L2J0cGlsZTIuYm9vdC5wYW1waGxldCIgIi4uL2Jvb3QvYnRwaWxlMi5s
aXNwIiAiYnRwaWxlMi5jbGlzcCIpCihub3RhbmdsZSAiLi4vYm9vdC9idHNj
YW4yLmJvb3QucGFtcGhsZXQiICIuLi9ib290L2J0c2NhbjIubGlzcCIgImJ0
c2NhbjIuY2xpc3AiKQoobm90YW5nbGUgIi4uL2Jvb3QvdHlwYXJzLmJvb3Qu
cGFtcGhsZXQiICIuLi9ib290L3R5cGFycy5saXNwIiAidHlwYXJzLmNsaXNw
IiApCjsobm90YW5nbGUgIi4uL2Jvb3QvdHlleHRyYS5ib290LnBhbXBobGV0
IiAiLi4vYm9vdC90eWV4dHJhLmxpc3AiICJ0eWV4dHJhLmNsaXNwIikKKG5v
dGFuZ2xlICIuLi9ib290L3R5dHJlZTEuYm9vdC5wYW1waGxldCIgIi4uL2Jv
b3QvdHl0cmVlMS5saXNwIiAidHl0cmVlMS5jbGlzcCIpCgooZG9saXN0IChm
aWxlIChkaXJlY3RvcnkgIi4uL2ludGVycC8qLmwqc3AucGFtcGhsZXQiKSkK
ICAgKG5vdGFuZ2xlIChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkgKHBhbXBo
bGV0bmFtZS10by1maWxlbmFtZSBmaWxlKSkpCgooZG9saXN0IChmaWxlIChk
aXJlY3RvcnkgIi4uL2ludGVycC8qLmJvb3QucGFtcGhsZXQiKSkKICAgKG5v
dGFuZ2xlIChwYXRobmFtZS10by1zdHJpbmcgZmlsZSkgKHBhbXBobGV0bmFt
ZS10by1maWxlbmFtZSBmaWxlKSkpCgoobm90YW5nbGUgIi4uL2ludGVycC9i
b29rdm9sNS5wYW1waGxldCIgIi4uL2ludGVycC9ib29rdm9sNS5saXNwIiAi
SW50ZXJwcmV0ZXIiKQoKKGRvbGlzdCAoZmlsZSAoZGlyZWN0b3J5ICIuLi9h
bGdlYnJhLyouc3BhZC5wYW1waGxldCIpKQogICAobm90YW5nbGUgKHBhdGhu
YW1lLXRvLXN0cmluZyBmaWxlKSAocGFtcGhsZXRuYW1lLXRvLWZpbGVuYW1l
IGZpbGUpKSkKCgogKSkKCg==

--0-202770926-1177880797=:36990--

\start
Date: Mon, 30 Apr 2007 00:06:10 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: re: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox
Cc: Gabriel Dos Reis

Bill Page wrote:
> On April 27, 2007 6:32 PM Waldek Hebisch wrote:
> > ... 
> > svn diff between wh-sandbox and build-improvements is probably
> > quite large, mostly due to file removals.  If we do not take
> > into account files which are entirely (or almost entirely)
> > removed and algebra files (where wh-sandbox removed bootstrap
> > Lisp) we get a diff of 780 kb (20456 lines).  The bulk of this
> > is in interp directory (about 11000 lines).  The second large
> > piece is graph subdirectory (about 3000 lines).  The next is
> > new asq program.  Other changes are relatively small.
> >
> 
> Although everything else is very nice, I think the single
> must significant achievement is wh-sandbox is the new algebra
> bootstrap method and the removal of the Lisp from the algebra
> files. In my opinion this is of great importance to the future
> of Axiom.
> 

I think content of algebra should go almost as-is to build-improvements.
ATM wh-sandbox uses different paths, but that is very easy to adjust.
I plan to add some explanations to Makefile.pamphlet (old
explanations are _very_ out of date).  Besides new bootstrap
procedure (which is contained in Makefile.pamphlet) algebra
has a namber of bug fixes and Martin's guessing package.  However,
there is some (weak) dependence on changes to interp. 

> > ... 
> > Both graph and asq should be independent of other changes.
> > 
> > Well, enough for today: I will summarize other changes later.
> > 
> 
> What about the changes to HyperDoc?
> 

HyperDoc changes are actually a few small fixes, same in interp,
some in lib, some in hyper.  In hyper Makefile.pamphlet may be
controversial:  IMO  '${HYPER}/pages/ht.db' rule in wh-sandbox
is more readible.

Let me repeat (and update) summary of main changes in wh-sandbox:

1) removal of unused code from compiler/interpreter
2) translating depsys using Shoe and removal of depsys bootstrap Lisp
3) new algebra bootstrap and removal of algebra bootstrap Lisp
4) mechanical generation of (most of) .pht pages
5) hyperdoc and algebra fixes
6) removal of useless files
7) pretty-printing of intermediate files and asq rewrite
8) adding guessing package written by Martin Rubey
9) prototype conversion in graph
10) safety/portability fixes in interp
11) making variable initialization explicit in interp

I think that main problem is merge of interp -- this is bulk of
changes and they are not entirely mechanical.  There are some
easy ones: bootstrap Lisp in c-util.boot.pamphlet and in 
interop.boot.pamphlet is unused, so this code in removed from
wh-sandbox.  OTOH Gaby converted to Shoe a bunch of files that
were earlier converted in wh-sandbox -- this created a conflict.
There were few fixes to interp files in build-improvements
revision 485 I think that I incorporated them all.  But recent
mass edits for Shoe covertion create conflicts in some files.

So there is some work to do in interp, especially due to Shoe
covertion:  my experience is that such changes while seemingly
trivial must be carefully validated, and this takes time.

There is some potential for controversion in interp/Makefile.pamphlet.
The version in wh-sandbox IMHO is simpler and has more functionality
than version in build-improvements.

I think that we can quickly agree about trivial or uncontroversial
changes (graph, algebra, some interp cleanups including removal
of bootstrap Lisp from c-util and interop).  If we agree on
design decision in interp then we will have to resolve conflicts
in recent work.

Gaby, now you should say how you imagine merge, in particular
if you object to some changes made to wh-sandbox (it looks
that you attach special importance to AX_FLAGS)?

\start
Date: Mon, 30 Apr 2007 01:51:04 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox

Gabriel Dos Reis wrote:
> AX_FLAGS presents far less technical problems than ENV does; in fact,
> I would be very much interested in the problems you see with AX_FLAGS
> that is not present with ENV.  
> 
> I asked for technical reasons, the serious reason I have been offered
> is that "you dislike it more than ENV".  THAT reads "gratuituous"
> difference in my book.
> 

First, I see no problem with name: since we can not use ENV changing
it to AX_FLAGS is OK.  My basic objection is that AX_FLAGS is redundant.
We already have mechanizm to propagate values to subdirectories:
we use var-def.mk.  So AX_FLAGS establishes parallel chanel,
which has significant potential for bugs and confusion.

The problem I see in writing

make AX_FLAGS

(as opposed to)

AX_FLAGS make

is that we override thing in Makefile. But we are effectively
"broadcasting" AX_FLAGS down which looks like abuse of mechanizm
designed for something else (that is allowing default in
Makfile but sometimes taking alternate values).

The second extra problem is that AX_FLAGS is new code, so may
trick potential readers to think that its use is right thing
to do.

\start
Date: Sun, 29 Apr 2007 19:14:58 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: re: [Axiom-commit] SF.net SVN: axiom: [508] branches/wh-sandbox

On Mon, 30 Apr 2007, Waldek Hebisch wrote:

> Gabriel Dos Reis wrote:
> > AX_FLAGS presents far less technical problems than ENV does; in fact,
> > I would be very much interested in the problems you see with AX_FLAGS
> > that is not present with ENV.  
> > 
> > I asked for technical reasons, the serious reason I have been offered
> > is that "you dislike it more than ENV".  THAT reads "gratuituous"
> > difference in my book.
> > 
> 
> First, I see no problem with name: since we can not use ENV changing
> it to AX_FLAGS is OK.  My basic objection is that AX_FLAGS is redundant.
> We already have mechanizm to propagate values to subdirectories:
> we use var-def.mk.

Well, if that is the basis of your objection, then it has no foundation.
The purpose of AX_FLAGS is not to propagate values to subdirectories.

The purpose of AX_FLAGS is to propagate values to *sub-processes*, much
like MAKEFLAGS.

Until very recently, that is a very simple, reliable way of communicating
values without duplication.

>  So AX_FLAGS establishes parallel chanel,
> which has significant potential for bugs and confusion.
> 
> The problem I see in writing
> 
> make AX_FLAGS
> 
> (as opposed to)
> 
> AX_FLAGS make
> 
> is that we override thing in Makefile. But we are effectively
> "broadcasting" AX_FLAGS down which looks like abuse of mechanizm
> designed for something else (that is allowing default in
> Makfile but sometimes taking alternate values).

That is an abuse only if you're mistaken about the purpose.

> The second extra problem is that AX_FLAGS is new code, 

Excuse me, but that is bullshit. 

\start
Date: Sun, 29 Apr 2007 20:46:33 -0500
From: Tim Daly
To: Cliff Yapp
Subject: finite-state-notangle graphic

Cliff,

Where can I find the finite-state-notangle graphic?

\start
Date: Sun, 29 Apr 2007 20:53:48 -0500
From: Tim Daly
To: Cliff Yapp
Subject: clweb, array-to-string

Can 
  (array-to-string ar)
be rewritten as
  (coerce ar 'string)

\start
Date: Mon, 30 Apr 2007 01:07:47 -0400
From: Bill Page
To: Gabriel Dos Reis, Waldek Hebisch
Subject: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox)

> Waldek Hebisch wrote:
> ...
> > My basic objection is that AX_FLAGS is redundant.
> > We already have mechanizm to propagate values to
> > subdirectories: we use var-def.mk.
> > So AX_FLAGS establishes parallel chanel, which has
> > significant potential for bugs and confusion.
>

Gabriel Dos Reis wrote:

> The purpose of AX_FLAGS is not to propagate values to
> subdirectories. The purpose of AX_FLAGS is to propagate
> values to *sub-processes*, much like MAKEFLAGS.

I think there is no substantive difference between
"propagate to subdirectories" and "propogate to sub-
processes" since I do not know what the former expression
could mean if not the latter. It seems clear to me that
provided the information is static (i.e. determined at
configure-time) it could be communicated to sub-processes
by either mechanism.

>
> > The second extra problem is that AX_FLAGS is new code,
> > so may trick potential readers to think that its use
> > is right thing to do.
>
> Excuse me, but that is bullshit.
>

I fail to see how either of these last comments add anything
substantial to this debate. :-( So let me try to get us past
this point.

Earlier Waldek wrote:

> The problem I see in writing
>
> make AX_FLAGS
>
> (as opposed to)
>
> AX_FLAGS make

[ which defines process environment variabes thar are inherited
as variables in 'make' ]

>
> is that we override thing in Makefile. But we are effectively
> "broadcasting" AX_FLAGS down which looks like abuse of
> mechanizm designed for something else (that is allowing
> default in Makfile but sometimes taking alternate values).

Reading

http://www.gnu.org/software/make/manual/make.html#Overriding
http://www.gnu.org/software/make/manual/make.html#Override-Directive

it seems to support the notion that passing arguments to make
is intended to suport overriding of default values. I agree
that it could potentially lead to confusion because any values
of these variables set locally in the make file are ignored
unless they are explicitly coded as 'override'. And the information
about which variables these are is not available locally in the
make file but rather determined by how the make file is called.

Gaby annouced 'var-def.mk' in 'ChangeLog.build-improvements':

> 2006-08-26  Gabriel Dos Reis  Gabriel Dos Reis
>
>        * config/var-def.mk: New file.  Hold boileplate definition
>        of standard Autoconf/Automake variables.
> ...

The GNU coding standards include conventions for Makefile
variables:

http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html#Mak=
efi
le-Conventions

And AX_FLAGS was introduced here:

> 2006-12-06  Gabriel Dos Reis  Gabriel Dos Reis
>
>        * config/var-def.mk (AXIOM, DAASE, SYS): Don't export
>        through GNU Make extension "export".
>        (AX_FLAGS): New.  Use for "exporting" variables.
> ...

But var-def.mk has also been extended to include axiom-specific
variables. For example in 'var-def.mk' we find:

  ## Where to find Axiom data bases.
  DAASE = $(axiom_src_datadir)

In  ChangeLog.build-improvements there is some evidence that
Gaby has already started to use 'var-def.mk' in the manner
suggested by Waldek:

> 2006-12-09  Gabriel Dos Reis  Gabriel Dos Reis
>
>        * config/var-def.mk (AX_FLAGS): Don't pass DAASE.

I think that Waldek is claiming that all variables should be
handled this way and that passing AX_FLAGS is unnecessary, thus
permitting all make variables to potentially be overriden.

Gaby, do you see any conflict between what Waldek is suggesting
and your current approach? Or do you see AX_FLAGS as serving
some other purpose not properly addressed by 'var-def.mk'?

\start
Date: Mon, 30 Apr 2007 01:56:36 -0500 (CDT)
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: AX_FLAGS  axiom: [508]branches/wh-sandbox)

On Mon, 30 Apr 2007, Bill Page wrote:

> > Waldek Hebisch wrote:
> > ...
> > > My basic objection is that AX_FLAGS is redundant.
> > > We already have mechanizm to propagate values to
> > > subdirectories: we use var-def.mk.
> > > So AX_FLAGS establishes parallel chanel, which has
> > > significant potential for bugs and confusion.
> > 
> 
> Gabriel Dos Reis wrote:
> 
> > The purpose of AX_FLAGS is not to propagate values to
> > subdirectories. The purpose of AX_FLAGS is to propagate
> > values to *sub-processes*, much like MAKEFLAGS.
> 
> I think there is no substantive difference between
> "propagate to subdirectories" and "propogate to sub-
> processes" since I do not know what the former expression
> could mean if not the latter.

I understand propagating to subdirectories means that Makefile in
subdirectories see the value of the variable.  Propagating to sub-processes
means that processes launched by Make either directly or recursively see the
value of the variable.  That is not the same thing.  
Granted the version of Axiom build-improvements branched from was using the
latter to simulate the former in most cases, but there is a distinction to be
made ansd config/var-def.mk was partlt created to address that.


> It seems clear to me that
> provided the information is static (i.e. determined at
> configure-time) it could be communicated to sub-processes
> by either mechanism.

If you define the variable only in the Makefile, you don't communicate it to
sub-processes. 

[...]

> > The problem I see in writing
> >
> > make AX_FLAGS
> > 
> > (as opposed to)
> > 
> > AX_FLAGS make
> 
> [ which defines process environment variabes thar are inherited
> as variables in 'make' ]

Notice that if you do either of those, you are communicating variables to
sub-processes.

> > 
> > is that we override thing in Makefile. But we are effectively
> > "broadcasting" AX_FLAGS down which looks like abuse of
> > mechanizm designed for something else (that is allowing
> > default in Makfile but sometimes taking alternate values).
> 
> Reading 
> 
> http://www.gnu.org/software/make/manual/make.html#Overriding
> http://www.gnu.org/software/make/manual/make.html#Override-Directive
> 
> it seems to support the notion that passing arguments to make
> is intended to suport overriding of default values. I agree
> that it could potentially lead to confusion because any values
> of these variables set locally in the make file are ignored
> unless they are explicitly coded as 'override'.

Before people start pulling out big words like "override" and "confusing",
they should probably look at the variables being passed in AX_FLAGS and 
elaborate on why they believe that any value set locally is ignored and why we
should not do that.

[...]

> And AX_FLAGS was introduced here:
> 
> > 2006-12-06  Gabriel Dos Reis  Gabriel Dos Reis
> >
> >        * config/var-def.mk (AXIOM, DAASE, SYS): Don't export
> >        through GNU Make extension "export".
> >        (AX_FLAGS): New.  Use for "exporting" variables.
> > ...
> 
> But var-def.mk has also been extended to include axiom-specific
> variables. For example in 'var-def.mk' we find:
> 
>   ## Where to find Axiom data bases.
>   DAASE = $(axiom_src_datadir)

Some variables like AXIOM, DAASE, SYS, etc. need to be visible to
sub-processes (e.g. AXIOMsys), not just Make.  A "natural" way to do 
that is to declare them exported.  Ideally, I would like to see that piece of 
information declared in one place once for all.  The version of Axiom
build-improvements branched off used the ENV variable, which proved to be
problematic under some circumstances.  Then I spend trimming down the content
of that variable: many of them did not need to be exported.  They were moved
to config/var-def.mk which I also created to hold variables that should be
present in each Makefile.  At some point, in a quick hack, I used the GNU Make 
extension "export" for some variables that truly need to be exported to
sub-processes.  When testing on *BSD and solaris, I removed the use of
that extension.  At that time, I still had a hope that we could cramm the
makefiles so that it could work with several Make programs.

Please note that, at the exception of NOISE, none of the involved variable is
one that will be set by user at whim.  In fact, they are things the user
should not even know about.  I would like to eliminate NOISE.

Please, also note that just setting those variables in the Makefile is not
sufficient.  They need to be exported.

As of today, we have two variables are passed in AX_FLAGS: SYS amd NOISE.
They are all variables I would like to see them removed.  SYS, because there
ought to be a better way of communicating the information we want to pass in
and a better way to read it on the other side; NOISE, because there ought to
be better way to selectively display information, but at the current
development stage it seems like one almost always need that verbosity.
In all cases, they are *implictly* passed to sub-processes and that is
faithful to the idea that they need NOT be emphasized.

That is remarkably different from the uses of AXIOM and DAASE in the
Makefile.  They are not exported through GNU Make "export", but rather set on
the commandline that invokves the specific program they affect:  AXIOMsys.  
I also found that, just declaring AXIOM and DAASE as exported is not
sufficient; at some occasions they need to be set to different values.
Consequently, I concluded that setting them on the command line for AXIOMsys
is a better thing to do.

Please notice that I do not invoke make as

   AXIOM=...  DAASE=... make ...

because I don't think that is the appropriate thing to do.  Those variables
affect only AXIOMsys and depsys.  They are scheduled for disappearance (though
I plan communicating them through AXIOMsys options).

> 
> In  ChangeLog.build-improvements there is some evidence that
> Gaby has already started to use 'var-def.mk' in the manner
> suggested by Waldek:
> 
> > 2006-12-09  Gabriel Dos Reis  Gabriel Dos Reis
> >
> >        * config/var-def.mk (AX_FLAGS): Don't pass DAASE.
> 
> I think that Waldek is claiming that all variables should be
> handled this way and that passing AX_FLAGS is unnecessary, thus
> permitting all make variables to potentially be overriden.

Why would you ever want to override SYS?

> 
> Gaby, do you see any conflict between what Waldek is suggesting
> and your current approach? Or do you see AX_FLAGS as serving
> some other purpose not properly addressed by 'var-def.mk'?

Please see above.  The only sensible thing to do (that I planeed to do but was
lowe priority) is to remove NOISE and restructrure some Boot files.
I don't think anything in AX_FLAGS needs to be potentially overriden.
I hope you see why I think AX_FLAGS should either disappear along with the
variables it communicates

\start
Date: Mon, 30 Apr 2007 11:55:47 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: noweb tarball
Cc: Gabriel Dos Reis

Bill Page wrote:
> On April 27, 2007 8:52 AM Waldek Hebisch wrote:
> > 
> > Let me restate my position: in general I am against putting
> > souces of prerequisities (especially as tarballs, but
> > unpacked form is also bad) in Axiom svn repositiry.  Of
> > course, sometimes we want to make an exception but I do not
> > see any reason in case of noweb.  But this does not exclude
> > having helper code which make use of prerequisities easier.
> > 
> 
> In principle I agree with this, however where should this
> "helper code" look for the tarball? And what name?
> 
> Your revision 517 uses:
> 
> +	  $(TAR) -zxf $(axiom_optional_srcdir)/noweb-2.10a.tgz && \
> 
> ...
> 
> +                yes) if test -f $axiom_top_srcdir/zips/noweb-2.10a.tgz ;
> then
> +                         axiom_build_noweb=yes
> +                     else
> +                         { { echo "$as_me:$LINENO: error:
> --with-included-noweb specified, but no noweb sources is present" >&5
> +echo "$as_me: error: --with-included-noweb specified, but no noweb sources
> is present" >&2;}
> +   { (exit 1); exit 1; }; }
> 
> and we have:
> 
> I suppose it is better to write:
> 
> +                yes) if test -f $axiom_optional_srcdir/noweb-2.10a.tgz ;
> then
> 
> In config/var-def.mk we have:
> 
>   axiom_optional_srcdir = $(abs_top_srcdir)/zips
>

ATM axiom_optional_srcdir is not available in configure, so we would
have to set it in configure and propagate to config/var-def.mk
 
> "with-included-noweb" implies to me that it is included, but
> you expect someone to copy 'noweb-2.10a.tgz' into the Axiom
> source distribution which seems awkward to me. Of course
> there is no "standard" place to look for such source files
> on Linux, but varies from one Linux distribution to the next
> and apparently from one project to the next.
> 
> Also, note the 'noweb-2.10a.tgz' is not the current version
> of noweb. See:
> 
> http://www.eecs.harvard.edu/~nr/noweb/dist
> 
> I suppose that these problems might be solved by an appropriate
> configure parameter, e.g.
> 
>   --with-noweb-src=/home/bpage/noweb-2.11b.tgz
> 
> But should we be concerned about supporting different releases
> of noweb if Norman Ramsey should decide to slightly change
> the method of building noweb with a new release?
>

My intention is that somebody can collect Axiom and its prerequisities
and make a source distribution which should be easy to build on
large set of platforms.  Maker of such distribution can use
different noweb version with different name: changing name is
trivial (while hooking noweb build to Axiom is not so trivial).

\start
Date: Mon, 30 Apr 2007 05:50:25 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: noweb tarball

On Mon, 30 Apr 2007, Waldek Hebisch wrote:

> > In config/var-def.mk we have:
> > 
> >   axiom_optional_srcdir = $(abs_top_srcdir)/zips
> >
> 
> ATM axiom_optional_srcdir is not available in configure, so we would
> have to set it in configure and propagate to config/var-def.mk

If axiom_optional_srcdir has value other than $(abs_top_srcdir)/zips, 
then I think you must be considering a different variable.

\start
Date: Mon, 30 Apr 2007 13:27:03 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: clweb, array-to-string

> Can 
>   (array-to-string ar)
> be rewritten as
>   (coerce ar 'string)
> 

If you ask about code I wrote the answer is no: I used arrays
of bytes (to avoid unicode overheads) and such array can not be
coerced to string.

\start
Date: Mon, 30 Apr 2007 13:42:54 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: noweb tarball

Gabriel Dos Reis wrote:
> On Mon, 30 Apr 2007, Waldek Hebisch wrote:
> 
> > > In config/var-def.mk we have:
> > > 
> > >   axiom_optional_srcdir = $(abs_top_srcdir)/zips
> > >
> > 
> > ATM axiom_optional_srcdir is not available in configure, so we would
> > have to set it in configure and propagate to config/var-def.mk
> 
> If axiom_optional_srcdir has value other than $(abs_top_srcdir)/zips, 
> then I think you must be considering a different variable.
> 

I am open to suggestions here but I do not understand in which direction
you are heading.  

IIUC Bill was pointing out that the code I commited in two different
placed contained location of noweb sources -- that can be avoided
propagating value from configure via config/var-def.mk.

I had intended to just use $(abs_top_srcdir)/zips (without change),
but appearently Bill wants more flexibility.

\start
Date: Mon, 30 Apr 2007 14:18:15 +0200 (CEST)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: Re: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox)

Gabriel Dos Reis wrote
> As of today, we have two variables are passed in AX_FLAGS: SYS amd NOISE.
> They are all variables I would like to see them removed.  SYS, because there
> ought to be a better way of communicating the information we want to pass in
> and a better way to read it on the other side; NOISE, because there ought to
> be better way to selectively display information, but at the current
> development stage it seems like one almost always need that verbosity.
> In all cases, they are *implictly* passed to sub-processes and that is
> faithful to the idea that they need NOT be emphasized.
> 
> That is remarkably different from the uses of AXIOM and DAASE in the
> Makefile.  They are not exported through GNU Make "export", but rather set on
> the commandline that invokves the specific program they affect:  AXIOMsys.  
> I also found that, just declaring AXIOM and DAASE as exported is not
> sufficient; at some occasions they need to be set to different values.
> Consequently, I concluded that setting them on the command line for AXIOMsys
> is a better thing to do.
>

Yes.  ATM wh-sandbox still exports AXIOM and DAASE, but in my experimental
database bootstrap I need different values on each interpsys invocation
(AXIOMsys is created later).

  Bill Page wrote: 
> > 
> > Gaby, do you see any conflict between what Waldek is suggesting
> > and your current approach? Or do you see AX_FLAGS as serving
> > some other purpose not properly addressed by 'var-def.mk'?
> 
> Please see above.  The only sensible thing to do (that I planeed to do but was
> lowe priority) is to remove NOISE and restructrure some Boot files.
> I don't think anything in AX_FLAGS needs to be potentially overriden.
> I hope you see why I think AX_FLAGS should either disappear along with the
> variables it communicates
> 

I am confused by this long message.  Does the above mean that you
agree with removal of AX_FLAGS?  Or do you consider change in NOISE
functionality a blocker?

\start
Date: Mon, 30 Apr 2007 08:21:03 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: noweb tarball

On Mon, 30 Apr 2007, Waldek Hebisch wrote:

> Gabriel Dos Reis wrote:
> > On Mon, 30 Apr 2007, Waldek Hebisch wrote:
> > 
> > > > In config/var-def.mk we have:
> > > > 
> > > >   axiom_optional_srcdir = $(abs_top_srcdir)/zips
> > > >
> > > 
> > > ATM axiom_optional_srcdir is not available in configure, so we would
> > > have to set it in configure and propagate to config/var-def.mk
> > 
> > If axiom_optional_srcdir has value other than $(abs_top_srcdir)/zips, 
> > then I think you must be considering a different variable.
> > 
> 
> I am open to suggestions here but I do not understand in which direction
> you are heading.  

Ideally, we should remove the zips/ directory.

If you want to add support for out of source infrastructure, I think
the natural way to do that is to use one of the --with-xxxx switch, e.g.

    --with-noweb-srcdir=/path/to/noweb/source

then you can propogate that value from within configure.

I suspect that matches what Bill wants.

I should observe that unless noweb's Makefile is supposed to stay the same
over releases, you may be heading into a quagmire

\start
Date: Mon, 30 Apr 2007 08:26:24 -0500 (CDT)
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: AX_FLAGS (was: [Axiom-commit] SF.net SVN: axiom: [508]branches/wh-sandbox)

On Mon, 30 Apr 2007, Waldek Hebisch wrote:

> > Please see above.  The only sensible thing to do (that I planeed to do but was
> > lowe priority) is to remove NOISE and restructrure some Boot files.
> > I don't think anything in AX_FLAGS needs to be potentially overriden.
> > I hope you see why I think AX_FLAGS should either disappear along with the
> > variables it communicates
> > 
> 
> I am confused by this long message.  Does the above mean that you
> agree with removal of AX_FLAGS?

AX_FLAGS should go away only when the variables it passes to sub-processes
also go away (not just by setting them in the Makefile).  I have explained 
what that flag does.  Just setting the variables in Makefile is
no better than using AX_FLAGS which encapsulates them.  
SYS is snicky but not hard.  NOISE needs more restructing, but is lower
priority for me.  

\start
Date: Mon, 30 Apr 2007 17:52:35 -0500
From: Tim Daly
To: Cliff Yapp
Subject: process and bibtex

Please copy the list. 

Just send updates as you get them. I read the document you gave me at
ECCAD and built the literate version you sent. I still have about 30
more iterations of Axiom builds before I've run merged and tested the
current queued changes so it will be a while yet.

I'm looking at a version that will run under GCL but keeping your
original for the future ANSI version. I want to set up one file
in the next release that builds using a version of clweb so we
can experiment.

We can use Beebe's bibtex file. Tell me what bibtex commands
you'd like to have happen with clweb, what files are involved,
and I'll put it into the build.

\start
Date: Mon, 30 Apr 2007 18:10:48 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: process and bibtex


--- Tim Daly wrote:

> Please copy the list. 

Opps.  Sorry about that.

> Just send updates as you get them. I read the document you gave me at
> ECCAD and built the literate version you sent.

Thanks!  By my estimate in another day or two I will have a version I'm
willing to post to the list.

> I still have about 30
> more iterations of Axiom builds before I've run merged and tested the
> current queued changes so it will be a while yet.

OK.

> I'm looking at a version that will run under GCL but keeping your
> original for the future ANSI version. I want to set up one file
> in the next release that builds using a version of clweb so we
> can experiment.

OK.  That will require the other half of noweb - translation to valid
LaTeX.  Hmm.  Letssee...

> We can use Beebe's bibtex file. Tell me what bibtex commands
> you'd like to have happen with clweb, what files are involved,
> and I'll put it into the build.

The latex part is nothing fancy:

latex cl-web-v0.5.lisp.tex
bibtex cl-web-v0.5.lisp
latex cl-web-v0.5.lisp.tex
latex cl-web-v0.5.lisp.tex

The files needed are:
http://www.math.utah.edu/pub/tex/bib/litprog.bib
and a required style file:
http://www.math.utah.edu/pub/tex/bib/bibnames.sty

The former is explicitly public domain, the latter has no license or
copyright statement at all - I doubt it would be a problem to use it
but I should drop him an email to be sure.  I'm currently using a test
bst file but I'll switch it over to the plain one - no point in
tackling too many issues at once.

That's a point, actually - is there a bibtex style file that folks
would regard as the "best" style to use for Axiom pamphlets?

The graphic for the finite state diagram I suspect needs to remain in
postscript format, as we don't want to add graphviz to the build
requirements.  I'm not quite sure how to handle that - perhaps include
the dot source as an appendix?

The command, for the record, is:

dot -Tps -o finite-state-tangle.ps finite-state-tangle.dot

I'd still like to find some way of organizing the bibliography so it is
viewable by category, but doing so is highly non-trivial.  The primary
difficulty with not doing so is finding a way to quickly answer the
questions "does Axiom's bibliography already have this paper in it" and
"if it does, what is the string I use to cite it?"  I suppose that's a
problem for an editor more than anything - my admittedly crude attempt
to create a system for divvying up the file by PACS and MSC2000
classifications is probably insufficient to cover all the needed
categories, and the ACM Computing Classification System (1998) is
copyrighted with usage terms that clearly would require specific
permission to use it in something like this.  (MSC2000 and PACS don't
seem to say much about it one way or the other.)  What we probably need
in reality is an editor that allows convenient and fast searching of a
very large bibliography by keyword/author/title/etc.

This topic died back a while ago as very little truly literate work has
been going on, but now that it's come up again can anyone recommend
tools for dealing efficiently with very large bibliographies?



