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

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: 04 Jun 2003 17:42:05 -0400
From: Camm Maguire
To: list
Subject: Re: Value stack overflow bug
cc: Gilbert Baumslag

Greetings!  Just wanted to check how this is going.  I've just tried
multiplying the VSSIZE in h/gclincl.h.in by four, and I seem to be
getting further along.  I forgot to do the *print-readably*, so am
retrying with that now.

Tim Daly writes:

> I've been chasing a very difficult bug for several months and
> I recently achieved a breakthru. Unfortunately it isn't a happy
> result. 
> 
> The nature of the bug is that several hundred of the thousand+
> algebra compiles die because of a "value stack overflow". I've 
> been micro-stepping the compiler (you REALLY begin to appreciate
> what a billion instructions per second mean :-) ). Since this
> is "known correct" code in some sense the bug must have something
> to do with the lisp but it has to be proven.
> 
> Originally I tried playing with the memory allocations using 
> init-memory-config but that had no effect. Schelter had introduced
> init-memory-config for Axiom because we wrestled this problem before.
> 
> Later I tried using (setq si::*multiply-stacks* 16) at system build
> time but that also had no effect. However the "no effect" was
> subtle. I read the code and it appears that this setq can only be done
> at the top level command prompt (for obvious reasons). The larger
> stacks are NOT saved using save-system so they cannot be saved into an
> image. Nor can they be automatically expanded in an Axiom image as you
> never enter the top level REP loop.
> 
> I worked under the assumption that the larger stacks WERE saved
> in the image and thus never saw the benefit which led me to the
> conclusion that it was still an Axiom bug and thus continued to
> chase it by hand.
> 
> Tonight I set out to rebuild Axiom's databases to try to eliminate
> them as the source of the failure. The database build also failed
> with a Value stack overflow. So I built a complete system by 
> hand-loading each routine into a clean lisp. It still failed with
> a value stack overflow. So I restarted lisp, setq'd the *multiply-stacks*
> variable at the command prompt and reloaded Axiom one routine at a time.
> This time the database build died with a Segmentation Violation.
> 
> Ah Ha! Rebuilding the databases is a stand-alone program that is
> completely independent of the compiles. Now there are two paths that
> fail due to Value stack overflow. Expanding the stacks (successfully
> this time) causes a segfault.
> 
> The same behavior happens in GCL 2.4.1 and GCL 2.5.2
> 
> So, the conclusions? 
> (1) GCL's default value stack size is too small to handle Axiom
> (2) The (setq si::*multiply-stacks* n) method
>     (a) can't be used to build Axiom's images
>     (b) causes a memory failure with a setfault
> (3) I need some way to hardcode a larger value stack size during
>     GCL image build. It looks like setting VSSIZE is the correct
>     method but I can't (yet) figure out where this should be
>     changed as it is #included in some obscure way.
> 
> Please help.

\start
Date: 04 Jun 2003 17:38:33 -0400
From: Camm Maguire
To: list
Subject: Re: Value stack overflow bug
cc: Gilbert Baumslag

Greetings!  Just wanted to check how this is going.  I've just tried
multiplying the VSSIZE in h/gclincl.h.in by four, and I seem to be
getting further along.  I forgot to do the *print-readably*, so am
retrying with that now.

Tim Daly writes:

> I've been chasing a very difficult bug for several months and
> I recently achieved a breakthru. Unfortunately it isn't a happy
> result. 
> 
> The nature of the bug is that several hundred of the thousand+
> algebra compiles die because of a "value stack overflow". I've 
> been micro-stepping the compiler (you REALLY begin to appreciate
> what a billion instructions per second mean :-) ). Since this
> is "known correct" code in some sense the bug must have something
> to do with the lisp but it has to be proven.
> 
> Originally I tried playing with the memory allocations using 
> init-memory-config but that had no effect. Schelter had introduced
> init-memory-config for Axiom because we wrestled this problem before.
> 
> Later I tried using (setq si::*multiply-stacks* 16) at system build
> time but that also had no effect. However the "no effect" was
> subtle. I read the code and it appears that this setq can only be done
> at the top level command prompt (for obvious reasons). The larger
> stacks are NOT saved using save-system so they cannot be saved into an
> image. Nor can they be automatically expanded in an Axiom image as you
> never enter the top level REP loop.
> 
> I worked under the assumption that the larger stacks WERE saved
> in the image and thus never saw the benefit which led me to the
> conclusion that it was still an Axiom bug and thus continued to
> chase it by hand.
> 
> Tonight I set out to rebuild Axiom's databases to try to eliminate
> them as the source of the failure. The database build also failed
> with a Value stack overflow. So I built a complete system by 
> hand-loading each routine into a clean lisp. It still failed with
> a value stack overflow. So I restarted lisp, setq'd the *multiply-stacks*
> variable at the command prompt and reloaded Axiom one routine at a time.
> This time the database build died with a Segmentation Violation.
> 
> Ah Ha! Rebuilding the databases is a stand-alone program that is
> completely independent of the compiles. Now there are two paths that
> fail due to Value stack overflow. Expanding the stacks (successfully
> this time) causes a segfault.
> 
> The same behavior happens in GCL 2.4.1 and GCL 2.5.2
> 
> So, the conclusions? 
> (1) GCL's default value stack size is too small to handle Axiom
> (2) The (setq si::*multiply-stacks* n) method
>     (a) can't be used to build Axiom's images
>     (b) causes a memory failure with a setfault
> (3) I need some way to hardcode a larger value stack size during
>     GCL image build. It looks like setting VSSIZE is the correct
>     method but I can't (yet) figure out where this should be
>     changed as it is #included in some obscure way.

\start
Date: Wed, 4 Jun 2003 21:44:42 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Value stack overflow bug
cc: Gilbert Baumslag

Camm,

I rebuilt the lisp (gcl-2.5.2) with a larger VSSIZE and rebuilt the axiom 
image but it turned out not to be the issue. I've finally solved the
make-database problem and can now reliably construct the multiple
databases. All of the underlying lisp problems appear to have been
solved. I've moved from 2.4 to 2.5.2 as the standard lisp. I solved
the *print-escape* problem (aka the *print-readably* problem) by
recoding the offending routines so they now work per the new language
standard. I've also reworked the *in-package* issue so it should now
work correctly in 2.5.2.

Unfortunately I've not yet solved the compile problem. Essentially the
issue is as follows: It was always the case that you needed a running
Axiom system to build a runnable Axiom system. I've been reworking the
system to fix this (as most people don't have a running Axiom). In order
for this to work you need to be able to bootstrap the Axiom compile
process. So far, though I've flattened a dozen issues, this still
remains unsolved.

This week I'm taking a different, temporary path. I'm building a working
Axiom that can be freely distributed and is derived from the source code.
However, it can't be built from the source code (yet). I hope to have it
available this weekend. I'm doing this for 3 reasons. First, it will
make Axiom available again. Second, it will allow users to generate
bug reports (hopefully one of the bugs will give us the clue to the
compiler problem). Third, some potential bright-spot of a developer
might be able to help with the compiler bug.

I'll let you know as soon as I complete the build, test it, and upload
it to tenkan.

Camm Camm Maguire writes:

> Greetings!  Just wanted to check how this is going.  I've just tried
> multiplying the VSSIZE in h/gclincl.h.in by four, and I seem to be
> getting further along.  I forgot to do the *print-readably*, so am
> retrying with that now.

>> Tim Daly writes:

>> I've been chasing a very difficult bug for several months and
>> I recently achieved a breakthru. Unfortunately it isn't a happy
>> result. 

\start
Date: Thu, 5 Jun 2003 12:00:46 +0200
From: Juergen Weiss
To: list
Subject: Input files

Hello,

in the old axiom distributions, there was a directory
with example and test files (*.input). They have 
not been in the cvs tree. Do they exist or have they
been lost? They could be used as a basis for system
verification.

\start
Date: Thu, 5 Jun 2003 11:20:53 +0100
From: Mike Dewar
To: Juergen Weiss
Subject: Re: Input files

They were in the sources which I sent to Tim.  The set under
development/src/input is richer than the set distributed under mnt and
is what we used to use for regression testing.  There was a top level
inputs directory which contained scripts to run the input files
automatically and compare them with stored results for different
platforms and versions of Axiom.

Mike. 

On Thu, Jun 05, 2003 at 12:00:46PM +0200, Juergen Weiss wrote:
> Hello,
> 
> in the old axiom distributions, there was a directory
> with example and test files (*.input). They have 
> not been in the cvs tree. Do they exist or have they
> been lost? They could be used as a basis for system
> verification.
> 

\start
Date: Thu, 5 Jun 2003 12:20:28 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: Input files

Juergen Weiss wrote:

> in the old axiom distributions, there was a directory
> with example and test files (*.input). They have 
> not been in the cvs tree. Do they exist or have they
> been lost? They could be used as a basis for system
> verification.

Juergen,

Yes, they exist. I'll put them in the tree this weekend.  The source
code consists of more than is in the CVS.  I haven't worked on getting
whole subsets of the system working yet.

The example/testing files will end up in src/input and are run as
regression testing on the algebra before it is shipped.  If you know a
particular area of algebra or develop examples it would be most useful
to have a copy of your input files.
 
If I can get a semi-working algebra system together then I'm going to
move the whole pile over to the savannah site and start using CVS from
that site.

\start
Date: Thu, 5 Jun 2003 23:43:37 -0400
From: Tim Daly
To: Camm Maguire
Subject: elt bug

Camm,

I've found another common lisp bug in gcl-2.5.2. 
To illustrate:

GCL-2.4> (setq a '(+))
GCL-2.4> (elt a 1)

Error: The index, 1, is too large

GCL-2.5.2> (setq a '(+))
GCL-2.5.2> (elt a 1)

Error: 1 is not of type POSITIVE-FIXNUM

\start
Date: Fri, 06 Jun 2003 19:41:15 +0200
From: David Mentre
To: list
Subject: Libre Software Meeting (was: Re: Value stack overflow bug)
cc: Gilbert Baumslag, Camm Maguire

Hello Tim,

Tim Daly writes:

> This week I'm taking a different, temporary path. I'm building a working
> Axiom that can be freely distributed and is derived from the source code.
> However, it can't be built from the source code (yet). I hope to have it
> available this weekend. I'm doing this for 3 reasons. First, it will
> make Axiom available again. Second, it will allow users to generate
> bug reports (hopefully one of the bugs will give us the clue to the
> compiler problem). Third, some potential bright-spot of a developer
> might be able to help with the compiler bug.

Great news. 

By the way, a friend told me that you would probably come to the Libre
Software Meeting, at Metz, France, July 9-12. Can you confirm that you
will come? During which days? 

I'm currently balancing to come or not and for personnal reasons I
probably won't attend the whole conference. So if you come, I'll try to
come at the same date. I think it would be nice to do a small
face-to-face Axiom meeting.

\start
Date: Fri, 6 Jun 2003 20:29:21 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Libre Software Meeting (was: Re: Value stack overflow bug)
cc: Gilbert Baumslag, Camm Maguire

I'm leaving here on July 4, arriving in Metz July 5 and staying until 
July 12th. Most of my pre-conference time is likely to be spent hacking.
I'll be spending one night in a Paris hotel on the way back.

I'd be happy to get together anytime that's convenient for you.

 david.mentre@wanadoo.fr writes:

> Hello Tim,
> 
> Tim Daly writes:
> 
> > This week I'm taking a different, temporary path. I'm building a working
> > Axiom that can be freely distributed and is derived from the source code.
> > However, it can't be built from the source code (yet). I hope to have it
> > available this weekend. I'm doing this for 3 reasons. First, it will
> > make Axiom available again. Second, it will allow users to generate
> > bug reports (hopefully one of the bugs will give us the clue to the
> > compiler problem). Third, some potential bright-spot of a developer
> > might be able to help with the compiler bug.
> 
> Great news. 
> 
> By the way, a friend told me that you would probably come to the Libre
> Software Meeting, at Metz, France, July 9-12. Can you confirm that you
> will come? During which days? 
> 
> I'm currently balancing to come or not and for personnal reasons I
> probably won't attend the whole conference. So if you come, I'll try to
> come at the same date. I think it would be nice to do a small
> face-to-face Axiom meeting.

\start
Date: Fri, 6 Jun 2003 21:44:53 -0400
From: Bill Page
To: list
Subject: RE: Value stack overflow bug

Tim,

On Wednesday, June 04, 2003 9:45 PM you wrote to Camm
Camm Maguire:

> ... 
> Unfortunately I've not yet solved the compile problem. 
> Essentially the issue is as follows: It was always the case 
> that you needed a running Axiom system to build a runnable 
> Axiom system. I've been reworking the system to fix this (as 
> most people don't have a running Axiom). In order for this to 
> work you need to be able to bootstrap the Axiom compile 
> process. So far, though I've flattened a dozen issues, this 
> still remains unsolved.

It seems to me that it is conceivable that one might always
need a running Axiom system in order to (conveniently) build
a runnable Axiom system. This is essentially the case with any
compiler that compiles itself. Most higher level languages are
in this sort of situation today, e.g. the GNU C compiler (gcc)
is written in gcc, right? Of course there might be the possibily
of "cross-compilation", i.e. using Axiom on one platform to
build Axiom on some other platform. And if you were really
ambitious and had a lot of time, one might be able to re-implement
the whole thing in some other language, e.g. the way the "Aldor
part" of Axiom was re-written in C.

A thought: Would using Aldor help to make a runnable Axiom
system?

> 
> This week I'm taking a different, temporary path. I'm 
> building a working Axiom that can be freely distributed and 
> is derived from the source code. However, it can't be built 
> from the source code (yet). I hope to have it available this 
> weekend. I'm doing this for 3 reasons. First, it will make 
> Axiom available again. Second, it will allow users to 
> generate bug reports (hopefully one of the bugs will give us 
> the clue to the compiler problem). Third, some potential 
> bright-spot of a developer might be able to help with the 
> compiler bug.
> 

What would be the problem if you were to take this approach
as the primary path instead of just a temporary one?

\start
Date: Sun, 8 Jun 2003 15:39:28 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Value stack overflow bug

Bill,

Sorry for the delay but I've been heads-down trying to get a
runnable Axiom version.

> > ... 
> > Unfortunately I've not yet solved the compile problem. 
> > Essentially the issue is as follows: It was always the case 
> > that you needed a running Axiom system to build a runnable 
> > Axiom system. I've been reworking the system to fix this (as 
> > most people don't have a running Axiom). In order for this to 
> > work you need to be able to bootstrap the Axiom compile 
> > process. So far, though I've flattened a dozen issues, this 
> > still remains unsolved.
> 
> It seems to me that it is conceivable that one might always
> need a running Axiom system in order to (conveniently) build
> a runnable Axiom system. This is essentially the case with any
> compiler that compiles itself. Most higher level languages are
> in this sort of situation today, e.g. the GNU C compiler (gcc)
> is written in gcc, right? Of course there might be the possibily
> of "cross-compilation", i.e. using Axiom on one platform to
> build Axiom on some other platform. And if you were really
> ambitious and had a lot of time, one might be able to re-implement
> the whole thing in some other language, e.g. the way the "Aldor
> part" of Axiom was re-written in C.

Technically Axiom can't be built from scratch at several levels
because it needs a Meta compiler, a Boot compiler, and an Axiom
compiler (and also a C and a Lisp compiler but they come free).
However, I've worked around most of the problems associated
with bootstrapping the system. Having such circularity is less than
ideal for several reasons not the least of which is that you wouldn't
be able to download sources and type 'make'. The whole system is
very close to being built from scratch. I've been bug-chasing the
remaining bugs but some are very deep and require days worth of
work (indeed, the last reported GCL ELT bug had me recursed 80
levels deep into the system. I thought my mental stack would
overflow :-) ).

> 
> A thought: Would using Aldor help to make a runnable Axiom
> system?
> 
> > 
> > This week I'm taking a different, temporary path. I'm 
> > building a working Axiom that can be freely distributed and 
> > is derived from the source code. However, it can't be built 
> > from the source code (yet). I hope to have it available this 
> > weekend. I'm doing this for 3 reasons. First, it will make 
> > Axiom available again. Second, it will allow users to 
> > generate bug reports (hopefully one of the bugs will give us 
> > the clue to the compiler problem). Third, some potential 
> > bright-spot of a developer might be able to help with the 
> > compiler bug.
> > 
> 
> What would be the problem if you were to take this approach
> as the primary path instead of just a temporary one?

If we were to pursue the aldor route I'd consider scrapping the axiom
interpreter and going to a compile-time only environment.  This has
been discussed several times and it is very, very hard.  Manuel
Bronstein has done some work on this path before.  I don't know of
anyone that would fund such an effort and I don't believe we would get
the research-level expertise for free.

But if I were to even entertain such a huge job (which, believe me,
I'm not) I'd go the other way and grind it all into common lisp
syntax. The ability of a program to read another program as data gives
a "second order" power that is hard in Axiom.

\start
Date: Sun, 8 Jun 2003 16:25:00 -0400
From: Bill Page
To: list
Subject: RE: Value stack overflow bug

Tim,

On Sunday, June 08, 2003 3:39 PM you wrote:
> 
> Sorry for the delay but I've been heads-down trying to get
> a runnable Axiom version.

No problem. I am glad you are taking this route and very
much look forward to the result. It is not my intention to
distract you from this efffort!

> ...
>> It seems to me that it is conceivable that one might always
>> need a running Axiom system in order to (conveniently) build
>> a runnable Axiom system. This is essentially the case with any
>> compiler that compiles itself. Most higher level languages are
>> in this sort of situation today, e.g. the GNU C compiler (gcc)
>> is written in gcc, right?
>> ...
> 
> Technically Axiom can't be built from scratch at several 
> levels because it needs a Meta compiler, a Boot compiler, and 
> an Axiom compiler (and also a C and a Lisp compiler but they 
> come free). However, I've worked around most of the problems 
> associated with bootstrapping the system. Having such 
> circularity is less than ideal for several reasons not the 
> least of which is that you wouldn't be able to download 
> sources and type 'make'.

But this is the *normal* situation for most high level
languages. I cannot just download gcc and type make -
I first must already have a running gcc (presumably older
version) on my system. So I don't see why we should not
expect this of Axiom as well.

> The whole system is very close to being built from scratch.

By "scratch" you mean starting with a running C compiler and
various source codes. First compile GCL, then bootsys, then ...
etc.

Could you (briefly) describe how this process would be
different if you could presume that there was already a
running Axiom system available? Say, for example, that
there was a new version of (some part of) Axiom available
in source code format from CVS plus a running C compiler,
GCL already compiled and running *and* an older version of
Axiom running on the system. What would be the most
convenient and/or most efficient steps to take to compile
and install the new version of the Axiom code?

> ... 
> If we were to pursue the aldor route I'd consider scrapping 
> the axiom interpreter and going to a compile-time only 
> environment.  This has been discussed several times and
> it is very, very hard.  Manuel Bronstein has done some work
> on this path before.  I don't know of anyone that would fund
> such an effort and I don't believe we would get the research-
> level expertise for free.

Perhaps a joint effort with the Aldor people? It is truly
amazing what one can get for free these days ...

> 
> But if I were to even entertain such a huge job (which, 
> believe me, I'm not) I'd go the other way and grind it
> all into common lisp syntax. The ability of a program to
> read another program as data gives a "second order" power
> that is hard in Axiom.
> 

You mean that this is not possible in Axiom, i.e. programs
as data? This is not such a foreign idea in high level
languages any more. For example it is fundamental to
Python and other languages of that genre. You can even find
it in Maple's programming language.

I have nothing against lisp as such. But lisp has been
around a long time and for a lot of different reasons
it has yet to reach it's full potential. I think there
are good reasons why people are still searching for better
higher level languages. Axiom (and Aldor) seem to be moving
in the right direction to me. To return to "just lisp"
seems like a backward step, no?

\start
Date: Mon, 9 Jun 2003 01:40:16 +0200
From: Ayal Pinkus
To: list
Subject: Re: Value stack overflow bug

Hi,

first off, a disclaimer: I am the maintainer of Yacas, a competing CAS 
;-)

>>
>> But if I were to even entertain such a huge job (which,
>> believe me, I'm not) I'd go the other way and grind it
>> all into common lisp syntax. The ability of a program to
>> read another program as data gives a "second order" power
>> that is hard in Axiom.
>>
>
> You mean that this is not possible in Axiom, i.e. programs
> as data? This is not such a foreign idea in high level
> languages any more. For example it is fundamental to
> Python and other languages of that genre. You can even find
> it in Maple's programming language.
>

You don't need to cast the source code into LISP syntax in
order to be able to read a program and manipulate it symbolically.
You can convert the code to internal format while reading (parsing) it.
We do that all the time with Yacas. Yacas code can be compiled, and
the compiler is written in Yacas script code, for instance.

Given an internal format that the interpreter understands (linked lists
perhaps even), the parser is simply responsible for converting it into
internal format. So you can define any syntax you like, and program
using that syntax. I haven't seen Axiom code yet, but it runs on top
of LISP, so I would imagine that is how it works in Axiom?

With Yacas we took the liberty of defining our own programming language,
which can be parsed by a simple operator grammar parser (similar to
what you have in Prolog). The internal structure is LISP however.

I agree that LISP is perhaps not the most pleasant syntax to
program in. You miss the opportunity of designing the programming
language specifically for the task at hand (building a CAS). LISP
does allow you to define your own language on top of it very easily.
I'd go that route in stead of using flat LISP syntax. LISP is a more 
natural
environment for defining your own programming language than say C++, I
believe. Being able to cast algorithms in a syntax that is more 
pleasant to
read is important, from a maintainability perspective. It makes it 
easier for
other developers to start contributing, or to fix bugs.

But that is subjective, just an opinion.

On another note: I saw some of you will be at the Libre Software 
Meeting. Looking
forward to meeting you!

Ayal Pinkus

\start
Date: Sun, 8 Jun 2003 21:18:09 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Value stack overflow bug

> Could you (briefly) describe how this process would be
> different if you could presume that there was already a
> running Axiom system available? Say, for example, that
> there was a new version of (some part of) Axiom available
> in source code format from CVS plus a running C compiler,
> GCL already compiled and running *and* an older version of
> Axiom running on the system. What would be the most
> convenient and/or most efficient steps to take to compile
> and install the new version of the Axiom code?

The normal installation process for users who have Axiom will
amount to downloading the CVS changes and typing make. Axiom
caches everything possible and even optimizes the code based
on the cached information during the 'update' builds. At some
future point the CVS will include a complete, built copy of
Axiom. The agreement with NAG precludes distribution of their
images.

> > ... 
> > If we were to pursue the aldor route I'd consider scrapping 
> > the axiom interpreter and going to a compile-time only 
> > environment.  This has been discussed several times and
> > it is very, very hard.  Manuel Bronstein has done some work
> > on this path before.  I don't know of anyone that would fund
> > such an effort and I don't believe we would get the research-
> > level expertise for free.
> 
> Perhaps a joint effort with the Aldor people? It is truly
> amazing what one can get for free these days ...

It isn't the aldor expertise that is needed but a comprehensive
understanding of the algebra code. The past code is undocumented
(the future code, nopefully, will correct this). Axiom grew up
as a research tool and represented the bleeding edge of computational
math in various areas. I can read the aldor code but it is hard to
infer WHY some algorithms work. (This is true even in the interpreter.
There are 7 parsers. One is a "zipper" parser done by Bill Burge who
wrote a book on parsing. However, the zipper parser is post-book and
is undocumented both in code and in theory.) In order to understand
the challenge pick up a copy of a computer algebra algorithms book
and consider what it would take to either write the code from those
descriptions or write the descriptions given the axiom code. I hope
to see the "book" level of documentation for Axiom. As part of that
effort it would make sense to rewrite the Axiom code in Aldor.

> > 
> > But if I were to even entertain such a huge job (which, 
> > believe me, I'm not) I'd go the other way and grind it
> > all into common lisp syntax. The ability of a program to
> > read another program as data gives a "second order" power
> > that is hard in Axiom.
> > 
> 
> You mean that this is not possible in Axiom, i.e. programs
> as data? This is not such a foreign idea in high level
> languages any more. For example it is fundamental to
> Python and other languages of that genre. You can even find
> it in Maple's programming language.

Yes, it's possible. It's possible in any language. But the unification
of program source code syntax and program data structure syntax
(lists) is a feature of no other language I'm aware of. How often do
you read a program (as data) in Python, operate on it, spit it out as
Python, and execute the result?

> 
> I have nothing against lisp as such. But lisp has been
> around a long time and for a lot of different reasons
> it has yet to reach it's full potential. I think there
> are good reasons why people are still searching for better
> higher level languages. Axiom (and Aldor) seem to be moving
> in the right direction to me. To return to "just lisp"
> seems like a backward step, no?

<RELIGION>

Believe me, nobody I've talked to agrees with me on this so you're in
the majority. But I've worked on a Symbolics machine and I've seen the
future, so to speak. (Imagine a world where you can hit an error, edit
the source, find the failing line of source code, change it, recompile
it, load it, and CONTINUE FROM THE POINT OF FAILURE, all in less than
5 seconds. I used to work that way and it was "just lisp").

Block structured languages need, at minimum, special code
walkers/manipulation tools in order to manipulate the sources.  (Think
of all of the Axiom parsers).  Which is hardly the issue. The real
issue is that languages determine what you can think.  The early
concept of computer algebra comes about with the realization that you
can symbolically differentiate program text.  The current generation
manipulates program text for program proofs.  Lisp minimizes the
distance between the thought and the code.

All of Axiom, including the algebra, compiles to lisp. It is currently
possible to write code in lisp if you understand the magic.

Axiom's language is very close to the algebra which is a huge win.
If you understand the domain you can read the Axiom code directly.
That's the huge benefit of Axiom's language. So it's unlikely to change
any time soon.

Not to worry, this is just a thought experiment anyway.

</RELIGION>

\start
Date: Sun, 8 Jun 2003 21:34:02 -0400
From: Tim Daly
To: Ayal Pinkus
Subject: Re: Value stack overflow bug

Ayal,

> You don't need to cast the source code into LISP syntax in
> order to be able to read a program and manipulate it symbolically.
> You can convert the code to internal format while reading (parsing) it.
> We do that all the time with Yacas. Yacas code can be compiled, and
> the compiler is written in Yacas script code, for instance.
> 
> Given an internal format that the interpreter understands (linked lists
> perhaps even), the parser is simply responsible for converting it into
> internal format. So you can define any syntax you like, and program
> using that syntax. I haven't seen Axiom code yet, but it runs on top
> of LISP, so I would imagine that is how it works in Axiom?

That's exactly how it works. 

> 
> With Yacas we took the liberty of defining our own programming language,
> which can be parsed by a simple operator grammar parser (similar to
> what you have in Prolog). The internal structure is LISP however.
> 
> I agree that LISP is perhaps not the most pleasant syntax to
> program in. You miss the opportunity of designing the programming
> language specifically for the task at hand (building a CAS). LISP
> does allow you to define your own language on top of it very easily.
> I'd go that route in stead of using flat LISP syntax. LISP is a more 
> natural
> environment for defining your own programming language than say C++, I
> believe. Being able to cast algorithms in a syntax that is more 
> pleasant to
> read is important, from a maintainability perspective. It makes it 
> easier for
> other developers to start contributing, or to fix bugs.
> 
> But that is subjective, just an opinion.

Your email arrived while I was composing the last message. See the
religion flame at the end. 

> 
> On another note: I saw some of you will be at the Libre Software 
> Meeting. Looking
> forward to meeting you!

It'll be interesting to meet people face to face.
I'm looking forward to it.

\start
Date: Mon, 9 Jun 2003 13:11:16 +0200
From: Ayal Pinkus
To: list
Subject: Re: Value stack overflow bug

>
> It isn't the aldor expertise that is needed but a comprehensive
> understanding of the algebra code. The past code is undocumented
> (the future code, nopefully, will correct this). Axiom grew up
> as a research tool and represented the bleeding edge of computational
> math in various areas. I can read the aldor code but it is hard to
> infer WHY some algorithms work. (This is true even in the interpreter.
> There are 7 parsers. One is a "zipper" parser done by Bill Burge who
> wrote a book on parsing. However, the zipper parser is post-book and
> is undocumented both in code and in theory.) In order to understand
> the challenge pick up a copy of a computer algebra algorithms book
> and consider what it would take to either write the code from those
> descriptions or write the descriptions given the axiom code. I hope
> to see the "book" level of documentation for Axiom. As part of that
> effort it would make sense to rewrite the Axiom code in Aldor.
>

I think it is great that Axiom is striving to document the algorithms
used. That is in part what people are interested in. They would want
to know how it works, but also be able to use the algorithms.

I have had a look at Maxima, largely undocumented terse code.
Computer algebra algorithms are far from trivial. They are not
the kinds of algorithms where you can just look at the code and
figure out what is going on. I'd imagine the "zipper" code you mention
is another beast; parsers are not very complex, but it might be
highly optimized code, which becomes unreadable again (?)
For a system to become maintainable documentation is needed
very much. Ideally, the next generation needs to be able to pick
the system up and maintain it.

Yacas has a similar aim, documenting algorithms that can be
used for CAS purposes. I hope we can collaborate on this
maybe, somehow, by sharing information. I think no one wants
to abandon their project they have already put so much effort
in, but sharing information could benefit everybody.

On a side note, it is a bit intimidating to see a CAS that has been
30 years in development become available ;-) But there is
room for different systems, even if only so users of the systems
can verify their calculations by using different systems.
And strengths between the systems probably differ.

Another question, perhaps a bit of a newbie question: is
the code available through cvs? I tried to find it but to no
avail. (Tenkan? Maybe its cvs server was down when i tried).
Is it top secret? It would be just out of curiosity.

\start
Date: Mon, 9 Jun 2003 08:08:28 -0400
From: Tim Daly
To: Ayal Pinkus, Tim Daly Jr.
Subject: source access

Tim,

Could you give Ayal Pinkus access to the Axiom cvs on tenkan?

Tim 

Ayal,

> Another question, perhaps a bit of a newbie question: is
> the code available through cvs? I tried to find it but to no
> avail. (Tenkan? Maybe its cvs server was down when i tried).
> Is it top secret? It would be just out of curiosity.

Top secret? Heaven forbid. No, it's available to developers at
the moment because it is not yet ready to release due to bugs.
However people on the axiom-developer list can get at it. The
source cvs currently lives on tenkan.org. Once it gets debugged
enough it will move to savannah. 

You should hear from the tenkan admin (also named Tim Daly but
not me) soon. 

\start
Date: 09 Jun 2003 16:11:48 -0400
From: Camm Maguire
To: list
Subject: Re: elt bug

Greetings, and thanks for your report!  Is your problem with the error
message?  This is indeed listed as a fixme in the code, and is only
done this way for now to signal the correct type of error.  I can give
you a patch if this is the case.

Or are you perhaps expecting a '+' as answer here?  I believe that
would be (elt a 0).

        Take care,

Tim Daly writes:

> Camm,
> 
> I've found another common lisp bug in gcl-2.5.2. 
> To illustrate:
> 
> GCL-2.4> (setq a '(+))
> GCL-2.4> (elt a 1)
> 
> Error: The index, 1, is too large
> 
> GCL-2.5.2> (setq a '(+))
> GCL-2.5.2> (elt a 1)
> 
> Error: 1 is not of type POSITIVE-FIXNUM

\start
Date: Mon, 9 Jun 2003 17:00:02 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: elt bug

Camm,

The error message is wrong. In particular it caused me several days
of effort to find as Axiom type-optimizes it's code and can throw
a valid message saying " ... is not of type POSITIVE-FIXNUM". A more
useful message would include the function name as well as the failure
as in:
  ELT: The index, 1, is larger than the sequence bound.

Please show me where to patch the code and I'll fix it.

\start
Date: Tue, 10 Jun 2003 19:58:12 +1000
From: Jason White
To: list
Subject: Re: source access

 > 
 > Ayal,
 > 
 > > Another question, perhaps a bit of a newbie question: is
 > > the code available through cvs? I tried to find it but to no
 > > avail. (Tenkan? Maybe its cvs server was down when i tried).

For those who want read-only access, try
:pserver:anonymous@www.tenkan.org:/home/cvs
and checkout axiom (no password required).

Incidentally, I agree with Tim that it should be possible to download
the sources to Axiom and GCL, type `make' and get a working binary
without having a running Axiom system beforehand. As Tim says he has
done most of the work already, this also seems the clearest path to
success, especially with a view toward portability. Obviously this is
a decision for the developers to make, but if there is no
architectural reason to the contrary, I think the build process should
be made to work as Tim envisages.

\start
Date: Tue, 10 Jun 2003 14:06:40 +0200
From: Juergen Weiss
To: Jason White
Subject: RE: source access

Actually the most difficult part of the build process -- to
handle the dependencies of the algebra sources has already
dealt with by Tim Daly. With a few precompiled (to lisp source)
modules, it is possible to compile all the algebra. (I don't
now, if it's possible to do it without the precompiled 
modules -- but that would be quite a bit of work and it's
questionable that it's worth the effort: one would have
to write some skeleton algebra modules, probably one would have
to fix the bootstrap mode of the algebra compiler and devise
a complicated iterative method to get the core algebra 
files compiled).

The current problem lies with gcl. With cmucl I was able to
compile all the algebra files and get a working algebra
system.

So there is nothing in principle and practice against generating
an axiom system with a simple call to make. There is a
problem with the gcl system which must be fixed. As far I can
see from the discussion in this list, it seems to be related
to the number of arguments in a function call or something similar. 
Akcl had to be customized even 10 years ago to run axiom. I think,
I did that once for akcl on sparc sunos 4.1. But I fear I cannot
remember the details. This problem is triggered by the axiom
compiler, which compiles algebra files to lisp, not the axiom 
runtime system. So Tim Daly wants to translate the files to
lisp on another system and distribute the translated lisp files
as a first measure. So one could get a working axiom runtime
system -- at first without the ability to compile the algebra files.

Other paths would be to use another lisp system, cmu cl for
example. Getting a core system with cmu cl is not so difficult
(I have one), but getting all the functionality (graphics,
hyperdoc etc.) requires some work. Because I'm mainly interested
in the algebra, that did not matter to me.

> -----Original Message-----
> From: Jason White
> Sent: Tuesday, June 10, 2003 11:58 AM
> To: list
> Subject: Re: source access
> 
> 
>  > 
>  > Ayal,
>  > 
>  > > Another question, perhaps a bit of a newbie question: is
>  > > the code available through cvs? I tried to find it but to no
>  > > avail. (Tenkan? Maybe its cvs server was down when i tried).
> 
> For those who want read-only access, try
> :pserver:anonymous@www.tenkan.org:/home/cvs
> and checkout axiom (no password required).
> 
> Incidentally, I agree with Tim that it should be possible to download
> the sources to Axiom and GCL, type `make' and get a working binary
> without having a running Axiom system beforehand. As Tim says he has
> done most of the work already, this also seems the clearest path to
> success, especially with a view toward portability. Obviously this is
> a decision for the developers to make, but if there is no
> architectural reason to the contrary, I think the build process should
> be made to work as Tim envisages.

\start
Date: Tue, 10 Jun 2003 22:53:05 +0200
From: Juergen Weiss
To: list
Subject: Value stack problem

Hi,

I had a look at the value stack problem. I extended VSSIZE to
over 80000. I'm not sure, but I think I could compile ALIST,
which could not be compiled before. But FS gave a value stack
overflow. Debugging with (use-fast-links nil), it seems
that when the function mainKernel is compiled, there is an
infinite recursion in the |extendsCategoryForm| function.
For example
start interpsys
)lisp (use-fast-links nil)
)set break break
)co FS

after the compiler is loaded, type ^C
(trace |extendsCategoryForm|)
:r

A stacktrace shows the infinite recursion

#546   extendsCategoryForm
{domain=s,form=(|UniqueFactorizationDomain|),form'=(|Field|)} =
[ihs=133]
#547   extendsCategoryForm
{domain=s,form=(|EuclideanDomain|),form'=(|Field|)} [ihs=132]
#548   extendsCategoryForm
{domain=s,form=(|UniqueFactorizationDomain|),form'=(|Field|)} =
[ihs=131]
#549   extendsCategoryForm
{domain=s,form=(|EuclideanDomain|),form'=(|Field|)} [ihs=130]
#550   extendsCategoryForm
{domain=s,form=(|UniqueFactorizationDomain|),form'=(|Field|)} =
[ihs=129]
#551   extendsCategoryForm
{domain=s,form=(|EuclideanDomain|),form'=(|Field|)} [ihs=128]
#552   extendsCategoryForm
{domain=s,form=(|UniqueFactorizationDomain|),form'=(|Field|)} =
[ihs=127]
#553   extendsCategoryForm {domain=s,form=(|FunctionSpace|
r),form'=(|Field|)} [ihs=126]
#554   extendsCategoryForm {domain=s,form=(|FunctionSpace|
r),form'=(|Join| (|Field|) (category |domain| (s...} [ihs=125]
#555   coerceHard {t$=(s (|FunctionSpace| r) ((#))),m=(|Join| =
(|Field|)
(category |domain| (signat...} [ihs=124]
#556   coerce {t$=(s (|FunctionSpace| r) ((#))),m=(|Join| (|Field|)
(category |domain| (signat...} [ihs=123]
#557   convert {t$=(s (|FunctionSpace| r) ((#))),m=(|Join| (|Field|)
(category |domain| (signat...} [ihs=122]
#558   compAtom {x=s,m=(|Join| (|Field|) (category |domain| =
(signature
|coerce| #) ...)),e=(((# ...} [ihs=121]

With cmu cl there is no infinite recursion, the recursive call to
extendsCategoryForm
terminates at some point.

\start
Date: Tue, 10 Jun 2003 17:49:56 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: Value stack problem

re: CMUCL vs GCL

Yes, it appears that there is code somewhere that depends on a
definition that has changed in the common lisp. I found at least 
one such problem related to set-difference. Clearly the code is
"right" in some sense.

\start
Date: Wed, 18 Jun 2003 12:34:34 -0400
From: Tim Daly
To: list
Subject: Axiom for Linux available

I've hand-built a version of Axiom for Linux. 
It is available for download at: http://axiom.tenkan.org
Please download the file and try to run it.
Instructions for installation are on the web page.

I'd like to build a windows version but will need some help from
someone with a windows machine.

Note that this version cannot, at the moment, be built automatically
from the CVS code. I'm in the process of updating the CVS at the 
moment but even the latest version will not fully automate the build.
The latest CVS version automates portions of the regression testing
for builds. A working subset of the test files is distributed with
the handbuilt version (see axiom/mnt/input/*)

Note also that this version includes only the interpreter and compiler.
There are many other portions of Axiom which still need to be built (e.g. 
the graphics subsystem).

The hand-built version has some known bugs. In particular:

recursive patterns sometimes fail.
LinearOrdinaryDifferentialOperators sometimes fails.
compiling domains with certain hasCategory dependencies fails.
name defaulting isn't working (specifiy full names to the read command)

If you find what you feel is a bug please send a .input file showing
the failing example to one of:
  Tim Daly
  axiom@tenkan.org
  list

If this version can be run successfully by several people I'll
look deeply into moving the whole pile onto savannah.

\start
Date: Thu, 19 Jun 2003 06:08:38 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: Re: Axiom for Linux available

On Wed, 18 Jun 2003, Tim Daly wrote:

> I've hand-built a version of Axiom for Linux.
> It is available for download at: http://axiom.tenkan.org

Dear Tim!

great work! I downloaded the axiom.xxx.tgz and everything seems to work
fine on my SuSE linux 8.2. Axiom starts and compoters with intergers and
polynoms. I would however suggest another place that /tmp, I have put it
into /usr/local/axiom...

May I kindly likr to ask, if there are the helpfiles also distributed. I
am a bloody newcommer to axiom and need example to see what it really can
do. I know a little bit of aldor, but some further resource would be fine.

Anyhow, you really did a great wonderful job!

\start
Date: Thu, 19 Jun 2003 00:27:16 -0400
From: Tim Daly
To: Bertfried Fauser
Subject: Re: Axiom for Linux available

Well, I chose /tmp just so it would be obvious to people that
the root location could be anything. I'll change the description
of the install process once I move the announcement out of the
developer group.

Check out the files in axiom/mnt/input for examples.
The Axiom textbook is available on amazon (used) for about $20.
I'll be uploading more documentation in the future but getting
the code to work is more important at the moment. I'll look into
how much I can put together with the minimum effort and add it
to the next distribution version.

\start
Date: Thu, 19 Jun 2003 00:28:35 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Float bugs

really curious behavior about round/truncate/fractionPart.
i've added it to the list of bugs. thanks.

\start
Date: Thu, 19 Jun 2003 00:31:54 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Axiom for Linux available

Bill,

I believe you have succeeded in getting a running port of the
interpreter. I need you to do a special compile of the algebra
code, run input tests, check the results, and if successful,
tar up the file with instructions so windows users can use it.

Alternatively, (or perhaps in addition) I need to learn how your
windows environment is set up and set up a machine here with the
same environment. What do you use? Which compiler?

\start
Date: Thu, 19 Jun 2003 06:54:01 -0400
From: Tim Daly
To: Bill Page
Subject: Re: AXIOM server number is undefined

re: bug 20030619001:

> Second, apparently axiom used to issue two ->
> prompts before before waiting for input (maybe
> the first one occurred in some explanatory text?)
> Anyway, all I had to do was to tell tm_axiom to
> only expect one prompt.

The first prompt is the startup prompt.
The second is the start of a "frame" (a separate namespace).
This is a bug but I have no fix for it yet.

You can see the things you can set by issuing the command:

)set

You can see further options of a set command (say messages) by:

)set messages

\start
Date: Thu, 19 Jun 2003 06:50:28 -0400
From: Tim Daly
To: Bill Page
Subject: Re: AXIOM server number is undefined

re: bug 20030619002:

> Also, is there an easy way to turn off all
> those 

>   Loading ...

> messages? They are good for debugging but not
> interesting to the user.

create a file called axiom.input in your home directory.
add a line that reads:

)set message autoload off

next time you start axiom and type a+1 you should no longer
get algebra load messages.

\start
Date: Thu, 19 Jun 2003 07:07:30 -0400
From: Tim Daly
To: Bill Page
Subject: Re: AXIOM server number is undefined

re: bug 20030619000:

> First, notice that the first two lines of output
> beginning

>   Using local database ...

> are run together into a single line (missing \n?)
> The total line length (151 chars) exceeded the
> internal line buffer maximum (128) specified in
> tm_axiom. That was easy to fix. But maybe you
> should make a note to fix it also in axiom.

Yes, I've chased this one. Curiously the messages are all
written out by the same code. 3 of the 4 messages work.
The offending message must take another code path but I 
haven't found it yet.

The "using local database" messages are due to the fact
that I've moved where the databases are loaded from.
By default they used to be loaded from the mnt/algebra
subdirectory (since there was no other). Nag changed it
so they were loaded from a "share" subdirectory. I'm in
the process of changing it back. This should work:

(assuming that code lives in /tmp)

mkdir /tmp/axiom/share
mkdir /tmp/axiom/share/algebra
cp /tmp/axiom/mnt/linux/algebra/*.daase /mnt/axiom/share/algebra
export AXIOM=/tmp/axiom/mnt/linux
export PATH=/tmp/axiom/mnt/linux/bin:$PATH
interpsys

In order to change where Axiom finds various database files on 
startup you can set a shell variable called DAASE (a contraction
of database). If you look at the shipped 'axiom' command which
lives in /tmp/axiom/mnt/linux/bin/axiom you'll see that I set
that variable in the shell script to the new load location. The
above commands move the databases back to the default location.
Axiom will only generate the loading messages when you've moved
the default location. 

The above commands call interpsys rather than axiom so you are
invoking the interpreter without using the axiom shell script.
You could change the axiom shell script to elide the DAASE
variable (once you've copied the daase files) and still use
the axiom command.

This will be fixed as soon as I hardcode the new default.

\start
Date: Fri, 20 Jun 2003 12:53:45 +1000
From: Jason White
To: list
Subject: Re: Axiom for Linux available

 > I'll be uploading more documentation in the future but getting
 > the code to work is more important at the moment. I'll look into
 > how much I can put together with the minimum effort and add it
 > to the next distribution version.

(1) -> )summary
cat: /home/jason/axiom/mnt/linux/lib/summary: No such file or directory

should be easy to fix if you have the file, which isn't in CVS either.

There is also a tutorial available online at
http://www-theory.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial/

There is also an overview document (in Postscript only) somewhere on
the Web (a site in the Netherlands if memory serves). I can try to
locate it again if necessary.

\start
Date: Fri, 20 Jun 2003 10:36:55 -0400
From: Tim Daly
To: Henry Baker
Subject: Meta Prag-Parse

Mr Baker,

I'm Tim Daly, the lead developer of the open source computer algebra
system Axiom. Axiom started in the 60s as an IBM Research effort, was
later sold to NAG in England, and has been withdrawn as a commercial
product. I'm converting it to open and free software. One of the seven
parsers in Axiom is written in Meta and I'm documenting the system.

You have written some documentation of Meta (Prag-Parse.[html,ps])
which you distribute with the meta code. I'd like to package those
files (or some derivative in our literate programming pamphlet format).
The files would be distributed under a modified BSD license as part of
the internal documentation of the Axiom source code. You would be given
credit of authorship. I'd like your permission to do that.

\start
Date: Fri, 20 Jun 2003 08:24:28 -0700
From: Henry Baker
To: Tim Daly
Subject: Re: Meta Prag-Parse

Tim:

No problem with Meta.  As referenced in my paper, the original Meta
ideas came from papers published in the 1960's.

I'd be interested in learning more about Axiom.  How big is it?  What
machines does it run on?  Are you going to make it available on a
palm-top?  :-)

If you want my Meta stuff in any other formats, please let me know.

I also have optimized versions of Lisp code that didn't appear in
the paper, because the paper would have gotten too big.

Henry Baker, PhD (CS MIT'78)
----------------------------
At 10:36 AM 6/20/03 -0400, Tim Daly wrote:
>Mr Baker,
>
>I'm Tim Daly, the lead developer of the open source computer algebra
>system Axiom. Axiom started in the 60s as an IBM Research effort, was
>later sold to NAG in England, and has been withdrawn as a commercial
>product. I'm converting it to open and free software. One of the seven
>parsers in Axiom is written in Meta and I'm documenting the system.
>
>You have written some documentation of Meta (Prag-Parse.[html,ps])
>which you distribute with the meta code. I'd like to package those
>files (or some derivative in our literate programming pamphlet format).
>The files would be distributed under a modified BSD license as part of
>the internal documentation of the Axiom source code. You would be given
>credit of authorship. I'd like your permission to do that.

\start
Date: Fri, 20 Jun 2003 11:11:42 -0400
From: Tim Daly
To: Henry Baker
Subject: Re: Meta Prag-Parse

Thanks for the quick response. I have a version of the Meta lisp
code that was included with the parse documentation. Is there some
way to decide whether this code is the latest? (If you put the code
someplace I can download and diff).

Bill Burge wrote an Axiom parser in Meta in the 60s. Bill is the author
of a book on parsing techniques.

Axiom is a large computer algebra system (originally one of the big
commercial systems like Mathematica and Maple). It's been developed
over the last 30 years and represents about 300 man-years of research
at last count.

NAG (The Numerical Algorithms Group) withdrew it from the market and
gave it to me to open source. I was one of the original developers
while it was a research project at IBM Research.

There is a web page (savannah.nongnu.org/projects/axiom) that is
the project home page. It will be in use shortly. Currently the
code is on tenkan.org and can be downloaded using anonymous CVS.

The home page is at www.nongnu.org/axiom and I've described some
ideas for future directions there.

There is a (alpha) runnable version of Axiom for Linux at:
axiom.tenkan.org  

The current state of the project is that the algebra portion of
the system is mostly buildable from source code. I'm working to
document the sources as well as chase known bugs. There are large
portions of the system (e.g. hypertex, graphics) which are still
on the list of things to do. 

As for other formats, all of Axiom (lisp, c, meta, boot, makefiles, etc)
is now in a common file format called pamphlets which is a literate
programming language based on Tex. I'll grind the Meta stuff into the
same format so it integrates with the rest of the developing documenation.

I originally had an Axiom that ran on DOS many centuries ago in less
than a meg of memory. I hope to port it to run on a Zaurus 5600 (that
is assuming I can get funding for it). Since the 5600 is an intel
chip running linux the port may even amount to a straight copy but
I doubt it. There is no such thing as a simple job.

\start
Date: Fri, 20 Jun 2003 14:28:19 -0700
From: Henry Baker
To: Tim Daly
Subject: Re: Meta Prag-Parse

Tim:

Is there any documentation online anywhere (html, pdf) ?

Henry
-----
At 11:11 AM 6/20/03 -0400, Tim Daly wrote:
>Thanks for the quick response. I have a version of the Meta lisp
>code that was included with the parse documentation. Is there some
>way to decide whether this code is the latest? (If you put the code
>someplace I can download and diff).
>
>Bill Burge wrote an Axiom parser in Meta in the 60s. Bill is the author
>of a book on parsing techniques.
>
>Axiom is a large computer algebra system (originally one of the big
>commercial systems like Mathematica and Maple). It's been developed
>over the last 30 years and represents about 300 man-years of research
>at last count.
>
>NAG (The Numerical Algorithms Group) withdrew it from the market and
>gave it to me to open source. I was one of the original developers
>while it was a research project at IBM Research.
>
>There is a web page (savannah.nongnu.org/projects/axiom) that is
>the project home page. It will be in use shortly. Currently the
>code is on tenkan.org and can be downloaded using anonymous CVS.
>
>The home page is at www.nongnu.org/axiom and I've described some
>ideas for future directions there.
>
>There is a (alpha) runnable version of Axiom for Linux at:
>axiom.tenkan.org  
>
>The current state of the project is that the algebra portion of
>the system is mostly buildable from source code. I'm working to
>document the sources as well as chase known bugs. There are large
>portions of the system (e.g. hypertex, graphics) which are still
>on the list of things to do. 
>
>As for other formats, all of Axiom (lisp, c, meta, boot, makefiles, etc)
>is now in a common file format called pamphlets which is a literate
>programming language based on Tex. I'll grind the Meta stuff into the
>same format so it integrates with the rest of the developing documenation.
>
>I originally had an Axiom that ran on DOS many centuries ago in less
>than a meg of memory. I hope to port it to run on a Zaurus 5600 (that
>is assuming I can get funding for it). Since the 5600 is an intel
>chip running linux the port may even amount to a straight copy but
>I doubt it. There is no such thing as a simple job.

\start
Date: Fri, 20 Jun 2003 19:45:14 -0400
From: Tim Daly
To: Henry Baker
Subject: Re: Meta Prag-Parse

re: documentation

sure, especially the meta parser :-)

i've been concentrating on documenting the source code as that's
where my expertise is needed most. there are two primary sources
of user-level documentation. first, there is a book on axiom
(available at amazon used for about $20. however, i believe i have
the source text for the book and, if i do, i'll be making that
available). second, the axiom/src/input subdirectory has a lot of
examples derived from the hyperdoc subsystem (which is not yet
ported) and used as regression tests.

i've been ignoring the user-level documentation issue but you're
the 4th person to ask and the system has only been available for
2 days. i'll concentrate on getting something resembling user
documentation available this weekend. i'll send you a note when
i upload something.

\start
Date: Sat, 21 Jun 2003 00:15:52 -0400
From: Tim Daly
To: Jason White
Subject: subscribing to axiom-developer, user interface issues.

The axiom-mail mailing list will heat up shortly but you might find it
a bit redundant. As Axiom gets introduced into a larger audience the
same questions will come around (even though the answers end up in a
FAQ :-) ). I'ts a part of the game. The plan is to introduce the first
versions to the developers, fix it, reintroduce the version into the
axiom list, fix it, then introduce it on savannah, and then mention it
to the researchers thru various paths, finally announcing it on places
like sci.math.symbolic, slashdot, etc.  I'm using the developers to
give me a clue (like, hey, where's the documentation?) since this is
all new to me. I'm also depending on developers to build axiom for
different platforms and interfaces to different tools.  If you want it
first the axiom-developer list is where it'll happen first.

Axiom grew fastest when it was used by many people to further their own
research and development goals. I'm hoping to bring this system to a
larger audience so people can push it in directions they care about.

There are a number of people in France and Germany who are interested
in using an open source computer algebra system in education. I've had
several discussions about a "zero learning curve" interface that makes
it MUCH easier to do algebra. This would be useful for teaching as you
don't want to spend a lot of teaching time explaining how to use the
system. So the user interface is likely to get attention sooner than
you'd expect. Bill Page and Joris van der Hoeven have created a
Texmacs front end. You could contribute by giving feedback about
accessibility issues in mathematics which is something I never think
about.

Another area where Axiom can excel is in research. I've had
discussions with people about extensions in various interesting
directions where computer algebra systems are weak. An open source
algebra system allows the researcher to quickly introduce their
algorithms. Trying to get a new algorithm published thru the
commercial systems is hard and takes a lot of time. An open source
system is clearly a fast-path to a large group.

A third direction of discussion has been toward proving the algorithms
in Axiom correct. We need to do this. How else can we trust systems of
this complexity? Fortunately most of the algorithms are in a very high
level language and are fairly close to their mathematical
descriptions. Unfortunately it's still a huge challenge.

There are several other directions that have been discussed.
It's an exciting time. Stay tuned...

\start
Date: Sat, 21 Jun 2003 16:00:02 +1000
From: Jason White
To: list
Subject:  Re: subscribing to axiom-developer, user interface issues.

A low-priority question:

To make Axiom output easily readable via synthetic speech or on my braille
display I need it in a linear format. Partial success can be achieved
as follows (see the last several lines for the problem):

(1) -> 1/3

        1
   (1)  -
        3
                                                       Type: Fraction Integer
(2) -> )set output fraction
--------------------------- The fraction Option ---------------------------

 Description: how fractions are formatted

 The fraction option may be followed by any one of the following:

 -> vertical 
    horizontal

 The current setting is indicated within the list.

(2) -> )set output fraction horizontal
(2) -> %

   (2)  1/3
                                                       Type: Fraction Integer
(3) -> a*x**3+b*x**2+c*x+d=0

           3      2
   (3)  a x  + b x  + c x + d= 0
                                            Type: Equation Polynomial Integer
(4) -> )set output scripts
--------------------------- The scripts Option ----------------------------

 Description: show subscripts,... linearly

 The scripts option may be followed by any one of the following:

    yes
    no

 The current setting is indicated within the list.

(4) -> )set output scripts yes
(4) -> %

           3      2
   (4)  a x  + b x  + c x + d= 0
                                            Type: Equation Polynomial Integer
(5) ->

Either the scripts option isn't working or I have misunderstood what
it is meant to do. That no "current setting" is highlighted in the
help text suggests this might be a bug.

\start
Date: 21 Jun 2003 11:16:19 +0200
From: Juergen Weiss
To: list
Subject: Output problem

Hi,

there is a problem with the generation of output
(1) -> [ i**3 for i  in 1..10]

   (1)  [1,8,27,64,125,216,343,512,729,100]
                                                   Type: List PositiveInteger

If you trace |processInteractive| you can really see, that
it's an output problem.

I ran the test with the Linux distribution of axiom and the
Linux libraries on FreeBSD. So I think, it's an akcl, not
a FreeBSD problem. The bad output does not happen on
cmu cl. Probably a rounding problem (the output of 1001
is correct)

\start
Date: Sat, 21 Jun 2003 06:59:57 -0400
From: Tim Daly
To: Jason White
Subject: set output script yes

Jason,

I have no idea what ")set output scripts yes" should do. I'll have to
read the code. Generally the way these things work is that the output
routine will call the "script" function from the domain (such as
Fraction Integer) and let the domain decide to output things in a
special way. It may be that Equation Polynomial Integer has no
script output method. I'll add it to the known bugs list.

If you have a read that understands tex you could try ")set output tex on".

\start
Date: Sat, 21 Jun 2003 07:20:24 -0400
From: Tim Daly
To: Bertfried Fauser
Subject: Re: Documentation
cc: Henry Baker

Bertfried,

>for a start up the link which was posted in this mailing list
>
>http://www-theory.dcs.st-and.ac.uk/~mnd/documentation/

I can't get to this site. It gives me a "403 Forbidden" error.
Also, I have to get permission to redistribute the documentation
as I didn't write it.

>helped at least me to come up with my first working AXIOM function. Having
>the book online available would be great, even if I odered it just a few
>minutes ago. And, there are no so many such books available for an
>affordable price, ....

Both paper and electronic versions have their uses. I've been unable to
Tex the user's guide that came from NAG due to missing files so it is
going to take a while to reverse-engineer what is missing.

>The documentation of Aldor may help a little bit further, especially
>concerning what types. For a new user the greatest problem seems to be to
>detect which functions are available doing routine jobs. I am thinking
>about compiling a sort of a command chart, perhaps with maple quivalent
>and may put it on my web page, if time allows.

I wrote one of the tutorial chapters for the Aldor compiler. 
Unfortunately it is slanted toward the issues of building a stand
alone domain. Since Aldor doesn't have Axiom's algebra pile you
basically have to start from scratch if you want to work only in
Aldor (Aldor can compile code that runs in Axiom also). So the
tutorial was focused on the issues that arise if you try to create
a simple polynomial domain from scratch.

Coding in Axiom usually starts at a much higher level. Almost every
primitive thing you can think of is hiding in the algebra somewhere. 
Finding it is not easy although there are some command-line
queries, such as the ")what operation" command, that can help.

There is also a stand-alone C program in the distribution called "asq"
(in English this sounds like "ask") which knows the format of the
databases and can answer questions without starting Axiom. For example, 
"asq -so DHMATRIX" will tell you the source file that contains the domain
DHMATRIX.

Ideally we need something like Java's JavaDoc facility. Perhaps JavaDoc
can be made to work on the algebra files. I'll put it on the "todo" list
to try. Of course, somebody would have to WRITE the javadoc descriptions
but at least the support machinery would be there. (I believe there is
a DOC++ function for C++ that does something similer).

\start
Date: Sat, 21 Jun 2003 07:33:34 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: Output problem

Juergen,

> there is a problem with the generation of output
> (1) -> [ i**3 for i  in 1..10]
> 
>    (1)  [1,8,27,64,125,216,343,512,729,100]
>                                                    Type: List PositiveInteger
> 
> If you trace |processInteractive| you can really see, that
> it's an output problem.
> 
> I ran the test with the Linux distribution of axiom and the
> Linux libraries on FreeBSD. So I think, it's an akcl, not
> a FreeBSD problem. The bad output does not happen on
> cmu cl. Probably a rounding problem (the output of 1001
> is correct)

Nobody really needs numbers larger than 3 digits :-)

Curiously, if you do the loop [ i**3 for i  in 1..12] all of the
other answers are right. 

The major difference between the CVS version of Axiom and the
hand-built distribution is the algebra files. The hand-built
version of the algebra is compiled using NAG's version of Axiom.
The CVS version is built from the CVS sources. Both give the
same wrong answer so it may be that the bug is in the output
routine in the algebra code. 

Good catch. I'll put it on the known bugs list.

\start
Date: Sat, 21 Jun 2003 07:40:03 -0400
From: Tim Daly
To: list
Subject: Dunstan's Documentation
cc: Bertfried Fauser

Bertfried,

I succeeded in getting to:

http://www-theory.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial

which looks like an excellent introduction to Axiom.

Does anyone on the list know Martin Dunstan? Can you give me a 
contact address? I'd like to get permission to redistribute this
tutorial with Axiom.

\start
Date: Sat, 21 Jun 2003 07:55:27 -0400
From: Tim Daly
To: Martin Dunstan
Subject: Axiom Documentation

Dr Dunstan,

I'm Tim Daly, the lead developer of the open source computer algebra
system Axiom. Axiom started in the 60s as an IBM Research effort, was
later sold to NAG in England, and has been withdrawn as a commercial
product. I know you worked closely with NAG in the past.

You have written quite a bit about Axiom. I have a copy of your thesis
work as well as a recent link to your tutorial listed at this site:
http://www.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial. 
Axiom is just now becoming available and needs documentation which can
be distributed with the source code and executables. Both your thesis
and this tutorial would be very useful to future developers and users
of Axiom. I'd like your permission to integrate your work as part of
the distribution.

The files would be distributed under a modified BSD license as part of
the documentation of Axiom. You would be given credit of authorship. 
I'd like your permission to do that.

\start
Date: Sun, 22 Jun 2003 11:21:54 +1000
From: Jason White
To: list
Subject: Re: Documentation

Tim Daly writes:
 > 
 > 
 > Both paper and electronic versions have their uses. I've been unable to
 > Tex the user's guide that came from NAG due to missing files so it is
 > going to take a while to reverse-engineer what is missing.

If you were to place the TeX sources in CVS it would at least be
possible to read those. I assume the missing components are
style files rather than parts of the user's guide itself.

Another useful document, which again you would need to seek permission
to distribute, is at http://remote.science.uva.nl/~heck/tour.ps.gz

Furthermore, I have found an advertisement for Axiom that offers a good
overview of the system:
http://www.sxst.it/nag__axm.htm

\start
Date: Sun, 22 Jun 2003 02:08:21 -0400
From: Tim Daly
To: Jason White
Subject: Re: Documentation

Jason,

I'd rather not put badly broken things up in publicly accessible
places. It's guaranteed that most people will expect a tex file
to properly tex. There are some missing style files but the tex
itself is so old that it causes Latex to default to an old version.
I can fix it (since I wrote portions of it) but it will take more 
time than I had hoped.

I'll look at the two documents you mentioned.

It is also rumored that Springer has an interactive textbook that
was based on Axiom but never released. I've been unable to find anyone
at Springer to confirm or deny this. It would be great if they would
consider releasing it as open source.

\start
Date: Sun, 22 Jun 2003 17:16:23 +1000
From: Jason White
To: list
Subject: Re: Output problem

Actually the bug can be triggered much more simply:

(1) -> [1000]

   (1)  [100]
                                                   Type: List PositiveInteger
\start
Date: Sun, 22 Jun 2003 10:39:08 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: Re: Documentation

On Sun, 22 Jun 2003, Tim Daly wrote:

Dear Tim,

was that Springer Germany or US? If I had a name or something more
concrete I could try to be inquisitive, but I canot promis anything.

cheers
BF.

> It is also rumored that Springer has an interactive textbook that
> was based on Axiom but never released. I've been unable to find anyone
> at Springer to confirm or deny this. It would be great if they would
> consider releasing it as open source.

\start
Date: 22 Jun 2003 10:06:33 -0400
From: Camm Maguire
To: Juergen Weiss
Subject: Re: source access

Greetings!

"Juergen Weiss" Juergen Weiss writes:

> The current problem lies with gcl. With cmucl I was able to
> compile all the algebra files and get a working algebra
> system.
> 
> So there is nothing in principle and practice against generating
> an axiom system with a simple call to make. There is a
> problem with the gcl system which must be fixed. As far I can
> see from the discussion in this list, it seems to be related
> to the number of arguments in a function call or something similar. 
> Akcl had to be customized even 10 years ago to run axiom. I think,
> I did that once for akcl on sparc sunos 4.1. But I fear I cannot
> remember the details. This problem is triggered by the axiom

OK, please forgive, as I only intermittently follow this list.  It was
my understanding that this 'value stack overflow' problem had been
resolved, but apparently I've misread some earlier email on the
subject.  It would be most helpful to me if someone could summarize in
as much detail as possible what is known about this issue.   Can one
provide a small example in lisp which triggers this overflow?  I take
it that there is some termination problem in a recursive function
call?  How its this related to the number of arguments in a call?
I've reproduced the ')co xpoly.spad' example, and have verified that
the value stack will terminate at some 44k deep if one expands the
default value stack size, but then there is a segfault.  Haven't yet
looked much deeper, but I'd like to time permitting.  I'd also like to
know what a proper stack should look like in a correctly functioning
setup. 

BTW, here is the patch submitted a while ago for the elt error message
bug, if you would like it:

Index: o/error.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/error.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- o/error.c	27 Feb 2003 15:50:59 -0000	1.15
+++ o/error.c	10 Jun 2003 13:28:11 -0000	1.16
@@ -120,7 +120,7 @@
 
 
 
-static object
+object
 Icall_error_handler(object error_name,object error_format_string,int nfmt_args,...)
 { object b[20];
   b[0]= error_name;
Index: o/sequence.d
===================================================================
RCS file: /cvsroot/gcl/gcl/o/sequence.d,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- o/sequence.d	15 Oct 2002 19:32:01 -0000	1.3
+++ o/sequence.d	10 Jun 2003 13:28:11 -0000	1.4
@@ -123,7 +123,9 @@
 E:
 	vs_push(make_fixnum(index));
 	/* FIXME message should indicate out of range */
-	FEwrong_type_argument(sLpositive_fixnum,vs_head);
+	Icall_error_handler(sKwrong_type_argument,
+		     make_simple_string("The index, ~S, is too large."),
+		     1,vs_head);
 	return(Cnil);
 }
 
Index: h/protoize.h
===================================================================
RCS file: /cvsroot/gcl/gcl/h/protoize.h,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- h/protoize.h	1 Mar 2003 22:37:37 -0000	1.26
+++ h/protoize.h	10 Jun 2003 13:28:11 -0000	1.27
@@ -1737,6 +1737,9 @@
 object
 cplus(object,object);
 
+object
+Icall_error_handler(object,object,int,...);
+
 #if defined (__MINGW32__)
 int bcmp ( const void *s1, const void *s2, size_t n );
 void bcopy ( const void *s1, void *s2, size_t n );


\start
Date: Sun, 22 Jun 2003 16:33:45 +0200
From: Juergen Weiss
To: Jason White
Subject: RE: Output problem

As I wrote already in an email to Tim Daly,
there are some roundoff errors in log10,
so that log10 1000 is 2.9...96 and
in the WIDTH function in i-output.boot
after a floor operation, the field is just
1 too small to print 1000.

> -----Original Message-----
> From: Jason White [mailto:Jason White] 
> Sent: Sunday, June 22, 2003 9:16 AM
> To: Tim Daly
> Cc: Juergen Weiss; list; axiom@tenkan.org
> Subject: Re: Output problem
> 
> 
> Actually the bug can be triggered much more simply:
> 
> (1) -> [1000]
> 
>    (1)  [100]
>                                                    Type: List 
> PositiveInteger
> 
> 

\start
Date: Sun, 22 Jun 2003 11:41:26 -0400
From: Bill Page
To: list
Subject: RE: Documentation

Tim, et al.

It does seem to be rather difficult to locate useful
articles on the Internet about AXIOM. As part of the
"revival" of AXIOM I think it might be worthwhile to
create a sort of archive - at least as a temporary
measure until Tim's more abitious plans for a formal
online AXIOM journal takes off. To that end, here is my
own list of AXIOM documents in electronic form that
I have managed to collect over the last few years.

I expect that other people on this list might have a
similar collection?

While not exactly "documentation", some of these papers
might be interesting only from a historical perspective,
some are about programming methodology and others are on
specific mathematical applications.

Unfortunately I no longer know most of the original
sources of these papers, so the url's below point to
my personal web site. I don't know the status of any
of these papers with respect to copyright (so please
treat them accordingly). But my intention for now is
only to make them available to the limited audience of
this group, so I don't think there should be a problem.

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

Next Generation Computer Algebra Systems
AXIOM and the Scratchpad Concept:
Applications to Research in Algebra
Larry Lambe
Presented to the 21 st Nordic Congress of Mathematicians,
June, 1992, Lulea, Sweden

http://wspage.tripod.com/docs/axiom-21cong.pdf


SCRATCHPAD/1
AN INTERACTIVE FACILITY FOR SYMBOLIC MATHEMATICS
J.H. Griesmer*
R.D. Jenks
IBM Thomas J. Watson Research Center
Yorktown Heights, N.Y.  10598

http://wspage.tripod.com/docs/axiom-jenks1.pdf


How to Make AXIOM Into a Scratchpad
Richard D. Jenks Barry M. Trager
IBM Thomas J. Watson Research Center
P.O. Box 218, Yorktown Heights, NY 10598 USA
{jenks ,bmt}@watson. ibm. com

http://wspage.tripod.com/docs/axiom-scratchpad.pdf


Object Oriented Mathematical Progamming
and Symbolic/Mumeric Interface
Larry Lambe and Richard Luczak
June 13, 1993

http://wspage.tripod.com/docs/axiom-fem.pdf


Object Oriented Method for Axiom.
Jean-Louis Boulanger
Laboratoire d'Informatique Fondamentale de Lille
Universite de Lille 1
59 655 Villeneuve d'ascq Cedex
FRANCE
Mail: boulang~lifl.fr
November 9, 1994

http://wspage.tripod.com/docs/axiom-obj.pdf


Real Algebraic Closure of an Ordered Field,
Implementation in Axiom *
Renaud Rioboo
LITP - Boite 168
Institut Blaise Pascal
Universtit4 Pierre et Marie Curie
4 Place Jussieu
F-75252 PARIS CEDEX 05
e-mail: rrQposso.ibp,fr

http://wspage.tripod.com/docs/axiom-field.pdf


JET - An AXIOM Environment for
Geometric Computations with Differential
Equations
W.M. Seiler and J. Calmet
Institut fur Algorithmem and Kognitive Systeme
Unersitat Karlsruhe
76128 Karsruhe, Germany
Email: seilerw@ira.uka.de

http://wspage.tripod.com/docs/axiom-jet95.pdf


Applying AXIOM to
Partial Differential Equations
W.M. Seiler
Institut fur Algorithmem and Kognitive Systeme
Unersitat Karlsruhe
76128 Karsruhe, Germany
Email: seilerw@ira.uka.de

http://wspage.tripod.com/docs/Axiom-pde.pdf


Pseudo Differential Operators and Integrable
Systems in AXIOM
Werner M. Seiler*
Institut fur Algorithmem and Kognitive Systeme
Unersitat Karlsruhe
D-76128 Karsruhe, Germany
Email: kg04@dkauni2.bitn.de

http://wspage.tripod.com/docs/axiom-PDO.pdf


About the Polynomial System Solve Facility of Axiom,
Macsyma, Maple, Mathematica, MuPAD, and Reduce
Hans-Gert Grabe
Institut fur Informatik, Universit  at Leipzig, Germany
February 23, 1998

http://wspage.tripod.com/docs/axiom-poly.pdf


A First Report on the An Compiler
Stephen M. Watt Peter A. Broadbery Samuel S. Dooley
Pietro Iglio Scott C. Morrison* Jonathan M. Steinbach
Robert S. Sutor
IBM Thomas J. Watson Research Center
P.O. BIDX 218, Yorktown Heights, NY 10598 USA
{smwatt ,peteb, dooley, lglio, jonms, sutor}@watson. ibm. com

http://wspage.tripod.com/docs/axiom-aldor-a-sharp.pdf

----------

Regards,
Bill Page.

> -----Original Message-----
> From: 
> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org 
> .org] On Behalf Of Jason White
> Sent: Saturday, June 21, 2003 9:22 PM
> To: list
> Subject: Re: Documentation
> 
> 
> Tim Daly writes:
>> 
>> 
>> Both paper and electronic versions have their uses.
>> I've been unable to Tex the user's guide that came
>> from NAG due to missing files so it is going to take
>> a while to reverse-engineer what is missing.
> 
> If you were to place the TeX sources in CVS it would at least 
> be possible to read those. I assume the missing components 
> are style files rather than parts of the user's guide itself.
> 
> Another useful document, which again you would need to seek 
> permission to distribute, is at 
> http://remote.science.uva.nl/~heck/tour.ps.gz
> 
> Furthermore, I 
> have found an advertisement for Axiom that offers a good 
> overview of the system: http://www.sxst.it/nag__axm.htm

\start
Date: Sun, 22 Jun 2003 11:41:26 -0400
From: Bill Page
To: list
Subject: RE: Dunstan's Documentation

Tim,

The most recent address I have for Martin Dunstan is

  mdunstan@computing.dundee.ac.uk

(See his email to me below about the tutorial.)

I think Martin's tutorial is useful but not particularly
complete.


-----Original Message-----
From: Martin N Dunstan [mailto:mdunstan@computing.dundee.ac.uk] 
Sent: Monday, January 27, 2003 9:49 AM
To: Bill Page
Subject: Re: web server not available?
Cc: Martin Dunstan

Hi Bill,

> I am very interested in your article
> 
> A Tutorial Introduction To AXIOM
> By Martin N. Dunstan.
>
http://www-theory.dcs.st-and.ac.uk:80/~mnd/documentation/axiom_tutorial/
> axiom.html

The Web site should now be available. The "proper" URL for it is now:

   http://www.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial/


-----Original Message-----
From: Martin N Dunstan [mailto:mdunstan@computing.dundee.ac.uk] 
Sent: Monday, December 16, 2002 10:18 AM
To: Bill Page
Subject: Re: web server not available?
Cc: mnd@dcs.st-and.ac.uk


Hi Bill,

> A Tutorial Introduction To AXIOM
> By Martin N. Dunstan.
>
http://www-theory.dcs.st-and.ac.uk:80/~mnd/documentation/axiom_tutorial/
> axiom.html

You might be able to find this on the NAG (www.nag.co.uk) server
although 
I suspect that may be a link to the above page.

The Web server at St Andrews has been changed and my files are still on
the old server. I tried moving them but couldn't find enough disk space
for them! I'll chase things up and see if I can get them restored.


> -----Original Message-----
> From: 
> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org 
> .org] On Behalf Of Tim Daly
> Sent: Saturday, June 21, 2003 7:40 AM
> To: Tim Daly
> Cc: Bertfried Fauser; Tim Daly; 
> list; axiom@tenkan.org
> Subject: Dunstan's Documentation
> 
> 
> Bertfried,
> 
> I succeeded in getting to:
> 
http://www-theory.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial

which looks like an excellent introduction to Axiom.

Does anyone on the list know Martin Dunstan? Can you give me a 
contact address? I'd like to get permission to redistribute this
tutorial with Axiom.

\start
Date: Mon, 23 Jun 2003 09:32:39 +0100 (BST)
From: Martin N Dunstan
To: Tim Daly
Subject: Re: Axiom Documentation

Hi Tim,

> Dr Dunstan,

I'd prefer "Martin" ;)

> You have written quite a bit about Axiom. I have a copy of your thesis
> work as well as a recent link to your tutorial listed at this site:
> http://www.dcs.st-and.ac.uk/~mnd/documentation/axiom_tutorial. 
> Axiom is just now becoming available and needs documentation which can
> be distributed with the source code and executables. Both your thesis
> and this tutorial would be very useful to future developers and users
> of Axiom. I'd like your permission to integrate your work as part of
> the distribution.

I've already given you permission, at least for my thesis. You're welcome
to use my Axiom tutorial as well although I must emphasise that I wrote it
to help me learn Axiom and my lack of background algebra shows through at
times!

Feel free to lift the files for the tutorial directly off the web. I can 
send you a tar file of the directory if that would be easier. The current 
location of the tutorial (on www.dcs.st-and.ac.uk) is less than ideal 
since I no longer work at St Andrews. If you wanted to put up a copy of 
the tutorial on an Axiom web site then please do.

\start
Date: Mon, 23 Jun 2003 23:09:05 +0200
From: David Mentre
To: list
Subject: Report on building axiom cvs 2003-06-23 (i386)

Hello Tim and other Axiomers,

I've tried to build (on i386) Axiom CVS as of Monday, 23rd of June,
2003. I know that you haven't fix all the issues but and I just wanted
to give it a small try. Here is a mini-report:

 1. the build fails when trying to build in src/input/ directory:

make[3]: Leaving directory `/home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/src/algebra'
make[2]: *** No rule to make target `/home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/src/input/Makefile.pamphlet',needed for `/home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/src/input/Makefile'. Stop.
make[2]: Leaving directory `/home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/src'
make[1]: *** [srcdir] Erreur 2
make[1]: Leaving directory `/home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new'
make: *** [all] Erreur 2


 2. the only error I have noticed happens when building debugsys. This
    is due to the bad path in debugsys.lisp.pamphlet. I know that Tim
    you don't consider it as an error, as debugsys is only need for you
    to hack on Axiom.

39 making /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/int/interp/debugsys.lisp from /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/src/interp/debugsys.lisp.pamphlet
7 building debugsys

>
Loading /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/int/interp/debugsys.lisp

Error: Cannot open the file /home/axiomgnu/new/int/interp/sys-pkg.lisp.
Error signalled by LOAD.
Broken at SYSTEM::BREAK-LEVEL.  Type :H for Help.
>>8 /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/obj/linux/bin/debugsys created


 3. I have also noticed five error messages (Semantic Errors) like this
    one:

0 making /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/int/algebra/ASP34.NRLIB from /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/int/algebra/ASP34.spad
[...]
   Semantic Errors: 
      [1] coerce:  code is BOTH a variable and a literal


  4. Another strange error message:

0 making /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/int/algebra/RESLATC.NRLIB from /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/int/algebra/RESLATC.spad
[...]
      RESLATC;coerce;ES;2 is replaced by errorBug: Should not be able to obtain value of type Exit 


  5. Yet another strange error message, in French!

0 making /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/int/algebra/SPLTREE.NRLIB from /home/david/pub/axiom-libre/axiom-cvs-2003-06-23-i386/new/new/int/algebra/SPLTREE.spad
[...]
      SPLTREE;eq?;2$B;20 is replaced by errorin eq? from SPLTREE : la vache qui rit est-elle folle? 




I had no time to dig further into the code. I have probably messed up
dummy error messages from Axiom packages and real errors from the build.

Tim, I can send you the whole compilation log if needed.

Best regards,
d.

BTW, Tim, would you accept some small patches that try to documents the
Makefiles, complete the FAQ, etc. ?

\start
Date: Mon, 23 Jun 2003 18:28:43 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Report on building axiom cvs 2003-06-23 (i386)

David,

re: (1) ... no rule for Makefile.pamphlet

Odd. Must have been a bad upload because it doesn't happen here. 
I'll reload that Makefile.pamphlet file.

re: (2) ... missing sys-pkg.lisp in debugsys

I'm a stickler for errors. There shouldn't be error messages (nor
warning messages if they can be helped (Axiom's current state is
a huge embarrassment in this regard)). 

So debugsys should build even if I'm the only user.

re: (3) ASP34.spad

There are a number of errors and warnings the algebra build, some
of which happen even in the NAG version. However, I've resisted the
urge to fix the algebra code until I'm done getting the rest of the
problems fixed.

re: (4) value of EXIT

methinks this is a bug that is new to GCL 2.5 but I haven't started
to pursue it yet. I'm not sure if EXIT is new to GCL or what.

re: (5) SPLTREE in french

je ne comprende pas. Another algebra error.

re: patches.

Any and all patches are welcome. This isn't supposed to be a 
one person project but a community effort; I'm just driving
the bus.

\start
Date: Tue, 24 Jun 2003 19:07:45 +0200
From: David Mentre
To: Tim Daly
Subject: src/input/Makefile.pamphlet (was: Re: Report on building axiom cvs 2003-06-23 (i386))

Tim Daly writes:

[ no src/input/Makefile.pamphlet ]
> re: (1) ... no rule for Makefile.pamphlet
>
> Odd. Must have been a bad upload because it doesn't happen here. 
> I'll reload that Makefile.pamphlet file.

In fact, the whole src/input directory is missing in CVS.

\start
Date: Wed, 25 Jun 2003 08:08:11 +1000
From: Jason White
To: David Mentre
Subject: Re: src/input/Makefile.pamphlet (was: Re: Report on building axiom cvs 2003-06-23 (i386))

David MENTRE writes:
 > Tim Daly writes:
 > 
 > [ no src/input/Makefile.pamphlet ]
 > > re: (1) ... no rule for Makefile.pamphlet
 > >
 > > Odd. Must have been a bad upload because it doesn't happen here. 
 > > I'll reload that Makefile.pamphlet file.
 > 
 > In fact, the whole src/input directory is missing in CVS.

It was added last week. Did you include the -d switch in your CVS
update command? You need to do this in order to retrieve directories
which have been added to the repository.

\start
Date: Tue, 24 Jun 2003 20:26:56 -0400
From: Tim Daly
To: Bertfried Fauser
Subject: Re: Documentation

Bertfried,

The only name I have is Rudiger Gebauer. He apparently was the contact
with IBM while they developed the interactive textbook based on Axiom.
As far I my IBM contacts are aware it was never published. It would
be useful to either open-source the technology or the whole book
with the technology. Perhaps we can work with them to make it
available again.

\start
Date: Tue, 24 Jun 2003 20:34:54 -0400
From: Tim Daly
To: Bertfried Fauser
Subject: Re: Documentation

Bertfried,

The only name I have is Rudiger Gebauer. He apparently was the contact
with IBM while they developed the interactive textbook based on Axiom.
As far I my IBM contacts are aware it was never published. It would
be useful to either open-source the technology or the whole book
with the technology. Perhaps we can work with them to make it
available again.

\start
Date: Tue, 24 Jun 2003 22:22:18 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: [Gcl-devel] use XDR with GCL on Windows

Mike,

On Tuesday, June 24, 2003 8:19 PM you wrote:

> ...
> [Bill wrote] 
> | My goal is to build Axiom to run under Windows using
> | MinGW and GCL. Tim Daly has provided several patches to
> | GCL 2.5.2 in order to support Axiom under linux. (See
> | cvs at tenkan.org) This works under linux.
> 
> Can you be more specific about the address of that site
> or those patches please.

The site is tenkan.org, e.g.

  cvs -d:pserver:billpage1@tenkan.org:/home/cvs login

It is the temporary closed development site for open
source Axiom until Tim Daly feels ready to post the Axiom
source to the public savanaha site. To get access to the
tenkan.org site, just send an email to

   Tim Daly

I am sure that he will be glad to hear of your interest. If
you want, I can send you the patch files for GCL 2.5.2 and
the axiom specific makefile.

> 
> 
> | I am able to compile GCL 2.5.2 under minGW without the pathes. But 
> | Axiom apparently requires XDR (and a few other changes). 
> Apply one of 
> | the pathes, which inserts
> |
> |   #define HAVE_XDR
> |
> | into the mingw.h causes the compiler to attempt to
> | include the file rpc/rpc.h and related code. Unfortunately 
> the rpc.h 
> | that is part of MinGW does not include the XDR functionality.
> |
> | I got as far as downloading some rpc code that does include XDR and 
> | *might* compile with MinGW
> |
> |   http://www.plt.rwth-aachen.de/ks/english/oncrpc.html
> |
> | (which you recommended some time back)
> 
> Only yesterday I wondered why you never got back about the 
> RPC functionality.  The geologist in me decided it was one of 
> those miraculous moments when everything goes right.

Only in the movies!

> 
> | but including the oncrpc headers in the GCL o/makefile 
> leads to some 
> | warnings of incompatible definitions (which can be
> | fixed) and finally to a gcc compiler message that I don't 
> understand.
> 
> 
> I commented out the definitions in "rpc/bcopy.h" to stop this problem.
> 
> 
> |   gcc -c -Wall -fwritable-strings -DVOL=volatile -fsigned-char
> | -march=i386  -I/home/axiomgnu/new/lsp/gcl-2.5.2/o  -I../h 
> -I../gcl-tk -I
> | /c/oncrpc funlink.c
> | C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccwtaaaa.s: Assembler messages:
> | C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccwtaaaa.s:9048: Error: length of
> | .comm "_D" is already 16; not changing to 528
> |
> | -------
> |
> | So, where should I go from here? Has anyone successfully built
> | GCL for windows with rpc and XDR?
> 
> 
> I just did this morning with the 2.5.3 source release code 
> using the MinGW32 build of the ONCRPC library which I will
> shortly send to you separately, and gcc 3.2.1, which is the
> one supplied with the Windows GCL binary release.
> All went smoothly, I'm pleased to say.
> 
> Make sure you copy the dll in the ONCRPC bin directory into
> your path somewhere, the RPC header directory into your include
> directory, and "librpclib.a" into your lib directory.
> 
> In addition to adding that define you mentioned above, you 
> should also add
> "-lrpclib" to the list of libraries for the link.
>

Ok, great. I will let you know how it goes. I can probably
move to 2.5.3 as well for axiom.
 
> 
> | Should I start with some
> | other source code for rpc that would be more compatible with
> | MinGW? Is there a way to avoid the compiler error? Other ideas?
> 
> 
> My guess is not until you see whether the system works.  I 
> don't know much about XDR, so I can't really help much in
> respect of the details.
> 
> Would it help if I incorporate the XDR functionality into the
> current Windows binary download?  I suppose that those patches
> from Tim Daly will then not be available.

Yes, perhaps, but you are right that some of the other patches
might also be needed. As I recall, the difference between 2.5.2
and 2.5.3 was at least one of the patches that originated with
Tim and Dave Mentre David [david.mentre@wanadoo.fr]. The primary
one for Axiom is the one for the old in-package behaviour. I will
see if I can determine which others (if any) are also required.

What is the status of the ONC rpc source code? Their website
seemed quite open to re-use. Would it be possible/desirable
to include these rpc sources with GCL?

\start
Date: Tue, 24 Jun 2003 23:02:31 -0400
From: Tim Daly
To: Bill Page, Mike Thomas
Subject:  use XDR with GCL on Windows, Makefile.windows, NAG libraries

Bill, Mike,

Clearly I'm jumping into the middle of this conversation but here's
a thought or two. 

First, Mike, the tenkan.org site will allow you to login using an
anonymous account so you can download the CVS code if you like.
Type:

cvs -d:pserver:anonymous@tenkan.org:/home/cvs login

and give it a null password and you should be able to download axiom:

cvs -z3 -co axiom

Second, Bill, we ought to have some discussion of a way to incorporate
the windows version into the system. If you can summarize the changes
I can write a chunk in the Makefile.pamphlet that should build the
system from scratch for windows. If done properly then all Mike or
any other windows user should have to do is:

export AXIOM=(path)/mnt/windows

and it should build a working windows version. Or maybe

export AXIOM=(path)/mnt/mingw

if we want to have several different windows build environments.  All
this amounts to will be a different chunk based on the basename of the
specified path.  Clearly I'm going to need your help on this. Perhaps
if you send me your makefile and some words about the needed changes
we can make this automatic. If you look at the top level Makefile.pamphlet
and search for \subsection{Makefile.linux} you'll see the chunk used
for AXIOM=(path)/mnt/linux. This section is extracted into a file called
Makefile.linux (search for \subsection{The Top Level Makefile}). The
user process is:

document Makefile   extracts the Makefile from Makefile.pamphlet
make                uses ${SYS} in the line: notangle -RMakefile.${SYS}
                    to create Makefile.linux and invoke make on it.

If you change the ${SYS} variable to "windows" the make step
above will try to find the chunk <<Makefile.windows>>= and extract
it to create Makefile.windows, then call make on it. 

So if you 
(1) copy the <<Makefile.linux>>= chunk, rename it to <<Makefile.windows>>=,
(2) put all of your Makefile dependent variables and stanzas there, 
(4) change ${SYS} to be SYS=windows
(5) document Makefile
(6) make
you'll have a windows-specific Makefile.windows that gets executed.

XDR is a data exchange format used to communicate between Axiom's
lisp code and NAG's fortran library. The NAG library used to be
an integral part of Axiom but needs to be either (a) tested by
somebody that actually has a NAG fortran library (which I don't)
or (b) redone using something like Octave (pain, pain, pain) or
(c) thrown out (significant functionality loss, not recommended).

GCL 2.5.3 is out? Cheese, ya can't blink for a second without
something changing :-) I'll look at the build issues on 2.5.3
soon. I believe I've solved the package issue so the patches
should go away.

I'm giving two talks (Axiom, Literate Programming) at a conference 
in early July so I'm kinda heads-down writing the slides and papers.
Needless to say, this is gonna cause a bit of lag in my responses.

\start
Date: Wed, 25 Jun 2003 14:27:38 +1000
From: Mike Thomas
To: Bill Page
Subject: ONCRPC binaries for MinGW32 - where to put it.

Hi again Bill.

CC MinGW32 list as this is a library (Sun's RPC) which may be of use to
other MinGW32 application developers.

| What is the status of the ONC rpc source code? Their website
| seemed quite open to re-use. Would it be possible/desirable
| to include these rpc sources with GCL?

The Sun copyright notice which applies to ONCRPC says "unrestricted use"
(with limits, see below.)

That said, the last thing the GNU Common Lisp developers need is
responsibility for the Windows port of RPC (ONCRPC) for two reasons:

1. Our people power is already stretched to the limit.

2. I think that the library should be independent from GCL (or any other
application).  The current source distribution site:

  http://www.plt.rwth-aachen.de/ks/english/oncrpc.html

is of course, nothing but a distribution site as noone maintains the code
and that is unlikely to change.

Until someone with the time and knowledge offers to do that, I think it
might be better just to distribute the MinGW32 binaries from one of the the
MinGW32 library sites eg http://mingwrep.sourceforge.net, or
http://jrfonseca.dyndns.org/projects/gnu-win32/software/ported/index.html.

My main concern is that the package might branch into incompatible streams
as happened with windows ports of libintl (?) and related libraries - a
problem discussed on the MinGW32 list within the past year.


=================== ONCRPC Copyright notice ===========================
 * Sun RPC is a product of Sun Microsystems, Inc. and is provided for
 * unrestricted use provided that this legend is included on all tape
 * media and as a part of the software program in whole or part.  Users
 * may copy or modify Sun RPC without charge, but are not authorized
 * to license or distribute it to anyone else except as part of a product or
 * program developed by the user.
 *
 * SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE
 * WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE.
 *
 * Sun RPC is provided with no support and without any obligation on the
 * part of Sun Microsystems, Inc. to assist in its use, correction,
 * modification or enhancement.
 *
 * SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE
 * INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY SUN RPC
 * OR ANY PART THEREOF.
 *
 * In no event will Sun Microsystems, Inc. be liable for any lost revenue
 * or profits or other special, indirect and consequential damages, even if
 * Sun has been advised of the possibility of such damages.
 *
 * Sun Microsystems, Inc.
 * 2550 Garcia Avenue
 * Mountain View, California  94043

\start
Date: Tue, 24 Jun 2003 22:45:16 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Mike Thomas
Subject: Re: [Gcl-devel] NAG libraries

--- Tim Daly wrote:

> XDR is a data exchange format used to communicate between Axiom's
> lisp code and NAG's fortran library. The NAG library used to be
> an integral part of Axiom but needs to be either (a) tested by
> somebody that actually has a NAG fortran library (which I don't)
> or (b) redone using something like Octave (pain, pain, pain) or
> (c) thrown out (significant functionality loss, not recommended).

I assume some variation of b) will be needed eventually, in the spirit
of openness if nothing else.  I don't know what the best way to go is
by any means, or what licensing restrictions are acceptable, but the
GNU Scientific Library folks seem to have a good list here: 
http://www.ugcs.caltech.edu/info/gsl/gsl-design_1.html#SEC1

As a NAG replacement the most logical one seems to be slatec, to the
newbie eye at least - I suppose fortran might not help if all the calls
have to be redone to conform to a non-NAG interface anyway.

slatec (fortran) http://www.netlib.org/slatec/  I think this is public
domain.

#	SLATEC Common Mathematical Library, Version 4.1, July 1993
#	a comprehensive software library containing over
#	1400 general purpose mathematical and statistical routines
#	written in Fortran 77.

In fortran there is also:

NSWC Mathematics Subroutine Library (fortran)

The NSWC Mathematics Subroutine Library is a collection of Fortran 77
routines specializing in numerical mathematics. It was collected and
developed by the:

   Computing Systems and Networks Division 
   Strategic and Space Systems Department
   U.S. Naval Surface Warfare Center
   Dahlgren Division, Dahlgren Virginia 22448-5000

Documentation for this one is apparently poor.

CERNLIB is largely fortran and GPLed, IIRC, but the site seems to
indicate they use NAG for some parts of the system so it probably
doesn't duplicate enough NAG functionality to be useful.

Anyway, just thought I'd throw those out.  'course, all you old salts
probably knew all about all those already ;-).

CY

\start
Date: Wed, 25 Jun 2003 10:11:16 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: AXIOM server number is undefined
cc: Bill Page

Hi Tim,

On Thu, Jun 19, 2003 at 07:07:30AM -0400, Tim Daly wrote:
<snip> 
> The "using local database" messages are due to the fact
> that I've moved where the databases are loaded from.
> By default they used to be loaded from the mnt/algebra
> subdirectory (since there was no other). Nag changed it
> so they were loaded from a "share" subdirectory. I'm in
> the process of changing it back. This should work:
As a matter of interest, why do you want the databases to live under
mnt?  I realise that if you aren't using CCL, where all the libraries
and interpreter code are shared across platforms, there is less obvious
justification for share but it still seems nicer to only have one set of
databases when you have multiple versions installed on a shared
filesystem.

\start
Date: Wed, 25 Jun 2003 10:20:09 +0100
From: Mike Dewar
To: Jason White
Subject: Re: subscribing to axiom-developer, user interface issues.

Hi Jason,

As it says, the scripts option only applies to subscripts:
G82328 (1) -> )set output scripts no 
G82328 (1) -> subscript(x,[1])    

   (4)  x
         1
                                                                 Type:
Symbol
G82328 (2) -> )set out scripts yes
G82328 (2) -> subscript(x,[1])    

   (5)  x[1]

There are several linear output formats that might suit you better
including TeX, script (an old IBM typsetting language) and Fortran.
For example:
G82328 (7) -> )set output tex on
G82328 (7) -> )set output algebra off
G82328 (7) -> subscript(x,[1])       

$$
x[1] 
\leqno(7)
$$


Mike.

On Sat, Jun 21, 2003 at 04:00:02PM +1000, Jason White wrote:
> A low-priority question:
> 
> To make Axiom output easily readable via synthetic speech or on my braille
> display I need it in a linear format. Partial success can be achieved
> as follows (see the last several lines for the problem):
> 
> (1) -> 1/3
> 
>         1
>    (1)  -
>         3
>                                                        Type: Fraction Integer
> (2) -> )set output fraction
> --------------------------- The fraction Option ---------------------------
> 
>  Description: how fractions are formatted
> 
>  The fraction option may be followed by any one of the following:
> 
>  -> vertical 
>     horizontal
> 
>  The current setting is indicated within the list.
> 
> (2) -> )set output fraction horizontal
> (2) -> %
> 
>    (2)  1/3
>                                                        Type: Fraction Integer
> (3) -> a*x**3+b*x**2+c*x+d=0
> 
>            3      2
>    (3)  a x  + b x  + c x + d= 0
>                                             Type: Equation Polynomial Integer
> (4) -> )set output scripts
> --------------------------- The scripts Option ----------------------------
> 
>  Description: show subscripts,... linearly
> 
>  The scripts option may be followed by any one of the following:
> 
>     yes
>     no
> 
>  The current setting is indicated within the list.
> 
> (4) -> )set output scripts yes
> (4) -> %
> 
>            3      2
>    (4)  a x  + b x  + c x + d= 0
>                                             Type: Equation Polynomial Integer
> (5) ->
> 
> Either the scripts option isn't working or I have misunderstood what
> it is meant to do. That no "current setting" is highlighted in the
> help text suggests this might be a bug.

\start
Date: Wed, 25 Jun 2003 10:22:20 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: Output problem

This works fine in the last NAG version of Axiom, built using CCL.
Mike.

On Sat, Jun 21, 2003 at 07:33:34AM -0400, Tim Daly wrote:
> Juergen,
> 
> 
> > there is a problem with the generation of output
> > (1) -> [ i**3 for i  in 1..10]
> > 
> >    (1)  [1,8,27,64,125,216,343,512,729,100]
> >                                                    Type: List PositiveInteger
> > 
> > If you trace |processInteractive| you can really see, that
> > it's an output problem.
> > 
> > I ran the test with the Linux distribution of axiom and the
> > Linux libraries on FreeBSD. So I think, it's an akcl, not
> > a FreeBSD problem. The bad output does not happen on
> > cmu cl. Probably a rounding problem (the output of 1001
> > is correct)
> 
> Nobody really needs numbers larger than 3 digits :-)
> 
> Curiously, if you do the loop [ i**3 for i  in 1..12] all of the
> other answers are right. 
> 
> The major difference between the CVS version of Axiom and the
> hand-built distribution is the algebra files. The hand-built
> version of the algebra is compiled using NAG's version of Axiom.
> The CVS version is built from the CVS sources. Both give the
> same wrong answer so it may be that the bug is in the output
> routine in the algebra code. 
> 
> Good catch. I'll put it on the known bugs list.

\start
Date: Wed, 25 Jun 2003 10:32:30 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: Documentation
cc: Bertfried Fauser

I believe that the textbook was an interactive version of Bill Jacob's
"Linear Functions and Matrix Theory" book, and it certainly wasn't ever
published.  You would need a lot of code (including the stuff from
TechExplorer that IBM wouldn't let us distribute) to maike it work.  I
saw it demo'd a few times and while a bit flaky (these were early
versions) it was pretty nice.  

Mike.

On Tue, Jun 24, 2003 at 08:26:56PM -0400, Tim Daly wrote:
> Bertfried,
> 
> The only name I have is Rudiger Gebauer. He apparently was the contact
> with IBM while they developed the interactive textbook based on Axiom.
> As far I my IBM contacts are aware it was never published. It would
> be useful to either open-source the technology or the whole book
> with the technology. Perhaps we can work with them to make it
> available again.

\start
Date: Wed, 25 Jun 2003 19:53:47 +1000
From: Jason White
To: Mike Dewar
Subject: Re: subscribing to axiom-developer, user interface issues.

Mike,
Mike Dewar writes:
 > Hi Jason,
 > 
 > As it says, the scripts option only applies to subscripts:

Thanks. I must have misinterpreted the elipsis in the help text
("subscripts,...").

TeX output works quite well.

Also, thank you for making Axiom available as free/open-source software.

While on the subject of output formats, as a longer-term goal, MathML
would probably be a useful addition.

\start
Date: Wed, 25 Jun 2003 11:18:33 +0100
From: Mike Dewar
To: Jason White
Subject: Re: subscribing to axiom-developer, user interface issues.

On Wed, Jun 25, 2003 at 07:53:47PM +1000, Jason White wrote:
> While on the subject of output formats, as a longer-term goal, MathML
> would probably be a useful addition.
I agree.  Actually we started including OpenMath (which in a way is a
superset of MathML) and were planning to include MathML once it
stabilised.

G82328 (2) -> OMwrite sin(x)

   (2)
  "<OMOBJ>
  <OMA>
    <OMS cd="transc1" name="sin"/>
    <OMV name="x"/>
  </OMA>
</OMOBJ>
"

\start
Date: Wed, 25 Jun 2003 07:06:53 -0400
From: Tim Daly
To: Mike Dewar
Subject: Re: Output problem

> This works fine in the last NAG version of Axiom, built using CCL.
> Mike.
> 
> On Sat, Jun 21, 2003 at 07:33:34AM -0400, Tim Daly wrote:
> > Juergen,
> > 
> > 
> > > there is a problem with the generation of output
> > > (1) -> [ i**3 for i  in 1..10]
> > > 
> > >    (1)  [1,8,27,64,125,216,343,512,729,100]
> > >                                                    Type: List PositiveInteger

Yes, the problem seems to be in the underlying lisp. However, I'm in
the process of re-rebuilding the algebra from the original sources
(the LODE category doesn't seem to build) in order to ensure that I
haven't introduced a typo that is causing the problem.

\start
Date: Wed, 25 Jun 2003 07:04:40 -0400
From: Tim Daly
To: Mike Dewar
Subject: Re: AXIOM server number is undefined
cc: Bill Page

> > The "using local database" messages are due to the fact
> > that I've moved where the databases are loaded from.
> > By default they used to be loaded from the mnt/algebra
> > subdirectory (since there was no other). Nag changed it
> > so they were loaded from a "share" subdirectory. I'm in
> > the process of changing it back. This should work:
> As a matter of interest, why do you want the databases to live under
> mnt?  I realise that if you aren't using CCL, where all the libraries
> and interpreter code are shared across platforms, there is less obvious
> justification for share but it still seems nicer to only have one set of
> databases when you have multiple versions installed on a shared
> filesystem.

The problem with share is that the databases might not be common.
In the IBM days I found that some algebra files, for instance, would
not build on some common lisps so the makefiles would exclude the
data from the databases. Database build is a dynamic step that happens
after the algebra build and was "system dependent, ship system" so it
ends up in mnt. There are "system independent, ship system" files but
they also ended up in mnt due to the "ship system" nature. I suppose
there could be a share subdirectory for this category I just haven't
given it any design thought. Basically I'm just following the old ruts.

The other problem with share, which is historically uninteresting at
this point, is that mnt was NFS mounted from multiple systems. Once
the build completes all that is left on the target system is mnt so
share would have to be a subdirectory of mnt. I don't expect to use
NFS any time soon so it's a "don't care" issue. Again, it's because
I'm following ruts in the road rather than some deep design.

\start
Date: Wed, 25 Jun 2003 06:37:15 -0400
From: Earnie Boyd
To: Mike Thomas
Subject:  Re: [Mingw-users] ONCRPC binaries for MinGW32 - where to put it.
cc: Bill Page

Mike Thomas wrote:
> 
> Until someone with the time and knowledge offers to do that, I think it
> might be better just to distribute the MinGW32 binaries from one of the the
> MinGW32 library sites eg http://mingwrep.sourceforge.net, or
> http://jrfonseca.dyndns.org/projects/gnu-win32/software/ported/index.html.
> 

Why, why hot just ask MinGW to host the packages?

> My main concern is that the package might branch into incompatible streams
> as happened with windows ports of libintl (?) and related libraries - a
> problem discussed on the MinGW32 list within the past year.
> 

A problem that could have been avoided if we all work together.

\start
Date: Wed, 25 Jun 2003 07:24:11 -0400
From: Tim Daly
To: Mike Dewar
Subject: Re: Documentation
cc: Bertfried Fauser

> I believe that the textbook was an interactive version of Bill Jacob's
> "Linear Functions and Matrix Theory" book, and it certainly wasn't ever
> published.  You would need a lot of code (including the stuff from
> TechExplorer that IBM wouldn't let us distribute) to maike it work.  I
> saw it demo'd a few times and while a bit flaky (these were early
> versions) it was pretty nice.  
> 
> Mike.
> 
> On Tue, Jun 24, 2003 at 08:26:56PM -0400, Tim Daly wrote:
> > Bertfried,
> > 
> > The only name I have is Rudiger Gebauer. He apparently was the contact
> > with IBM while they developed the interactive textbook based on Axiom.
> > As far I my IBM contacts are aware it was never published. It would
> > be useful to either open-source the technology or the whole book
> > with the technology. Perhaps we can work with them to make it
> > available again.

I'm trying to think thru the issue involved in making Axiom open source.
The key issue, at least in my mind, is to try to communicate from the
designers (of algebra, of boot code, of system facilities, etc) in this
generation to the users/maintainers/developers of the next generation.
IBM and NAG had the luxury of devoting people to the system over many
years so we tended not to write things down or require extensive docs
on the algebra code. As the complexity rises it gets harder to extend.

On the user documentation issue I've been scratching at ideas for how
to bring the pamphlet file structure to the "next level". Ideally you
could download a pamphlet file, "drag and drop" it onto a running Axiom,
automatically fetch any algebra pamphlets (recursively) from the references
section and have all of the parts updated (e.g. the databases, the docs).

Along the way to this idea comes the struggle with user-level documentation.
I'd like to see new algebra added (say as an additional chapter) to an
Axiom textbook automatically. That way the user could find examples and
explanations in "the textbook".

Well, I know that IBM did a lot of work on the textbook subject and
(a) I'd hate to see it die, (b) I'd hope to steal, ummm, build upon
the work already done, (c) see how much of the ideas and machinery
can be reused, and (d) lead the way to a more dynamic form of
publishing the docs (which perhaps we could convince Springer was
worthwhile to use as an electronic form of books).

If I can get the machinery in place then the whole level of Axiom goes
up a step and it is easier (and harder) to extend, maintain, and change.

\start
Date: Wed, 25 Jun 2003 13:06:29 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: AXIOM server number is undefined
cc: Bill Page

Tim,

I think you're confusing what makes sense in a development environment
with what makes sense for a product.  When Axiom was still a product we
had a lot of sites (mainly Universities) maintaining multiple versions
of the product on a shared fileserver.  Its much easier to maintain a
system if multiple copies of files are eliminated.

These days of course disk space isn't an issue and if you're planning to
deliver the system via CVS its much less likely that people will have
multiple, compatible systems. Its not a big deal really.

Cheers, Mike.

On Wed, Jun 25, 2003 at 07:04:40AM -0400, Tim Daly wrote:
> > > The "using local database" messages are due to the fact
> > > that I've moved where the databases are loaded from.
> > > By default they used to be loaded from the mnt/algebra
> > > subdirectory (since there was no other). Nag changed it
> > > so they were loaded from a "share" subdirectory. I'm in
> > > the process of changing it back. This should work:
> > As a matter of interest, why do you want the databases to live under
> > mnt?  I realise that if you aren't using CCL, where all the libraries
> > and interpreter code are shared across platforms, there is less obvious
> > justification for share but it still seems nicer to only have one set of
> > databases when you have multiple versions installed on a shared
> > filesystem.
> 
> The problem with share is that the databases might not be common.
> In the IBM days I found that some algebra files, for instance, would
> not build on some common lisps so the makefiles would exclude the
> data from the databases. Database build is a dynamic step that happens
> after the algebra build and was "system dependent, ship system" so it
> ends up in mnt. There are "system independent, ship system" files but
> they also ended up in mnt due to the "ship system" nature. I suppose
> there could be a share subdirectory for this category I just haven't
> given it any design thought. Basically I'm just following the old ruts.
> 
> The other problem with share, which is historically uninteresting at
> this point, is that mnt was NFS mounted from multiple systems. Once
> the build completes all that is left on the target system is mnt so
> share would have to be a subdirectory of mnt. I don't expect to use
> NFS any time soon so it's a "don't care" issue. Again, it's because
> I'm following ruts in the road rather than some deep design.

\start
Date: Wed, 25 Jun 2003 13:16:50 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: Documentation
cc: Bertfried Fauser

I suspect that one of the reasons why Springer didn't pursue the project
was that the machinery was too specific to generalise easily to other
books.  There is an economic problem in that the normal "production cost"
of a textbook is low - if you assume that its based on existing academic
lecture notes - and so the break-even point is low.  This is
particularly important in Europe where we have very little in the way of
a common University syllabus for mathematics and so the target audience
for a textbook may be quite small.  Adding interactivity pushes the
price up very substantially.

That being said, for a number of years I've been working with Arjeh
Cohen and his group at Eindhoven who have an interactive textbook,
published by Springer, called "Algebra Interactive!" which is "powered"
by a mixture of Java applets and GAP for heavy algebra.  Its about to go
into its second edition and the communication with the "algebra engine"
will be based on OpenMath, so in theory you ought to be able to plug
other engines in.  I'm sure that they'd be interested in looking at
using OpenAxiom once its reasonably stable, and they might well have
some technology you'd like to adopt.

I'm also aware of some commercial activities in this area but I'm not
sure whether they are public knowledge or not.  In any case its a field
which attracts plenty of interest and I'm sure that a free Axiom would
appeal to authors and publishers alike.

Cheers, Mike.

On Wed, Jun 25, 2003 at 07:24:11AM -0400, Tim Daly wrote:
> > I believe that the textbook was an interactive version of Bill Jacob's
> > "Linear Functions and Matrix Theory" book, and it certainly wasn't ever
> > published.  You would need a lot of code (including the stuff from
> > TechExplorer that IBM wouldn't let us distribute) to maike it work.  I
> > saw it demo'd a few times and while a bit flaky (these were early
> > versions) it was pretty nice.  
> > 
> > Mike.
> > 
> > On Tue, Jun 24, 2003 at 08:26:56PM -0400, Tim Daly wrote:
> > > Bertfried,
> > > 
> > > The only name I have is Rudiger Gebauer. He apparently was the contact
> > > with IBM while they developed the interactive textbook based on Axiom.
> > > As far I my IBM contacts are aware it was never published. It would
> > > be useful to either open-source the technology or the whole book
> > > with the technology. Perhaps we can work with them to make it
> > > available again.
> 
> I'm trying to think thru the issue involved in making Axiom open source.
> The key issue, at least in my mind, is to try to communicate from the
> designers (of algebra, of boot code, of system facilities, etc) in this
> generation to the users/maintainers/developers of the next generation.
> IBM and NAG had the luxury of devoting people to the system over many
> years so we tended not to write things down or require extensive docs
> on the algebra code. As the complexity rises it gets harder to extend.
> 
> On the user documentation issue I've been scratching at ideas for how
> to bring the pamphlet file structure to the "next level". Ideally you
> could download a pamphlet file, "drag and drop" it onto a running Axiom,
> automatically fetch any algebra pamphlets (recursively) from the references
> section and have all of the parts updated (e.g. the databases, the docs).
> 
> Along the way to this idea comes the struggle with user-level documentation.
> I'd like to see new algebra added (say as an additional chapter) to an
> Axiom textbook automatically. That way the user could find examples and
> explanations in "the textbook".
> 
> Well, I know that IBM did a lot of work on the textbook subject and
> (a) I'd hate to see it die, (b) I'd hope to steal, ummm, build upon
> the work already done, (c) see how much of the ideas and machinery
> can be reused, and (d) lead the way to a more dynamic form of
> publishing the docs (which perhaps we could convince Springer was
> worthwhile to use as an electronic form of books).
> 
> If I can get the machinery in place then the whole level of Axiom goes
> up a step and it is easier (and harder) to extend, maintain, and change.

\start
Date: Wed, 25 Jun 2003 18:48:33 +0200
From: David Mentre
To: Jason White
Subject: Re: src/input/Makefile.pamphlet

Jason White writes:

>  > In fact, the whole src/input directory is missing in CVS.
>
> It was added last week. Did you include the -d switch in your CVS
> update command? You need to do this in order to retrieve directories
> which have been added to the repository.

Yes, you are right. I forgot this switch. Thanks.

I think the right command is 'cvs update -Cd'.

\start
Date: Thu, 26 Jun 2003 09:45:40 +1000
From: Mike Thomas
To: list
Subject: ONCRPC binaries for MinGW32 - where to put it.
cc: Bill Page

Hi Earnie.

| > MinGW32 library sites eg http://mingwrep.sourceforge.net, or
| >
| http://jrfonseca.dyndns.org/projects/gnu-win32/software/ported/index.html.
| >
|
| Why, why hot just ask MinGW to host the packages?

True.  I assumed that the MinGW team was not interested in hosting third
party libraries, given the specialised nature of MinGW32 as a Windows
compiler rather than as a Unix emulation system or all-round library
collection.

| > My main concern is that the package might branch into
| incompatible streams
| > as happened with windows ports of libintl (?) and related libraries - a
| > problem discussed on the MinGW32 list within the past year.
| >
|
| A problem that could have been avoided if we all work together.

I agree entirely.  What should I do to pass this bundle on to you guys?  My
memory is that I just built the package by modifying the makefiles, so the
source/build directory structure is just as it came from the original home.

\start
Date: Thu, 26 Jun 2003 11:28:39 +1000
From: Jason White
To: Mike Dewar
Subject: Re: subscribing to axiom-developer, user interface issues.

Mike Dewar writes:
 > On Wed, Jun 25, 2003 at 07:53:47PM +1000, Jason White wrote:
 > > While on the subject of output formats, as a longer-term goal, MathML
 > > would probably be a useful addition.
 > I agree.  Actually we started including OpenMath (which in a way is a
 > superset of MathML) and were planning to include MathML once it
 > stabilised.
 > 
 > G82328 (2) -> OMwrite sin(x)

Interesting. Upon issuing this command under Tim's test release I get:

(1) -> OMwrite sin(x)
 
   >> System error:
   OM-STRINGTOSTRINGPTR is invalid as a function.

protected-symbol-warn called with (NIL)

Another item for the bug list?

\start
Date: Thu, 26 Jun 2003 00:17:08 -0400
From: Tim Daly
To: Jason White
Subject: OMwrite sin(x)
cc: Mike Dewar

Yep, another bug. sigh.

\start
Date: Thu, 26 Jun 2003 13:28:34 +0200 (CEST)
From: Joris van der Hoeven
To: list
Subject: Re: [Texmacs-dev] re: AXIOM server number is undefined
cc: Bill Page

Hi,

Please be careful with the mailing lists you put into your CC;
I am not sure that the TeXmacs developers are interested by
internal discussions about Axiom...

Best wishes, Joris


> Hi Tim,
>
> On Thu, Jun 19, 2003 at 07:07:30AM -0400, Tim Daly wrote:
> <snip>
> > The "using local database" messages are due to the fact
> > that I've moved where the databases are loaded from.
> > By default they used to be loaded from the mnt/algebra
> > subdirectory (since there was no other). Nag changed it
> > so they were loaded from a "share" subdirectory. I'm in
> > the process of changing it back. This should work:
> As a matter of interest, why do you want the databases to live under
> mnt?  I realise that if you aren't using CCL, where all the libraries
> and interpreter code are shared across platforms, there is less obvious
> justification for share but it still seems nicer to only have one set of
> databases when you have multiple versions installed on a shared
> filesystem.

\start
Date: Fri, 27 Jun 2003 17:04:06 -0500
From: James Amundson
To: Cliff Yapp
Subject: Re:  NAG libraries
cc: Bill Page

On Wed, 2003-06-25 at 00:45, C Y wrote:
> I don't know what the best way to go is
> by any means, or what licensing restrictions are acceptable, but the
> GNU Scientific Library folks seem to have a good list here: 
> http://www.ugcs.caltech.edu/info/gsl/gsl-design_1.html#SEC1
> 
> As a NAG replacement the most logical one seems to be slatec, to the
> newbie eye at least - I suppose fortran might not help if all the calls
> have to be redone to conform to a non-NAG interface anyway.

Why don't you think GSL would be the logical choice? Because it is C
instead of Fortran? That shouldn't matter much.


> CERNLIB is largely fortran and GPLed, IIRC, but the site seems to
> indicate they use NAG for some parts of the system so it probably
> doesn't duplicate enough NAG functionality to be useful.

Actually, the folks at CERN are considering switching from NAG to GSL. I
don't know if a decision has been made.

\start
Date: Sat, 28 Jun 2003 11:02:05 +1000
From: Jason White
To: list
Subject: GNU Scientific Library

The main site is at http://www.gnu.org/software/gsl/

\start
Date: Fri, 27 Jun 2003 21:09:03 -0400
From: Bill Page
To: list
Subject: mainVariable(x)$QF

Tim,

I have been spending some time looking at the stack
overflow problem. Perhaps this is something that you
already know but I found that at least one case of
this kind of stack overflow occurs when compiling
category FunctionSpace (fspace.spad.pamphlet).
Specifically, near the end of this file in the context
of

...
  if R has IntegralDomain then

    mainKernel x    == mainVariable(x)$QF
...

The problem apparently arises in when trying to compile
the mainKernel function. If (for the sake of debugging)
you comment those function definitions that involve QF,
then the compilation of category FunctionSpace proceeds.

I have not yet inserted all of the necessary algebra
into the algebra/Makefile.pamphlet, but I will let you
know later this weekend if this approach will allow me
to get any further.

I hope this helps.

\start
Date: Fri, 27 Jun 2003 20:55:20 -0400
From: Bill Page
To: list
Subject: mainVariable(x)$QF

Tim,

I have been spending some time looking at the stack
overflow problem. Perhaps this is something that you
already know but I found that at least one case of
this kind of stack overflow occurs when compiling
category FunctionSpace (fspace.spad.pamphlet).
Specifically, near the end of this file in the context
of

...
  if R has IntegralDomain then

    mainKernel x    == mainVariable(x)$QF
...

The problem apparently arises in when trying to compile
the mainKernel function. If (for the sake of debugging)
you comment those function definitions that involve QF,
then the compilation of category FunctionSpace proceeds.

I have not yet inserted all of the necessary algebra
into the algebra/Makefile.pamphlet, but I will let you
know later this weekend if this approach will allow me
to get any further.

I hope this helps.

\start
Date: Fri, 27 Jun 2003 20:34:32 -0700 (PDT)
From: Cliff Yapp
To: James Amundson
Subject: Re: [Gcl-devel] NAG libraries
cc: Bill Page

--- James Amundson wrote:
> > As a NAG replacement the most logical one seems to be slatec, to
> > the newbie eye at least - I suppose fortran might not help if all 
> > the calls have to be redone to conform to a non-NAG interface 
> > anyway.
> 
> Why don't you think GSL would be the logical choice? Because it is C
> instead of Fortran? That shouldn't matter much.

If switching to C from Fortran isn't a problem as far as restructuring
axiom is concerned, then I agree GSL is definitely the logical choice. 
My working assumption was that NAG Fortran calls -> SLATEC Fortran
calls would be an easier mapping than NAG Fortran calls -> GSL C calls,
but if that's not true than GSL is of course a much more logical choice
- maintained and modernized.
 
> > CERNLIB is largely fortran and GPLed, IIRC, but the site seems to
> > indicate they use NAG for some parts of the system so it probably
> > doesn't duplicate enough NAG functionality to be useful.
> 
> Actually, the folks at CERN are considering switching from NAG to
> GSL. I don't know if a decision has been made.

Oh, cool.  :-)  If they do, perhaps an axiom+GSL combination could make
use of cernlib as well.

\start
Date: 28 Jun 2003 22:00:53 -0400
From: Camm Maguire
To: list
Subject: Re: Report on building axiom cvs 2003-06-23 (i386)

Greetings!

Tim Daly writes:

> David,
> 
> re: (1) ... no rule for Makefile.pamphlet
> 
> Odd. Must have been a bad upload because it doesn't happen here. 
> I'll reload that Makefile.pamphlet file.
> 
> re: (2) ... missing sys-pkg.lisp in debugsys
> 
> I'm a stickler for errors. There shouldn't be error messages (nor
> warning messages if they can be helped (Axiom's current state is
> a huge embarrassment in this regard)). 
> 
> So debugsys should build even if I'm the only user.
> 
> re: (3) ASP34.spad
> 
> There are a number of errors and warnings the algebra build, some
> of which happen even in the NAG version. However, I've resisted the
> urge to fix the algebra code until I'm done getting the rest of the
> problems fixed.
> 
> re: (4) value of EXIT
> 
> methinks this is a bug that is new to GCL 2.5 but I haven't started
> to pursue it yet. I'm not sure if EXIT is new to GCL or what.

Yes, in latest GCL, quit and exit are synonyms for bye.  Hope this
helps. 

Take care,

> 
> re: (5) SPLTREE in french
> 
> je ne comprende pas. Another algebra error.
> 
> re: patches.
> 
> Any and all patches are welcome. This isn't supposed to be a 
> one person project but a community effort; I'm just driving
> the bus.
> 

\start
Date: Sat, 28 Jun 2003 23:41:59 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Report on building axiom cvs 2003-06-23 (i386)

Camm,

re: EXIT

Can you tell me where the best place would be to comment out this change?
We define exit and use it everywhere. In theory they are in different
packages but that's going to take a long time to prove. For the moment
I'd just rather include another patch that undefines the term in GCL.

\start
Date: Sun, 29 Jun 2003 18:15:04 +0200
From: Juergen Weiss
To: list
Subject: Error when converting to a set

The last command in coercels.input converts the result
to a set. With gcl, the result contains duplicate 
elements. Problem does not occur with cmu cl.

\start
Date: Sun, 29 Jun 2003 12:37:16 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: Error when converting to a set

Juergen,

Now THAT's interesting. I've built cmucl but have not yet built Axiom
on top of it. I'm trying to prepare two talks and a Rosetta CD for 
a conference so I'm rather lagged. 

I suspect that the problems we are encountering have to do with the
differences between the common lisps. The problem Bill Page found
( If R has IntegralDomain ) is also related to the underlying common
lisp as far as I can tell. It appears that SET-DIFFERENCE gives 
different (but set-equivalent) answers. For instance, in 

CCL (the NAG common lisp)

(setq a '(a))
(setq b '(a b c))
(set-difference b a) ==> (b c)

GCL

(setq a '(a))
(setq b '(a b c))
(set-difference b a) ==> (c b)

I'm not sure if Axiom depends on this but the compiler uses it to
decide which super-domains need to be processed. In theory it shouldn't
make any difference. In practice it means that the tree-walk will take
branches in a different order. 

I suspect the bug you've found and the bug related to the short-set
[1000] ==> [100] are related to subtle lisp differences.

Subtle differences in the common lisps are VERY hard to find since they
occur so deep within the processing stack. Ideally Axiom should not depend
on these differences.

Good catch, though. The input files will be used for regression testing
the results so it is important that people verify the answers given.

Tim Daly
axiom@tenkan.org

(my Tim Daly account seems to be VERY unreliable lately. please use
the axiom@tenkan.org id instead).

\start
Date: 29 Jun 2003 21:38:26 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel]  Re: Report on building axiom cvs 2003-06-23 (i386)

Greetings!

Index: main.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/main.c,v
retrieving revision 1.26
diff -u -r1.26 main.c
--- main.c	1 Mar 2003 22:37:37 -0000	1.26
+++ main.c	30 Jun 2003 01:36:23 -0000
@@ -627,9 +627,9 @@
        ,0,1,NONE,OI,OO,OO,OO,(fixnum exitc),"")
 {	return fLbye(exitc); }
  
-DEFUN_NEW("EXIT",object,fLexit,LISP
-       ,0,1,NONE,OI,OO,OO,OO,(fixnum exitc),"")
-{	return fLbye(exitc); }
+/* DEFUN_NEW("EXIT",object,fLexit,LISP */
+/*        ,0,1,NONE,OI,OO,OO,OO,(fixnum exitc),"") */
+/* {	return fLbye(exitc); } */
  
 
 /*  c_trace(void) */

Tim Daly writes:

> Camm,
> 
> re: EXIT
> 
> Can you tell me where the best place would be to comment out this change?
> We define exit and use it everywhere. In theory they are in different
> packages but that's going to take a long time to prove. For the moment
> I'd just rather include another patch that undefines the term in GCL.

\start
Date: Sun, 29 Jun 2003 21:42:38 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel]  Re: Report on building axiom cvs 2003-06-23 (i386)

re: EXIT. Thanks. -- Tim



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