\start
Date: Fri, 1 Nov 2002 11:48:42 -0500
From: Tim Daly 
To: Bill Page, Robert Morelli,  Philippe Toffin
Subject: Axiom-mail

Gentlemen, 

All three of you (Bill Page, Robert Morelli, and Philippe Toffin) have
expressed interest in helping with Axiom. I'm starting to set up the
machinery so we can communicate. I have a service provider who has
set up CVS services for me where I can practice remote management of
a project while I get the first version of the code set up. I've 
asked for a userid with write access for each of you. Once that arrives
I'll let you know where and how to access the code.

Please do the following: 
 a) download noweb and try a simple example.
 b) make sure you copy list on your emails so
    we have a record of this process. as more developers join I can
    point them at the record and get them up to speed.

The userids should arrive shortly and I'll let you know as soon as
they are available. Working remotely on a project can be frustrating
(I've already done it) and there will be times when you feel like
you are either neglected or out of the loop of the discussions. 
Please try to be patient with your fellow developers. They are all
volunteers like yourself and they have real lives, real time
constraints, and real interests that may not match yours.

Thanks for volunteering.

\start
Date: Fri, 1 Nov 2002 16:54:21 -0500
From: Bill Page 
To: list
Subject:  Re: Axiom-mail

Hello everyone,

Rather than duplicate email, I think I will try sending
this reply just to the axiom-developer list. Tim could
you please let me know if this is ok and if everything is
working as expected with this email list. Is this email
being forwarded to the other people currently interested
in working on AXIOM development?

On 2002/11/01 Fri AM 11:48:42 EST Tim Daly wrote:
> ... 
> Please do the following: 
>  a) download noweb and try a simple example.
>  b) make sure you copy list on your
> emails so we have a record of this process. as more
> developers join I can point them at the record and get
> them up to speed.
>

I am new to noweb but the concept is familiar to me. Also
Linux is not my usual working environment although I do
use it for several things including Aldor and running a
NAT router on my network. I currently use RedHat 7.2 and
intend to install 8.0 pretty soon.

Do any of you have experience with the cygwin environment
under Windows? I the following web site seems to contain
some current information and a detailed recipe for running
noweb (as well as ICON and MikTex) under cygwin on Windows:

  http://www.literateprogramming.com/noweb/nowebinstall.html

I have tried this and it seems to work exactly as
advertised.

Will it be possible for me to use the cygwin environment
for develop work on AXIOM? If it is possible, do you think
it is advisable?

\start
Date: Fri, 1 Nov 2002 21:57:49 -0500
From: Tim Daly 
To: Bill Page, Robert Morelli, Philippe Toffin
Subject:  Re: Status

All,

Be sure you've subscribed to the axiom-developer mailing list as I'll only
be copying the list from now on so we can journal the discussions. I urge
you to actually try these instructions because it will make sure that we
share the same ability to create, use and view pamphlets. If these
instructions don't work for you let me know because we need to make
sure you've got a proper environment set up.

I've uploaded 3 examples of literate programming to illustrate styles.

An Algebra Example:

The first is called dhmatrix.pamphlet. The instructions for use are:

1)  wget http://home.earthlink.net/~jgg964/dhmatrix.pamphlet
2)  notangle dhmatrix.pamphlet >dhmatrix.spad
3)  noweave dhmatrix.pamphlet >dhmatrix.tex
4)  latex dhmatrix.tex
5)  latex dhmatrix.tex
6)  xdvi dhmatrix.dvi

step (1) will fetch the file. (wget is a useful utility for fetching
   files given by a url. how you actually get the file is up to you)
step (2) will read the pamphlet file and create a spad file.
   spad is the algebra language of Axiom. This file is extracted from
   the pamphlet file and when diff'ed against the original source
   shows no difference (an important point since we don't want to
   introduce errors by wrapping the original source files into a
   literate style).
step (3) will extract the tex output from the pamphlet file. notice
   that the dhmatrix.tex file has commands like \documentclass 
   prepended automatically by noweb. This is, in general, not what
   we want so normally we will use the -delay parameter to noweave.
   However for this particular example I am experimenting with the
   ability to collect many pamphlets into a booklet and I deliberately
   left off the \documentclass, etc. The default behavior of noweb
   works in this case.
step (4) and (5) read the dhmatrix.tex file and create dhmatrix.dvi
   We need to latex it twice to get the cross-references right. I
   don't believe there are any cross-references in this file yet but
   I do this by habit.
step (6) will let us view the dhmatrix.dvi file. You could also use
   other utilities like dvips to create a postscript file or dvipdf
   to create a pdf file. I tend to work directly from the dvi file.

The dhmatrix.pamphlet file is an example of documenting the algebra
code. The original dhmatrix.spad file (which I wrote) was taken from
Richard Paul's Ph.D. thesis which became a book (Robot Manipulators).
Richard gave me permission to quote from his thesis for documenting
the domain. There is much more work to be done but this pamphlet was
written as a first experiment.

In general I hope to search out primary sources for the algebra
that lives in Axiom and either get permission to directly quote
the relevant paper or study the paper and write a new pamphlet.
There is a large piece of work to track down the original works.

The next piece of algebra documentation is to use Barry Trager's
Ph.D. thesis to document the integration code. I have his thesis
and permission to use it for documentation purposes. There is a
long leap from the thesis to the code so I have a fair bit of
background research I need to do before I can write up the 
pamphlet. The original thesis is 85 pages.



A MAKEFILE Example:

The second file I've uploaded is actually from the sources we'll
be using. It is a Makefile in the Codemist Common Lisp (CCL) subtree.
The instructions are:

1)  wget http://home.earthlink.net/~jgg964/Makefile.pamphlet
2)  notangle -t8 Makefile.pamphlet >Makefile
3)  noweave -delay Makefile.pamphlet >Makefile.tex
4)  latex Makefile.tex
5)  latex Makefile.tex
6)  xdvi -expert -s 3 Makefile.dvi

step (1) will fetch the file.
step (2) will read the pamphlet file and create the Makefile. Notice
   the -t8 (tabs every 8 spaces) parameter to notangle. In general we
   will need this parameter and it doesn't hurt to have it if there are
   no tabs so we will use it all the time.
step (3) noweave will read the pamphlet file and create the tex output.
   Notice the -delay option to noweave. We have included the \documentstyle
   and other header information in the pamphlet file already. The -delay
   option allows us to do this. Unless the file is going to be included
   as part of a larger document (like the algebra file above) we will
   generally write our own document headers.
steps (4) and (5) are latex->dvi done twice to get reference right.
   You are certain to get a complaint about a missing noweb.sty file
   because this Makefile was ripped out of the real source tree.
   For demo purposes you can modify the line in the original pamphlet
   file from:
\usepackage{/home/axiomgnu/new/mnt/linux/bin/tex/noweb}
   to:
\usepackage{noweb}
   and rerun the command. I would ask you to resist the urge to 
   change the tex file directly as you need to think of the pamphlet
   file as the source and everything else as machine-generated files.
step (6) invokes xdvi with -expert (which eliminates the buttons as
   I know the keyboard commands) and -s 3 (which gives sufficient
   magnification so I can read it).

This makefile shows a documentation style for Makefiles in general.

Makefiles are generally very verbose in their stanzas because we will
not be doing compiles in the same directories as the source files nor
will we be depending on default stanzas to do compiles. 

We need to document the various stanzas and any special options that
we might add to the compile commands. Look for the TPD string which
I use to ifdef any changes I made to the original C sources. This
shows up as a -DTPD on the compile line for that particular stanza.

Also note that the end of the Makefile.tex contains references to
other pamphlets. The reason for these to support a future plan. We'd
like to be able to accept new code, particularly algebra code, that
we can add to the system in a reasonably automated fashion. The 
references will give us this connection. I expect to expand the
format later. These are only placeholders.

The other reason for the references is that the commands are not
actually documented in the Makefile. The Makefile only documents
build information and other special instructions. For instance,
in another Makefile (not shown here) you need to build a special
Axiom library before you build the C code. While the Makefiles
know this it would be easy for a human to overlook. Instructions
on how to use a particular command as well as documentation on
the C code that implements the command do not belong in the Makefile
but reside in the pamphlet file for the command itself.

Makefiles will also contain information about what a particular
directory contains and why it exists in the source tree.



A Non-Axiom Example:

This is an example using Java to show how to build a stand-alone
command and its Makefile

1)  wget http://home.earthlink.net/~jgg964/Magman.pamphlet
2)  notangle -t8 Magman.pamphlet >Makefile
3)  make

This illustrates a couple of useful points. First, the default
output of running notangle is the stanza marked <<*>>= in the
original source file. In Magman.pamphlet this is the Makefile.
If you read the dvi file that gets generated (or read the
generated Makefile if you must (sigh)) you will see that we
use the -R feature of notangle. The -R flag will extract particular
tags from the pamphlet file. So, if this were C code we could embed
the .h file, the .c file, and the associated Makefile into the pamphlet 
and send them as one file.

Another point is that this pamphlet file has real mathematics and
real references in it. We will need this to explain sections of Axiom.
In the long term plan we want people to submit papers to an Axiom 
Journal that includes the mathematics and executable code. That way
reviewers can test the code, readers can understand the code, the
system can import the code and maintainers can update the code.

This code is not related to Axiom but is here to illustrate the
embedded Makefile and mathematics points. If you don't have Java 
this will fail but that is not important. Note that we mix Java
C and Makefile in the same pamphlet file.

\start
Date: Sun, 3 Nov 2002 22:10:06 -0500
From: Bill Page
To: Tim Daly
Subject:  examples

Tim,

I have successfully downloaded your 3 sample pamphlet
files and completed the recommended exercises. So far
everything seems to be working ok for me win cygwin
under Windows XP just as you describe. It seems to me
that this should work quite well.

Let me know when you have the user id for access to
CVS.

Thanks.

Bill Page.

> -----Original Message-----
> 
> All,
> 
> Be sure you've subscribed to the axiom-developer mailing list 
> as I'll only be copying the list from now on so we can 
> journal the discussions. I urge you to actually try these 
> instructions because it will make sure that we share the same 
> ability to create, use and view pamphlets. If these 
> instructions don't work for you let me know because we need 
> to make sure you've got a proper environment set up.
> 
> I've uploaded 3 examples of literate programming to illustrate styles.
> 
> An Algebra Example:
> 
> The first is called dhmatrix.pamphlet. The instructions for use are:
> 
> 1)  wget http://home.earthlink.net/~jgg964/dhmatrix.pamphlet
> 2)  notangle dhmatrix.pamphlet >dhmatrix.spad
> 3)  noweave dhmatrix.pamphlet >dhmatrix.tex
> 4)  latex dhmatrix.tex
> 5)  latex dhmatrix.tex
> 6)  xdvi dhmatrix.dvi
> 
> step (1) will fetch the file. (wget is a useful utility for fetching
>    files given by a url. how you actually get the file is up 
> to you) step (2) will read the pamphlet file and create a spad file.
>    spad is the algebra language of Axiom. This file is extracted from
>    the pamphlet file and when diff'ed against the original source
>    shows no difference (an important point since we don't want to
>    introduce errors by wrapping the original source files into a
>    literate style).
> step (3) will extract the tex output from the pamphlet file. notice
>    that the dhmatrix.tex file has commands like \documentclass 
>    prepended automatically by noweb. This is, in general, not what
>    we want so normally we will use the -delay parameter to noweave.
>    However for this particular example I am experimenting with the
>    ability to collect many pamphlets into a booklet and I deliberately
>    left off the \documentclass, etc. The default behavior of noweb
>    works in this case.
> step (4) and (5) read the dhmatrix.tex file and create dhmatrix.dvi
>    We need to latex it twice to get the cross-references right. I
>    don't believe there are any cross-references in this file yet but
>    I do this by habit.
> step (6) will let us view the dhmatrix.dvi file. You could also use
>    other utilities like dvips to create a postscript file or dvipdf
>    to create a pdf file. I tend to work directly from the dvi file.
> 
> The dhmatrix.pamphlet file is an example of documenting the 
> algebra code. The original dhmatrix.spad file (which I wrote) 
> was taken from Richard Paul's Ph.D. thesis which became a 
> book (Robot Manipulators). Richard gave me permission to 
> quote from his thesis for documenting the domain. There is 
> much more work to be done but this pamphlet was written as a 
> first experiment.
> 
> In general I hope to search out primary sources for the 
> algebra that lives in Axiom and either get permission to 
> directly quote the relevant paper or study the paper and 
> write a new pamphlet. There is a large piece of work to track 
> down the original works.
> 
> The next piece of algebra documentation is to use Barry 
> Trager's Ph.D. thesis to document the integration code. I 
> have his thesis and permission to use it for documentation 
> purposes. There is a long leap from the thesis to the code so 
> I have a fair bit of background research I need to do before 
> I can write up the 
> pamphlet. The original thesis is 85 pages.
> 
> 
> 
> A MAKEFILE Example:
> 
> The second file I've uploaded is actually from the sources 
> we'll be using. It is a Makefile in the Codemist Common Lisp 
> (CCL) subtree. The instructions are:
> 
> 1)  wget http://home.earthlink.net/~jgg964/Makefile.pamphlet
> 2)  notangle -t8 Makefile.pamphlet >Makefile
> 3)  noweave -delay Makefile.pamphlet >Makefile.tex
> 4)  latex Makefile.tex
> 5)  latex Makefile.tex
> 6)  xdvi -expert -s 3 Makefile.dvi
> 
> step (1) will fetch the file.
> step (2) will read the pamphlet file and create the Makefile. Notice
>    the -t8 (tabs every 8 spaces) parameter to notangle. In general we
>    will need this parameter and it doesn't hurt to have it if 
> there are
>    no tabs so we will use it all the time.
> step (3) noweave will read the pamphlet file and create the 
> tex output.
>    Notice the -delay option to noweave. We have included the 
> \documentstyle
>    and other header information in the pamphlet file already. 
> The -delay
>    option allows us to do this. Unless the file is going to 
> be included
>    as part of a larger document (like the algebra file above) we will
>    generally write our own document headers.
> steps (4) and (5) are latex->dvi done twice to get reference right.
>    You are certain to get a complaint about a missing noweb.sty file
>    because this Makefile was ripped out of the real source tree.
>    For demo purposes you can modify the line in the original pamphlet
>    file from: \usepackage{/home/axiomgnu/new/mnt/linux/bin/tex/noweb}
>    to:
> \usepackage{noweb}
>    and rerun the command. I would ask you to resist the urge to 
>    change the tex file directly as you need to think of the pamphlet
>    file as the source and everything else as 
> machine-generated files. step (6) invokes xdvi with -expert 
> (which eliminates the buttons as
>    I know the keyboard commands) and -s 3 (which gives sufficient
>    magnification so I can read it).
> 
> This makefile shows a documentation style for Makefiles in general.
> 
> Makefiles are generally very verbose in their stanzas because 
> we will not be doing compiles in the same directories as the 
> source files nor will we be depending on default stanzas to 
> do compiles. 
> 
> We need to document the various stanzas and any special 
> options that we might add to the compile commands. Look for 
> the TPD string which I use to ifdef any changes I made to the 
> original C sources. This shows up as a -DTPD on the compile 
> line for that particular stanza.
> 
> Also note that the end of the Makefile.tex contains 
> references to other pamphlets. The reason for these to 
> support a future plan. We'd like to be able to accept new 
> code, particularly algebra code, that we can add to the 
> system in a reasonably automated fashion. The 
> references will give us this connection. I expect to expand 
> the format later. These are only placeholders.
> 
> The other reason for the references is that the commands are 
> not actually documented in the Makefile. The Makefile only 
> documents build information and other special instructions. 
> For instance, in another Makefile (not shown here) you need 
> to build a special Axiom library before you build the C code. 
> While the Makefiles know this it would be easy for a human to 
> overlook. Instructions on how to use a particular command as 
> well as documentation on the C code that implements the 
> command do not belong in the Makefile but reside in the 
> pamphlet file for the command itself.
> 
> Makefiles will also contain information about what a 
> particular directory contains and why it exists in the source tree.
> 
> 
> 
> A Non-Axiom Example:
> 
> This is an example using Java to show how to build a 
> stand-alone command and its Makefile
> 
> 1)  wget http://home.earthlink.net/~jgg964/Magman.pamphlet
> 2)  notangle -t8 Magman.pamphlet >Makefile
> 3)  make
> 
> This illustrates a couple of useful points. First, the 
> default output of running notangle is the stanza marked 
> <<*>>= in the original source file. In Magman.pamphlet this 
> is the Makefile. If you read the dvi file that gets generated 
> (or read the generated Makefile if you must (sigh)) you will 
> see that we use the -R feature of notangle. The -R flag will 
> extract particular tags from the pamphlet file. So, if this 
> were C code we could embed the .h file, the .c file, and the 
> associated Makefile into the pamphlet 
> and send them as one file.
> 
> Another point is that this pamphlet file has real mathematics 
> and real references in it. We will need this to explain 
> sections of Axiom. In the long term plan we want people to 
> submit papers to an Axiom 
> Journal that includes the mathematics and executable code. 
> That way reviewers can test the code, readers can understand 
> the code, the system can import the code and maintainers can 
> update the code.
> 
> This code is not related to Axiom but is here to illustrate 
> the embedded Makefile and mathematics points. If you don't have Java 
> this will fail but that is not important. Note that we mix 
> Java C and Makefile in the same pamphlet file.

\start
Date: Sun, 3 Nov 2002 21:57:20 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: examples

Excellent. Rumor has it that CCL will run under windows and cygwin so
you might end up taking the lead in applying fixes and testing those
platforms. I'm still getting CCL ready for first release.  Once that
comes out we can see what the windows and cygwin issues are.

\start
Date: Mon, 4 Nov 2002 17:48:52 -0500
From: Bill Page
To: Tim Daly
Subject: Re: examples

Tim,

Ok, that's fine with me. I am willing to run with cygwin
for now. If necessary, I can switch over to Red Hat Linux
on another system later (or maybe I will work in parallel
on both systems if I have enough time).

What is the situation with CCL (Codemist Common Lisp,
right?)? Is Codemist making it public domain? It seems
to me that when I installed REDUCE (also based on CCL),
that the lisp interpreter was "proprietary".

Is there anything in particular you would recommend in
terms of getting ready for CCL?

Regards,
Bill Page.

> 
> From: Tim Daly 
> Date: 2002/11/03 Sun PM 09:57:20 EST
> To: Bill Page
> Subject:  Re: examples
> 
> Excellent. Rumor has it that CCL will run under windows and cygwin so
> you might end up taking the lead in applying fixes and testing those
> platforms. I'm still getting CCL ready for first release.  Once that
> comes out we can see what the windows and cygwin issues are.

\start
Date: Mon, 4 Nov 2002 18:13:28 -0500
From: Bill Page
To: Tim Daly
Subject: Re: examples

Tim,

What is the story about the version of CCL (and Axiom??)
that is available at the Codemist website

  http://www.codemist.co.uk/

(click on the CSL/CCL link). The same thing is also
apparently at

  http://homepage.ntlworld.com/codemist/

In a quick web search several people have apparently
already noticed that this is now available but no one
mentions any notice or statement from Codemist.

> Excellent. Rumor has it that CCL will run under windows and cygwin so
> you might end up taking the lead in applying fixes and testing those
> platforms. I'm still getting CCL ready for first release.  Once that
> comes out we can see what the windows and cygwin issues are.

\start
Date: Mon, 4 Nov 2002 19:44:29 -0500
From: Tim Daly 
To: Bill Page
Subject:  ccl.tgz

re: http://www.codemist.co.uk/ccl.tgz

These were the original files I used for downloading, I believe.
Google must have found them from somewhere. They are massively changed
into literate format in the current system though the pamphlet files
contain little more than source code at the moment.  The makefiles are
wildly different and are documented.  I haven't concentrated on
documenting any of the internals yet except where I need to make
changes. That step will occur when I have cycles to spare.

The REDUCE lisp interpreter was (and portions still are) proprietary.
Arthur Norman has released portions of the code necessary to build Axiom 
under the BSD style license used by NAG.

re: getting ready for CCL

I've created a CVS directory on the real website (it is only
the license directory and it contains the text of the licenses
I've found in the source code consolidated into single files).
See if you can check out the axiom subtree. It should contain
the following structure:

 axiom
   license
     LICENSE.AXIOM
     LICENSE.BULL
     LICENSE.CCL
     LICENSE.EAY
     LICENSE.FSF
     LICENSE.NOWEB
     LICENSE.RAND
     LICENSE.SMC

Please make note of all of the steps required to get these files,
including what pages you had to visit and what permissions you needed
(I believe you'll have to generate an ssh key). I'll use your steps
document as instructions for new developers so try to be as detailed
as possible. Once you can reach these files I'll start CVS adding the
tree I have now. That will allow us to see if you can build the lisps.
It all builds cleanly here but I have a monoculture of Linux systems.

Tim

\start
Date: Mon, 4 Nov 2002 21:26:45 -0500
From: Tim Daly 
To: Bill Page
Subject:  AIM Instant Message

I've registered with the AOL Instant Messenger service under
the screen name of "gnuaxiom". If you have access to this 
service try adding me to your buddy list.

\start
Date: Mon, 4 Nov 2002 19:55:37 -0500
From: Tim Daly 
To: Bill Page
Subject:  ccl.tgz

When you've succeeded doing a CVS checkout I think we should figure
out a mechanism where we can instant message each other (and any other
developers). I know that the AOL things don't run here but there must
be a common format between thee and me. This will vastly shorten the
time it takes to communicate. 

\start
Date: Tue, 5 Nov 2002 06:34:08 -0500
From: Tim Daly 
To: Philippe Toffin
Subject: Re:  Axiom Development

> Daly,
> 
> I have been working with Axiom for many years, first with a version for
> IBM risc6000, (this plattform is not running any more), and now with a
> Linux version that I got from Nag some time ago.
> I am desesperately trying to run my former programs: I enclosed somes
> files with a very simple Domain definition, with one single function;
> you can see the result of the compilation wich is fine, and the result of
> the running wich is interrupted because it does not find the Integers!!!
> 
> I do not know if you are the appropriate person able to tell me what is
> wrong; may be there is some open forum for questions: could you forward
> this if it is the case?
> 
> thanks anyway
> 
> philippe

Philippe,

I'll look at this after work tonight. I'm the "appropriate" person as
I'm the only person. We'll eventually have a task list and a bug list
running (actually, they exist but so far they all come to me anyway
so sending me the files directly is quicker). We have to figure out
who is responsible for what parts of the system which will take time.

I have set up an AOL Instant Messenger client (my screen name is
gnuaxiom). That way everyone who has subscribed to the developer
mailing list will be able to communicate in real time rather than
thru email. 

I'm working to set developers up with write access to CVS on tenkan,
my private CVS server. That way we can make mistakes and work out
details of communicating and working together. The root admin guy
is at a conference until wednesday of this week but I should be ready
shortly after that.

I posted a single directory with a few files in it on the real CVS.
See if you can do a CVS checkout of the tree. You will need to 
create an ssh key (with the -t rsa1 option). You won't yet have
write access to the source but you can read it.

\start
Date: Tue, 5 Nov 2002 06:23:41 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: list of developers

> Bill Page wrote:
> 
> Tim,
> 
> The "Developers List" at
> 
>   http://savannah.nongnu.org/projects/axiom
> 
> still shows only you as a developer. Should I expect to
> see the other three people (including myself) in this list?
> Is this necessary before I can get full access to CVS?
> 
> I have made some first attempts to access the axiom cvs
> repository. I can certainly view it via the web with no
> problem. But I don't seem to be able to use :pserver: access
> (at least not from where I am working for the next 2 days -
> behind a rather strick firewall). I'll try this again from
> home on Thursday.
> 
> I have also set up and registered an SSH key. I understand
> it takes some time to become effective. It is not working
> yet, but I will try again later today.

Bill,

Being on the developer's list will give you write access which we're
really not ready for yet.  People will be added to the list when we've
figured out the rest of the machinery and how we are going to
communicate. And we need to decide areas of responsibility so we don't
clobber each other's code as CVS does not support locking.  Besides,
at the moment there is nothing to modify. We need to filter the first
few changes thru me until I'm sure developers understand the system.
It is a big system and simple changes can have widespread
consequences.  One of the parts we need to get working is a regression
test tree.  That used to be wired into the makefiles but only for the
final algebra. We need to do much more thorough testing.

I'm working on adding developers to the write list on tenkan where I
prototype work and things are much more relaxed as the work is not
publicly available. We can freely damage things there while we work
out the bugs of interacting. Unfortunately the root guy is at a lisp
conference in san fransisco until wednesday.  I'll let you know
further details as soon as I know.

However, you should be able to have read access. Try:

cvs -z3 -d(yourUserId)@savannah.gnu.org:/cvsroot/axiom co axiom

it should prompt you for your RSA key. If it isn't prompting you
for the key you might have generated a key without using the 
-t rsa1 option. It won't let you login but it will let you do 
a checkout. If this doesn't work let me know and we'll debug it.
Be sure to write down whatever you do to fix it as you may be
the first one with the problem but other developers will certainly
fall into the same trap.

As for communications, I succeeded in setting up AIM on linux.
My screen name is gnuaxiom (axiom was either taken or too short).
If you can't get AIM running lets pick a common instant message
platform so we can improve communications. I'd like to figure out
how to log the message streams so we can share the experience but
so far I don't see how to with this client. If I had the cycles
I'd grab the source and hack it in but that's pretty low on the
long list. I'm generally available after about 5pm EST.

I checked further into the CCL source code you found. It might build a
running CCL (I didn't try) but it is missing the files necessary to
support Axiom. The benefit of playing with that file might be that you
learn to build CCL using their makefiles.  This could be good as
you'll know the details of running it under cygwin and windows,
neither of which I can test but both of which it would be nice to have
running.  The down sides are that the makefiles are different and it
won't run Axiom.

\start
Date: Wed, 6 Nov 2002 12:25:34 -0500
From: Bill Page
To: Tim Daly
Subject: Re:  ccl.tgz

Tim,

Unfortunately AOL (and instant messaging in general)
isn't accessible from the computers as my current
"day job". But it shouldn't be a problem when I am at
home (tomorrow).

I have continued to try to access the cvs repository but
I am unable to get past the password prompt that is
generated when I do

$ cvs -dbillpage1@subversions.gnu.org:/cvsroot/axiom co axiom
billpage1@subversions.gnu.org's password:
Permission denied, please try again.
billpage1@subversions.gnu.org's password:
Permission denied, please try again.
billpage1@subversions.gnu.org's password:
Permission denied.
cvs [checkout aborted]: end of file from server

The documentation says that I would get this prompt if
my public key is not being recognized. But I have double
checked everything and I am quite sure that I have
generated the rsa1 key properly. I've set protocol 1 in
the ssh config file and I have uploaded the public key
to Savannah (and waited the appropriate amount of time).
So I don't think that's the problem. I also thought that
maybe the rather strict firewall rules here where I am
working might prevent an SSH connection, but the network
guru's here assure me that SSH should be possible -
although they warn that almost all non-standard port
usage is disabled. I know that the :pserver: protocol on
cvs uses port 2401 which I am quite sure is on the
disabled list, so that explains why anonymous mode also
does not work (if you have not done anything else to
prevent it).

Anyway, tomorrow I will try all this again from the other
side of the firewall from my other machines at home.

Also, in my spare time here I've been poking around the
source for CCL that I downloaded from the Codemist site.
My first attempts to build this under cygwin have been
unsuccessful. There seem to be a number of notes embedded
in make files etc. that need to be consulted and changed
before the make files, as downloaded, will run. There is
also a makemake.c bootstrap program that looks a little
more promising, but although it generated a new set of
make files, those also did not work on my first try.
I don't intend to spend much time on this, but I will let
you know if I make any progress.

I look forward to seeing (and helping to create) the well
documented noweb version of this stuff.

Cheers,
Bill Page.

> 
> From: Tim Daly 
> Date: 2002/11/04 Mon PM 07:55:37 EST
> To: Bill Page
> Subject:  ccl.tgz
> 
> When you've succeeded doing a CVS checkout I think we should figure
> out a mechanism where we can instant message each other (and any other
> developers). I know that the AOL things don't run here but there must
> be a common format between thee and me. This will vastly shorten the
> time it takes to communicate. 

\start
Date: Wed, 6 Nov 2002 12:52:41 -0500
From: Bill Page
To: Tim Daly
Subject: Re:  AIM Instant Message

Tim,

I have the Windows instant messaging thing installed at
home and it is supposed to be AOL compatible. I will give
it a try tomorrow. Actually, I very seldom ever use the
instant stuff since I seldom seem to be online when the
person I want to talk to is also online and I find it
rather inefficient in any case. I prefer email for it's
asynchronicity and offline "think time" (plus spellchecker
<grin>). But if a quick conversation would help, I am not
at all adverse to the old fashioned telephone.

If you want you can reach me at

  (613) 546-9795

when I'm at home (Thursday -> Sunday) or at

  (613) 996-5896

when I am at work.

Regards,
Bill Page.

> 
> Date: 2002/11/04 Mon PM 09:26:45 EST
> From: Tim Daly 
> To: Bill Page
> Subject:  AIM Instant Message
> 
> I've registered with the AOL Instant Messenger service under
> the screen name of "gnuaxiom". If you have access to this 
> service try adding me to your buddy list.

\start
Date: Thu, 7 Nov 2002 00:16:36 -0500
From: Tim Daly 
To: Bill Page
Subject: Re:  AIM Instant Message

Bill,
I've uploaded the latest version to tenkan. 
I'm going to try to contact my sysadmin and get the developers
set up with access so we can experiment with working together.

\start
Date: Thu, 7 Nov 2002 00:14:27 -0500
From: Tim Daly 
To: list
Subject: Re:  Axiom Development
CC: Philippe Toffin

Philippe,

Sorry, I didn't get a chance to look at your problem last night.
I had a surprise presentation I have to set up for a meeting today.

\start
Date: Thu, 7 Nov 2002 00:24:49 -0500
From: Tim Daly 
To: Andrey G. Grozin
Subject:  clef

clef is a single program. the source (without the include files)
is attached. let me know if you need more.

Tim

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

/*
Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

    - Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

    - Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

    - Neither the name of The Numerical ALgorithms Group Ltd. nor the
      names of its contributors may be used to endorse or promote products
      derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

#include "useproto.h"
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <termios.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <errno.h>
#include <signal.h>


#if defined (SGIplatform)
#include <bstring.h>
#endif


#include "edible.h"
#include "com.h"
#include "bsdsignal.h"

#include "bsdsignal.H1"
#include "openpty.H1"
#include "prt.H1"
#include "edin.H1"
#include "wct.H1"
#include "edible.H1"
#include "fnct_key.H1"

#ifdef unlikely
#define log 1
#define logterm 1
#define siglog 1
#endif


#define Cursor_shape(x) 


#ifdef siglog
int sigfile;
char sigbuff[256];
#endif

/*   Here are the term structures I need for setting and resetting the
     terminal characteristics. */

struct termios childbuf;   /* the childs normal operating termio */
struct termios oldbuf;     /* the initial settings */
struct termios rawbuf;     /* the parents raw state, when it is doing nothing */
struct termios canonbuf;   /* set it to be canonical */

/*   the terminals mapping of the function keys */
unsigned char  _INTR, _QUIT, _ERASE, _KILL, _EOF, _EOL, _RES1, _RES2;


int ppid;        /* the parents's parent pid */
int child_pid;   /* the childs process id */

short INS_MODE ;    /* Flag for insert mode */
short ECHOIT = 1;   /* Flag for echoing */
short PTY;          /* Flag which tells me whether I should echo newlines */

int MODE;    /* am I in cbreak, raw, or canonical */

char in_buff[1024];   /* buffer for storing characters read until they are processed */
char buff[MAXLINE];                 /**  Buffers for collecting input and  **/
int  buff_flag[MAXLINE];      /**     flags for whether buff chars
                                           are printing
                                           or non-printing                **/


char controllerPath[20];  /* path name for opening the controller side */
char serverPath[20];      /* path name for opening the server side     */

int contNum, serverNum;          /* file descriptors for pty's */
int num_read;                    /* Number of chars read */

#ifdef log 
int logfd;
char logpath[30];
#endif





int
#ifdef _NO_PROTO
main(argc, argv)
     int argc;
     char *argv[];
#else
main(int argc, char *argv[])
#endif
     
{
  fd_set rfds;                  /* the structure for the select call */
  int code;                    /* return code from system calls */
  char out_buff[MAXLINE];       /* from child and stdin */
  int out_flag[MAXLINE] ; /* initialize the output flags */
  char *program;          /* a string to hold the child program invocation */ 
  char **pargs = 0;             /* holds parts of the command line */
  int not_command = 1;          /* a flag while parsing the command line */
  
  
  
  /* try to get a pseudoterminal to play with */
  if (ptyopen(&contNum, &serverNum, controllerPath, serverPath) == -1) {
    perror("ptyopen failed");
    exit(-1);
  }
  
  /* call the routine that handles signals */
  catch_signals();
  
  /* parse the command line arguments - as with the aixterm  the command 
     argument -e should be last on the line. */
  
  while(*++argv && not_command) {
    if(!strcmp(*argv, "-f"))
      load_wct_file(*++argv);
    else if(!strcmp(*argv, "-e")) {
      not_command = 0;
      pargs = ++argv;
    }
    else {
      fprintf(stderr, "usage: clef [-f fname] -e command\n");
      exit(-1);
    }
  }
  skim_wct(); 
  
#ifdef log 
  sprintf(logpath, "/tmp/cleflog%d", getpid());
  logfd = open(logpath, O_CREAT | O_RDWR, 0666);
#endif
  
  /* get the original termio settings, so the child has them */
  
  if(tcgetattr(0,&childbuf) == -1) {
    perror("clef trying to get the initial terminal settings");
    exit(-1);
  }
  
  /* start the child process */
  
  child_pid = fork();
  switch(child_pid) {
  case -1 :
    perror("clef can't create a new process");
    exit(-1);
  case 0:
    /* CHILD */
    /* Dissasociate form my parents group so all my child processes
       look at my terminal as the controlling terminal for the group */
    setsid();

    
    serverNum = open(serverPath,O_RDWR);
    
    /* since I am the child, I can close ptc, and dup pts for all it
       standard descriptors */
    if( (dup2(serverNum, 0) == -1)  ||
	(dup2(serverNum, 1) == -1) ||
	(dup2(serverNum, 2) == -1)  ) {
      perror("clef trying to dup2");
      exit(-1);
    }
    
    /* since they have been duped, close them */
    close(serverNum);
    close(contNum); 
    
    
    /* To make sure everything is nice, set off enhedit */
    /*    childbuf.c_line = 0; */
    
    /* reconfigure the child's terminal get echoing */
    if(tcsetattr(0, TCSAFLUSH, &childbuf) == -1) {
      perror("clef child trying to set child's terminal");
      exit(-1);
    }
    
    /* fire up the child's process */
    if(pargs){
      execvp( pargs[0], pargs);
      perror("clef trying to execvp its argument");
      fprintf(stderr, "Process --> %s\n", pargs[0]);
    }
    else{
      program = getenv("SHELL");
      if (!program)
	program = strdup("/bin/sh");  
      else 
	program = strdup (program);
      execlp( program,program, 0);
      perror("clef trying to execlp the default child");
      fprintf(stderr, "Process --> %s\n", program);
    }
    exit(-1);
    break;
    /* end switch */
  }
  /* PARENT */
  /* Since I am the parent, I should start to initialize some stuff.
     I have to close the pts side for it to work properly */
  
  close(serverNum);  
  ppid = getppid();
  
  /* Iinitialize some stuff for the reading and writing */
  init_flag(out_flag, MAXLINE);
  define_function_keys();
  init_reader();
  PTY = 1;
  init_parent();
  
  /* Here is the main loop, it simply starts reading characters from
     the std input, and from the child. */
  
  while(1)  {           /* loop forever */
    
    /* use select to see who has stuff waiting for me to handle */
    /* set file descriptors for ptc and stdin */
    FD_ZERO(&rfds);
    FD_SET(contNum,&rfds);
    FD_SET(0,&rfds);
    set_function_chars();
#ifdef log
    {
      char modepath[30];
      sprintf(modepath, "\nMODE = %d\n", MODE);
      write(logfd, modepath, strlen(modepath));
    }
#endif
#ifdef logterm
    {
      struct termio ptermio;
      char pbuff[1024];
      tcgetattr(contNum, &ptermio);
      sprintf(pbuff, "child's settings: Lflag = %d, Oflag = %d, Iflag = %d\n",
	      ptermio.c_lflag, ptermio.c_oflag, ptermio.c_iflag);
      write(logfd, pbuff, strlen(pbuff));
    }
#endif
    
    code = select(FD_SETSIZE,(void *) &rfds, NULL, NULL, NULL);
    for(; code < 0 ;) {
      if(errno == EINTR) {
        check_flip();
        code = select(FD_SETSIZE,(void *) &rfds, NULL, NULL, NULL);
      }
      else  {
        perror("clef select failure");
        exit(-1);
      }
    }
    
    /* reading from the child **/
    if( FD_ISSET(contNum,&rfds)) {       
      if( (num_read = read(contNum, out_buff, MAXLINE)) == -1) { 
        num_read = 0;
      }
#ifdef log 
      write(logfd, "OUT<<<<<", strlen("OUT<<<<<"));
      write(logfd, out_buff, num_read);
#endif
      if(num_read > 0) {
        /* now do the printing to the screen */
        if(MODE!= CLEFRAW) {
          back_up(buff_pntr);
          write(1,out_buff, num_read);
          print_whole_buff();    /* reprint the input buffer */
        }
        else write(1,out_buff, num_read);
      }
    } /* done the child stuff */
    /* I should read from std input */
    else  {
      if(FD_ISSET(0,&rfds)) {          
        num_read = read(0, in_buff, MAXLINE);
#ifdef log 
	write(logfd, "IN<<<<<", strlen("IN<<<<<"));
	write(logfd, in_buff, num_read);
#endif
        check_flip();
        if(MODE == CLEFRAW ) 
          write(contNum, in_buff, num_read);
        else 
          do_reading();
      }
    }
  }
}


void
#ifdef _NO_PROTO
init_parent()
#else
init_parent(void)
#endif
{
  
  /* get the original termio settings, so I never have to check again */
  if(tcgetattr(0, &oldbuf) == -1) {
    perror("clef trying to get terminal initial settings");
    exit(-1);
  }
  
  /* get the settings for my different modes */  
  if ((tcgetattr(0, &canonbuf) == -1) ||
      (tcgetattr(0, &rawbuf) == -1) ) {
    perror("clef trying to get terminal settings");
    exit(-1);
  }
  
     
  canonbuf.c_lflag &= ~(ICANON | ECHO | ISIG); 
  /* read before an eoln is typed */

  canonbuf.c_lflag |= ISIG;
 
  /*  canonbuf.c_line = 0;       turn off enhanced edit */

  canonbuf.c_cc[VMIN] = 1;          /* we want every character  */
  canonbuf.c_cc[VTIME] = 1;         /* these may require tweaking */

  /* also set up the parents raw setting for when needed **/
  rawbuf.c_oflag = rawbuf.c_iflag = rawbuf.c_lflag /* = rawbuf.c_line */ = 0;
  rawbuf.c_cc[VMIN] = 1;
  rawbuf.c_cc[VTIME] = 1;


  if(tcsetattr(0, TCSAFLUSH, &canonbuf) == -1) {
    perror("clef setting parent terminal to canonical processing");
    exit(0);
  }
  
  /* initialize some flags I will be using */
  MODE = CLEFCANONICAL;
  INS_MODE = 1;
  Cursor_shape(2);
}


void 
#ifdef _NO_PROTO
hangup_handler(sig)
     int sig;
#else
hangup_handler(int sig)
#endif
{
#ifdef siglog
  sigfile = open(sigbuff, O_RDWR | O_APPEND);
  write(sigfile, "Hangup Handler\n", strlen("Hangup Handler\n"));
  close(sigfile);
#endif
  /* try to kill my child if it is around */
  if(kill(child_pid, 0)) kill(child_pid, SIGTERM);
  if(kill(ppid, 0) >= 0) {
    /* fix the terminal and exit */
    if(tcsetattr(0, TCSAFLUSH, &oldbuf) == -1) {
      perror("clef restoring terminal in hangup handler");
    }
    printf("\n");
  }
  /* remove the temporary editor filename */
  unlink(editorfilename);
  exit(-1);
}

void 
#ifdef _NO_PROTO
terminate_handler(sig)
     int sig;
#else
terminate_handler(int sig)
#endif
{
#ifdef siglog
  sigfile = open(sigbuff, O_RDWR | O_APPEND);
  write(sigfile, "Terminate Handler\n", strlen("Terminate Handler\n") + 1);
  close(sigfile);
  sleep(1);
#endif
  kill(child_pid, SIGTERM);
  /* fix the terminal, and exit */
  if(tcsetattr(0, TCSAFLUSH, &oldbuf) == -1) {
    perror("clef restoring terminal in terminate handler");
  }
  printf("\n");
  Cursor_shape(2);
  fprintf(stderr, "\n");
  /* remove the temporary editor filename */
  unlink(editorfilename);
  exit(0);
}

void 
#ifdef _NO_PROTO
interrupt_handler(sig)
     int sig;
#else
interrupt_handler(int sig)
#endif
{
#ifdef siglog
  sigfile = open(sigbuff, O_RDWR | O_APPEND);
  write(sigfile, "Interrupt Handler\n", strlen("Interrupt Handler\n") + 1);
  close(sigfile);
  sleep(1);
#endif
  kill(child_pid, SIGINT);
}

void 
#ifdef _NO_PROTO
child_handler(sig)
     int sig;
#else
child_handler(int sig)
#endif
{
#ifdef siglog
  sigfile = open(sigbuff, O_RDWR | O_APPEND );
  write(sigfile, "Child Handler\n", strlen("Child Handler\n") + 1);
  close(sigfile);
#endif
  Cursor_shape(2);
  close(contNum);
  if(kill(ppid, 0) >= 0) {
   /* fix the terminal, and exit */
    if(tcsetattr(0, TCSAFLUSH, &oldbuf) == -1) {
      perror("clef restoring terminal in child handler");
    }
    printf("\n");
  }
  /* remove the temporary editor filename */
  unlink(editorfilename);
  exit(0);
}

void 
#ifdef _NO_PROTO
alarm_handler(sig)
     int sig;
#else
alarm_handler(int sig)
#endif
{
  int newppid = getppid();
#ifdef siglog
  sigfile = open(sigbuff, O_RDWR | O_APPEND);
  write(sigfile, "Alarm Handler\n", strlen("Alarm Handler\n")+ 1 );
  close(sigfile);
#endif
  /* simply gets the parent process id, if different, it terminates ,
    otherwise it resets the alarm */
  
  if(ppid == newppid) {
    alarm(60);
    return;
  }
  else {
    /* once that is done fix the terminal, and exit */
    if(tcsetattr(0, TCSAFLUSH, &oldbuf) == -1) {
      perror("clef restoring terminal in alarm handler");
    }
    Cursor_shape(2);
    fprintf(stderr, "\n");
    /* remove the temporary editor filename */
    unlink(editorfilename);
    exit(0);
  }
}

/* a procedure which tells my parent how to catch signals from its children */
void
#ifdef _NO_PROTO
catch_signals() 
#else
catch_signals(void) 
#endif
{
#ifdef siglog
  sprintf(sigbuff, "/tmp/csig%d", getpid());
  sigfile = open(sigbuff, O_RDWR | O_TRUNC | O_CREAT);
  write(sigfile, "Started \n", strlen("Started \n"));
  close(sigfile);
#endif
  bsdSignal(SIGHUP, hangup_handler,RestartSystemCalls); 
  bsdSignal(SIGCHLD,child_handler,RestartSystemCalls); 
  bsdSignal(SIGTERM, terminate_handler,RestartSystemCalls);
  bsdSignal(SIGINT, interrupt_handler,RestartSystemCalls); 
  bsdSignal(SIGALRM, alarm_handler,RestartSystemCalls);
  alarm(60);
}

/* Here is where I check the child's termio settings, and try to copy them.
   I simply trace through the main modes (CLEFRAW,  CLEFCANONICAL) and
   try to simulate them */
void 
#ifdef _NO_PROTO
check_flip()
#else
check_flip(void)
#endif
{
  return;
  
#if 0
  /*simply checks the termio structure of the child */
  
  if(tcgetattr(contNum, &childbuf) == -1) {
    perror("clef parent getting child's terminal in check_termio");
  }
  if(childbuf.c_lflag & ICANON) {
    if(MODE != CLEFCANONICAL) {
      flip_canonical(contNum);
      MODE = CLEFCANONICAL;
    }
  }
  else {
    if(MODE != CLEFRAW) {
      flip_raw(contNum);
      MODE = CLEFRAW;
    }
  }
  /* While I am here, lets set the echo */
  if(childbuf.c_lflag & ECHO) ECHOIT = 1;
  else ECHOIT = 0;
#endif
}



void
#ifdef _NO_PROTO
flip_raw(chann)
     int chann;
#else
flip_raw(int chann)
#endif
{
  
  if(MODE == CLEFCANONICAL) 
    send_buff_to_child(chann);
  
  if(tcsetattr(0, TCSAFLUSH, &rawbuf) == -1) {
    perror("clef resetting parent to raw ");
    exit(-1);
  }
}


void
#ifdef _NO_PROTO
flip_canonical(chann)
     int chann;
#else
flip_canonical(int chann)
#endif
{
  if(tcsetattr(0, TCSAFLUSH, &canonbuf) == -1) {
    perror("clef resetting parent to canonical ");
    exit(-1);
  }
  if(INS_MODE) 
    Cursor_shape(5);
  else 
    Cursor_shape(2);
}

void
#ifdef _NO_PROTO
etc_get_next_line(line, nr, fd)
     char *line;
     int *nr;
     int fd;
#else
etc_get_next_line(char * line,int * nr,int  fd)
#endif
{
  *nr = read(fd, line, 1024);
  if(*nr == -1) {
    perror("Reading /etc/master");
  }
  if(*nr == 0) {
    fprintf(stderr, "Not found \n");
  }
}

#define etc_whitespace(c) ((c == ' ' || c == '\t')?(1):(0))


void
#ifdef _NO_PROTO
set_function_chars()
#else
set_function_chars(void)
#endif
{
  /* get the special characters */
  _INTR = childbuf.c_cc[VINTR];
  _QUIT = childbuf.c_cc[VQUIT];
  _ERASE = childbuf.c_cc[VERASE];
  _KILL = childbuf.c_cc[VKILL];
  _EOF = childbuf.c_cc[VEOF];
  _EOL = childbuf.c_cc[VEOL];
  return;
}


\start
Date: Thu, 7 Nov 2002 09:06:41 -0500
From: Bill Page
To: list
Subject: RE:  AIM Instant Message

Tim,

On Wednesday, November 06, 2002 12:53 PM I wrote:
> 
> I have the Windows instant messaging thing installed at
> home and it is supposed to be AOL compatible.

Ooops, that's wrong. It is not compatible. Silly me.

I will get AIM installed later today and see if we
can make it work.

\start
Date: Thu, 7 Nov 2002 09:50:00 -0500
From: Bill Page
To: list
Subject:  CVS access

Tim,

Ok I have successfully checked out the axiom module from
the CVS repository using the instructions at

  https://savannah.nongnu.org/cvs/?group=axiom

Working from home, I do not have a "fascist firewall" to
worry about. So the anonymous access via :pserver: worked
fine the first time. The commands I used under the Cygwin
bash shell were:

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

$ cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom login
(Logging in to anoncvs@subversions.gnu.org)
CVS password:

Administrator@ASUS ~
$ cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom
cvs server: Updating axiom
cvs server: Updating axiom/license
U axiom/license/LICENSE.AXIOM
U axiom/license/LICENSE.BULL
U axiom/license/LICENSE.CCL
U axiom/license/LICENSE.EAY
U axiom/license/LICENSE.FSF
U axiom/license/LICENSE.NOWEB
U axiom/license/LICENSE.RAND
U axiom/license/LICENSE.SMC

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

"Developer CVS Access via SSH" was not necessary in order
to checkout the files. But I have generated another rsa1
key for my machine here at home and added to my account
profile at Savannah. In an hour or so (to give Savannah
a chance to update their key database), I will try to do
the checkout again in "developer" mode.

Regards,
Bill Page.

On Wednesday, November 06, 2002 12:26 PM I wrote:
> ... 
> I have continued to try to access the cvs repository but
> I am unable to get past the password prompt that is
> generated when I do
> 
> $ cvs -dbillpage1@subversions.gnu.org:/cvsroot/axiom co axiom 
> billpage1@subversions.gnu.org's password: Permission denied, 
> please try again. billpage1@subversions.gnu.org's password: 
> Permission denied, please try again. 
> billpage1@subversions.gnu.org's password: Permission denied. 
> cvs [checkout aborted]: end of file from server
> 
> The documentation says that I would get this prompt if
> my public key is not being recognized. But I have double 
> checked everything and I am quite sure that I have generated 
> the rsa1 key properly. I've set protocol 1 in the ssh config 
> file and I have uploaded the public key to Savannah (and 
> waited the appropriate amount of time). So I don't think 
> that's the problem. I also thought that maybe the rather 
> strict firewall rules here where I am working might prevent 
> an SSH connection, but the network guru's here assure me that 
> SSH should be possible - although they warn that almost all 
> non-standard port usage is disabled. I know that the 
> :pserver: protocol on cvs uses port 2401 which I am quite 
> sure is on the disabled list, so that explains why anonymous 
> mode also does not work (if you have not done anything else 
> to prevent it).
> 
> Anyway, tomorrow I will try all this again from the other
> side of the firewall from my other machines at home.
> 

\start
Date: Thu, 7 Nov 2002 11:32:21 -0500
From: Bill Page
To: list
Subject:  NAG demo version of AXIOM - flexlm license?

Tim,

It has occurred to me that during our work on the
open source version of AXIOM it would be very nice
to have a previous operational version of AXIOM
available for testing and comparison. To that end
I have installed the Windows PC version of AXIOM
that was sent to me by NAG several years ago. It is
on a Cdrom labelled

 NAG PC/CD Software Collection Edition 5
 PCCD/5 September 1999

I am able to install AXIOM successfully under
Windows XP after copying the install directory
to hard disk and setting NT compatibility mode on
the setup program, but when I run AXIOM, it is
looking for a flexlm license.dat file. The demo
arrangement was that you could ask NAG to send you
a license file by email that was valid for 30 days.
Of course I don't have such a file and therefore
AXIOM (or more specifically, "techexpl.exe") refuses
to run. I get a similar message when I try to run
the TTY interface version).

BTW, what interface is included in the version of
AXIOM with which we will be working?

Anyway, I was wondering if your relationship with
the people at NAG is "flex"ible enough that it would
be possible to ask someone there for a valid license
file? I understand, of course that NAG no longer
supports AXIOM as a product, but perhaps they are
sympathetic to the open source development project?

I don't suppose it would be particularly easy (or
legal) to try to hack around the flex license check...
I was thinking that perhaps it would be possible
to find an old or revised version of techexpl.exe that
does not do this license check and would still be
compatible with the rest of AXIOM. Howe ever I am not
sufficiently familiar with how the interface between
techexplorer and AXIOM works (used to work?). There is
apparently a new version of techexplorer available for
IBM which runs as a browser plug-in. I presume that this
new version would not be compatible with AXIOM, right?

What do you think?

\start
Date: Thu, 7 Nov 2002 17:13:53 +0000
From: Mike Dewar
To: Bill Page
Subject: Re:  NAG demo version of AXIOM - flexlm license?

Dear Bill,

I've already supplied Tim with a copy of the last release of Axiom for
this purpose.  You won't get anywhere with trying to use other versions
of Techexplorer with that version of Axiom because (a) they are
incompatible, and (b) the license management is also in CCL.

Techexplorer remains the property of IBM and while we have rights to
parts of it we were explicitly forbidden to allow the use of any of them
with OpenAxiom.  The sources we released should allow you to build Axiom
under Windows but only with a fairly basic TTY-style interface.  Due to
the complexity of the build process and (until NT 4 came along) the
general flakiness of Windows we always built all the Windows image files
for CCL on Unix, so I'd strongly recommend getting a Linux version
running first before you tackle Windows.

We are very sympathetic to the Open Source project (we wouldn't have
gone to the considerable time and expense to release the code under an
open license otherwise), however I'm not sure whether we can issue new
licenses for old versons of Axiom since this might breach our "severance
agreement" with IBM.

Regards, Mike.


On Thu, Nov 07, 2002 at 11:32:21AM -0500, Bill Page wrote:
> Tim,
> 
> It has occurred to me that during our work on the
> open source version of AXIOM it would be very nice
> to have a previous operational version of AXIOM
> available for testing and comparison. To that end
> I have installed the Windows PC version of AXIOM
> that was sent to me by NAG several years ago. It is
> on a Cdrom labelled
> 
>  NAG PC/CD Software Collection Edition 5
>  PCCD/5 September 1999
> 
> I am able to install AXIOM successfully under
> Windows XP after copying the install directory
> to hard disk and setting NT compatibility mode on
> the setup program, but when I run AXIOM, it is
> looking for a flexlm license.dat file. The demo
> arrangement was that you could ask NAG to send you
> a license file by email that was valid for 30 days.
> Of course I don't have such a file and therefore
> AXIOM (or more specifically, "techexpl.exe") refuses
> to run. I get a similar message when I try to run
> the TTY interface version).
> 
> BTW, what interface is included in the version of
> AXIOM with which we will be working?
> 
> Anyway, I was wondering if your relationship with
> the people at NAG is "flex"ible enough that it would
> be possible to ask someone there for a valid license
> file? I understand, of course that NAG no longer
> supports AXIOM as a product, but perhaps they are
> sympathetic to the open source development project?
> 
> I don't suppose it would be particularly easy (or
> legal) to try to hack around the flex license check...
> I was thinking that perhaps it would be possible
> to find an old or revised version of techexpl.exe that
> does not do this license check and would still be
> compatible with the rest of AXIOM. Howe ever I am not
> sufficiently familiar with how the interface between
> techexplorer and AXIOM works (used to work?). There is
> apparently a new version of techexplorer available for
> IBM which runs as a browser plug-in. I presume that this
> new version would not be compatible with AXIOM, right?
> 
> What do you think?

\start
Date: Thu, 7 Nov 2002 12:56:42 -0500
From: Bill Page
To: list
Subject:  RE: CVS access

Tim,

On Thursday, November 07, 2002 9:50 AM I wrote:
> ... 
> "Developer CVS Access via SSH" was not necessary in order
> to checkout the files. But I have generated another rsa1
> key for my machine here at home and added to my account
> profile at Savannah. In an hour or so (to give Savannah
> a chance to update their key database), I will try to do
> the checkout again in "developer" mode.
> 

I still can't seem to get "developer CVS access" to work
at Savannah. Although I have generated an rsa1 key and
registered the public key in my Savannah account, I still
get the following results:

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

$ cvs -z3 -dbillpage1@subversions.gnu.org:/cvsroot/axiom co axiom
billpage1@subversions.gnu.org's password:
Permission denied, please try again.
billpage1@subversions.gnu.org's password:
Permission denied, please try again.
billpage1@subversions.gnu.org's password:
Permission denied (publickey,password,keyboard-interactive).
cvs [checkout aborted]: end of file from server (consult above messages
if any)

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

Note: The documentation says that I would only be asked
for a password if the authentication fails, but if I do
try to enter a password anyway, after three failed
attempts I don't always get the full

  Permission denied (publickey,password,keyboard-interactive).

message. Sometimes it just says

  Permission denied.

I am beginning to wonder whether this mode works only
if one is also registered as a "developer" for the
project. You explained earlier why at this time only
you are registered as a developer.

\start
Date: Thu, 7 Nov 2002 16:15:29 -0500
From: Tim Daly 
To: Arthur Norman
Subject:  Re: posting CCL

Arthur,

Sorry about that. I collected the licenses from the source code.  I'm
not sure why the license text differs but I must have made a mistake
somewhere.  I've been using the distribution from the website you gave
me not the distribution from nag, as requested. I'll modify the
LICENSE.CCL file that is posted. I have no intention of changing any
licenses in any way. I'm working on the code on a different CVS site
so I can make my mistakes in private and, hopefully, minimize these
issues. Let me know if you see anything else that you'd like me to
change and I'll try to fix it.

Tim

----------------- attached file ---------------------------------

I observe on the Savannah/Axiom web-site that you have posted some
licenses and expect to put CCL there soon. May I requeat that you check
the license that I have released CCL under and do not publish a confusing
file called LICENSE.CCL that differs from it, and that you do not put CCL
files on savannah until this has been checked. Sorry to be a pain! It is
good that things are moving forward.

The only CCL files I have put in a deliberate public place are on
www.codemist.co.uk. CCL files you got via NAG are not intended (certainly
by me) to fall under any license that NAG applies to parts of Axiom that
it itself releases. What follows is the license file that I include in the
distribution on www.codemist.co.uk...

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

                         CCL Public License 1.0
                         ======================


Copyright (C) 2002, Codemist Ltd.  All rights reserved.
acn@codemist.co.uk


Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions 
are met:

(1) Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer. 

(2) Redistributions in binary form must reproduce the above copyright
notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution. 

(3) Neither the name of Codemist nor the names of other contributors may 
be used to endorse or promote products derived from this software without
specific prior written permission. 

(4) If you distribute a modified form or either source or binary code 
  (a) you must make the source form of these modification available 
      to Codemist;
  (b) you grant Codemist a royalty-free license to use, modify
      or redistribute your modifications without limitation;
  (c) you represent that you are legally entitled to grant these rights 
      and that you are not providing Codemist with any code that violates
      any law or breaches any contract.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS 
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED 
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

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


\start
Date: Thu, 7 Nov 2002 17:22:34 -0500
From: Tim Daly 
To: list
Subject: Re:  Re: posting CCL
CC: Arthur Norman

The CVS tree has been updated with your change.  -- Tim

\start
Date: Thu, 7 Nov 2002 18:03:30 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: CVS access

Bill,

The problem is likely that you are not using ssh to do the
connection since the CVS_RSH is not set. If it is not set
I believe that CVS defaults to using RSH and will ask you
to log in. You don't need a login and only need to be a
developer to have write access. I tried checking out the
code as anonymous and it worked.

\start
Date: Thu, 7 Nov 2002 18:01:23 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: CVS access

Bill,

Check that your shell variable CVS_RSH is set to "ssh".

\start
Date: Thu, 7 Nov 2002 18:20:16 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: NAG demo version of AXIOM - flexlm license?

Bill,

I helped install the flexlm hooks into Axiom when it was first
delivered so I'm well aware of how it works. The technical
aspects are not at issue. 

However, I have an agreement with NAG where they have asked
me not to distribute their version of Axiom. While I don't agree
with all the lawyers who have taken over programming I have to 
say that NAG's been very cooperative and helpful. I see every
reason to do anything they ask.

The down side, as you point out, is that developers other than
myself will not have a reference version of the system. However
this will change once we get a clean system build and the NAG
version will quickly become out of date. Thus the issue will be
gone in the near term. Until then it will be up to me to check
the resulting code against the NAG version.

All I can counsel is patience.

\start
Date: Thu, 7 Nov 2002 18:27:36 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: CVS access

Sigh. Actually, I was mistaken in my anonymous test which is unrelated
to the CVS_RSH shell variable. However, setting this variable should
cure the problem. If not, let me know.

\start
Date: Thu, 7 Nov 2002 19:07:44 -0500
From: Bill Page
To: list
Subject: Re: NAG demo version of AXIOM - flexlm license?

Tim,

On Thursday, November 07, 2002 6:20 PM you wrote:
> ... 
> The down side, as you point out, is that developers other 
> than myself will not have a reference version of the system. 
> However this will change once we get a clean system build and 
> the NAG version will quickly become out of date. Thus the 
> issue will be gone in the near term. Until then it will be up 
> to me to check the resulting code against the NAG version.
> 
> All I can counsel is patience.
> 

No problem. I'm just trying to get something interesting
started here on my side.

And thanks also to Mike Dewar for explaining NAG's view
point. I understand why what I asked might be difficult.
I must say that a do really appreciate all of the efforts
that the people at NAG have made to make the source code
for this new "OpenAxiom" available. Thank you very much
indeed!

\start
Date: Thu, 7 Nov 2002 18:47:15 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: CVS access

Ummm, that would make no sense so we must be missing something.
Why would an anonymous user be able to check out the source tree
but not the developer? 

I'll create another id and try it from there.

\start
Date: Thu, 7 Nov 2002 19:07:46 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: CVS access

I've created a new userid, new key pair and registered a new key.
I noticed in the process that there is a checkbox on the 
"account configuration" page titled "Enable CVS admin commands". 
I didn't check that (yet) but that might be related.
In any case, I'll let you know how I solve this.

\start
Date: Thu, 7 Nov 2002 18:54:35 -0500
From: Bill Page
To: list
Subject:  RE: CVS access

Tim,

On Thursday, November 07, 2002 6:01 PM you wrote:
> 
> Check that your shell variable CVS_RSH is set to "ssh".
> 

Yes, I set CVS_RSH to "ssh" as described at

  https://savannah.nongnu.org/cvs/?group=axiom

> The problem is likely that you are not using ssh to do the 
> connection since the CVS_RSH is not set. If it is not set I 
> believe that CVS defaults to using RSH and will ask you to 
> log in.

You are right that I get a different error message
if I do not set CVS_RSH to "ssh", however it does
not work when it is set correctly. If I use the
-t trace option on cvs, I can see that it attempts
to use ssh as the following shell output shows

--------

Administrator@ASUS ~
$ export CVS_RSH=ssh

Administrator@ASUS ~
$ cvs -t -dbillpage1@subversions.gnu.org:/cvsroot/axiom co axiom
cvs checkout: notice: main loop with
CVSROOT=billpage1@subversions.gnu.org:/cvsr
oot/axiom
 -> Starting server: ssh subversions.gnu.org -l billpage1 cvs server
billpage1@subversions.gnu.org's password:
Permission denied, please try again.
billpage1@subversions.gnu.org's password:
Permission denied, please try again.
billpage1@subversions.gnu.org's password:
Permission denied.
cvs [checkout aborted]: end of file from server (consult above
messages if any)

Administrator@ASUS ~
$

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

In fact if I just try to start a secure shell with the
usual command

$ ssh subversions.gnu.org -l billpage1 cvs server

I get the same result.

> You don't need a login and only need to be a 
> developer to have write access. I tried checking out
> the code as anonymous and it worked.

Yes as I said in my earlier message it is possible to
checkout the code as anoncvs via the :pserver: protocol.
In this case no rsa1 key and no ssh is required. This
is described on the Savannah web page I referred to
above.

It seems to me that the ssh type of secure access
would only be required by someone who is intending
to check code back into the repository and perhaps
the check out function does not work in the case of
using ssh if the user is not also been authorized to
check code in.

\start
Date: Thu, 7 Nov 2002 21:01:07 -0500
From: Tim Daly 
To: Bill Page, Mike Dewar, Martin Rubey, Philippe Toffin, Tim Daly Jr.
Subject:  accounts on tenkan

Please send a note to Tim Daly Jr. (no, it is not me)
and tell him your preferred userid and password. He will
set you up with all the necessary things to help develop
Axiom. Tenkan.org is the site where we can "play in the
sandbox" until we work out the coordination issues.

\start
Date: Fri, 8 Nov 2002 06:47:37 -0500
From: Tim Daly 
To: Bill Page
Subject:  AIM

We can't use the AIM client. Somebody broke into my box last night
thru that door. Sigh.

\start
Date: Fri, 8 Nov 2002 10:23:44 -0500
From: Bill Page
To: list
Subject:  RE: AIM


Tim,

Gee, you must live in a rough cyber neighborhood ...
I hope everything is ok.

Are you running a firewall (iptables with NAT or similar
on Linux)? If not it's not that hard to setup and there
are several very simple "How-To's" available that explain
it quite clearly. I connect to the Internet that way and
share the connection with Windows and a wireless LAN here
at home.

Bill.

> We can't use the AIM client. Somebody broke into my box last 
> night thru that door. Sigh.

\start
Date: Mon, 11 Nov 2002 22:28:44 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: accounts on tenkan
CC: Tim Daly Jr.


> Hello Tim and Tim,

Tim Daly Jr. is my son. 

> I take it that you are not the same person but somehow
> related? <grin>
> 
> Thanks for setting up the account. I was able to login
> and to check out files. I did
> 
>   $ cvs ... co axiom
> 
> and I am currently in middle of the process of downloading
> the whole set of project files. It is taking a rather long
> time to download - there are some BIG files in the zips
> directory. Here are a few initial questions. I'll probably
> have more when the download is done and I've had a change
> to look them over a little better.

Yes, there are some "serious big files" in zips at the moment.
There are 3 lisp platforms that Axiom is planned to run on, each
of which has advantages: CCL (Codemist Common Lisp), GCL (Gnu
Common Lisp) and CMUCL (Carnegie-Mellon University Common Lisp).
The current Makefile will build CCL from the lsp/ccl subtree and
GCL from the zips directory. The next version (or the one thereafter)
will also build CMUCL.

> I noticed that the directory structure is a little odd
> 
>   axiom
>     new
>       new
>         license
>         lsp
>         src
>         zips
>       original
>         ...
> 
> Did you intend to have two subdirectories names new?
> Is there a purpose for the outter most one?

The axiom/new/new is a mistake but there is no way to delete directories
thru cvs which is why i set up a practice site. The mistake was not
intentional (by definition, I guess).

The original directory was also a test case and can be ignored.

> 
> BTW, the serious big files in zips seem to be mostly 
> Common Lisp stuff? How does that fit in compared to the
> Codemist Lisp?
> 
> Finally, where should I start? Will the Makefile.pamphlet
> in the .../lsp/ subdirectory build a working CCL? It still
> looks a little "skinny" in terms of documentation... 

You should read the axiom/new/new/Makefile.dvi file (assuming xdvi
works on your machine. otherwise you might need to convert it to
pdf or ps. give me some feedback on formats). In theory you only
need change to axiom/new/new and type make. save a console trace
and we can fix what fails.

The Makefile is set up so you can type 
  make clean
and it will reset you back to the initial conditions. if you
make changes to any files in the source tree they will get
re-expanded when you next type 
  make
i go to great lengths to cache work so the minimum work 
necessary to build a system occurs. However the make clean
will assume you want to start fresh and will destroy everything
(except changes in the src directory).

You can comment out the build of either ccl or gcl in the 
new/lsp/Makefile.pamphlet file (never change the raw Makefile as
it gets rewritten) and the change will happen in the next build.

Alternatively you can comment out the call in the new/Makefile.pamphlet
(which is the top level Makefile source and it treated as special)
but you need to recreate the Makefile by hand. Building the top level
Makefile will assume that you have the mnt/linux/bin/document command
and the mnt/linux/bin/tex/noweb.sty file. These are automatically
created by the 
  make 
command. Once the first make is done you can make changes in the
new/Makefile.pamphlet file and recreate it by typing:
  mnt/linux/bin/document Makefile
(note: not Makefile.pamphlet, just Makefile)

Except for the top level Makefile every other change to the system
should happen magically by typing make in the axiom/new/new directory.
If it doesn't let me know and I'll fix it. The Makefile.pamphlet tree
is supposed to document and automate all of the knowledge necessary
to build a system from scratch.

To test the result you can do:
  cd mnt/linux/bin
  echo "(+ 2 2)" | ./ccl
  echo "(+ 2 2)" | ./gcl

The correct answer is left up to the student but whatever it is
they should be = (but not eq).

> 
> On my side: I've spent some of my spare time today trying
> to build a working version of TeXmacs under Cygwin. It is
> supposed to be posssible but still in "testing" mode
> according to their web site, but very few details were
> provided. So far no success. I've connected to their email
> list for further help.

As for TeXmacs just send a message to Joris van der Hoeven. He's
exceptional at responding. Andrey G. Grozin 
is also quite responsive.

\start
Date: Mon, 11 Nov 2002 23:09:09 -0500
From: Tim Daly 
To: Bill Page
Subject:  documentation

Oh, right. I forgot to mention that you can type:
  cd axiom/new/new
  make document
and it will make the directory structure in the INT
subdirectory mirroring the top level structure:
  new
    int
      lsp
        ccl
          src
      src
        lib
...

Each subdirectory should contain .dvi files which either are a more
complete explanation of the sources or need to be written.  There
should be one .dvi file for each .pamphlet file in the lsp and source
trees.

\start
Date: Tue, 12 Nov 2002 20:50:41 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: first steps

well, THAT went poorly :-)

I guess I should have mentioned that you can change the environment
variables from their default values to your new values. The only 
one you should have to change is the SPAD variable. So, assuming
you tried to install axiom in /usr/local try:

  cd /usr/local/axiom
  make SPAD=/usr/local/axiom

You could either eliminate the extra level of new or include it in
the command line. It won't be there in the final system.

There is a certain catch-22 about using the document command on
the root Makefile. I'll have to give it a bit more thought.

noweb will generate non-fatal errors (the error 1 ignored message)
This is normal in my setup. I have to figure out why but the build
completes fine with the few errors that do occur.

The noweb is part of the 'all' stanza but it is only made the first
time. Once the noweb stanza successfully completes you'll find a
file 'noweb' in the top level directory. If this file exists the
Makefile will not attempt to build noweb. This is documented in 
the Makefile.pamphlet file. Erasing this file will cause noweb to
be rebuilt.

If you want you can build noweb yourself and do a 
  cd /usr/local/axiom
  touch noweb
and the Makefile will no longer attempt to build noweb. Of course
you'll have to do the copy of the final commands into the 
$SPAD/mnt/linux/bin directory.

The "console read hang" is due to a syntax error introduced into the
Makefile.pamphlet file in src/Makefile.pamphlet. In order to reduce
the amount of tex-related output the output is redirected to
$SPAD/obj/tmp/trace. Look at this file for the error. Methinks
you must have changed this file.

Each echoed line from a Makefile stanza has a locally unique number.
You can find problems by looking at the last "Entering directory"
message (which tells you which Makefile will be run) and then
searching the makefile for the unique number. This will tell you
the failing stanza. Search for 'echo' and you should see them.

Your system build failed because you don't have the Xlib libraries.
You need the following RPMS installed to build the system on RedHat 8.0
XFree86-devel-4.2.0-72.i386.rpm (for /usr/X11R6/include/X11/Xlib.h)

Hope this helps.

Tim

========================= attached file =========================

Tim,

Here is the result of my first attempt to use your
Makefile.pamphlet. Perhaps I have included more details
below then you need, but I thought I would give you a
flavor of what I am seeing so far. Please let me know
if I should continue like this or be more brief.

---------
$ cd /usr/src/axiom/new

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ ls
CVS  Makefile  Makefile.dvi  Makefile.pamphlet  README  license  lsp  src  zips

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ make
3 checking directory structure
4 Environment: SPAD=/home/axiomgnu/new LSP=/home/axiomgnu/new/lsp SRC=/home/axio
mgnu/new/src INT=/home/axiomgnu/new/int OBJ=/home/axiomgnu/new/obj SYS=linux MNT
=/home/axiomgnu/new/mnt ZIPS=/home/axiomgnu/new/zips SPADBIN=/home/axiomgnu/new/
mnt/linux/bin CC=gcc RANLIB=ranlib CCLBASE=/home/axiomgnu/new/obj/linux/ccl/ccll
isp TMP=/home/axiomgnu/new/obj/tmp
cp: cannot stat `/home/axiomgnu/new/src/scripts/*': No such file or directory
make: *** [rootdirs] Error 1

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$

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

Note first of all that I eliminated the extra level of
/new/new so compared to what I got from cvs

  axiom/new/* --> axiom/*

Secondly on my system under Cygwin, it is normal to load
new source files in /usr/new, hence the files are in

  /usr/src/axiom

As the above console trace shows, the make stopped when it
could now find the /home/axiomgnu/new directory pointed to
by the variable SPAD.

I read the Makefile.dvi (after converting it to a .pdf file)
but did not see any mention of a hard coded directory
name. Anyway, I continued by changing the SPAD= statement
in the Makefile.pamphlet file. But when I tried to use the
command

  document Makefile

of course my system did not find the document script.
Instead I entered the commands

  notangle -t8 Makefile.pamphlet > Makefile.new
  mv Makefile Makefile.old
  mv Makefile.new Makefile

but then the build process aborted during the make of
noweb as shown below

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

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ pwd
/usr/src/axiom/new

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ vi Makefile.pamphlet

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ notangle -t8 Makefile.pamphlet > Makefile.new

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ ls -l
total 75
drwxrwxrwx    2 Administ None            0 Nov 12 19:31 CVS
-rwxrwxrwx    1 Administ None         2850 Nov  6 20:17 Makefile
-rwxrwxrwx    1 Administ None        39176 Nov  6 20:17 Makefile.dvi
-rw-rw-rw-    1 Administ None         2850 Nov 12 19:52 Makefile.new
-rwxrwxrwx    1 Administ None        24812 Nov 12 19:52 Makefile.pamphlet
-rwxrwxrwx    1 Administ None          106 Nov  6 20:17 README
drwxrwxrwx    3 Administ None         4096 Nov 12 19:31 license
drwxrwxrwx    4 Administ None            0 Nov 12 19:31 lsp
drwxrwxrwx    6 Administ None            0 Nov 12 19:31 src
drwxrwxrwx    4 Administ None            0 Nov 12 19:30 zips

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ mv Makefile Makefile.old

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ mv Makefile.new Makefile

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ make
3 checking directory structure
4 Environment: SPAD=/usr/src/axiom/new LSP=/usr/src/axiom/new/lsp SRC=/usr/src/a
xiom/new/src INT=/usr/src/axiom/new/int OBJ=/usr/src/axiom/new/obj SYS=linux MNT
=/usr/src/axiom/new/mnt ZIPS=/usr/src/axiom/new/zips SPADBIN=/usr/src/axiom/new/
mnt/linux/bin CC=gcc RANLIB=ranlib CCLBASE=/usr/src/axiom/new/obj/linux/ccl/ccll
isp TMP=/usr/src/axiom/new/obj/tmp
5 making noweb
make[1]: [install-shell] Error 1 (ignored)
make[1]: [install-code] Error 1 (ignored)
strip: c/nt: No such file or directory
strip: c/markup: No such file or directory
strip: c/mnt: No such file or directory
strip: c/finduses: No such file or directory
make[1]: *** [install-code] Error 1
make: *** [noweb] Error 2

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$

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

I wonder whether the make of noweb should be included in
the 'all' stanza. I removed it from Makefile.pamphlet and
then tried again but it stopped apparently waiting for
input from the console ... strange.

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

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ vi Makefile.pamphlet

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ notangle -t8 Makefile.pamphlet > Makefile.new

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ mv Makefile.new Makefile

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$ make
3 checking directory structure
4 Environment: SPAD=/usr/src/axiom/new LSP=/usr/src/axiom/new/lsp SRC=/usr/src/a
xiom/new/src INT=/usr/src/axiom/new/int OBJ=/usr/src/axiom/new/obj SYS=linux MNT
=/usr/src/axiom/new/mnt ZIPS=/usr/src/axiom/new/zips SPADBIN=/usr/src/axiom/new/
mnt/linux/bin CC=gcc RANLIB=ranlib CCLBASE=/usr/src/axiom/new/obj/linux/ccl/ccll
isp TMP=/usr/src/axiom/new/obj/tmp
8 making /usr/src/axiom/new/src/Makefile from /usr/src/axiom/new/src/Makefile.pa
mphlet

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

Pressing control-D several times (means end of file on
unix), seemed to allow the build process to continue but
it eventually failed again

----------

7 making /usr/src/axiom/new/src
make[1]: Entering directory `/usr/src/axiom/new/src'
3 making /usr/src/axiom/new/src/scripts/Makefile from /usr/src/axiom/new/src/scr
ipts/Makefile.pamphlet
2 making /usr/src/axiom/new/src/scripts
make[2]: Entering directory `/usr/src/axiom/new/src/scripts'
1 making /usr/src/axiom/new/src/scripts
make[2]: Leaving directory `/usr/src/axiom/new/src/scripts'
7 making /usr/src/axiom/new/src/lib/Makefile from /usr/src/axiom/new/src/lib/Mak
efile.pamphlet
6 making /usr/src/axiom/new/src/lib
make[2]: Entering directory `/usr/src/axiom/new/src/lib'
2 making /usr/src/axiom/new/int/lib/bsdsignal.c from /usr/src/axiom/new/src/lib/
bsdsignal.c.pamphlet
3 making /usr/src/axiom/new/obj/linux/lib/bsdsignal.o from /usr/src/axiom/new/in
t/lib/bsdsignal.c
8 making /usr/src/axiom/new/int/lib/cursor.c from /usr/src/axiom/new/src/lib/cur
sor.c.pamphlet
9 making /usr/src/axiom/new/obj/linux/lib/cursor.o from /usr/src/axiom/new/int/l
ib/cursor.c
11 making /usr/src/axiom/new/int/lib/edin.c from /usr/src/axiom/new/src/lib/edin
.c.pamphlet
12 making /usr/src/axiom/new/obj/linux/lib/edin.o from /usr/src/axiom/new/int/li
b/edin.c
14 making /usr/src/axiom/new/int/lib/fnct_key.c from /usr/src/axiom/new/src/lib/
fnct_key.c.pamphlet
15 making /usr/src/axiom/new/obj/linux/lib/fnct_key.o from /usr/src/axiom/new/in
t/lib/fnct_key.c
17 making /usr/src/axiom/new/int/lib/halloc.c from /usr/src/axiom/new/src/lib/ha
lloc.c.pamphlet
18 making /usr/src/axiom/new/obj/linux/lib/halloc.o from /usr/src/axiom/new/int/
lib/halloc.c
20 making /usr/src/axiom/new/int/lib/openpty.c from /usr/src/axiom/new/src/lib/o
penpty.c.pamphlet
21 making /usr/src/axiom/new/obj/linux/lib/openpty.o from /usr/src/axiom/new/int
/lib/openpty.c
23 making /usr/src/axiom/new/int/lib/pixmap.c from /usr/src/axiom/new/src/lib/pi
xmap.c.pamphlet
24 making /usr/src/axiom/new/obj/linux/lib/pixmap.o from /usr/src/axiom/new/int/
lib/pixmap.c
/usr/src/axiom/new/int/lib/pixmap.c:5:22: X11/Xlib.h: No such file or directory
/usr/src/axiom/new/int/lib/pixmap.c:6:23: X11/Xutil.h: No such file or directory

/usr/src/axiom/new/int/lib/pixmap.c:7:21: X11/Xos.h: No such file or directory
In file included from /usr/src/axiom/new/int/lib/pixmap.c:17:
/usr/src/axiom/new/src/include/spadcolors.h:3:19: X11/X.h: No such file or direc
tory
In file included from /usr/src/axiom/new/int/lib/pixmap.c:17:
/usr/src/axiom/new/src/include/spadcolors.h:27: parse error before "colorMap"
/usr/src/axiom/new/src/include/spadcolors.h:27: warning: data definition has no
type or storage class
In file included from /usr/src/axiom/new/int/lib/pixmap.c:19:
/usr/src/axiom/new/src/include/pixmap.H1:9: parse error before '*' token
/usr/src/axiom/new/src/include/pixmap.H1:10: parse error before '*' token
In file included from /usr/src/axiom/new/int/lib/pixmap.c:21:
/usr/src/axiom/new/src/include/spadcolors.H1:15: parse error before '*' token
/usr/src/axiom/new/src/include/spadcolors.H1:16: parse error before '*' token
/usr/src/axiom/new/src/include/spadcolors.H1:17: parse error before '*' token
/usr/src/axiom/new/src/include/spadcolors.H1:19: parse error before '*' token
/usr/src/axiom/new/src/include/spadcolors.H1:20: parse error before '*' token
In file included from /usr/src/axiom/new/int/lib/pixmap.c:260:
/usr/src/axiom/new/src/include/xpm.h:45:23: X11/Xlib.h: No such file or director
y
/usr/src/axiom/new/src/include/xpm.h:46:24: X11/Xutil.h: No such file or directo
ry
In file included from /usr/src/axiom/new/int/lib/pixmap.c:260:
/usr/src/axiom/new/src/include/xpm.h:121: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:131: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:143: parse error before "Visual"
/usr/src/axiom/new/src/include/xpm.h:143: warning: no semicolon at end of struct
 or union
/usr/src/axiom/new/src/include/xpm.h:144: warning: data definition has no type o
r storage class
/usr/src/axiom/new/src/include/xpm.h:175: parse error before "exactColors"
/usr/src/axiom/new/src/include/xpm.h:175: warning: data definition has no type o
r storage class
/usr/src/axiom/new/src/include/xpm.h:184: parse error before "nalloc_pixels"
/usr/src/axiom/new/src/include/xpm.h:184: warning: data definition has no type o
r storage class
/usr/src/axiom/new/src/include/xpm.h:187: parse error before "alloc_close_colors
"
/usr/src/axiom/new/src/include/xpm.h:187: warning: data definition has no type o
r storage class
/usr/src/axiom/new/src/include/xpm.h:199: parse error before '}' token
/usr/src/axiom/new/src/include/xpm.h:199: warning: data definition has no type o
r storage class
/usr/src/axiom/new/src/include/xpm.h:285: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:291: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:298: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:304: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:311: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:317: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:323: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:329: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:335: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:342: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:348: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:354: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:363: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:386: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:392: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:398: parse error before '*' token
/usr/src/axiom/new/src/include/xpm.h:404: parse error before '*' token
/usr/src/axiom/new/int/lib/pixmap.c:271: parse error before '*' token
/usr/src/axiom/new/int/lib/pixmap.c: In function `read_pixmap_file':
/usr/src/axiom/new/int/lib/pixmap.c:274: parse error before "attr"
/usr/src/axiom/new/int/lib/pixmap.c:275: `XImage' undeclared (first use in this
function)
/usr/src/axiom/new/int/lib/pixmap.c:275: (Each undeclared identifier is reported
 only once
/usr/src/axiom/new/int/lib/pixmap.c:275: for each function it appears in.)
/usr/src/axiom/new/int/lib/pixmap.c:275: `xireturn' undeclared (first use in thi
s function)
/usr/src/axiom/new/int/lib/pixmap.c:278: `attr' undeclared (first use in this fu
nction)
/usr/src/axiom/new/int/lib/pixmap.c:280: `ZPixmap' undeclared (first use in this
 function)
/usr/src/axiom/new/int/lib/pixmap.c:286: `False' undeclared (first use in this f
unction)
/usr/src/axiom/new/int/lib/pixmap.c:294: `display' undeclared (first use in this
 function)
/usr/src/axiom/new/int/lib/pixmap.c:294: `filename' undeclared (first use in thi
s function)
/usr/src/axiom/new/int/lib/pixmap.c:294: `xi' undeclared (first use in this func
tion)
/usr/src/axiom/new/int/lib/pixmap.c:295: invalid type argument of `unary *'
/usr/src/axiom/new/int/lib/pixmap.c:296: invalid type argument of `unary *'
/usr/src/axiom/new/int/lib/pixmap.c: At top level:
/usr/src/axiom/new/int/lib/pixmap.c:314: parse error before '*' token
/usr/src/axiom/new/int/lib/pixmap.c: In function `write_pixmap_file':
/usr/src/axiom/new/int/lib/pixmap.c:317: parse error before "attr"
/usr/src/axiom/new/int/lib/pixmap.c:318: `XImage' undeclared (first use in this
function)
/usr/src/axiom/new/int/lib/pixmap.c:318: `xi' undeclared (first use in this func
tion)
/usr/src/axiom/new/int/lib/pixmap.c:318: `xireturn' undeclared (first use in thi
s function)
/usr/src/axiom/new/int/lib/pixmap.c:322: `dsp' undeclared (first use in this fun
ction)
/usr/src/axiom/new/int/lib/pixmap.c:322: `wid' undeclared (first use in this fun
ction)
/usr/src/axiom/new/int/lib/pixmap.c:322: `x' undeclared (first use in this funct
ion)
/usr/src/axiom/new/int/lib/pixmap.c:322: `y' undeclared (first use in this funct
ion)
/usr/src/axiom/new/int/lib/pixmap.c:322: `AllPlanes' undeclared (first use in th
is function)
/usr/src/axiom/new/int/lib/pixmap.c:322: `ZPixmap' undeclared (first use in this
 function)
/usr/src/axiom/new/int/lib/pixmap.c:324: `fn' undeclared (first use in this func
tion)
make[2]: *** [/usr/src/axiom/new/obj/linux/lib/pixmap.o] Error 1
make[2]: Leaving directory `/usr/src/axiom/new/src/lib'
make[1]: *** [libdir] Error 2
make[1]: Leaving directory `/usr/src/axiom/new/src'
make: *** [srcdir] Error 2

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new
$

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

So that's it for now, maybe you can see some simple things
I might do to make make work a little better.

\start
Date: Tue, 12 Nov 2002 21:02:47 -0500
From: Tim Daly 
To: Bill Page
Subject:  First steps, part-dieu

Ok, I mistyped:

If you installed in /usr/local/axiom you need to set SPAD to include new:

  cd /usr/local/axiom/new
  make SPAD=/usr/local/axiom/new

also the noweb file is in the new directory so the cmds should read:

  cd /usr/local/axiom/new
  touch noweb

I'm not sure if rpm files will install in Cygwin. If not we need to 
find a different method for creating the /usr/X11R6/include/X11 files.

\start
Date: Tue, 12 Nov 2002 22:33:07 -0500
From: Bill Page
To: list
Subject:  Re: first steps

Tim,

On 2002/11/12 Tue PM 08:50:41 EST you wrote:
> 
> well, THAT went poorly :-)
> 

Not to worry ... I know I am making it hard for myself
trying to do this on cygwin right away.

> I guess I should have mentioned that you can change the
> environment variables from their default values to your
> new values. The only one you should have to change is the
> SPAD variable. So, assuming you tried to install axiom
> in /usr/local try:
> 
>   cd /usr/local/axiom
>   make SPAD=/usr/local/axiom
>

Yes, this is good. I think it should be in the Makefile.dvi
and/or in the README file.

> ... 
> If you want you can build noweb yourself and do a 
>   cd /usr/local/axiom
>   touch noweb
> and the Makefile will no longer attempt to build noweb.
> Of course you'll have to do the copy of the final
> commands into the $SPAD/mnt/linux/bin directory.
>

Ok I see how that can work. At the present time the
commands that you included to make noweb fail under
cygwin. I have already installed noweb is a different
way. Some users also may have noweb installed and may
not want to rebuild it. So again, this would be a good
note to put in the README file. Perhaps there is some
reliable way to tell whether noweb has already been
installed? Of course it might be in different places on
different systems.
 
> The "console read hang" is due to a syntax error
> introduced into the Makefile.pamphlet file in
> src/Makefile.pamphlet. In order to reduce the amount of
> tex-related output the output is redirected to
> $SPAD/obj/tmp/trace. Look at this file for the error.
> Methinks you must have changed this file.
>

The contents of the trace file shows that I am missing
the noweb.sty file from my LaTex directory. Apparently
it was latex that was waiting for console input. Perhaps
this is an artifact of the fact that I did not let the
Makefile build noweb for me? In this case I may have to
add the file manually to the

  /usr/share/texmf/tex/latex/base

directory.

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

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new/obj/tmp
$ cat trace
This is TeX, Version 3.14159 (Web2C 7.3.7)
(./Makefile.tex
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))

! LaTeX Error: File `noweb.sty' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)

Enter file name:
! Emergency stop.
<read *>

l.3 \begin
          {document}^^M
No pages of output.
Transcript written on Makefile.log.
This is TeX, Version 3.14159 (Web2C 7.3.7)
(./Makefile.tex
LaTeX2e <2001/06/01>
Babel <v3.7h> and hyphenation patterns for american, french, german, ngerman, n
ohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo))

! LaTeX Error: File `noweb.sty' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)

Enter file name:
! Emergency stop.
<read *>

l.3 \begin
          {document}^^M
No pages of output.
Transcript written on Makefile.log.

Administrator@CANDIS-SYSADM1 /usr/src/axiom/new/obj/tmp
$

-----------------
 
> 
> Your system build failed because you don't have the Xlib
> libraries. You need the following RPMS installed to build
> the system on RedHat 8.0 XFree86-devel-4.2.0-72.i386.rpm
> (for /usr/X11R6/include/X11/Xlib.h)

Hmmm... I did install the cywin standard XFree86 stuff but
maybe that does not include the libraries? This is going
to take a litte more research.

> 
> Hope this helps.
> 

Yes, it helped a lot. I let you know how I progress.

\start
Date: Tue, 12 Nov 2002 22:28:01 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: first steps

Touching any pamphlet file will cause it to be rebuilt during
the make. This requires noweb to exist.

If the make fails to install noweb then the 
$SPAD/mnt/linux/bin/tex/noweb.sty file and the
$SPAD/mnt/linux/bin/notangle and $SPAD/mnt/linux/bin/noweave 
commands will not exist. These two commands and the style file
are required to rebuild a pamphlet. They are built as part of
the noweb build.

Additionally, there is a command called 'document' in 
$SPAD/src/scripts that gets copied to $SPAD/mnt/linux/bin
and is used to build the pamphlet files.

You can create these by hand as follows:

  cd /usr/local/axiom/new
  mkdir -p mnt/linux/bin/tex
  cp (whereEverItExists)/notangle mnt/linux/bin
  cp (whereEverItExists)/noweave mnt/linux/bin
  cp (whereEverItExists)/noweb.sty mnt/linux/bin/tex
  cp src/scripts/* /mnt/linux/bin

The mkdir -p option creates any subdirectories that don't
exist on the specified path if necessary. Once these files
exist in mnt/linux/bin you need to update your PATH:

export PATH=/usr/local/axiom/new/mnt/linux/bin:$PATH

and the notangle, noweave and document commands should exist.

\start
Date: Fri, 15 Nov 2002 20:32:11 -0500
From: Bill Page
To: list
Subject:  making ccl on cygwin

Tim,

I have been trying hard to get CCL to compile
and link under Cygwin. I have resolved most
problems but I've run into a problem with the
"rusty" coding in CCL relating to remote procedure
calls (rpc). There are several variants of the
rpc api, the one being used by CCL is originally
from SUN. Cygwin does not normally include this
so the #include "rpc/rpc.h" is not defined
instead there is a "win32/rpc.h" which has a
somewhat different set of interface routines
and parameters. I was able to locate a version
of the SUN rpc which had been adapted for Cygwin
but it is not being directly maintained by the
Cygwin people. Anyway, after installing it
successfully, I got further with the CCL compile
but then ran into some C code that does not
conform to the standards expected by gcc version
3.2 (at least not with the options that the
Makefile contains).

What version of C compiler are you using? Is
it gcc 3.2 on Red Hat 8.0 linux or some other?

Anyway, I was wondering what you might think
about a some surgery to get rid of what appears
to be some "code rot" in this part of CCL? Is
rpc really needed for Axiom? I can imagine that
it might be relevant to someone interested in
parallel processing versions etc. but I expect
that anyone serious about doing this sort of
development would prefer a more modern inter-
process communication protocol than rpc? No?

What do you think?

\start
Date: Fri, 15 Nov 2002 20:50:39 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: making ccl on cygwin

Bill,

Two possible directions:

First, I'm told that Cygwin has been replaced with native code
that runs directly in Windows which, of course, would require
that you redo your whole environment and seems a bit extreme.

Second, I believe that rpc is used for the graphics but I'm not
certain yet. If you have changes you'd like to propose the best
current path to follow would be to:

(1) modify the .pamphlet files with changes to the code and some
paragraphs explaining what you changed and why.

(2) surround any changes you make in C code with some flag like
-DCYGWIN or -DBXP (Bill X Page). Note that I used -DTPD to mark
some of my changes so I could revisit them later. Add the new
-DBXP flag on the gcc lines of the stanzas that compile the
changed files. Make a note of it in the Makefile.pamphlet file.

(3) create a patch file that can be applied to the original 
.pamphlet file and send me the patches. try to make sure that
a patch implements only one "conceptual" change at a time. 
That is, it might affect several files but only changes one
function, like rpc functionality. I've been making changes also
so I'm going to have to carefully merge your patches with my
changed files.

In general, focus on getting the image built and runnable.
We'll do detailed debugging as we have time.

I'm using redhat 7.2 (gcc 2.95), 7.2 (gcc 2.96) and 8.0 (gcc 3.1)
Send me a patch for the compile flags change you'd like.

I should have the bootsys layer ready to upload shortly.
Once we get out of the C code and into a running lisp life
should be much easier.

\start
Date: Fri, 15 Nov 2002 21:51:50 -0500
From: Tim Daly 
To: Bill Page
Subject:  document command

How are you at writing bash shell scripts?

The document command currently takes one argument
which is the name of a pamphlet file. If the name
ends in .pamphlet it clips it off.

In the Makefiles I call the document command if
there are changes. The document command calls latex
which generates a tremendous amount of output most
of which I ignore. In order to reduce the noise I
code lines like:
   document Makefile >${TMP}/trace

This has a problem. If the .pamphlet file has a 
syntax error then latex will put up a read and hang.
Since the output is being sent to a file nothing
will appear on the console and the whole make
process appears to hang. 

A slightly better solution would be to implement an
option on document to specify the output file like:
   document -o ${TMP}/trace Makefile
Then we can make a global variable called NOISE.
By default we set
   NOISE=-o ${TMP}/trace
and write
   document ${NOISE} Makefile

Then if there is a hung make a developer can write
   make NOISE=
and the lines change into
   document Makefile
which will output all of the latex.

I'm not much of a bash programmer.
If you know bash could you take a stab at 
rewriting document to take a "-o file" option?
If not, I'll look at it.

\start
Date: Sat, 16 Nov 2002 12:36:39 -0500
From: Tim Daly 
To: Bill Page
Subject:  bash script

re: bash script.

Nevermind. I finally beat it into submission.  Apparently you can't
nest if statements and you can't have a space in the assignment
command surrounding the '=' sign.

I'm surprised that comments don't need a character in column 6.
Cretinous language. 
The designers should be shot.

Anyway, it works and it will fix the "hung console" problem
(not really as it will still hang but the real fix will require
more work as i have to figure out how to convince latex not to
read from the console and also return a failing return code so
i can react to it better. sigh)

\start
Date: Sun, 17 Nov 2002 18:00:55 -0500
From: Bill Page
To: list
Subject:  RE: making ccl on cygwin

Tim,

I've succeded in building CCL and am now working
on GCL. GCL should be easier, I hope.

On Friday, November 15, 2002 8:51 PM you wrote:
> 
> Two possible directions:
> 
> First, I'm told that Cygwin has been replaced with
> native code that runs directly in Windows which, of
> course, would require that you redo your whole
> environment and seems a bit extreme.

Although I am willing to work towards a direct Windows
implementation of Axiom, I think the "half-way" point
represented by Cygwin is a better target at this
point - not too far away from Linux but far enough
to represent some (but hopefully not too many)
challenges.

> 
> Second, I believe that rpc is used for the graphics
> but I'm not certain yet. If you have changes you'd
> like to propose the best current path to follow would
> be to:
> 
> (1) modify the .pamphlet files with changes to the
> code and some paragraphs explaining what you changed
> and why.
> 
> (2) surround any changes you make in C code with some
> flag like -DCYGWIN or -DBXP (Bill X Page). Note that
> I used -DTPD to mark some of my changes so I could
> revisit them later. Add the new -DBXP flag on the gcc
> lines of the stanzas that compile the changed files.
> Make a note of it in the Makefile.pamphlet file.
>

I have been able to retain rpc and will mark the few
changes that I needed to make to get it to compile as
you suggest above.
 
> (3) create a patch file that can be applied to the
> original .pamphlet file and send me the patches.
> Try to make sure that a patch implements only one
> "conceptual" change at a time. That is, it might
> affect several files but only changes one function,
> like rpc functionality. I've been making changes 
> also so I'm going to have to carefully merge your
> patches with my changed files.

Ok. By "patch file" do you mean the output of diff?

In the future do you intend to make use of the
"concurrent" functionality of cvs to keep track
of these sort of "parallel" changes?

> 
> In general, focus on getting the image built and
> runnable. We'll do detailed debugging as we have
> time.

Understood.

> 
> I'm using redhat 7.2 (gcc 2.95), 7.2 (gcc 2.96)
> and 8.0 (gcc 3.1) Send me a patch for the compile
> flags change you'd like.

Do you feel like upgrading to the current release
of gcc 3.2?

  http://gcc.gnu.org/gcc-3.2/

It isn't necessary of course but 3.2 is supposed to
be more "standard" than previous versions.

  http://gcc.gnu.org/gcc-3.2/c++-abi.html


> 
> I should have the bootsys layer ready to upload
> shortly. Once we get out of the C code and into a
> running lisp life should be much easier.
> 

I am looking forward to that!

\start
Date: Sun, 17 Nov 2002 18:04:18 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: making ccl on cygwin

I'm uploading and cleaning the cvs at the moment.
I'll answer shortly.

\start
Date: Sun, 17 Nov 2002 19:42:38 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: making ccl on cygwin

I've uploaded the machinery to build bootsys.

In theory you should just need to type make and it
will eventually build obj/linux/bin/bootsys.
You should be able to run this image thus:
  cd obj/linux/bin
  ./bootsys

re: Cygwin. That's fine. I wasn't objecting to using
Cygwin but just passing along information.

re: diff and patch. yes. you should be able to 
   diff -Naur oldfile newfile
do man patch for details

re: using CVS. yes, we'll be using CVS to make these
changes shortly. At the moment I'm doing "forward" work
on CVS, that is, I'm uploading new code as I build it
and clean it up. I'm trying to get a clean version of
CVS and my working directories have acres of cruft that
should never get uploaded (e.g. the partial "original"
directories"). Once I get a grip on CVS we'll work 
exclusively thru CVS. For now, however, please bear
with me and use patch files.

Especially problematic about using CVS for the initial
port to Cygwin is that, to do it correctly, you need to
modify the top level Makefile with new stanzas. You should
be building on obj/cygwin, not obj/linux. I know how to
make that magic happen but I haven't sufficiently explained
it in the Makefile. I'm going to use your example (given
that you get to be the pioneer) to force me to explain
how and why to make changes while porting. 

You may notice three other things in the top level Makefile.
First, you made the contributors list. Second, there is a
FAQ section with your build questions. If you think of more
we should add them. Third, the author line is now Nicolas
Bourbaki. He apparently was a French general that screwed
up badly. In the 30s a group of French mathematicians started
using that pseudonym to publish their results. Given that 
there are many tens of contributors to Axiom it seemed 
unreasonable to attribute particular pieces to anyone and
unreasonable to attribute the pamphlet files to me. So, 
Bourbaki seems like a reasonable alternative.

I've upgraded my redhat 8 box to 3.2. I can't upgrade
the other boxes as I have to use them for other code.
Yes, 3.2 is correct but only if you use the latest
"standard" as the definition of correctness. Most of
the C and C++ code I have is badly broken by the 
language definition changes. I have a lot of things
that need fixing and I need the old compiler to keep
runnable versions of my code. 

The latest version, just to add to your confusion,
is running on GCL, not CCL. I've discovered a problem
with CCL and sent a note to Arthur. CCL isn't really
a common lisp and never pretended to be. However, it
has an obscure model of "compile-file" and I have to 
ponder how to build upon it. Just to continue development
I switched to GCL for the moment. If I've done my job
right you shouldn't notice.

You'll notice that the CVS directory is much lighter to
download. I've gone thru several download/upload iterations
so I can be sure you get a clean copy. The "original" directory
is still built but is empty. It was partially uploaded by 
mistake anyway. The annoying new/new still exists and I'll
fix that soon. The zips directory is lighter as cmucl is gone.
I'll add back an abbreviated version when I get the build to
succeed. It is a matter of some annoyance that CVS will not
delete directories.

\start
Date: Mon, 18 Nov 2002 09:36:10 +0000
From: Mike Dewar
To: Bill Page
Subject: Re:  making ccl on cygwin

Hi Bill,

The versions of Axiom up to 2.2 for Windows were built with Watcom C
because it was the fastest C compiler around at the time.  We moved to
Visual C++ (version 6 I think) for Axiom 2.3 since Watcom C was no
longer supported.  We never built a cygwin version.  The version of CCL
you have is a merge of our latest version with Arthur Norman's, and I
haven't tried building it under Windows.

The license manager certainly needed RPC, as did our link to the NAG
Library (on Unix only).  I'm not sure whether any of the graphics or
sman code used it - I don't think so but I could be wrong.

The code I sent to Tim was tested on Redhat Linux (nominally 6.2 but it
gets patched and upgraded constantly) with gcc 2.91.66.  

Good luck!

Mike.

On Fri, Nov 15, 2002 at 08:32:11PM -0500, Bill Page wrote:
> Tim,
> 
> I have been trying hard to get CCL to compile
> and link under Cygwin. I have resolved most
> problems but I've run into a problem with the
> "rusty" coding in CCL relating to remote procedure
> calls (rpc). There are several variants of the
> rpc api, the one being used by CCL is originally
> from SUN. Cygwin does not normally include this
> so the #include "rpc/rpc.h" is not defined
> instead there is a "win32/rpc.h" which has a
> somewhat different set of interface routines
> and parameters. I was able to locate a version
> of the SUN rpc which had been adapted for Cygwin
> but it is not being directly maintained by the
> Cygwin people. Anyway, after installing it
> successfully, I got further with the CCL compile
> but then ran into some C code that does not
> conform to the standards expected by gcc version
> 3.2 (at least not with the options that the
> Makefile contains).
> 
> What version of C compiler are you using? Is
> it gcc 3.2 on Red Hat 8.0 linux or some other?
> 
> Anyway, I was wondering what you might think
> about a some surgery to get rid of what appears
> to be some "code rot" in this part of CCL? Is
> rpc really needed for Axiom? I can imagine that
> it might be relevant to someone interested in
> parallel processing versions etc. but I expect
> that anyone serious about doing this sort of
> development would prefer a more modern inter-
> process communication protocol than rpc? No?
> 
> What do you think?

\start
Date: Mon, 18 Nov 2002 08:55:43 -0500
From: Tim Daly 
To: Norman Ramsey
Subject: Undefined Chunks behavior

Norman,

Some of the code I'm processing includes files that define
the language used and contains code like:
  <<' Name '>>
which is, of course, view as a chunk. The default behavior of
an undefined chunk elides the << >> pair. It would be more 
useful to me if the default behavior was to output the chunk
exactly as found. Another example is C code that does:
  x << 3 && y >> 2
where again it would be useful to have the default behavior
to be an unchanged output.

Is there a way to do this currently? If not, can you recommend
a place where I could look to apply this change?

\start
Date: Mon, 18 Nov 2002 10:36:01 -0500
From: Tim Daly 
To: Norman Ramsey
Subject:  Re: Undefined Chunks behavior

Thanks. I'll look at the filter technique. Sort of a "do no harm" default.

I'm familiar with the @<< escape but it will mean that I have to change
the original documents whereas defaulting to an unchanged document means
that I don't introduce semantic errors (like lost shifts in C) if I
miss an undefined chunk message. 

\start
Date: Mon, 18 Nov 2002 10:25:47 -0500
From: Norman Ramsey
To: Tim Daly
Subject: Re: Undefined Chunks behavior 

You could write a noweb filter to do this easily enough,
but the `correct', sanctioned way to solve this problem is to
escape the source code by writing, e.g.,

  @<<' Name '@>>

N

\start
Date: Mon, 18 Nov 2002 20:35:36 -0500
From: Tim Daly 
To: Norman Ramsey
Subject: Re: Undefined Chunks behavior

Actually, it appears that the correct fix is to modify modules.c
(line 201 in modules.nw, line 117 in modules.c) to create a new,
dummy Module that expands into <<foo>> if foo is not found and
then calls expand on that.

I don't see how to do this with filters. Perhaps I'm missing something.

\start
Date: Mon, 18 Nov 2002 22:54:08 -0500
From: Tim Daly 
To: Norman Ramsey
Subject: Undefined Chunks behavior

Norman,

I have included two patch files you can apply to change the
behavior for undefined chunks. Previously undefined chunks
generated an error and were elided from the output. Now they are
complained about but included in the output surrounded by 
the << and >> symbols which should recreate the original input.

This seems to do the "least harm" to the file as it reproduces
what it doesn't understand.

The change is explained in the nw file.

To fix these you only need to cd to the noweb/src/c directory
and type:
  patch <modules.c.patch
  patch <modules.nw.patch

(actually, you can feed this original mail file to patch 
and it will "do the right thing" but you probably already 
know that).

I've included both because I ran into a catch-22 when I tried
to notangle modules.nw without having a running notangle.
Clearly that won't be a problem for you.

Tim

======================== modules.nw.patch =============================
--- modules.nw.tpd	Mon Nov 18 20:56:03 2002
+++ modules.nw	Mon Nov 18 21:59:57 2002
@@ -197,11 +197,17 @@
 out as a special case.
 This change probably blows the case where the module being expanded is
 empty.
+
+If the lookup fails then the module (or chunk) is an undefined name.
+We complain about it but want to output the original source.
+We just wrap it in the bogus chunk name in the angle brackets 
+that it must have had in the input and output it. (Tim Daly Nov 13, 2002)
 <<expand a module>>=
 newmod = lookup(p->contents);
 if (newmod==NULL) {
-    errormsg (Error, "undefined chunk name: @<<%s@>>", p->contents);
+    errormsg (Error, "ignoring undefined chunk name: @<<%s@>>", p->contents);
     error=Error;
+    printf("@<<%s@>>",p->contents);
 } else {
     int retcode;
     if (*locformat == 0 && partial_distance == 0) {


======================== modules.c.patch ==============================
--- modules.c	Wed Mar 28 13:49:22 2001
+++ modules.c.tpd	Mon Nov 18 22:26:35 2002
@@ -1,4 +1,3 @@
-#line 50 "modules.nw"
 static char rcsid[] = "$Id: modules.nw,v 2.16 2001/03/28 18:44:46 nr Exp nr $";
 static char rcsname[] = "$Name: v2_10a $";
 #include <stdio.h>
@@ -11,18 +10,14 @@
 #include "columns.h"
 #include "strsave.h"
 
-#line 110 "modules.nw"
 static struct modpart *
 newmodpart(int type, char *s, Location *loc);   /* create a new module part */
 
 static
 void append(Module mp, struct modpart *p);
-#line 227 "modules.nw"
 static int seekcycle(Module mp, Parent parent);
-#line 132 "modules.nw"
 static char *lastfilename = 0;
 static int lastlineno = -1;
-#line 41 "modules.nw"
 Module newmodule (char *modname) {
     Module p = (Module) malloc (sizeof (struct module));
     checkptr(p);
@@ -31,12 +26,10 @@
     p->head = p->tail = NULL;
     return p;
 }
-#line 74 "modules.nw"
 void add_part (Module mp, char *s, Parttype type, Location *loc) {
     struct modpart *p = newmodpart(type,s,loc);
     append (mp,p);
 }
-#line 79 "modules.nw"
 static struct modpart *
 newmodpart(int type, char *s, Location *loc) {
     struct modpart *p = (struct modpart *) malloc (sizeof (struct modpart));
@@ -44,19 +37,15 @@
     p->ptype = type;
     if (s) {
         p->contents = strsave(s);
-        
-#line 104 "modules.nw"
-{ int k = strlen(p->contents)-1;
-  if (p->contents[k] == '\n') p->contents[k] = '\0';
-  else impossible("input line doesn't end with newline");
-}
-#line 87 "modules.nw"
+        { int k = strlen(p->contents)-1;
+          if (p->contents[k] == '\n') p->contents[k] = '\0';
+          else impossible("input line doesn't end with newline");
+        }
     }
     if (loc) p->loc = *loc;
     p->next = NULL;
     return p;
 }
-#line 93 "modules.nw"
 static
 void append(Module mp, struct modpart *p) {
     /* append p to mp's list of modparts */
@@ -67,12 +56,10 @@
         mp->tail = p;
     }
 }
-#line 137 "modules.nw"
 void resetloc(void) {
   lastfilename = 0;
   lastlineno = -1;
 }
-#line 145 "modules.nw"
 int expand (Module mp, int indent, int partial_distance, Parent parent,  
             char *locformat, FILE *out) {
     struct modpart *p;
@@ -80,69 +67,51 @@
     int error=Normal;
     struct parent thismodule; /* the value only matters when we're expanding a module */
 
-    
-#line 219 "modules.nw"
-thismodule.this = mp;
-thismodule.parent = parent;
-#line 153 "modules.nw"
-    
-#line 222 "modules.nw"
-if (seekcycle(mp, parent)) {
-    errormsg(Error, "<<%s>>", mp->name);
-    return Error;
-}
+    thismodule.this = mp;
+    thismodule.parent = parent;
+    if (seekcycle(mp, parent)) {
+        errormsg(Error, "<<%s>>", mp->name);
+        return Error;
+    }
 
-#line 155 "modules.nw"
     for (p=mp->head; p!=NULL; p=p->next) {
         switch (p->ptype) {
-            case STRING:  
-#line 176 "modules.nw"
-if (*(p->contents) != '\0') {
-    if (*locformat) {
-        if (printloc(out,locformat,p->loc,partial_distance) && (p != mp->head))
-              indent_for(partial_distance, out);
-    } else if (partial_distance == 0) {
-        indent_for(indent, out);
-        partial_distance = indent;
-    }
-    fprintf(out,"%s",p->contents);
-    partial_distance = limitcolumn(p->contents, partial_distance);
-}
-#line 157 "modules.nw"
-                                            ;  break;
-            case MODULE:  
-#line 201 "modules.nw"
-newmod = lookup(p->contents);
-if (newmod==NULL) {
-    errormsg (Error, "undefined chunk name: <<%s>>", p->contents);
-    error=Error;
-} else {
-    int retcode;
-    if (*locformat == 0 && partial_distance == 0) {
-        indent_for(indent, out);
-        partial_distance = indent;
-    }
-    retcode = expand (newmod, partial_distance, partial_distance,
-                      &thismodule, locformat, out);
-    if (retcode > error) error = retcode;
-}
-partial_distance = limitcolumn(p->contents, partial_distance + 2) + 2; 
-                                /* account for surrounding brackets */
-#line 158 "modules.nw"
-                                             ; break;
-            case NEWLINE: 
-#line 188 "modules.nw"
-partial_distance = 0;
-putc('\n', out);
-lastlineno++;
-#line 159 "modules.nw"
-                                             ; break;
+            case STRING:  if (*(p->contents) != '\0') {
+                              if (*locformat) {
+                                  if (printloc(out,locformat,p->loc,partial_distance) && (p != mp->head))
+                                        indent_for(partial_distance, out);
+                              } else if (partial_distance == 0) {
+                                  indent_for(indent, out);
+                                  partial_distance = indent;
+                              }
+                              fprintf(out,"%s",p->contents);
+                              partial_distance = limitcolumn(p->contents, partial_distance);
+                          };  break;
+            case MODULE:  newmod = lookup(p->contents);
+                          if (newmod==NULL) {
+                              errormsg (Error, "ignoring undefined chunk name: <<%s>>", p->contents);
+                              error=Error;
+                              printf("<<%s>>",p->contents);
+                          } else {
+                              int retcode;
+                              if (*locformat == 0 && partial_distance == 0) {
+                                  indent_for(indent, out);
+                                  partial_distance = indent;
+                              }
+                              retcode = expand (newmod, partial_distance, partial_distance,
+                                                &thismodule, locformat, out);
+                              if (retcode > error) error = retcode;
+                          }
+                          partial_distance = limitcolumn(p->contents, partial_distance + 2) + 2; 
+                                                          /* account for surrounding brackets */; break;
+            case NEWLINE: partial_distance = 0;
+                          putc('\n', out);
+                          lastlineno++;; break;
             default: impossible("bad part type");
         }
     }
     return error;
 }
-#line 229 "modules.nw"
 static int seekcycle(Module mp, Parent parent) {
     if (parent == NULL) {
         return 0;
@@ -155,57 +124,45 @@
         return 0;
     }
 }
-#line 251 "modules.nw"
 int printloc(FILE *fp, char *fmt, Location loc, int partial) {
     char *p;
     if (*fmt
     && (loc.filename!=lastfilename || lastlineno != loc.lineno)) {
         if (partial) putc('\n',fp);
-        
-#line 263 "modules.nw"
-for (p = fmt; *p; p++) {
-    if (*p == '%') {
-        switch (*++p) {
-            case '%': putc('%', fp);                             break;
-            case 'N': putc('\n', fp);                            break;
-            case 'F': fprintf(fp, "%s", loc.filename);           break;
-            case 'L': fprintf(fp, "%d", loc.lineno);             break;
-            case '-': case '+': 
-                        if (isdigit(p[1]) && p[2] == 'L') {
-                          fprintf(fp, "%d", *p == '+' ? loc.lineno + (p[1] - '0')
-                                                      : loc.lineno - (p[1] - '0'));
-                          p += 2;
-                        } else
-                          
-#line 283 "modules.nw"
-{ static int complained = 0;
-  if (!complained) {
-    errormsg(Error,"Bad format sequence ``%%%c'' in -L%s",*p,fmt);
-    complained = 1;
-  }
-}
-#line 277 "modules.nw"
-                      break;            
-            default:  
-#line 283 "modules.nw"
-{ static int complained = 0;
-  if (!complained) {
-    errormsg(Error,"Bad format sequence ``%%%c'' in -L%s",*p,fmt);
-    complained = 1;
-  }
-}
-#line 278 "modules.nw"
-                                                                break;
+        for (p = fmt; *p; p++) {
+            if (*p == '%') {
+                switch (*++p) {
+                    case '%': putc('%', fp);                             break;
+                    case 'N': putc('\n', fp);                            break;
+                    case 'F': fprintf(fp, "%s", loc.filename);           break;
+                    case 'L': fprintf(fp, "%d", loc.lineno);             break;
+                    case '-': case '+': 
+                                if (isdigit(p[1]) && p[2] == 'L') {
+                                  fprintf(fp, "%d", *p == '+' ? loc.lineno + (p[1] - '0')
+                                                              : loc.lineno - (p[1] - '0'));
+                                  p += 2;
+                                } else
+                                  { static int complained = 0;
+                                    if (!complained) {
+                                      errormsg(Error,"Bad format sequence ``%%%c'' in -L%s",*p,fmt);
+                                      complained = 1;
+                                    }
+                                  }
+                              break;            
+                    default:  { static int complained = 0;
+                                if (!complained) {
+                                  errormsg(Error,"Bad format sequence ``%%%c'' in -L%s",*p,fmt);
+                                  complained = 1;
+                                }
+                              }   break;
+                }
+            } else putc(*p, fp);
         }
-    } else putc(*p, fp);
-}
-#line 257 "modules.nw"
         lastfilename = loc.filename;
         lastlineno = loc.lineno;
         return 1;
     } else return 0;
 }
-#line 309 "modules.nw"
 void remove_final_newline (Module mp) {
         /* remove trailing newline that must be in module */
     if (mp->tail==NULL) /* module has no text */


\start
Date: Tue, 19 Nov 2002 2:32:19 -0500
From: Bill Page
To: Joris van der Hoeven
Subject:  visual literate programming
Cc: Nicolas M. Thiery, Dylan Thurston, Philippe Toffin, Barry Trager, Carlo Traverso, Theodore Thomas Tsikas, Gioia M. Vago, Joris van der Hoeven, Leonid Vaserstein, Nikolay Vassiliev
Tim and Joris,

I have now started to become quite familiar with TeXmacs
and am rather pleased with it's capabilities. I think it
is a good choice for a new graphical front-end for axiom.

By now you (Tim) have authored a number of significant
noweb "pamphlet" files for the new open source version
of axiom and have even made some simple changes to noweb
to accommodate the axiom build process.

It has always seemed quite clear to me that the overall
appearance of a complex system (such as axiom) is strongly
influenced by the environment in which it is developed.
Thus systems developed in a "command line" oriented
environment (the classical Unix environment) tend to be
command line oriented etc. So therefore I am quite
interested in finding ways to continue the development of
axiom from with in the environment in which it will
eventually run. To that end, let me recall your exchange
with Jorix van der Hoeven of last June.

---------

On Fri, 31 May 2002, Tim Daly wrote:

> Axiom's website has been updated
> http://home.earthlink.net/~jgg964/axiom.html
>
>   * Discussion of the Literate Programming

I would just like to remind you that we want to make TeXmacs
an editor for literate programming in the mid-range future.
At the moment David Allouche is working on a very general
dynamic rewriting scheme, which will englobe TMSL (TeXmacs
style language), XSL and literate programming rewriters.
I expect this work to be finished in six months from now.
Among the TeXmacs developers, at least three persons are
very interested in literate programming. At the moment
these three persons are volunteers, but if someone has
some money available, then I think that their projects
could be boosted in a serious way.

Joris van der Hoeven
http://www.texmacs.org: GNU TeXmacs scientific text editor
http://www.math.u-psud.fr/~vdhoeven: personal homepage

---------

I would like to find out what is the current status of the
application of TeXmacs to literate programming and what are
your current thoughts about this subject with respect to
the axiom project.

If it hasn't been done already, I would be quite interested
in attempting to develop an appropriate filter for TeXmacs
which would be able to import a noweb pamphlet file (of the
kind that you are now writing) into a form that could be
directly edited and printed in "noweave/latex" format.
Then one would also want to be able to export both to the
original noweb pamphlet format and also to "notangle" code.

Has there been any new developments in this area? Are there
any other places on the web to look for this kind of work?

\start
Date: Tue, 19 Nov 2002 6:20:19 -0500
From: Bill Page
To: list
Subject:  new Makefile.pamphlet problems

Tim,

I downloaded a new version of the source yesterday. I have
noticed that with the new organization of the makefile
with the platform specific files, the old methode of
restarting the make with

  make clean

no longer works the way it did. I did not see this
documented in the noweave output.

I am planning to create a platform specific makefile for
cygwin following the example in your makefile.pamphlet but
I find the documentation still a little thin about how this
is supposed to work.

Here are a few more quick notes;

1) The use of the 'strip' command causes trouble in the
make for noweb. There is a note to the effect that it is
necessary to comment out this line of the makefile in the
case of HPUX. It seems to apply to cygwin as well. The
problem is that cygwin executable files end with the
extension .exe but strip just takes the name given to it
and in true unix style this has no extension.

2) cygwin cannot handle a copy to /dev/null. It complains
that it cannot create this file. This causes another
problem during the make of noweb. See the ELISP variable
in the makefile. But a cat > /dev/null does seem to work
as expected.

\start
Date: Tue, 19 Nov 2002 06:33:24 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: new Makefile.pamphlet problems

Bill,

Wow, creating a platform file. That's ambitious but I'm happy 
to see you do it. Lets see if I can give you a few quick pointers:

1) The top level Makefile now selects the platform based on the
SYS= variable. Thus you need to set a SYS=cygwin in the top level
default. This used to be parsed out of the SPAD variable (taking
the basename of the SPAD variable) but I've forgotten the magic
I used to make basename expand in the Makefile. Thus just setting
SPAD=......./cygwin used to be enough. I'll fix that eventually.

2) the all: stanza (approx line 500 in Makefile.pamphlet) will
notangle out the appropriate platform-specific Makefile. For example,
if SYS=cygwin it will look for a chunk called <<Makefile.cygwin>>
and extract it. Then it will invoke Make on the newly extracted
Makefile.cygwin.

3) <<Makefile.cygwin>> is responsible for setting the top-level
Makefile variables, setting up appropriate directories, setting
proper command defaults (e.g. strip -> echo) etc. 


More later. I've got to go to work.
Keep up the good work.

\start
Date: Tue, 19 Nov 2002 07:03:02 -0500
From: Tim Daly 
To: Bill Page
Subject:  Makefile.pamphlet

Bill,

I still have a couple minutes before I leave for work....

To handle the strip problem properly you have to think globally. 

1) Find all instances of strip and replace them with ${STRIP}
2) Add STRIP=strip to ALL the platform-specific Makefiles.
3) Add STRIP=${STRIP} to the end of the ENV= line in each 
   platform specific Makefile
   (this step is what propagates the variables to all of the
    children. It creates an environment list for the child because
    the shell allows the syntax
       FOO=bar Baz
    to define FOO in the environment for Baz. We use this fact)
4) Clone one of the platform specific Makefiles which seems
   close to your platform.
5) Set all of the FOO= variable appropriately in your 
   platform specific Makefile
6) Set the STRIP= variable in your platform specific Makefile
   to be STRIP=echo or some other null function.
7) Document everything you do in the pamphlet files

Gotta go...

\start
Date: Tue, 19 Nov 2002 07:18:04 -0500
From: Tim Daly 
To: Bill Page
Subject:  Makefile.pamphlet

Bill,

(one foot out the door....)

Oh, yeah. You should be aware that things will start showing
up in the cygwin directory (e.g. obj/cygwin/... and mnt/cygwin/...)
as a side-effect of changing SYS=

This is the intended effect. It has two implications. First,
we can build multiple platforms from the same files and second,
they can be kept in the same filesystems for distribution.

Also, handle /dev/null just like strip. Make DEVNULL=/dev/null
and spread it around everywhere. Better yet, use DEVNULL=${TMP}/null
as ${TMP} is our guaranteed writable filesystem.

Be very careful (i.e. anal) about where you put stuff. Read the
top level description of the directory structure and
understand the meaning of the 4 directories (src, int, obj and
mnt). The long term goal will be to ship a CD with src and int
already expanded and people will be able to create an obj and
mnt on their system and do a complete build. Thus, AFTER THE
FIRST BUILD, src and int are assumed read-only. 

(really gotta go)

\start
Date: Tue, 19 Nov 2002 20:13:32 -0500
From: Tim Daly 
To: Bill Page
Subject:  visual literate programming
CC: Joris Van Der Hoeven

Bill and Joris,

I've signed up on the mailing list for TeXmacs and I downloaded
the latest version to try it on the pamphlet files. I tried it
against the examples 
http://home.earthlink.net/~jgg964/dhmatrix.pamphlet
http://home.earthlink.net/~jgg964/Makefile.pamphlet
http://home.earthlink.net/~jgg964/Magman.pamphlet

There are several things failing. \subsubsection is wrong.
\cite is wrong and the whole biblio section is broken.
Worst of all is that the <<foo>> chunks of code are
mangled. I also tried it against the dhmatrix.tex, etc
files and it still comes out bent. However, the math
comes out beatifully. It does know quite a few of the
tex directives. It ran Axiom fine from within the buffer.

This isn't a criticism of TeXmacs. It just means we need to
work together to improve the tool and make pamphlet files
into a "standard" for TeXmacs. There are a lot of possible
directions including things like adding an automatic call
to notangle, nountangle so code can be maintained directly
from the pamphlet, including invoking the compiler on the
untangled code. It would be nice to be able to follow 
\cite references to other pamphlets. TeXmacs needs to 
really understand the noweb chunks.

I really would like to make literate programs be the only
"source" files and have the rest happen by magic.

\start
Date: Tue, 19 Nov 2002 20:26:39 -0500
From: Tim Daly 
To: Norman Ramsey
Subject: Undefined Chunks behavior

re: awk filter. 

Thanks.  I've avoided shell programming for all these years and
virtually never use awk. Changing the C code was my only viable option.
I'd already modified the C code by the time your first reply arrived.
Your solution is clearly better. 

Tim


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

 > Actually, it appears that the correct fix is to modify modules.c
 > (line 201 in modules.nw, line 117 in modules.c) to create a new,
 > dummy Module that expands into <<foo>> if foo is not found and
 > then calls expand on that.

Absolutely *don't* do this.  It is not necessary.

 > I don't see how to do this with filters. Perhaps I'm missing something.

Write an awk script that copies all lines to stdout, and in the
process, identifies each @use that has no corresponding @defn.
For each such @use emit this code chunk:

@begin code
@defn this is my text
@text <<this is my text>>
@end code



Norman

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

 > Norman,
 > 
 > I have included two patch files you can apply to change the
 > behavior for undefined chunks. 

What this problem needs is ten lines of awk.  Here's your noweb filter:

  #!/bin/sh
  
  awk '
  /^@use /  { uses [substr($0, 6)] = 1 }
  /^@defn / { defns[substr($0, 7)] = 1 }
  { print }
  END {
    for (i in uses) 
      if (!defns[i])
        printf "@begin code\n@defn %s\n@nl\n@text <<%s>>\n@end code\n", i, i
  }'
  
  exit 0
  
  # test with
  
  sed '1,/test with/d' $0 | notangle -filter $0
  
  <<*>>=
  return x << 2 >> 2;
  @


\start
Date: Wed, 20 Nov 2002 12:31:07 +0100 (MET)
From: Joris van der Hoeven
To: list
Subject: Re: [Texmacs-dev]  visual literate programming
Cc: Bill Page

Hi Tim,

> I've signed up on the mailing list for TeXmacs and I downloaded
> the latest version to try it on the pamphlet files. I tried it
> against the examples 
> http://home.earthlink.net/~jgg964/dhmatrix.pamphlet
> http://home.earthlink.net/~jgg964/Makefile.pamphlet
> http://home.earthlink.net/~jgg964/Magman.pamphlet

Is the pamphlet format described somewhere?
It probably just uses a particular style file.

> There are several things failing. \subsubsection is wrong.
> \cite is wrong and the whole biblio section is broken.
> Worst of all is that the <<foo>> chunks of code are
> mangled. I also tried it against the dhmatrix.tex, etc
> files and it still comes out bent. However, the math
> comes out beatifully. It does know quite a few of the
> tex directives. It ran Axiom fine from within the buffer.

I mainly had problems with Makefile.pamphlet.
Importing verbatim text is dangerous with TeXmacs,
if you created a new environment for this:
as soon as you hit a $, TeXmacs can get confused.

I did not see any problems with \subsubsection and \cite.
It should not be too hard to fix the other problems.

> This isn't a criticism of TeXmacs. It just means we need to
> work together to improve the tool and make pamphlet files
> into a "standard" for TeXmacs. There are a lot of possible
> directions including things like adding an automatic call
> to notangle, nountangle so code can be maintained directly
> from the pamphlet, including invoking the compiler on the
> untangled code. It would be nice to be able to follow 
> \cite references to other pamphlets. TeXmacs needs to 
> really understand the noweb chunks.

Yes, we can take a look at this.

> I really would like to make literate programs be the only
> "source" files and have the rest happen by magic.

Indeed.


\start
Date: Wed, 20 Nov 2002 07:36:39 -0500
From: Tim Daly 
To: list
Subject:  (no subject)
CC: Bill Page, Joris van der Hoeven

Joris,

At the moment there are no formal requirements for a pamphlet file.
I hope to develop them in the future. In particular the plans call
for required sections on test cases, user help, examples, etc. which
will be "exploded" to various parts of the filesystem. The only case
used at the moment is in .c.pamphlet files which contain both the
.c and the .h code, both of which are broken out at compile time.
Also the cross-reference section will be used to automatically
load required pamphlets.

I'll retry the \subsubsection and \cite cases. I could easily have
screwed something up. I think that we can recognize the code
chunking mechanism in noweave's output and have TeXmacs handle it
properly. I'm not sure of all of the details of TexMacs or noweb
but we'll figure it out. 

Norman's noweb wraps code in the sequence, causing a "definition"
<<some identifying string>>=
code
...
code
@
where everything outside the <<>>= ... @ is considered text.
Code between the boundaries is basically a verbatim environment.

Code definitions are "used" by specifying:
<<some identifying string>>
Notice the lack of trailing equal sign.

Joris, can you point me at some specific part of the TeXmacs docs
that will help us develop a pamphlet "style" file. A style file
that properly handle noweb vanilla output would be quite useful.

\start
Date: Wed, 20 Nov 2002 11:40:05 -0500
From: Bill Page 
To: list
Subject:  Re: GCL on Cygwin for Axiom


Tim,

Damn. I am sorry to hear that Schelter is not still
available. I guess the Internet hasn't quite progressed to
that stage yet... And it's a reminder to me that there is
some urgency in this project to document Axiom and make it
available. <frown>

What I meant to write was GCL (Schelter's lisp), not GCC -
It was late and I was frustrated. I am more awake not.

Yes, GCC runs just fine on Cygwin for me but I do not have
a running version of GCL. In comparison to CCL, GCL is a
monster! Nearly everything I have tried to do in order to
make a running version of GCL under cygwin has failed with
obviously incorrect and untested code C coding. Getting CCL
to run was a piece of cake compared to this!

Does your offer to help extend to GCL? I have so many
problems and have tried so many things that it is a bit
hard to know where to start asking questions. But ...

1) First things: The version 2.4.1 of GCL that is in your
CVS is a bit out of date. The current version is 2.4.3.
And even the version of GMP (GNU math package) that is
in 2.4.3 is quite out of date. The most recent version
of GMP is 4.1

2) Via the web, I found that it is known that version 2.4.1
of GCL is missing some critical files for the Cywin build,
specifically 'unexnt.c'. So after several more failed
attempts witn 2.4.1, I download 2.4.3 and tried to compile
it. unexnt.c is there, but there are a whole host of other
problems, many of which seem to relate to GMP. So I
downloaded 4.1 of GMP. That built just fine on it's own
and after some fiddling I finally got GCL to link with it.
After alot of fixing other small things, I finally got to
the final load step for GCL only to have the the loader
blow up with a segment fault and stack dump ... jeez.

3) There is a "pre-release" version of GCL posted at the
Savannah site which is supposed into compile into native
Window's application with the mingw32 version of GCC.
Perhaps that is where I will try to go next.

4) But first a few more attempts. I am in the middle of
getting the missing unexnt.c file from the newest version
of GCL and using it with the older version. I will let you
know how far this one goes.

> Schelter's dead. But if you do get an answer let me know :-)
> Did you want help with GCC (Gnu Compiler Collection) or
> GCL (Gnu Common Lisp)?
> 
> I thought you had GCC running. How can I help?

\start
Date: Wed, 20 Nov 2002 17:54:05 +0100 (CET)
From: Martin Rubey
To: Bill Page
Subject: Re: GCL on Cygwin for Axiom


> 3) There is a "pre-release" version of GCL posted at the
> Savannah site which is supposed into compile into native
> Window's application with the mingw32 version of GCC.
> Perhaps that is where I will try to go next.

I think this is the way to go. And I think that Mike Thomas
is the one to ask, if there are Windows
Problems. There is a Mingw binary availaible on 
ftp://ftp.gnu.org/pub/gnu/gcl/cvs/

(but I do not have windows)

Camm Maguire will also be glad to help, I think

wou might want to look at 

http://mail.gnu.org/pipermail/gcl-devel/2002-September/001084.html

\start
Date: Wed, 20 Nov 2002 12:13:19 -0500
From: Bill Page
To: Martin Rubey
Subject:  Re: GCL on Cygwin for Axiom
CC: Mike Thomas

On 2002/11/20 Wed AM 11:54:05 EST Martin Rubey

> .. 
> > 3) There is a "pre-release" version of GCL posted at the
> > Savannah site which is supposed into compile into native
> > Window's application with the mingw32 version of GCC.
> > Perhaps that is where I will try to go next.
> 
> I think this is the way to go. And I think that Mike
> Thomas Mike Thomas is the one to
> ask, if there are Windows Problems. There is a Mingw
> binary availaible on 
> ftp://ftp.gnu.org/pub/gnu/gcl/cvs/
> 
> (but I do not have windows)
> 
> Camm Maguire will also be glad to help, I think
> 
> you might want to look at 
> 
> http://mail.gnu.org/pipermail/gcl-devel/2002-September/001084.html
> 

Excellent! Thank you for this information. My most
recent attempt to build a Cygwin version just failed
so Mingw native Windows it is ...

BTW, if it is true what Mike Thomas says that: "A port
to Cygwin would be trivial ...", then he's a much better
hacker than I am!

\start
Date: Wed, 20 Nov 2002 12:22:05 -0500
From: Bill Page
To: list
Subject:  Re: GCL on Cygwin for Axiom
CC: Mike Thomas

Background.

> Subject:  Re: GCL on Cygwin for Axiom
> 
> Tim,
> 
> Damn. I am sorry to hear that Schelter is not still
> available. I guess the Internet hasn't quite progressed to
> that stage yet... And it's a reminder to me that there is
> some urgency in this project to document Axiom and make it
> available. <frown>
> 
> What I meant to write was GCL (Schelter's lisp), not GCC -
> It was late and I was frustrated. I am more awake not.
> 
> Yes, GCC runs just fine on Cygwin for me but I do not have
> a running version of GCL. In comparison to CCL, GCL is a
> monster! Nearly everything I have tried to do in order to
> make a running version of GCL under cygwin has failed with
> obviously incorrect and untested code C coding. Getting
> CCL to run was a piece of cake compared to this!
> 
> Does your offer to help extend to GCL? I have so many
> problems and have tried so many things that it is a bit
> hard to know where to start asking questions. But ...
> 
> 1) First things: The version 2.4.1 of GCL that is in your
> CVS is a bit out of date. The current version is 2.4.3.
> And even the version of GMP (GNU math package) that is
> in 2.4.3 is quite out of date. The most recent version
> of GMP is 4.1
> 
> 2) Via the web, I found that it is known that version
> 2.4.1 of GCL is missing some critical files for the Cywin
> build, specifically 'unexnt.c'. So after several more
> failed attempts witn 2.4.1, I download 2.4.3 and tried to
> compile it. unexnt.c is there, but there are a whole host
> of other problems, many of which seem to relate to GMP.
> So I downloaded 4.1 of GMP. That built just fine on it's
> own and after some fiddling I finally got GCL to link
> with it. After alot of fixing other small things, I
> finally got to the final load step for GCL only to have
> the the loader blow up with a segment fault and stack
> dump ... jeez.
> 
> 3) There is a "pre-release" version of GCL posted at the
> Savannah site which is supposed into compile into native
> Window's application with the mingw32 version of GCC.
> Perhaps that is where I will try to go next.
> 
> 4) But first a few more attempts. I am in the middle of
> getting the missing unexnt.c file from the newest version
> of GCL and using it with the older version. I will let you
> know how far this one goes.
> 
> Cheers,
> Bill Page.
> 
> > Subject: Re: GCL on Cygwin for Axiom
> > 
> > Bill,
> > 
> > Schelter's dead. But if you do get an answer let me
> > know :-)
> > Did you want help with GCC (Gnu Compiler Collection) or
> > GCL (Gnu Common Lisp)?
> > 
> > I thought you had GCC running. How can I help?

> From: Bill Page
> Date: 2002/11/20 Wed AM 04:03:37 EST
> To: <schelter@math.utexas.edu>
> CC: 
> Subject: GCL on Cygwin for Axiom
> 
> Dr. Schelter;
> 
> I am working with Tim Daly on the Axiom open source
> project. One of the tasks that I have taken on is the
> implementation of a Windows/Cygwin version of Axiom. At
> the present time it is planned that Axiom will run on
> several different Lisp platforms including GCC and the
> recently made publicly available Codemist CCL interpreter.
> 
> Tim is proceeding with porting the Axiom code to the GCC
> environment under Linux but has run into a few initial
> complications with the use of CCL. I have been successful
> at building CCL under the Windows/Cygwin environment but
> am having a "devil" of a time trying to install GCC on
> this platform. I have not been able to find any
> combination of recent versions of both Cygwin and GCC
> and/or choice of options for which I can successfully
> prepare the GCC executables.
> 
> I have tried my best of obtain more information about the
> available operational versions via the web, but so far I
> have not found an answer. I would very much appreciate
> your recommendations on how to approach this. I have
> heard that there is a "native" Windows version of GCC
> available which will compile under Mingw32. This version
> would likely be compatible with our goals for Axiom.
> Could you tell me who I might contact concerning the
> current status of the Mingw32 version and/or a
> Windows/Cygwin version.
> 
> Thanks for your time.
> 

\start
Date: Wed, 20 Nov 2002 16:17:10 -0500
From: Tim Daly 
To: Bill Page
Subject: Re: GCL on Cygwin for Axiom
CC: Martin Rubey, Mike Thomas

re: trivial port of gcl....

Not at all. Since gcl uses the native loader formats there is
always an issue of developing a loader that understand the
format for a particular platform. Bill and I struggled with
this whole issue on AIX for the RS/6000. 

\start
Date: Wed, 20 Nov 2002 13:09:23 -0500
From: Bill Page
To: list
Subject:  GCL on Cygwin for Axiom

Hello,

I recently downloaded gcl-cvs-20021014-mingw32.zip from
  ftp://ftp.gnu.org/pub/gnu/gcl/cvs/

I was hoping to be able to run make with this on my
Windows/Cygwin system but the only makefile I can find
is in

 gclm\lib\gcl-2.5.0\gcl-tk

and that one does not work with the current directory
configuration.

Could someone please point me in the correct direction
for a complete source distribution that can be built and
run under Cygwin (but not to run with the Cygwin dll -
that's another issue).

\start
Date: Wed, 20 Nov 2002 16:45:25 -0500
From: Tim Daly 
To: Bill Page
Subject: Re:  Re: GCL on Cygwin for Axiom
CC: Camm Maguire

> Damn. I am sorry to hear that Schelter is not still
> available. I guess the Internet hasn't quite progressed to
> that stage yet... And it's a reminder to me that there is
> some urgency in this project to document Axiom and make it
> available. <frown>

Actually Bill's death is what set me off to try to open
source Axiom. He and I worked together on AKCL (pre-GCL)
and I was impressed with him.

As to the urgency question, yeah, I'm gettin' old and the males 
in my clan die young. I'm writing as fast as I can :-)

> What I meant to write was GCL (Schelter's lisp), not GCC -
> It was late and I was frustrated. I am more awake not.

grin. either you used a relatively recent form of negation
(trailing not) or you had a typo and meant now. either way
it was funny.

> Yes, GCC runs just fine on Cygwin for me but I do not have
> a running version of GCL. In comparison to CCL, GCL is a
> monster! Nearly everything I have tried to do in order to
> make a running version of GCL under cygwin has failed with
> obviously incorrect and untested code C coding. Getting CCL
> to run was a piece of cake compared to this!

CCL is supposed to be cross-platform by design and I believe
was ported to Cygwin before. GCL is much more platform specific
and depends on the GCC environment for portability. I'll raise
the priority of getting CCL running from the Makefiles so you
can continue to contribute. 

> Does your offer to help extend to GCL? I have so many
> problems and have tried so many things that it is a bit
> hard to know where to start asking questions. But ...

sure. I'll help any way I can.

> 1) First things: The version 2.4.1 of GCL that is in your
> CVS is a bit out of date. The current version is 2.4.3.
> And even the version of GMP (GNU math package) that is
> in 2.4.3 is quite out of date. The most recent version
> of GMP is 4.1

The point of the zips directory is to keep a version that 
is known to work. Things die of code-rot (that is, somebody
"upgrades" their subsystem, like C++ did, and everybody downstream
is broken). I wanted to make sure there was at least a working
version available. I'll download and test 2.4.3 before I put
it in the zips.

As for the GMP connection you should tweak 
Camm Maguire about it.

> 2) Via the web, I found that it is known that version 2.4.1
> of GCL is missing some critical files for the Cywin build,
> specifically 'unexnt.c'. So after several more failed
> attempts witn 2.4.1, I download 2.4.3 and tried to compile
> it. unexnt.c is there, but there are a whole host of other
> problems, many of which seem to relate to GMP. So I
> downloaded 4.1 of GMP. That built just fine on it's own
> and after some fiddling I finally got GCL to link with it.
> After alot of fixing other small things, I finally got to
> the final load step for GCL only to have the the loader
> blow up with a segment fault and stack dump ... jeez.

Read the GMP pamphlet files. I'm sure they explain what they
are trying to do well enough to fix it :-) Methinks you're
on the foreskin of technology here. Try restoring the clean
2.4.3 version, run a make and send me the output trace. I'll
look at it and hopefuly have something insightful to say.

> 3) There is a "pre-release" version of GCL posted at the
> Savannah site which is supposed into compile into native
> Window's application with the mingw32 version of GCC.
> Perhaps that is where I will try to go next.

mingw32? Don't know what that is.

> 4) But first a few more attempts. I am in the middle of
> getting the missing unexnt.c file from the newest version
> of GCL and using it with the older version. I will let you
> know how far this one goes.

good luck. Let me know if I can help. Send console traces.
I'm pushing on the next layer of the system but I'll give
some thought to the CCL issue.

\start
Date: Thu, 21 Nov 2002 09:30:04 +1000
From: Mike Thomas
To: Bill Page, Martin Rubey
Subject: Re: GCL on Cygwin for Axiom

Hi there.

> BTW, if it is true what Mike Thomas says that: "A port
> to Cygwin would be trivial ...", then he's a much better
> hacker than I am!

Ahhh... you'll have to be much more sophisticated than that to get me to do
the job!!!

\start
Date: Thu, 21 Nov 2002 09:51:31 +1000
From: Mike Thomas
To: list
Subject: Re: GCL on Cygwin for Axiom

My first attempt bounced from axiom-developer even though the other went
through??

> Hi there.
>
> Below please find an attempt to discourage the development of a Cygwin
> version of GCL and in the interests of intellectual freedom, "paper
napkin"
> instructions on how to go about it if you decide to do so.
>
> > re: trivial port of gcl....
> >
> > Not at all. Since gcl uses the native loader formats there is
> > always an issue of developing a loader that understand the
> > format for a particular platform. Bill and I struggled with
> > this whole issue on AIX for the RS/6000.
>
>
> REBUTTAL
>
> Fortunately, Cygwin and Mingw32 use the same binary format and GNU
binutils
> (modulo Cygwin Unix emulation) so as far as I know that is not a problem
> here.
>
>
> WHY NOT TO DO A GCL CYGWIN PORT
>
> I think that a Cygwin version will not buy you very much functionality and
> is likely to be slower where Unix emulation is used.  You will also have
the
> usual conflicts between Cygwin application paths and Windows paths, drives
> mounted as text mode etc.
>
> More importantly, it will also be yet another branch of the code that
> someone will have to maintain and package, which is a problem as it stands
> because very few people seem to be interested in supporting GCL on
Windows.
> Note that most of the inherently difficult outstanding problems on Mingw32
> are going to be the same on Cygwin - BFD linking comes to mind.
>
> On a final note, it might be worthwhile checking out ECL (
> http://ww.telent.net/cliki/ECL  ), which allegedly supports Cygwin.  ECL
is
> very closely related to GCL/AKCL.
>
>
> HOW TO START A CYGWIN PORT OF GCL
>
> Having said that, off the top of my head here is what I believe you would
> need to do to port GCL to Cygwin:
>
> - Get the latest source from CVS (see the GCL web site
> http://savannah.gnu.org/projects/gcl/  )
>
> - Copy the files "h/mingw.*" to "h/cygwin.*".  Check that they make sense
in
> the context of Cygwin and minimise modifications until you have found a
> specific reason for doing so when trying to compile and run GCL.
>
> - Grep the source for __MINGW32__ and WIN32 and check that the code does
> what you would want then add the __CYGWIN__ macro in places where Cygwin
> specific changes are required.  I have left the road open for Cygwin and
> other Windows compilers through the convention that _WIN32 denotes code
> which will work under any Windows compiler, and in other cases the
compiler
> specific macro is used.
>
> - Ensure that file opening is forced to binary mode so that when object
> loading occurs the object files are interpreted as binary rather than
> textual data (see "o/main.c":
> ...
> #ifdef _WIN32
>  _fmode = _O_BINARY;
> #endif
> ...
> ie if Cygwin doesn't support _fmode you'll have to find another way.
>
> - check that configure.in does the right thing for Cygwin.
>
> - try building and make further plans based on the outcome.
>
>
>
> Cheers and best of luck
>
> Mike Thomas.
>
>

\start
Date: Wed, 20 Nov 2002 19:46:04 -0500
From: Tim Daly 
To: Bill Page
Subject:  gcl 2.4.3


Bill,

I've checked out gcl 2.4.3 and it works. I'll be updating the 
tenkan cvs with the new version shortly.

\start
Date: Wed, 20 Nov 2002 20:12:16 -0500
From: Tim Daly 
To: Bill Page
Subject:  gcl 2.4.3

Bill,

Ah, I lied. I ran into the _Bool issue with 2.4.3 also.
I'll see if I can figure out a patch.
Until then lets stick with 2.4.1

\start
Date: Wed, 20 Nov 2002 20:29:59 -0500
From: Tim Daly 
To: Bill Page
Subject:  gcl 2.4.3

Bill,

I've done a small amount of checking on the GCL/Cygwin issue.
GCL looks like it knows about Cygwin. Check configure.in
and you'll see:
   i*cygwin*)
on line 488.
What is the result of this test? (gcc -v | fgrep ming)

\start
Date: 20 Nov 2002 20:30:35 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: GCL on Cygwin for Axiom
Cc: Mike Thomas

Greetings!  Allow me a futile attempt at an adequate answer on behalf
of the late Dr. Schelter:

Shortly after Dr. Schelter died, Richard Stallman requested a
volunteer to continue maintenance of GCL.  There was not much response
from the lisp community.  Like many of you, I was moved by
Dr. Schelter's work, and did not want to see it rot away.  RMS
encouraged me to act on this sentiment and do what I could to keep GCL
going, in spite of my then total unfamiliarity with lisp.  (I have
extensive experience in C, though).  So I agreed.

We set the project up at http://savannah.gnu.org/projects/gcl, and
formed the gcl-devel@gnu.org mailing list.  Over time, several
volunteers arose, bringing the current number of GCL developers to 12.
We attempted to quickly stabilize Dr. Schelter's last work with a
bug-fix only 2.4.x series, the latest of which is 2.4.3.  This is
known to compile itself and maxima on linux x86 boxes and pass all
tests without error.  I'm not sure about the windows status of this
release, though my understanding is that 2.4.3 produces a working
maxima under mingw as well.

We then branched CVS into the 2.5.0 series, and have pushed forward on
several fronts.  

On the portability side, we introduced relocation code calling
routines in the bfd library.  This together with extensive changes for
64 bit support, has produced a current CVS snapshot which builds a
test-passing maxima on all 11 Debian architectures (x86 ppc arm m68k
sparc mips mipsel ia64 alpha hppa s390), Windows Mingw, sparc solaris,
and (apparently) FreeBSD.  

This effort revealed several bugs in the code, the fixing of which,
coupled with a general overhaul to remove all compiler warnings, has
led to a code base which now supports full C compiler optimization on
all platforms save one, leading to a general performance increase of
some 10%.  

A major push in the direction of full ansi compliance has begun.  clcs
and pcl code has been incorporated, several missing elements
(e.g. ansi loop, destructuring bind, defpackage, etc) have been added
into the core system, numerical constants are now handled correctly to
full IEEE precision, COMMON-LISP and COMMON-LISP-USER packages are
provided, and perhaps most significantly, Paul Dietz has been
developing our own ansi-test regression suite, leading to steady
progress in fixing any failures thus revealed.  I'm told that we
actually do better than Allegro on Paul's tests :-).  These features
are optionally enabled at compile time with --enable-ansi.

Several extensions have been incorporated or are in the process of being
incorporated.  xgcl is now included in the standard tree, the author
or pargcl has refreshed his additions, and preliminary discussion of
blas/lapack support has been positive.  The ansi common lisp spec in
.texi format has also been patched for modern texinfo systems,
included in the standard tree and is now built into searchable info
files at compile time.

On some systems, native relocation is not yet available due to
unfinished support in the bfd library.  These are mips mipsel alpha
ia64 and hppa.  On such systems, we've reenabled the dlopen code
options Dr. Schelter had provided, giving a GCL which can correctly
load objects, but not save them via save-system.  To enable the
building of systems such as maxima on these platforms, which
frequently rely on dumping the image via save-system by default, we've
added some code to automate the approach Dr. Schelter had put together
for maxima 5.6.  Briefly, one can call (compiler::link '( <object file
list>) "image_name" "initialization code" "extra libs" nil) after
compilation and it 'will just work'.  Maxima CVS can optionally use
this method, as well as the Debian package of acl2, both of which have
been verified.  

On Debian systems, gcl/maxima and gcl/acl2 packages now exist which
compile and pass all tests on all platforms, with the exception of a
few remaining issues with acl2, which should be resolved shortly.
Mike tells me that the latest Mingw GCL binary does likewise on
Windows.  We hope to make axiom the third such example!

As for the future, we hope to get GCL into sufficient shape one day to
submit is for consideration as the standard common lisp front end to
the gcc family of compilers.  GCL may not be the most compliant, but
to my knowledge it carries the most number of open source apps to the
most number of platforms, and with generally quite good performance. 

As for libraries, both gmp and bfd can be linked in dynamically.  The
former is so by default on Debian systems.  This allows GCL to use the
latest lib compatible with the API of soname 3.  CVS has a relatively
new gmp included for local building and static linkage as well, under
the directory gmp3.

In sum, GCL is a work in progress.  We hope it will be useful to the
lisp community.  I must say that I share the sentiment you expressed
below.  A lot of work has gone into intelligent lisp programming, and
it appears in danger of getting lost as the human repositories of its
knowledge go on to better things.  This would be a terrible waste.  It
is the hope of bringing these gems forward into the open source world
of a new generation that chiefly motivates my work on GCL.

Take care,



Bill Page writes:

> Background.
> > 
> > Damn. I am sorry to hear that Schelter is not still
> > available. I guess the Internet hasn't quite progressed to
> > that stage yet... And it's a reminder to me that there is
> > some urgency in this project to document Axiom and make it
> > available. <frown>
> > 
> > What I meant to write was GCL (Schelter's lisp), not GCC -
> > It was late and I was frustrated. I am more awake not.
> > 
> > Yes, GCC runs just fine on Cygwin for me but I do not have
> > a running version of GCL. In comparison to CCL, GCL is a
> > monster! Nearly everything I have tried to do in order to
> > make a running version of GCL under cygwin has failed with
> > obviously incorrect and untested code C coding. Getting
> > CCL to run was a piece of cake compared to this!
> > 
> > Does your offer to help extend to GCL? I have so many
> > problems and have tried so many things that it is a bit
> > hard to know where to start asking questions. But ...
> > 
> > 1) First things: The version 2.4.1 of GCL that is in your
> > CVS is a bit out of date. The current version is 2.4.3.
> > And even the version of GMP (GNU math package) that is
> > in 2.4.3 is quite out of date. The most recent version
> > of GMP is 4.1
> > 
> > 2) Via the web, I found that it is known that version
> > 2.4.1 of GCL is missing some critical files for the Cywin
> > build, specifically 'unexnt.c'. So after several more
> > failed attempts witn 2.4.1, I download 2.4.3 and tried to
> > compile it. unexnt.c is there, but there are a whole host
> > of other problems, many of which seem to relate to GMP.
> > So I downloaded 4.1 of GMP. That built just fine on it's
> > own and after some fiddling I finally got GCL to link
> > with it. After alot of fixing other small things, I
> > finally got to the final load step for GCL only to have
> > the the loader blow up with a segment fault and stack
> > dump ... jeez.
> > 
> > 3) There is a "pre-release" version of GCL posted at the
> > Savannah site which is supposed into compile into native
> > Window's application with the mingw32 version of GCC.
> > Perhaps that is where I will try to go next.
> > 
> > 4) But first a few more attempts. I am in the middle of
> > getting the missing unexnt.c file from the newest version
> > of GCL and using it with the older version. I will let you
> > know how far this one goes.
> > 
> > Cheers,
> > Bill Page.
> > 
> > > 
> > > Schelter's dead. But if you do get an answer let me
> > > know :-)
> > > Did you want help with GCC (Gnu Compiler Collection) or
> > > GCL (Gnu Common Lisp)?
> > > 
> > > I thought you had GCC running. How can I help?
> > > 
> > > Tim
> > > 
> > 
> > _______________________________________________
> > Axiom-developer mailing list
> > list
> > http://mail.nongnu.org/mailman/listinfo/axiom-developer
> > 
> 
> > 
> > Dr. Schelter;
> > 
> > I am working with Tim Daly on the Axiom open source
> > project. One of the tasks that I have taken on is the
> > implementation of a Windows/Cygwin version of Axiom. At
> > the present time it is planned that Axiom will run on
> > several different Lisp platforms including GCC and the
> > recently made publicly available Codemist CCL interpreter.
> > 
> > Tim is proceeding with porting the Axiom code to the GCC
> > environment under Linux but has run into a few initial
> > complications with the use of CCL. I have been successful
> > at building CCL under the Windows/Cygwin environment but
> > am having a "devil" of a time trying to install GCC on
> > this platform. I have not been able to find any
> > combination of recent versions of both Cygwin and GCC
> > and/or choice of options for which I can successfully
> > prepare the GCC executables.
> > 
> > I have tried my best of obtain more information about the
> > available operational versions via the web, but so far I
> > have not found an answer. I would very much appreciate
> > your recommendations on how to approach this. I have
> > heard that there is a "native" Windows version of GCC
> > available which will compile under Mingw32. This version
> > would likely be compatible with our goals for Axiom.
> > Could you tell me who I might contact concerning the
> > current status of the Mingw32 version and/or a
> > Windows/Cygwin version.
> > 
> > Thanks for your time.
> > 

\start
Date: Wed, 20 Nov 2002 20:46:30 -0500
From: Tim Daly 
To: Camm Maguire
Subject: Re: GCL on Cygwin for Axiom
CC: Bill Page, Mike Thomas

Ok, I'll try 2.5 and see if that builds.

\start
Date: Wed, 20 Nov 2002 21:37:49 -0500
From: Tim Daly 
To: Camm Maguire, Bill Page
Subject:  _BOOL problem in GCL 2.4.3 for GCC 2.96
CC: Mike Thomas

Camm,

This patch will fix 2.4.3 to work on all systems.
You can just save this mail file to 386-linux.defs.patch and type:
   cd gcl-2.4.3/o
   patch < 386-linux.defs.patch 
Perhaps you could call it 2.4.4?

The problem is the include of the file
/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdbool.h
which typedefs bool. This causes sfasl.c to fail to compile.

To fix the build on GCC 2.96 add the flag -D_STDBOOL_H to the
sfasl.h compile line. The correct way to do this is to apply
the attached patch file. Note that configure writes over several
files so you can't patch them directly. Under Bill's scheme you
make platform specific changes in the h/*.defs files.

The "bug" was introduced when bfd support was added.
In this particular case the "include <bfd.h>" also does an
"include <stdbool.h>" which typedefs bool causing the conflict.
If you read the include <bfd.h> file you'll find that this bug
has bitten many people. There are checks in the file so that
<stdbool.h> is only included if the compiler version is 2
and the subversion > 95. Since my RedHat 7.2 is gcc 2.95 this
works. My RedHat 7.3 is gcc 2.96 and fails. The correct fix
is NEVER to include this file as it will always cause a conflict
for GCL. The easiest way to do this is to claim that the file
has already been included. The first time it is included it
defines a flag _STDBOOL_H. So, we lie about it and always
define the flag thus avoiding the problem. 

Some day I should sign up as a GCL developer :-)

Tim

===================================================================
--- 386-linux.defs	Sun Feb  3 13:44:07 2002
+++ /tmp/386-linux.defs	Wed Nov 20 21:21:08 2002
@@ -21,7 +21,7 @@
 # and also in the compiler::*cc* variable for later compilation of
 # lisp files.
 # (the -pipe is just since our file system is slow..)
-CC = ${GCC} -pipe -fwritable-strings  -DVOL=volatile -I$(GCLDIR)/o -fsigned-char
+CC = ${GCC} -pipe -fwritable-strings  -DVOL=volatile -I$(GCLDIR)/o -fsigned-char -D_STDBOOL_H 
 
 # under redhat 6.1 and slackware 7.0 we needed to have this
 # link be static, but should be ok with the fix to unixport/rsym_elf.c

\start
Date: Wed, 20 Nov 2002 21:41:25 -0500
From: Tim Daly 
To: Camm Maguire, Bill Page
Subject:  _BOOL problem in GCL 2.4.3 for GCC 2.96 (typo fix)
CC: Mike Thomas

Camm, I fat-fingered the last mail. The actual .defs file is in the
'h' directory, not the 'o' directory. These are the correct instructions:


This patch will fix 2.4.3 to work on all systems.
You can just save this mail file to 386-linux.defs.patch and type:
   cd gcl-2.4.3/h
   patch < 386-linux.defs.patch 
Perhaps you could call it 2.4.4?

The problem is the include of the file
/usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdbool.h
which typedefs bool. This causes sfasl.c to fail to compile.

To fix the build on GCC 2.96 add the flag -D_STDBOOL_H to the
sfasl.h compile line. The correct way to do this is to apply
the attached patch file. Note that configure writes over several
files so you can't patch them directly. Under Bill's scheme you
make platform specific changes in the h/*.defs files.

The "bug" was introduced when bfd support was added.
In this particular case the "include <bfd.h>" also does an
"include <stdbool.h>" which typedefs bool causing the conflict.
If you read the include <bfd.h> file you'll find that this bug
has bitten many people. There are checks in the file so that
<stdbool.h> is only included if the compiler version is 2
and the subversion > 95. Since my RedHat 7.2 is gcc 2.95 this
works. My RedHat 7.3 is gcc 2.96 and fails. The correct fix
is NEVER to include this file as it will always cause a conflict
for GCL. The easiest way to do this is to claim that the file
has already been included. The first time it is included it
defines a flag _STDBOOL_H. So, we lie about it and always
define the flag thus avoiding the problem. 

Some day I should sign up as a GCL developer :-)

Tim

===================================================================
--- 386-linux.defs	Sun Feb  3 13:44:07 2002
+++ /tmp/386-linux.defs	Wed Nov 20 21:21:08 2002
@@ -21,7 +21,7 @@
 # and also in the compiler::*cc* variable for later compilation of
 # lisp files.
 # (the -pipe is just since our file system is slow..)
-CC = ${GCC} -pipe -fwritable-strings  -DVOL=volatile -I$(GCLDIR)/o -fsigned-char
+CC = ${GCC} -pipe -fwritable-strings  -DVOL=volatile -I$(GCLDIR)/o -fsigned-char -D_STDBOOL_H 
 
 # under redhat 6.1 and slackware 7.0 we needed to have this
 # link be static, but should be ok with the fix to unixport/rsym_elf.c

\start
Date: Wed, 20 Nov 2002 22:40:27 -0500
From: Tim Daly 
To: Camm Maguire
Subject:  gcl 2.5

I'm happy to report that GCL 2.5 builds cleanly on RedHat 7.2 (gcc 2.95)
RedHat 7.3 (gcc 2.96) and RedHat 8.0 (gcc 3.2).

Where can I find this test suite you mentioned?

\start
Date: Wed, 20 Nov 2002 22:58:28 -0500
From: Tim Daly 
To: Camm Maguire
Subject:  gcl 2.5 bug report

gcl
>(in-package 'foo)
Error: A package error occurred on FOO: "No such package".

This is clearly an error. Steele pg 183 says that in-package
will create a package that does not exist. pg 182 says a package
name can be a symbol or a string.

\start
Date: 21 Nov 2002 08:09:27 -0500
From: Camm Maguire
To: list
Subject:  Re: [Gcl-devel] gcl 2.5

Greetings!  Great!  In the subdir ansi-tests.  Try this out (only when
you've configured with --enable-ansi):

cd ansi-tests
../unixport/saved_ansi_gcl
(load "gclload.lsp")

Tim Daly  writes:

> I'm happy to report that GCL 2.5 builds cleanly on RedHat 7.2 (gcc 2.95)
> RedHat 7.3 (gcc 2.96) and RedHat 8.0 (gcc 3.2).
> 
> Where can I find this test suite you mentioned?
> 

\start
Date: 21 Nov 2002 08:08:16 -0500
From: Camm Maguire
To: list
Subject:  Re: [Gcl-devel] gcl 2.5 bug report


Hi Tim!  The behavior you describe is CLTL1.  CLTL2 and ansi say you
have to make-package first.  As this change did not break our existing
'customers' maxima and acl2, we just incorporated it into the base
image.  If it is a problem for you, I could escape the updated
behavior to only kick in when configuring the ansi image.  Shouldn't be
too tough to add a make-package, no?

Take care,

Tim Daly  writes:

> gcl
> >(in-package 'foo)
> Error: A package error occurred on FOO: "No such package".
> 
> This is clearly an error. Steele pg 183 says that in-package
> will create a package that does not exist. pg 182 says a package
> name can be a symbol or a string.

\start
Date: Thu, 21 Nov 2002 17:30:07 +0100 (MET)
From: Joris van der Hoeven
To: list
Subject:  Re: [Texmacs-dev] Axiom and TeXmacs
Cc: Bill Page

> Norman's noweb wraps code in the sequence, causing a "definition"
> <<some identifying string>>=
> code
> ...
> code
> @
> where everything outside the <<>>= ... @ is considered text.
> Code between the boundaries is basically a verbatim environment.
> 
> Code definitions are "used" by specifying:
> <<some identifying string>>
> Notice the lack of trailing equal sign.

Maybe we should preprocess the pamphlet file using Perl
before doing the conversion. I think that St=E9phane Payrard
might be willing to help us with that.

> Joris, can you point me at some specific part of the TeXmacs docs
> that will help us develop a pamphlet "style" file. A style file
> that properly handle noweb vanilla output would be quite useful.

Help -> Styles

Unfortunately, the documentation is very incomplete,
because the support for writing style files will be much improved
at a not yet specified date...


\start
Date: Thu, 21 Nov 2002 16:11:08 -0500
From: Bill Page
To: Joris van der Hoeven
Subject:  RE: [Texmacs-dev] Axiom and TeXmacs

On Thursday, November 21, 2002 11:30 AM Joris van der Hoeven

> [Tim] 
> > Norman's noweb wraps code in the sequence, causing a
> > "definition"  <<some identifying string>>= code
> > ...
> > code
> > @
> > where everything outside the <<>>= ... @ is considered
> > text. Code between the boundaries is basically a verbatim
> > environment.
> > 
> > Code definitions are "used" by specifying:
> > <<some identifying string>>
> > Notice the lack of trailing equal sign.
> 
> Maybe we should preprocess the pamphlet file using Perl
> before doing the conversion. I think that St=E9phane
> Payrard might be willing to help us with that.
>

If I understand you correctly, I do not think a Perl
filter is a good approach. I have nothing against Perl
as such, its just that I think the goal should be more
than loading a pamphlet file into TeXmacs in a readable
manner.

I think there should be a new File->Import->Pamphlet
option for this case. The result of importing a pamphlet
should be a TeXmacs document with a folded structure.
The code chunks should appear folded into the document so
that when viewed or printed with a style called "weave"
for example, the result would be the same as the output
of

 noweave | latex

A different style which displayed the contents of the
folded chunks could be used for editing. Code chunks
have to be named and will also have references to
other code chunks embedded in them.

Perhaps it would be nicer if TeXmacs was able to
expand and collapse folds on demand. It is not really
clear to me hold folding is intended to work in TeXmacs.
I wasn't able to find any documentation about it and
my experiments with it so far have not produced a clear
picture. Perhaps it is still largely in the planning
stage? 

Finally there should be an new File->Export->Tangle
menu option that would generate code and be equivalent
to

  notangle

which expands the code chunks starting with the root
<<*>>= and including all the referenced code chunks
in the whole tree structure.

We could also have a Tools->Selections->Export->Tangle
option that applies notangle starting with a selected
code chunk instead of the root.

What do you think, Tim?
 
> > Joris, can you point me at some specific part of
> > the TeXmacs docs that will help us develop a pamphlet
> > "style" file. A style file that properly handle
> > noweb vanilla output would be quite useful.
> 
> Help -> Styles
> 
> Unfortunately, the documentation is very incomplete,
> because the support for writing style files will be
> much improved at a not yet specified date...
> 

Perhaps it would help to be able to look at some
existing styles that do something similar to what
we want. What would you recommend?

\start
Date: 21 Nov 2002 16:31:09 -0500
From: Camm Maguire
To: Tim Daly
Subject:  Re: [Gcl-devel] _BOOL problem in GCL 2.4.3 for GCC 2.96
Cc: Bill Page, Mike Thomas

Greetings!

Tim Daly  writes:

> Camm,
> 
> This patch will fix 2.4.3 to work on all systems.
> You can just save this mail file to 386-linux.defs.patch and type:
>    cd gcl-2.4.3/o
>    patch < 386-linux.defs.patch 
> Perhaps you could call it 2.4.4?
> 
> The problem is the include of the file
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdbool.h
> which typedefs bool. This causes sfasl.c to fail to compile.
> 
> To fix the build on GCC 2.96 add the flag -D_STDBOOL_H to the
> sfasl.h compile line. The correct way to do this is to apply
> the attached patch file. Note that configure writes over several
> files so you can't patch them directly. Under Bill's scheme you
> make platform specific changes in the h/*.defs files.
> 
> The "bug" was introduced when bfd support was added.
> In this particular case the "include <bfd.h>" also does an
> "include <stdbool.h>" which typedefs bool causing the conflict.
> If you read the include <bfd.h> file you'll find that this bug
> has bitten many people. There are checks in the file so that
> <stdbool.h> is only included if the compiler version is 2
> and the subversion > 95. Since my RedHat 7.2 is gcc 2.95 this
> works. My RedHat 7.3 is gcc 2.96 and fails. The correct fix
> is NEVER to include this file as it will always cause a conflict
> for GCL. The easiest way to do this is to claim that the file
> has already been included. The first time it is included it
> defines a flag _STDBOOL_H. So, we lie about it and always
> define the flag thus avoiding the problem. 
> 

Thanks for the detailed analysis!  We had dealt with this in CVS with
an #undef bool in object.h, but I rather like your solution better.

BTW, a word to the wise, gcc 2.96 is very broken, and should be
avoided at all costs.  The Gcc people never released it, but the
Redhat people rushed it out as they needed some c++ stuff for a
release they could not reschedule.

I'll try to get a 2.4.4 out this weekend, with a bool fix, and with
the version numbers correctly reported.  If anyone has something else
they think should go in, please let me know by Friday evening.

> Some day I should sign up as a GCL developer :-)
> 

Indeed!!  Whenever you are free and interested ...

Take care,

> Tim
> 
> ===================================================================
> --- 386-linux.defs	Sun Feb  3 13:44:07 2002
> +++ /tmp/386-linux.defs	Wed Nov 20 21:21:08 2002
> @@ -21,7 +21,7 @@
>  # and also in the compiler::*cc* variable for later compilation of
>  # lisp files.
>  # (the -pipe is just since our file system is slow..)
> -CC = ${GCC} -pipe -fwritable-strings  -DVOL=volatile -I$(GCLDIR)/o -fsigned-char
> +CC = ${GCC} -pipe -fwritable-strings  -DVOL=volatile -I$(GCLDIR)/o -fsigned-char -D_STDBOOL_H 
>  
>  # under redhat 6.1 and slackware 7.0 we needed to have this
>  # link be static, but should be ok with the fix to unixport/rsym_elf.c

\start
Date: Thu, 21 Nov 2002 21:21:59 -0500
From: Bill Page
To: list
Subject:  Re: GCL on Cygwin for Axiom

On Wednesday, November 20, 2002 6:26 PM Mike Thomas
Mike Thomas wrote:

> ... 
> Below please find an attempt to discourage the development
> of a Cygwin version of GCL and in the interests of
> intellectual freedom, "paper napkin" instructions on
> how to go about it if you decide to do so.
> ...

Ok, I have no particularly strong reason to continue
with Cygwin. My current goal is to support the open
source version of Axiom with both Codemist CCL and GCL
on a Windows platform and I just considered Cygwin as
a logical "half-way" point.

On Wednesday, November 20, 2002 8:31 PM Camm Maguire

> ...
> On Debian systems, gcl/maxima and gcl/acl2 packages
> now exist which compile and pass all tests on all
> platforms, with the exception of a few remaining
> issues with acl2, which should be resolved shortly.
> Mike tells me that the latest Mingw GCL binary does
> likewise on Windows.  We hope to make axiom the third
> such example!
> ...

Since GCL can already be built on both Linux and Windows
(with mingw), the only problem is CCL. CCL should be
relatively easy to port, but my initial worry would
be the use of SUN rpc in CCL. I am quite sure there is
no port of this version of rpc to native Windows, is
there? I even had trouble finding one that works with
Cygwin.

A secondary issue is that the next goal after getting
OpenAxiom to run in Windows is to provide a new GUI
frontend (to replace Techexplorer). The current plan
is to use TeXmacs. Currently TeXmacs runs only on Linux
and Cygwin (with Xfree86). Making it work under native
Windows sounds formidable and I am not sure if anyone
is seriously attempting such a port. But I suppose there
is no reason (in principle) why one could not support
TeXmacs under Cygwin with access to the Windows native
version of Axiom. The main purpose of Cygwin then would
be to provide the x-server windows environment.

So, I am about to embark on setting up MinGW + MSYS on
my Windows system and see how far I can get with
the current Axiom build. Tim: I'll probably go for
the GCL 2.5 since that version is know to work and
modify the makefile.pamphlet files accordingly.

\start
Date: Fri, 22 Nov 2002 13:54:11 +1000
From: Mike Thomas
To: Bill Page
Subject:  Re: [Gcl-devel] Re: GCL on Cygwin for Axiom

Hi Bill.

> Ok, I have no particularly strong reason to continue
> with Cygwin. My current goal is to support the open
> source version of Axiom with both Codemist CCL and GCL
> on a Windows platform and I just considered Cygwin as
> a logical "half-way" point.

It may be worth your while to also consider CLISP and Corman Common Lisp.

> Since GCL can already be built on both Linux and Windows
> (with mingw), the only problem is CCL. CCL should be
> relatively easy to port, but my initial worry would
> be the use of SUN rpc in CCL. I am quite sure there is
> no port of this version of rpc to native Windows, is
> there? I even had trouble finding one that works with
> Cygwin.

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

I once built this package with Mingw32 for the pre-agreed price of a packet
of potato chips for my youngest daughter as a result of a mialing list
discussion about open source programming.  (These duly arrived by surface
mail several months later along with other yummy tidbits and a reply package
is on it's way!)

I haven't used it as I have no interest in such things so I can't claim it
will meet your needs, but try it out.  I can package and send the prebuilt
version if you wish.

> But I suppose there
> is no reason (in principle) why one could not support
> TeXmacs under Cygwin with access to the Windows native
> version of Axiom.

In principle (I don't know what TeXMacs is) that should be fine and is one
of the beauties of using a native Windows build of Axiom rather than getting
hooked on the Cygwin dll.

\start
Date: Fri, 22 Nov 2002 10:59:24 +0000
From: Mike Dewar
To: Bill Page
Subject: Re: GCL on Cygwin for Axiom

On Thu, Nov 21, 2002 at 09:21:59PM -0500, Bill Page wrote:
> Since GCL can already be built on both Linux and Windows
> (with mingw), the only problem is CCL. CCL should be
> relatively easy to port, but my initial worry would
> be the use of SUN rpc in CCL. I am quite sure there is
> no port of this version of rpc to native Windows, is
> there? I even had trouble finding one that works with
> Cygwin.
CCL should build "out pof the box" on Windows - after all we have been
shipping the Windows version of Axiom based on it for many years.  The
Axiom architecture is different on Unix and Windows and the RPC
dependency you found almost certainly only exists in the Unix build.
The problem may be in generating a correct makefile - there are tools
for doing this (makebase etc) but they may need adapting to take account
of the non-standard Axiom enhancements. 

\start
Date: Fri, 22 Nov 2002 07:36:08 -0500
From: Earnie Boyd
To: Bill Page
Subject: Re: [Mingw-users] Re: GCL on Cygwin for Axiom

Bill Page wrote:
> 
> A secondary issue is that the next goal after getting
> OpenAxiom to run in Windows is to provide a new GUI
> frontend (to replace Techexplorer). The current plan
> is to use TeXmacs. Currently TeXmacs runs only on Linux
> and Cygwin (with Xfree86). Making it work under native
> Windows sounds formidable and I am not sure if anyone
> is seriously attempting such a port. But I suppose there
> is no reason (in principle) why one could not support
> TeXmacs under Cygwin with access to the Windows native
> version of Axiom. The main purpose of Cygwin then would
> be to provide the x-server windows environment.
> 

For a cygwinless X11 you should check out 
http://sources.redhat.com/win32-x11/ , it appears old, incomplete and 
not currently being worked but ...

\start
Date: Fri, 22 Nov 2002 08:05:40 -0500
From: Earnie Boyd
To: list
Subject:  Re: [Mingw-users] Re: GCL on Cygwin for Axiom
CC: Bill Page

Earnie Boyd wrote:
> Bill Page wrote:
> 
>>
>> A secondary issue is that the next goal after getting
>> OpenAxiom to run in Windows is to provide a new GUI
>> frontend (to replace Techexplorer). The current plan
>> is to use TeXmacs. Currently TeXmacs runs only on Linux
>> and Cygwin (with Xfree86). Making it work under native
>> Windows sounds formidable and I am not sure if anyone
>> is seriously attempting such a port. But I suppose there
>> is no reason (in principle) why one could not support
>> TeXmacs under Cygwin with access to the Windows native
>> version of Axiom. The main purpose of Cygwin then would
>> be to provide the x-server windows environment.
>>
> 
> For a cygwinless X11 you should check out 
> http://sources.redhat.com/win32-x11/ , it appears old, incomplete and 
> not currently being worked but ...
> 

And this http://libw11.sourceforge.net/ which eliminates the need for an 
X server.

\start
Date: Fri, 22 Nov 2002 11:51:17 -0500
From: Tim Daly 
To: Bill Page
Subject:  many topics
CC: Mike Dewar, Tim Daly Jr.

Bill,

re: cygwin

I'm trying to get access to a windows box so I can set up 
cygwin. Damn things are pretty scarce :-) The key problem
is setting up a "compile farm" of various pieces of equipment.
If I can break free about $1000 I can stack a bunch of used
equipment in my basement and set up a local farm. I'm 
deliberately maintaining 3 versions of linux (albeit all
redhat. gotta expand that too) so I can cross-build and find
bugs (like the Bool bug in GCL on RH7.3). I'll have to start
haunting Ebay to find used equipment. Christmas cometh. I'm
CERTAIN the girlfriend will appreciate her used Sun box :-)

re: Lisp

I downloaded CLISP last night and am downloading Corman now.  Lets see
if we can find a runnable Common Lisp you can use. GCL 2.4.x should
run there in some form but I don't know how it will interact with
mingw. I've been looking at the Codemist version and find I'm going to
have to bend a few things around in the Makefiles to make it work due
to the compile-file issue. I'll make it work but it is slow going.
For portability reasons Codemist is our best bet as it uses byte-codes.
I've also discovered (as you will shortly) that GCL 2.5 is ansi-95
compatible which means that the original source code needs
changes. For example, use-package used to create the package by
default. Now it appears that you need to call make-package first.
So to bring Axiom up to the present-day standards is going to take
me a bit more time.

re: TeXmacs

I know that a semi-native windows port has been high on Joris's list
for a long time so any progress there (possibly using mingw) would be
a heeuugge win. I've been too heads-down on the other issues to do
more than test it. We have to add the noweb.sty file to the list of
files that TeXmacs knows about.  I want to add a bunch of Latex macros
to noweb.sty (probably forking off an Axiom.sty file that is upward
compatible) but that's an enqueued task.

re: tenkan CVS

I've asked for all of the developers to have write access to the CVS so
we can try coordinating things thru there. Feel free to make your own
mis...ummm, changes there and I'll adapt. Please, please try to
document everything you do even if it is a one line fix.  At least
test it once and let me know if you can write to it.

\start
Date: 22 Nov 2002 12:02:24 -0500
From: Camm Maguire
To: Tim Daly
Subject:  Re: [Gcl-devel] many topics
Cc: Bill Page, Mike Dewar, Tim Daly Jr.

Greetings!

Tim Daly  writes:

> Bill,
> 
> re: cygwin
> 
> I'm trying to get access to a windows box so I can set up 
> cygwin. Damn things are pretty scarce :-) The key problem
> is setting up a "compile farm" of various pieces of equipment.
> If I can break free about $1000 I can stack a bunch of used
> equipment in my basement and set up a local farm. I'm 
> deliberately maintaining 3 versions of linux (albeit all
> redhat. gotta expand that too) so I can cross-build and find
> bugs (like the Bool bug in GCL on RH7.3). I'll have to start
> haunting Ebay to find used equipment. Christmas cometh. I'm
> CERTAIN the girlfriend will appreciate her used Sun box :-)
> 
> re: Lisp
> 
> I downloaded CLISP last night and am downloading Corman now.  Lets see
> if we can find a runnable Common Lisp you can use. GCL 2.4.x should
> run there in some form but I don't know how it will interact with
> mingw. I've been looking at the Codemist version and find I'm going to
> have to bend a few things around in the Makefiles to make it work due
> to the compile-file issue. I'll make it work but it is slow going.
> For portability reasons Codemist is our best bet as it uses byte-codes.
> I've also discovered (as you will shortly) that GCL 2.5 is ansi-95
> compatible which means that the original source code needs
> changes. For example, use-package used to create the package by
> default. Now it appears that you need to call make-package first.
> So to bring Axiom up to the present-day standards is going to take
> me a bit more time.
> 

If this proves onerous, I could #ifdef in the old behavior when
configuring without --enable-ansi.  But its probably a good idea for
Axiom to make this change in the long run.  If you'd like me to do
this, just let me know.

Take care,

> re: TeXmacs
> 
> I know that a semi-native windows port has been high on Joris's list
> for a long time so any progress there (possibly using mingw) would be
> a heeuugge win. I've been too heads-down on the other issues to do
> more than test it. We have to add the noweb.sty file to the list of
> files that TeXmacs knows about.  I want to add a bunch of Latex macros
> to noweb.sty (probably forking off an Axiom.sty file that is upward
> compatible) but that's an enqueued task.
> 
> re: tenkan CVS
> 
> I've asked for all of the developers to have write access to the CVS so
> we can try coordinating things thru there. Feel free to make your own
> mis...ummm, changes there and I'll adapt. Please, please try to
> document everything you do even if it is a one line fix.  At least
> test it once and let me know if you can write to it.

\start
Date: Fri, 22 Nov 2002 12:23:37 -0500
From: Tim Daly 
To: Camm Maguire
Subject:  Re: [Gcl-devel] many topics
CC: Bill Page, Mike Dewar, Tim Daly Jr.

re: ifdef-ing out make-package check.

Nope, leave it in. Axiom's got to come up to standards not the other
way around.

\start
Date: Sat, 23 Nov 2002 09:19:09 +0100 (MET)
From: Joris van der Hoeven
To: Bill Page
Subject:  RE: [Texmacs-dev] Axiom and TeXmacs

> > Maybe we should preprocess the pamphlet file using Perl
> > before doing the conversion. I think that St=E9phane
> > Payrard might be willing to help us with that.
> 
> If I understand you correctly, I do not think a Perl
> filter is a good approach. I have nothing against Perl
> as such, its just that I think the goal should be more
> than loading a pamphlet file into TeXmacs in a readable
> manner.
> 
> I think there should be a new File->Import->Pamphlet
> option for this case. The result of importing a pamphlet
> should be a TeXmacs document with a folded structure.
> The code chunks should appear folded into the document so
> that when viewed or printed with a style called "weave"
> for example, the result would be the same as the output
> of
> 
>  noweave | latex
> 
> A different style which displayed the contents of the
> folded chunks could be used for editing. Code chunks
> have to be named and will also have references to
> other code chunks embedded in them.

Well, as I understand it, the pamphlet format is
a LaTeX with special escape sequences for dealing
with code or other special markup. Therefore,
I think that the best way of importing such files
is to first convert it to standard LaTeX
(with possible pamphlet-specific commands),
with a language like Perl, and next convert
the result to TeXmacs using the standard input filter.

> Perhaps it would be nicer if TeXmacs was able to
> expand and collapse folds on demand. It is not really
> clear to me hold folding is intended to work in TeXmacs.
> I wasn't able to find any documentation about it and
> my experiments with it so far have not produced a clear
> picture. Perhaps it is still largely in the planning
> stage? 

Yes, this will be dealt with sometime next year.

> Finally there should be an new File->Export->Tangle
> menu option that would generate code and be equivalent
> to
> 
>   notangle
> 
> which expands the code chunks starting with the root
> <<*>>= and including all the referenced code chunks
> in the whole tree structure.

Yes, that should not be difficult.

> We could also have a Tools->Selections->Export->Tangle
> option that applies notangle starting with a selected
> code chunk instead of the root.

Yes, we systematically do that for all formats.

> > > Joris, can you point me at some specific part of
> > > the TeXmacs docs that will help us develop a pamphlet
> > > "style" file. A style file that properly handle
> > > noweb vanilla output would be quite useful.
> > 
> > Help -> Styles
> > 
> > Unfortunately, the documentation is very incomplete,
> > because the support for writing style files will be
> > much improved at a not yet specified date...
> 
> Perhaps it would help to be able to look at some
> existing styles that do something similar to what
> we want. What would you recommend?

I think that we first need to know what you already have.
Also: how much documentation does already exist in
the pamphlet format?

\start
Date: Sat, 23 Nov 2002 08:55:50 -0500
From: Bill Page
To: Joris van der Hoeven
Subject:  RE: [Texmacs-dev] Axiom and TeXmacs

On Saturday, November 23, 2002 3:19 AM Joris van der Hoeven
> ... 
> Well, as I understand it, the pamphlet format is
> a LaTeX with special escape sequences for dealing
> with code or other special markup. Therefore,
> I think that the best way of importing such files
> is to first convert it to standard LaTeX
> (with possible pamphlet-specific commands),
> with a language like Perl, and next convert
> the result to TeXmacs using the standard input filter.

Yes and no. Tim, please correct me if I make a mistake
here...

The pamphlet format is really noweb input format. As
Norman Ramsey defines it, the input to noweb is quite
language independent and very simple. noweb is a
simplified version of Knuth's web ("no" for Norman,
I guess). All we have are named "code" chunks e.g.

 <<name>>= ... <<othername>> ... @

which may reference other code chunks, e.g.
<<othername>> above, embedded in a text stream. Text
areas start with @ (except first). There are two
primary operations to be done on this file. One is
"weave" which extracts just the text stream (no code)
and the other is "tangle" which expands a given code
chunk (by default starting with the root chunk <<*>>=)
by including all of the other code chunks referenced
in that chunk, recursively. It is possible to 
generate different results from the same input file
by specifying a different root for tangle.

It is true that the text stream is usually LaTex
code but I don't think that is a requirement of
noweb. The code chunks can also be in any language.

I believe Tim Daly defined the term "pamphlet" to
refer to the noweb input files that he is using in
the open source axiom project. These will (I presume)
always have a LaTex text stream part plus code
chunks in several different languages: makefile
script, C, lisp, SPAD (axiom specific), etc. I think
Tim has in mind also using such pamphlet files to
exchange axiom code between users.

And of course we also plan to use TeXmacs as
a front-end to axiom itself as a high level user
interface capable of entering and displaying
mathematics in a rich graphics format.

So when importing a pamphlet file into TeXmacs,
it is desirable to interpret the text stream part
of the input file as LaTex and convert it
appropriately, but it is also important to retain
the code chunks in their place in the original
file. What I was suggesting below was that it
seemed natural to me to treat these chunks as
"folded" into the TeXmacs document. That way,
when the folds are collapsed (closed), the
document would have the appearance of LaTex applied
to the weave output and would print that way. But
one could open a folded code chunk and edit it.
The only new thing would be expanding code chunks
during a "tangle" export. This could be done
easily just by extracting all code chunks and
then calling notangle.

> 
> > Perhaps it would be nicer if TeXmacs was able to
> > expand and collapse folds on demand. It is not
> > really clear to me hold folding is intended to
> > work in TeXmacs. I wasn't able to find any
> > documentation about it and my experiments with
> > it so far have not produced a clear picture. 
> > Perhaps it is still largely in the planning stage?
> 
> Yes, this will be dealt with sometime next year.
>

Would you be interested in having someone (me) help
to accelerate that schedule? Are there other people
interested in the "fold" concept?
 
> > ... 
> > Perhaps it would help to be able to look at some
> > existing styles that do something similar to what
> > we want. What would you recommend?
> 
> I think that we first need to know what you already
> have.

There are LaTex "styles" and TeXmacs "styles". These
are different, right? So far I think Tim has only
made use of only relatively standard LaTex style
files.

The reason I mentioned TeXmacs styles is because
that is the only way thing that I could find at
this time that interacts with how folded text is
displayed. Perhaps that is not the way you intend
to go with folds?

> Also: how much documentation does already exist
> in the pamphlet format?
>

We are only at the beginning of the project. Did
you have in mind some other format?

\start
Date: Sat, 23 Nov 2002 12:17:52 -0500
From: Tim Daly 
To: Joris van der Hoeven
Subject:  noweb, pamphlets, and TeXmacs
Cc: Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

All,

I've written some tutorial notes on the pamphlet idea to try to get
everyone at the same level of discussion. Essentially what Bill
has been pursuing is a way to integrate noweb and TeXmacs so that
we can support pamphlet file documents. As there is some confusion
about what each part is I've decided to write it out in full. 
Feel free to complain about mistakes.

Bill's ideas are essentially correct. His note is attached.

=================
RE: NOWEB
=================

Knuth and Dijkstra advocated literate programming to try to solve
the problem of marrying the knowledge behind a program with the 
text of the program itself. Knuth wrote Web which was designed to
work with Pascal thus:

    .web formatted document
        |   |
        |   ------> tangle ----> pascal code ----> compile ---> execute
        ----------> weave  ----> tex format  ----> latex   ---> read

As this was Pascal-specific various other language-specific versions
were generated, e.g. CWeb for C.

Norman's innovation is that we don't need to be language specific.
With just a few additional tags above TeX we gain great power.

Since Axiom uses many forms of code (Makefiles, C, lisp, boot, spad, etc)
this is a key idea. We need to be able to embed many things transparently.
If we remove the language-specific options and simplify things we
can reduce the problem to this:


    .noweb formatted document
        |   |
        |   ------> notangle ----> any code    ----> compile ---> execute
        ----------> noweave  ----> tex format  ----> latex   ---> read

Norman's implementation is called noweb. In essence, a noweb document
consists of alternations of code chunks and text blocks. A code
block is marked by:

<<(some string)>>=

   code

@

Code chunks continue until encountering an @ in column 1 or another
chunk marker (the <<(some string)>>= tag). 

The trailing equal sign marks this as a "definition" of the (some
string) block. Lack of a trailing equal sign marks this as a "use"
of the (some string) block. Uses are expanded by notangle.

Another important idea is that multiple occurences of the definition
string are concatenated into one definition thus:

<<a>>=
  code 1
@
....
<<a>>=
  code 2
@
....
<<a>>  ==> expands into:
              code 1
              code 2

We use this idea extensively in the documentation of code.

Text blocks are all that are not code chunks. Text blocks are tex
formatted document blocks.


=================
RE: TEXMACS
=================

TeXmacs is neither emacs not TeX but is an interesting cross-product
of the two ideas. Joris set out to make a useful front-end to a
computer algebra system and ended up with a generally useful tool.
It communicates with many computer algebra systems and is able to
properly format the math output in TeX style yet retain it as a
live object that can be handed back to the underlying system. In
addition, TeXmacs is able to properly format a large subset of 
Tex and Latex documents.

TeXmacs, as Bill has been pointing out, is an excellent target for
an Axiom front-end. It already can talk directly to Axiom's interpreter
and embed the output into the TeXmacs buffer. It can already display
the .tex output from noweb.

Support for native noweb format would be most useful. The subtle
distinction that Bill was mentioning is that currently we can take
the "tex format" output and display it in TeXmacs. However, we would
like to fully support noweb as a standard format. This implies a couple
changes.

As mentioned above noweb does:

    .noweb formatted document
        |   |
        |   ------> notangle ----> any code    ----> compile ---> execute
        ----------> noweave  ----> tex format  ----> latex   ---> read

If TeXmacs understood the noweb format fully it would need to have
the following features:

0) The ability to recognize and format a code chunk.
1) The ability to recognize the <<defn>>=, concatenation, and <<use>>
   features of the code chunks.
2) The ability to create a "notangled" buffer from the current buffer
   that would contain the formatted code.

     Ideally you could make changes in the formatted code and have the
     changes reflected back into the original buffer. Some of these
     changes could be problematic.

3) The ability to create a "noweave" buffer from the current buffer
   that would contain the formatted document.

     The same comment as above applies. It would take some careful
     design to properly "untangle" some changes.

4) Bill has suggested that the folding mechanism know about the code
   chunks and be able to fold and unfold them. Perhaps the way to 
   make the "untangle" work would be to ignore the separate buffer
   idea above and just use folding. I have no opinion about either
   path yet.

     It is very important that NO changes occur in the code chunks.
     If TeXmacs or noweb or any other tool does not understand the
     format it must maintain "transparency". That is, it must NOT
     try to format things in the code chunks. Other tools have special
     needs (e.g. Makefiles care about tabs) and you can't change
     the code chunks because they will be output to other tools.

5) There are other ideas, not yet exposed, that it would be nice to
   have supported. I guess I need to talk more about the pamphlet 
   idea in depth.


=================
RE: PAMPHLET FILES AND THE PRESENT
=================

Pamphlet files are now the native format for code and documentation.
There are no longer any Makefile, C, lisp, boot or spad files in the 
system. All file formats have been subsumed into pamphlet files.

Currently .pamphlet documents, except for a recent patch, are 
normal .noweb formatted documents. They have very little structure
at the moment.

Here is the way things currently interact:

    .pamphlet formatted document
        |   |
        |   ------> notangle ----> any code    ----> compile ---> execute
        ----------> noweave  ----> tex format  ----> latex   ---> read

Pamphlet files are currently being used to document the internals
of Axiom. A file written originally in Boot is now written as a
pamphlet file. The pamphlet file is expanded and the rest of the
compile process takes place thus:

Originally:

   foo.boot -> (translate) -> foo.lisp -> (compile) -> foo.o (load) .....

Now:

    foo.pamphlet 
        |   |
        |   -> notangle -> foo.boot -> (translate) ....
        -----> noweave  -> foo.tex  -> latex -> read


=================
RE: PAMPHLET FILES AND THE FUTURE
=================

However, pamphlet files have a larger purpose besides documenting
internals of the system. Axiom has a large amount of algebra code
written in SPAD, a high level language. Much of the research behind
this code is hidden away in libraries. I'm hoping to use literate
programming to join these two threads, the theory and the implementation,
into a unified whole and then expand it beyond a simple join. 

The end vision of using literate programming in Axiom is that you can
receive a "Booklet" which gives the theory and implementation of some
area of math, say linear algebra.  The "Booklet" is composed of
"pamphlets" (not the same concept as a chapter but that's close
enough).

Suppose you have an Axiom system. If you receive a Booklet you can
"drag and drop" the Booklet onto the system. It decomposes the Booklet
into Pamphlets, follows the references to pick up required pamphlets,
compiles the code, expands the user documentation into the proper
format, sets up example files for use, runs test cases to ensure that
functions work, adds the documentation to the theory tree, and washes
the dirty dishes.

Booklet format or Pamphlet format would be the standard format
for submission to an "Axiom Journal". This journal would allow
people to test code that was submitted with the theory. After all,
we expect Physics and Chemistry experiments to be reproduced and
validated; why not Computational Mathematics?

Booklets can be composed from a running system in (at least) two
directions. 

First, you compose a set of Pamphlet files "across the system" so that
you could document, say, all of the matrix facilities currently
available. 

Second, you compose a set of Pamphlet files "thru the system" so that
you could document, say, the integration mechanism from the top level
function all the way to the implementation details.

Thus you can insert and extract Booklets with Axiom making it easier
to share knowledge.

Future:

 Linear Algebra Booklet
 |   
 |-> NullSpace.pamphlet 
 |   |   |   |
 |   |   |   -> notangle -> nullspace.spad -> 
 |   |   -----> noweave  -> nullspace.tex  -> latex -> read
 |   |--------> dereference -> load and use other code.spad ->
 |   |--------> userdocs    -> update Axioms user documentation 
 |   |--------> testcase    -> run test cases
 |   |--------> examples    -> input files
 |   |--------> textbook    -> update Axiom's current textbook
 |   |--------> proofs      -> ACL2, MetaPRL files
 |-> Pivots.pamphlet
    ......

Huge dream, I realize, but except for the dishes, I see no technical
reason why it can't be done.

This implies, of course, that Pamphlets can be decomposed into a
finer level of detail which is still under development. 

=================
RE: PAMPHLET FILES AND THE NEAR TERM
=================

All of which implies a huge amount of work. It would be great
to have a front-end that supported both the current and future
directions. 

RE: NOWEB CHANGES

Currently noweb needs to expand the chunk definition syntax
to handle some more general scheme such as a URL. We need to
be able to extract code chunks from other pamphlets so that
you can have the following situation:

pamphlet A:  (the definition document)
    ...
    <<foo>>=
    ...

pamphlet B:  (the using document)
    ...
    <<pamphlet:/path/A#foo>>
    ...

It would be useful if this could happen for text blocks also
so that generally useful descriptions could be inserted into
multiple pamphlets. Since the text blocks currently have
no label this becomes problematic. We need to develop text
labels so we can follow a uniform scheme. Multiple text blocks
containing essentially the same information already exist in
the system. This needs to be fixed.

For larger references (e.g. whole pamphlets) I'm currently
using the bibliography environment. However, I plan to have
a new Latex tag, say PAMPHLETREFS, that have a bibtex-like
reference set. Tags in this environment point to other
pamphlet files. Perhaps the "URL syntax" proposed above 
could use the \PCITE{} tag instead:

pamphlet A:  (the definition document)
    ...
    <<foo>>=
    ...

pamphlet B:  (the using document)
    ...
    <<\pcite{3}{foo}>>
    ...


Anybody who understands bibtex and would like
to take a shot at this is welcome. 

RE: TEXMACS CHANGES

Currently TeXmacs could take the following steps, probably as
a joint effort, to support Axiom:

1) Recognize noweb format
2) Integrate commands to notangle and noweave
3) Possibly either support
   a) folding out code
   b) notangle, noweave to "dependent" buffers
   c) backport changes to "dependent" buffers to the original document
   d) possibly all of the above
4) Integrate noweb.sty
     Eventually this will evolve into Axiom.sty as we need to add
     more latex macros, like \begin{theorem}, \begin{userdoc}, 
     \begin{pamphletrefs}, etc

Perhaps we can lay out a more detailed plan that includes various
steps we can all work on.

I'm willing to help with any steps taken in this direction.
Feedback is welcome.

Tim



------------------------- forwarded note ---------------------------
On Saturday, November 23, 2002 3:19 AM Joris van der Hoeven
> ... 
> Well, as I understand it, the pamphlet format is
> a LaTeX with special escape sequences for dealing
> with code or other special markup. Therefore,
> I think that the best way of importing such files
> is to first convert it to standard LaTeX
> (with possible pamphlet-specific commands),
> with a language like Perl, and next convert
> the result to TeXmacs using the standard input filter.

Yes and no. Tim, please correct me if I make a mistake
here...

The pamphlet format is really noweb input format. As
Norman Ramsey defines it, the input to noweb is quite
language independent and very simple. noweb is a
simplified version of Knuth's web ("no" for Norman,
I guess). All we have are named "code" chunks e.g.

 <<name>>= ... <<othername>> ... @

which may reference other code chunks, e.g.
<<othername>> above, embedded in a text stream. Text
areas start with @ (except first). There are two
primary operations to be done on this file. One is
"weave" which extracts just the text stream (no code)
and the other is "tangle" which expands a given code
chunk (by default starting with the root chunk <<*>>=)
by including all of the other code chunks referenced
in that chunk, recursively. It is possible to 
generate different results from the same input file
by specifying a different root for tangle.

It is true that the text stream is usually LaTex
code but I don't think that is a requirement of
noweb. The code chunks can also be in any language.

I believe Tim Daly defined the term "pamphlet" to
refer to the noweb input files that he is using in
the open source axiom project. These will (I presume)
always have a LaTex text stream part plus code
chunks in several different languages: makefile
script, C, lisp, SPAD (axiom specific), etc. I think
Tim has in mind also using such pamphlet files to
exchange axiom code between users.

And of course we also plan to use TeXmacs as
a front-end to axiom itself as a high level user
interface capable of entering and displaying
mathematics in a rich graphics format.

So when importing a pamphlet file into TeXmacs,
it is desirable to interpret the text stream part
of the input file as LaTex and convert it
appropriately, but it is also important to retain
the code chunks in their place in the original
file. What I was suggesting below was that it
seemed natural to me to treat these chunks as
"folded" into the TeXmacs document. That way,
when the folds are collapsed (closed), the
document would have the appearance of LaTex applied
to the weave output and would print that way. But
one could open a folded code chunk and edit it.
The only new thing would be expanding code chunks
during a "tangle" export. This could be done
easily just by extracting all code chunks and
then calling notangle.

> 
> > Perhaps it would be nicer if TeXmacs was able to
> > expand and collapse folds on demand. It is not
> > really clear to me hold folding is intended to
> > work in TeXmacs. I wasn't able to find any
> > documentation about it and my experiments with
> > it so far have not produced a clear picture. 
> > Perhaps it is still largely in the planning stage?
> 
> Yes, this will be dealt with sometime next year.
>

Would you be interested in having someone (me) help
to accelerate that schedule? Are there other people
interested in the "fold" concept?
 
> > ... 
> > Perhaps it would help to be able to look at some
> > existing styles that do something similar to what
> > we want. What would you recommend?
> 
> I think that we first need to know what you already
> have.

There are LaTex "styles" and TeXmacs "styles". These
are different, right? So far I think Tim has only
made use of only relatively standard LaTex style
files.

The reason I mentioned TeXmacs styles is because
that is the only way thing that I could find at
this time that interacts with how folded text is
displayed. Perhaps that is not the way you intend
to go with folds?

> Also: how much documentation does already exist
> in the pamphlet format?
>

We are only at the beginning of the project. Did
you have in mind some other format?

\start
Date: Sat, 23 Nov 2002 14:05:01 -0500
From: Bill Page
To: Joris van der Hoeven
Subject:  RE: noweb, pamphlets, and TeXmacs
Cc: Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

Tim,

Thanks for the treatise on noweb etc.

On Saturday, November 23, 2002 12:18 PM
Tim Daly wrote:

>... 
> RE: NOWEB CHANGES
> 
> Currently noweb needs to expand the chunk definition syntax
> to handle some more general scheme such as a URL. We need to
> be able to extract code chunks from other pamphlets so that
> you can have the following situation:
> 
> pamphlet A:  (the definition document)
>     ...
>     <<foo>>=
>     ...
> 
> pamphlet B:  (the using document)
>     ...
>     <<pamphlet:/path/A#foo>>
>     ...
> 

Sounds cool to me! Hypercode - perhaps the ultimate form
of open source. Maybe someone's thought of this before?

I especially like the idea of using code that is contained
within its own (presumably complete) documentation.

> It would be useful if this could happen for text blocks
> also so that generally useful descriptions could be
> inserted into multiple pamphlets. Since the text blocks
> currently have no label this becomes problematic. We need
> to develop text labels so we can follow a uniform scheme.
> Multiple text blocks containing essentially the same
> information already exist in the system. This needs to be
> fixed.
> 

Why not just forget what is now the text part and
simply have at least two pre-defined roots, one
for code and one for documentation? Then tangle does
both jobs.

\start
Date: Sun, 24 Nov 2002 01:51:45 -0500
From: William Sit
To: Tim Daly
Subject:  Re: noweb, pamphlets, and TeXmacs
CC: Joris van der Hoeven, Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein

Just a simple comment on:

> Currently noweb needs to expand the chunk definition syntax
> to handle some more general scheme such as a URL.

I object to allowing URL in the pamphlet document, the reason being that
pamplet is designed to be "self-contained" (as much as possible). A URL
is unfortunately not something permanent and the link therefore can
frequently be broken. Unless there is some mechanism to ensure that all
URL are valid and updated, it would not be useful. An example: authors
post preprints to the web. Perhaps because of copyright, the preprints
are withdrawn after publication. The URL pointing to the preprint no
longer works, and no new one can be substituted (even pointing to the
journal does not assure availability because of subscription; pointing
to an archive may violate copyright).

  The trouble is that there is no mechanism for the author of the
pamphlet who cited the URL to be aware or notified when the URL fails
(which may happen years afterwards when someone try that link). If the
goal is to preserve documentation and readability "for eternity", this
would not be acceptable.

  Ideally, it seems we are planning to build Axiom into a mathematical
encyclopedia for symbolic computation, and so references should be as
internal as possible. Of course, we cannot achieve this until "steady
state" occurs, but if this dilemma is not considered and resolved now,
the goal could never be reached.

  The same consideration would require that the Axiom system be always
backward compatible when the language grows to incorporate new
technologies; and if not, there should be automatic translations to
update all existing pamphlets.

\start
Date: Sun, 24 Nov 2002 09:56:26 -0500
From: Tim Daly 
To: William Sit
Subject:  Re: noweb, pamphlets, and TeXmacs
CC: Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein

Bill,

The URLs are all assumed to be internal, hence the pamphlet:
prefix. I only wanted to steal the syntax since parsers are
available and the syntax is already defined. Nothing about
Axiom is intended to point elsewhere.

The key issue is that I'd like to share code chunks and text blocks
between pamphlets. I can do this with \include tex macros but the
macros do not know the pamphlet file format. URLs (PRLs? Pamphlet
resource locators?)

Consider the issue of describing the way your code makes novel use
of some routine out of another document, say DHMATRIX.spad.pamphlet.
Rather than either copying the code or including a makefile
that will build both documents and strip the code block (both
solutions work) you could just <<PRL:/(path)/doc#code>>.

You do make a good point that this technology cries for abuse.
Perhaps a new syntax and working could correct that.

\start
Date: Sun, 24 Nov 2002 16:36:16 +0100 (CET)
From: Bertfried Fauser
To: list
Subject:  axiom mailing lists

Dear All,

	I follow with great interest and emphasis the mails in the
axiom-mail and axiom-developer mailing lists. However, if you dump all
messages into both lists, one gets really spamed by copies of identical
mails.

	I would also appreciate if replies would contain only those parts
of the original message which are relavant, e.g. the very helpfull and
nice desciption of the pamphlet format was received some 4 to 5 times, and
in such long mail replies its very cumbersome to scan the whole several
kB long mail if reasonable further comments supplied.

	Sorry if this is mail, comming from an inactive listener to the
lists, is considered unpolite, I would appologize for that.

\start
Date: Sun, 24 Nov 2002 10:39:18 -0500
From: Tim Daly 
To: William Sit
Subject:  Re: noweb, pamphlets, and TeXmacs
CC: Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein

Bill,

About PRLs (Pamphlet URLs)...

The key reason, which didn't leap to mind this morning, is that
they are the enabling technology behind "Booklets". The Booklet
is intended to collect Pamphlets into a joined form. However,
for purposes of a readable exposition, it will almost certainly
be necessary to quote sections of the Pamphlets "out of order".

Consider what happens when you try to explain all of the matrix
facilities, which are individually described in Pamphlets, as one
Booklet. Clearly one could use the "Big Staple" approach and just
concatenate them. However, it would be better if the Booklet were
more organized. Booklets need to quote portions of the Pamphlets.
You could clearly do this by copying but it would be better to
use <<PRL:>> style references.

\start
Date: Sun, 24 Nov 2002 17:07:01 +0100 (MET)
From: Joris van der Hoeven
To: Bill Page
Subject:  RE: [Texmacs-dev] Axiom and TeXmacs

> > Also: how much documentation does already exist
> > in the pamphlet format?
> 
> We are only at the beginning of the project. Did
> you have in mind some other format?

I would advocate using the TeXmacs format in that case,
so that we won't have to write specialized converters,
and maintain them for every change in the format.

Operations on pamphlet documents like extraction of
the code or the documentation may be seen as particular
instances of operations on structured documents.
In other words, operations like "tangle" might be
written directly in scheme (so that they can be invoked
using a shell/scheme script).

Notice that we have started to adopt a similar strategy
for the online documentation of TeXmacs: documentation
is subdivided in small entities which can be treated
independently (maintainance, translations, etc.).
We next provide markup and programs to reconstitute
complete documentation (like a full manual) from these pages.

This process is still at a very early stage and we plan to improve it
slowly but steadily. In the future, we plan for instance to add better
tools for cross-citation, automatic searching, several possible views
of documentation, folding, etc. We also plan to enhance the tools for
writing documentation: specialized menus, collective authoring via
the web, and so on.

\start
Date: Sun, 24 Nov 2002 18:17:25 +0100 (MET)
From: Joris van der Hoeven
To: Tim Daly 
Subject:  Re: noweb, pamphlets, and TeXmacs
Cc: Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

Thanks for the detailed tutorial, Tim.

> Knuth and Dijkstra advocated literate programming to try to solve
> the problem of marrying the knowledge behind a program with the 
> text of the program itself. Knuth wrote Web which was designed to
> work with Pascal thus:
> 
>     .web formatted document
>         |   |
>         |   ------> tangle ----> pascal code ----> compile ---> execute
>         ----------> weave  ----> tex format  ----> latex   ---> read
> 
> As this was Pascal-specific various other language-specific versions
> were generated, e.g. CWeb for C.
> 
> Norman's innovation is that we don't need to be language specific.
> With just a few additional tags above TeX we gain great power.

I also would like to stress that 1) there is no reason to stick to
only two possible ways of extraction (tangle and weave) and
2) that the language independence might also hold for weave.

> In addition, TeXmacs is able to properly format a large subset of 
> Tex and Latex documents.

Notice that TeXmacs is not just capable to properly format a large
subset of TeX/LaTeX, but that it also provides markup which is not
available in TeX/LaTeX (hyperlinks, actions, simple folding, etc.).
What is more, like in TeX/LaTeX, you may define your own markup,
and, like in Emacs, construct special editing modes for editing
such markup. This may apply in particular to things like customized
ways of folding, direct execution of an Axiom example from
the documentation, etc.

> 0) The ability to recognize and format a code chunk.
> 1) The ability to recognize the <<defn>>=, concatenation, and <<use>>
>    features of the code chunks.

All you have to do is to add a special tag like "chunk"
with one or more arguments. A preprocessor might then rewrite
your <<defn>>= syntax into more standard LaTeX like
\begin{chunk}{...} ... \end{chunk} and then use
the standard input filter.

However, as I pointed out before, it might be better to directly
use the TeXmacs format with additional tags and write the operations
like tangle and weave in Scheme.

> 2) The ability to create a "notangled" buffer from the current buffer
>    that would contain the formatted code.
> 
>      Ideally you could make changes in the formatted code and have the
>      changes reflected back into the original buffer. Some of these
>      changes could be problematic.

I rather see this as having several possible ways of looking at
pamphlet documents. Also, David Allouche will be working next year on
a way to perform operations like "tangle" and "weave" dynamically during
the editing phase. This presupposes that "tangle" and "weave" become
native operations in TeXmacs, comparible to (but not an instance of)
the application of an XML style.

> 3) The ability to create a "noweave" buffer from the current buffer
>    that would contain the formatted document.
> 
>      The same comment as above applies. It would take some careful
>      design to properly "untangle" some changes.

Yes, as I said before, there is no reason to distinguish between tangle
and weave and no reason to limit oneself to two operations.

> 4) Bill has suggested that the folding mechanism know about the code
>    chunks and be able to fold and unfold them. Perhaps the way to 
>    make the "untangle" work would be to ignore the separate buffer
>    idea above and just use folding. I have no opinion about either
>    path yet.

In a dynamic editor like TeXmacs, it should be noticed that
folding/unfolding becomes in fact a quite subtle operation.
In fact, one has to think about the kind of semantics that one requires.

For instance, do you see folding as an operations which makes a change
in the text, or rather like an operation which modifies the view of
a text? The first interpretation is easiest to implement.
In the second case, one has to define the notion of a "view"
(and in particular: what information determines a view?).
Also, you would have to think about how to undo changes.

Another difficulty has to do with TeXmacs' ability to let the user
define his/her own macros. What should be the semantics of
a macro which is built upon a "fold" tag?

> 5) There are other ideas, not yet exposed, that it would be nice to
>    have supported. I guess I need to talk more about the pamphlet 
>    idea in depth.

Well, it would be nice to make up a list of all tags (with options and
everything) which might be useful for pamphlet files. You might also
want to take a look at some (still very rudimentary) ideas in
the tmdoc format.

At the moment, I mainly see the "chunk" tag as a variant of
our "specific" tag, which is used in order to export content
in a specific way to specific formats. We basically have to
respecify the semantics of such a tag in a very general setting.

> First, you compose a set of Pamphlet files "across the system" so that
> you could document, say, all of the matrix facilities currently
> available. 
> 
> Second, you compose a set of Pamphlet files "thru the system" so that
> you could document, say, the integration mechanism from the top level
> function all the way to the implementation details.

My way of viewing this is the use of one file for each atomic
functionality of the system. Each such file should come with
meta-information like the bigger classes to which it belongs
(linear algebra, topology, etc.). Each file may also contain
information about other relevant related files or how to
traverse files in a sensible order (cf. tmdoc style).
One may then implement special functions into TeXmacs for
extracting the information one needs.

> Thus you can insert and extract Booklets with Axiom making it easier
> to share knowledge.
> 
> Future:
> 
>  Linear Algebra Booklet
>  |   
>  |-> NullSpace.pamphlet 
>  |   |   |   |
>  |   |   |   -> notangle -> nullspace.spad -> 
>  |   |   -----> noweave  -> nullspace.tex  -> latex -> read
>  |   |--------> dereference -> load and use other code.spad ->
>  |   |--------> userdocs    -> update Axioms user documentation 
>  |   |--------> testcase    -> run test cases
>  |   |--------> examples    -> input files
>  |   |--------> textbook    -> update Axiom's current textbook
>  |   |--------> proofs      -> ACL2, MetaPRL files
>  |-> Pivots.pamphlet
>     ......

Absolutely.

> Huge dream, I realize, but except for the dishes, I see no technical
> reason why it can't be done.
>
> This implies, of course, that Pamphlets can be decomposed into a
> finer level of detail which is still under development. 

Well, it all boils down to inventing suitable markup tags which
reflect the complexity of the problem. So please give this matter
a thought and come up with some more precise proposals.
After that, we will have a discussion and see how to implement
all this in TeXmacs.

> Currently noweb needs to expand the chunk definition syntax
> to handle some more general scheme such as a URL. We need to
> be able to extract code chunks from other pamphlets so that
> you can have the following situation:
> 
> pamphlet A:  (the definition document)
>     ...
>     <<foo>>=
>     ...
> 
> pamphlet B:  (the using document)
>     ...
>     <<pamphlet:/path/A#foo>>
>     ...
> 
> It would be useful if this could happen for text blocks also
> so that generally useful descriptions could be inserted into
> multiple pamphlets. Since the text blocks currently have
> no label this becomes problematic. We need to develop text
> labels so we can follow a uniform scheme. Multiple text blocks
> containing essentially the same information already exist in
> the system. This needs to be fixed.
> 
> For larger references (e.g. whole pamphlets) I'm currently
> using the bibliography environment. However, I plan to have
> a new Latex tag, say PAMPHLETREFS, that have a bibtex-like
> reference set. Tags in this environment point to other
> pamphlet files. Perhaps the "URL syntax" proposed above 
> could use the \PCITE{} tag instead:
> 
> pamphlet A:  (the definition document)
>     ...
>     <<foo>>=
>     ...
> 
> pamphlet B:  (the using document)
>     ...
>     <<\pcite{3}{foo}>>
>     ...
>
> Anybody who understands bibtex and would like
> to take a shot at this is welcome.

As I see it now, you have the following ingredients for chunck tags:

1) A "format" which determines the program which should be used 
   in order to do extractions. More generally, it reflects the purpose
   of the enclosed content (documentation, code, example, etc.).

2) An "identifier" for specifying how several chunks should be grouped
   together. In fact, it might be nice to see this independently from
   the chunk tags, but rather as a variant of labels and references.
   In other words, logical grouping of different parts of content
   may be nice in other circumstances too.

So maybe we should see the chunk tag as the combination of
two more basic tags: one for specifying the purpose, functionality
or class of a given region of text, and one for grouping scattered
pieces of information.

> RE: TEXMACS CHANGES
> 
> Currently TeXmacs could take the following steps, probably as
> a joint effort, to support Axiom:
> 
> 1) Recognize noweb format

And we should decide whether we want to keep on working with this format,
or whether we want to switch to a format for which it will be easier to
add new features.

> 2) Integrate commands to notangle and noweave.

This should be straightforward to write in Scheme once that one has
the appropriate tags.

> 3) Possibly either support
>    a) folding out code

Please think more precisely about the semantics that
you would like to have.

>    b) notangle, noweave to "dependent" buffers

Cf. improving the markup for inclusions like in the tmdoc style.

>    c) backport changes to "dependent" buffers to the original document

Dynamic editing of depending buffers is very likely to require
the "dynamic rewriters" that David Allouche will implement next year;
this will probably take us a year of work. 

I also remind you that TeXmacs does not have a one-to-one mapping with
TeX/LaTeX. In other words, you can not longer use TeX/LaTeX as a reliable
format for explanatory text in this scheme. If you want to edit
the original document using TeXmacs, it is better to either use TeXmacs
as the document format for your pamphlet files, or at least to replace
chunks of LaTeX by chunks of TeXmacs.

> 4) Integrate noweb.sty
>      Eventually this will evolve into Axiom.sty as we need to add
>      more latex macros, like \begin{theorem}, \begin{userdoc}, 
>      \begin{pamphletrefs}, etc

You should write a noweb.ts TeXmacs style file for this.
Unfortunately, writing style files is not well documented yet,
but you can ask questions on the texmacs-dev list.

\start
Date: Sun, 24 Nov 2002 12:27:22 -0500
From: Tim Daly 
To: list
Subject:  Re: noweb, pamphlets, and TeXmacs

Joris, 

Is TeXmacs scriptable? That is, can I run it from a Makefile
silently during document generation? The way Axiom is structured
you can build the whole of the system from the sources by typing
"make". This currently includes the tangling for code generation
and weaving for document generation. Porting tangle and weave to
lisp would allow those operations to continue to be scripted. My
question concerns other TeXmacs operations like URL tag following.

\start
Date: Sun, 24 Nov 2002 19:20:54 +0100 (MET)
From: Joris van der Hoeven
To: Tim Daly 
Subject:  Re: noweb, pamphlets, and TeXmacs

> Is TeXmacs scriptable? That is, can I run it from a Makefile
> silently during document generation?

Yes, but probably you do not want to run TeXmacs as a script,
but rather Scheme, since you just want to extract information from
the TeXmacs document (which can be saved as a scheme expression).
You might want to run TeXmacs as a script though if you want to use it as
a real typesetter. However, this feature has to be improved, because it is
not very clean yet.

> The way Axiom is structured
> you can build the whole of the system from the sources by typing
> "make". This currently includes the tangling for code generation
> and weaving for document generation. Porting tangle and weave to
> lisp would allow those operations to continue to be scripted. My
> question concerns other TeXmacs operations like URL tag following.

\start
Date: Sun, 24 Nov 2002 13:45:29 -0500
From: William Sit
To: Tim Daly
Subject:  Re: noweb, pamphlets, and TeXmacs
CC: Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein

> The URLs are all assumed to be internal, hence the pamphlet:
> prefix. 
> you could just <<PRL:/(path)/doc#code>>
In this case, we agree. I would suggest then that the (path) be left out
and recovered dynamically from the user's installation (much like a
relative html reference, but based on the Pamphlet system installation
directory path). Here I am assuming that a user installs all existing
pamphlets when the new Axiom system is installed. If this is not the
case (as some users may prefer), then some "external" but stable
depository for these pamphlets would be searched (also dynamically
rather than hard coded into the pamphlet). So new versions can update
the external paths without having to change the pamphlets. These updates
can also be done automatically similar to patches to software bugs.

\start
Date: Sun, 24 Nov 2002 13:46:26 -0500
From: Tim Daly 
To: William Sit
Subject:  Re: noweb, pamphlets, and TeXmacs

>>In this case, we agree. I would suggest then that the (path) be left out
>>and recovered dynamically from the user's installation (much like a
>>relative html reference, but based on the Pamphlet system installation

Excellent idea. 

\start
Date: Sun, 24 Nov 2002 14:00:24 -0500
From: Bill Page
To: Joris van der Hoeven
Subject:  RE: noweb, pamphlets, and TeXmacs
Cc: Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

Everyone,

I am glad to see that this is such a "hot topic"!

BTW, I am sorry that some of you (like me) who are
members of multiple lists are likely receive
several copies of this message. It seems sort of
unavoidable for the moment while we are exploring
just how "interdisciplinary" this subject is. Perhaps
some we should absorb this subject back into the Axiom
mailing list since that is where is started. Those
people who are interested will have had a chance
to subscribe if they want to monitor this subject.

Anyway, I spent some time today thinking about alternate
mark-up languages for pamphlets. I suppose what I do
for a living could not help but intrude on my views
in this project... depressing perhaps, considering
that I would like to view this as an ambitious hobby
rather than "work" ... <frown>

Anyway, I do a lot of work with XML and XSL style sheets
these in the context of large scientific bibliographic
databases. Also, I have been reading about some ideas
expressed on the TeXmacs list about XML. A quick look
at the TeXmacs file format shows many very obvious
relationships to XML. In fact it seems that it could
almost be 1-1 except for a slightly different tag
syntax. There is an awful lot of work being done
these days on XML as the prime candidate "next
generation" structured document language. And it
turns out that "structured documents" have many
many uses. They are a kind of half-way point between
data bases record and free form text documents.

XSL (or more properly XSLT) is a structured document
transformation language that is itself in XML format.
The main purpose of XSLT these days is to generate
HTML to be displayed in a web browser. The Microsoft
browser and several others even include the XSLT
processor in the browser itself. And implementations
of XSLT processors exist for almost all server
environments. Besides HTML, other output formats are
possible, e.g. PDF format etc.

So the concept was this (expressed as a question):
How difficult would it be to write an XSLT style
sheet that would perform weave and tangle on an
XML file? I almost sat down to give it an initial
try when I thought about doing a web search on the
subject of "XML"

  http://xmlp.sourceforge.net/

and

  http://groups.yahoo.com/group/xml-litprog-l/

see also

  http://www.vivtek.com/litprog.html

Damn the web! It seems that someone somewhere has
always already thought of all the good ideas ...
<grin>.

> From: Joris van der Hoeven
> Sent: Sunday, November 24, 2002 12:17 PM
> .. 
> Notice that TeXmacs is not just capable to properly
> format a large subset of TeX/LaTeX, but that it also
> provides mark-up which is not available in TeX/LaTeX
> (hyperlinks, actions, simple folding, etc.). What
> is more, like in TeX/LaTeX, you may define your own
> mark-up, and, like in Emacs, construct special editing
> modes for editing such mark-up. This may apply in
> particular to things like customized ways of folding,
> direct execution of an Axiom example from the
> documentation, etc.
> 
> > 0) The ability to recognize and format a code chunk.
> > 1) The ability to recognize the <<defn>>=,
> > concatenation, and <<use>> features of the code
> > chunks.
> 
> ... 
> However, as I pointed out before, it might be better
> to directly use the TeXmacs format with additional
> tags and write the operations like tangle and weave
> in Scheme.
> 
> ... as I said before, there is no reason to distinguish 
> between tangle and weave and no reason to limit oneself
> to two operations.
> 
> > 4) Bill has suggested that the folding mechanism
> > know about the code chunks and be able to fold and
> > unfold them. Perhaps the way to make the "untangle"
> > work would be to ignore the separate buffer idea
> > above and just use folding. I have no opinion about
> > either path yet.
> 
> In a dynamic editor like TeXmacs, it should be noticed
> that folding/unfolding becomes in fact a quite subtle
> operation. In fact, one has to think about the kind of
> semantics that one requires.
> 
> For instance, do you see folding as an operations
> which makes a change in the text, or rather like
> an operation which modifies the view of a text?
> The first interpretation is easiest to implement.
> In the second case, one has to define the notion
> of a "view" (and in particular: what information
> determines a view?). Also, you would have to
> think about how to undo changes.
>

I really like the idea that the code appears "folded"
into the document, but still part of it. When the folds
are collapsed, the result is just documentation. But
when the folds are expanded, they are visible and
editable just like any other part of the document. So
in that sense I am only talking about a "view" of
the document (with one, several, or all folds collapsed). 

I would definitely say that folding should not be
an operation that changes the text, however we it
might be desirable if it (optionally?) affected how
the documented was printed as well as displayed.

This sort of folding is now a common feature of
math packages like Maple and Mathematica. It helps
a lot to be able to read a document in a "top down"
fashion. In this sense the programming code is at
the "bottom" of the document fold structure.
 
> Another difficulty has to do with TeXmacs' ability
> to let the user define his/her own macros. What
> should be the semantics 
> of a macro which is built upon a "fold" tag?
> 
> > 5) There are other ideas, not yet exposed, that
> > it would be nice to have supported. I guess I
> > need to talk more about the pamphlet idea in depth.
> 
> Well, it would be nice to make up a list of all tags
> (with options and everything) which might be useful
> for pamphlet files. You might also want to take a
> look at some (still very rudimentary) ideas in the
> tmdoc format.
>

I think that Anthony Coates (see links above) has
already done quite an excellent job of defining a
simple set of tags and attributes. These could
probably be used almost directly as a model for
TeXmacs.
 
> At the moment, I mainly see the "chunk" tag as
> a variant of our "specific" tag, which is used in
> order to export content in a specific way to specific
> formats. We basically have to re-specify the semantics
> of such a tag in a very general setting.
> 
> > First, you compose a set of Pamphlet files "across
> > the system" so that you could document, say, all of
> > the matrix facilities currently available.
> > 
> > Second, you compose a set of Pamphlet files "thru
> > the system" so that you could document, say, the
> > integration mechanism from the top level function
> > all the way to the implementation details.
> 
> My way of viewing this is the use of one file for
> each atomic functionality of the system. Each such
> file should come with meta-information like the bigger
> classes to which it belongs (linear algebra, topology,
> etc.). Each file may also contain information about
> other relevant related files or how to traverse files
> in a sensible order (cf. tmdoc style). One may then
> implement special functions into TeXmacs for extracting 
> the information one needs.
> 
> > Thus you can insert and extract Booklets with Axiom
> > making it easier to share knowledge.
> > 
> ... 
> > Huge dream, I realize, but except for the dishes,
> > I see no technical reason why it can't be done.
> >
> > This implies, of course, that Pamphlets can be
> > decomposed into a finer level of detail which is
> > still under development.
> 
> Well, it all boils down to inventing suitable mark-up
> tags which reflect the complexity of the problem. So
> please give this matter a thought and come up with
> some more precise proposals. After that, we will have
> a discussion and see how to implement all this in
> TeXmacs.
> 
> > Currently noweb needs to expand the chunk definition
> > syntax to handle some more general scheme such as a
> > URL. We need to be able to extract code chunks from
> > other pamphlets so that you can have the following 
> > situation:
> > 
> > pamphlet A:  (the definition document)
> >     ...
> >     <<foo>>=
> >     ...
> > 
> > pamphlet B:  (the using document)
> >     ...
> >     <<pamphlet:/path/A#foo>>
> >     ...
> > 
> > It would be useful if this could happen for text
> > blocks also so that generally useful descriptions
> > could be inserted into multiple pamphlets. Since
> > the text blocks currently have no label this becomes
> > problematic. We need to develop text labels so we
> > can follow a uniform scheme. Multiple text blocks
> > containing essentially the same information already
> > exist in the system. This needs to be fixed.
> > 
> ... 
> As I see it now, you have the following ingredients
> for chunk tags:
> 
> 1) A "format" which determines the program which
> should be used in order to do extractions. More
> generally, it reflects the purpose of the enclosed
> content (documentation, code, example, etc.).
> 
> 2) An "identifier" for specifying how several chunks
> should be grouped together. In fact, it might be
> nice to see this independently from the chunk tags,
> but rather as a variant of labels and references.
> In other words, logical grouping of different parts
> of content may be nice in other circumstances too.
> 
> So maybe we should see the chunk tag as the
> combination of two more basic tags: one for
> specifying the purpose, functionality or class of
> a given region of text, and one for grouping
> scattered pieces of information.
>

I think you (Joris) may be surprised how close
your ideas are to Anthony's on this!
 
> > RE: TEXMACS CHANGES
> > 
> > Currently TeXmacs could take the following
> > steps, probably as a joint effort, to support
> > Axiom:
> > 
> > 1) Recognize noweb format
> 
> And we should decide whether we want to keep on
> working with this format, or whether we want to
> switch to a format for which it will be easier
> to add new features.
> 
> > 2) Integrate commands to notangle and noweave.
> 
> This should be straightforward to write in Scheme
> once that one has the appropriate tags.
> 
> > 3) Possibly either support
> >    a) folding out code
> 
> Please think more precisely about the semantics
> that you would like to have.
> 
> >    b) notangle, noweave to "dependent" buffers
> 
> Cf. improving the mark-up for inclusions like in
> the tmdoc style.
> 
> ... 
> I also remind you that TeXmacs does not have a
> one-to-one mapping with TeX/LaTeX. In other words,
> you can not longer use TeX/LaTeX as a reliable
> format for explanatory text in this scheme. If you
> want to edit the original document using TeXmacs,
> it is better to either use TeXmacs as the document 
> format for your pamphlet files, or at least to
> replace chunks of LaTeX by chunks of TeXmacs.
> 

\start
Date: Sun, 24 Nov 2002 20:22:24 +0100 (MET)
From: Joris van der Hoeven
To: Bill Page
Subject:  RE: noweb, pamphlets, and TeXmacs
Cc: Joris van der Hoeven, Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

> I think that Anthony Coates (see links above) has
> already done quite an excellent job of defining a
> simple set of tags and attributes. These could
> probably be used almost directly as a model for
> TeXmacs.

Thanks for the pointers. Unfortunately, I could not find a detailed
summary of the relevant *tags* being used. I really think that
two or three well-chosen tags should cover everything that
we want to do (w.r.t. tangle and weave; folding and such is yet
another story). This is what we should discuss in my opinion.

\start
Date: Sun, 24 Nov 2002 15:00:24 -0500
From: Bill Page
To: Joris van der Hoeven
Subject:  RE: noweb, pamphlets, and TeXmacs
Cc:Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

On Sunday, November 24, 2002 2:22 PM Joris van der Hoeven 
>
> [Bill Page] 
> > I think that Anthony Coates (see links above) has
> > already done quite an excellent job of defining a
> > simple set of tags and attributes. These could
> > probably be used almost directly as a model for
> > TeXmacs.
> 
> Thanks for the pointers. Unfortunately, I could not
> find a detailed summary of the relevant *tags* being
> used.
> 

Check out the quick sketch at

  http://www.vivtek.com/lpml/language.html

and also the more formal definitions at

  http://xmlp.sourceforge.net/2002/extreme/index.html#fragment-dtd

> I really think that two or three well-chosen tags
> should cover everything that we want to do (w.r.t.
> tangle and weave; folding and such is yet another
> story). This is what we should discuss in my opinion.

I agree completely with your point of view. It is
essential to find some way to keep it simple the
way Norman managed to do with WEB. I think the
trouble with powerful (i.e. very flexible and
expressive) languages like XML is that there is an
urge to become less "humble" (in the sense of Edsger
Dykstra).

@unpublished{EWD:EWD340,
   author = "Edsger W. Dijkstra",
   title = "The humble programmer",
   year = "1972",
   note = "Turing Award lecture; published as {\cite EWD:EWD340pub}",
   url = "http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF",
   fileSize = 473 KB
   }

See also

  http://www.cs.utexas.edu/users/EWD/

I hope that his work will continue to inspire
et another generation of programmers.

  http://www.cs.utexas.edu/users/EWD/obituary.html

\start
Date: Sun, 24 Nov 2002 21:27:57 GMT
From: Anthony B. Coates
To: Bill Page, Joris van der Hoeven
Subject:  Re: noweb, pamphlets, and TeXmacs
Cc: Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

** Reply to message from Bill Page on Sun, 24 Nov
2002 15:00:24 -0500

A couple of things.  TeXmacs looks nice.  I wish I had as nice a front end for
xmLP.  I've often felt that the lack of nice front-ends has hurt the take-up of
LitProg (& Emacs does not count as a nice front-end, not for the 95% majority).
An ideal LitProg editor would be WYSIWYG, so that what you see when editing is
equivalent to what you would get with a traditional LitProg tool after
"weaving" the documentation.

Note that xmLP takes most of its ideas on literate programming from FunnelWeb
(http://www.ross.net/funnelweb/) which supports TeX, LaTeX, and HTML as
underlying document formats, as well as providing its own markup for simple
documents.  So, you could copy ideas from FunnelWeb to use in TeXmacs, if you
wanted.

> I agree completely with your point of view. It is
> essential to find some way to keep it simple the
> way Norman managed to do with WEB. I think the
> trouble with powerful (i.e. very flexible and
> expressive) languages like XML is that there is an
> urge to become less "humble" (in the sense of Edsger
> Dykstra).

XML markups for documents, e.g. DocBook, are no more complicated than LaTeX. 
However, what one hopes to get from XML is composability & reusability.  Hence
xmLP defines a minimal set of tags, and a combination of DocBook + MathML +
xmLP would provide much the same functionality as I used when using FunnelWeb
for my physics studies, if had a suitable way to produce printed output (and
that would probably require PassiveTeX, so I still wouldn't be able to escape
TeX as an underlying technology).

\start
Date: Mon, 25 Nov 2002 14:58:17 +0100
From: Johannes Hesing
To: Bill Page,  Joris van der Hoeven
Subject:  Re: [xml-litprog-l] Re: noweb, pamphlets, and TeXmacs
Cc: Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

On Sun 2002-11-24 (21:27), Anthony B. Coates wrote:
> ** Reply to message from Bill Page on Sun, 24 Nov
> 2002 15:00:24 -0500
> 
> A couple of things.  TeXmacs looks nice.  I wish I had as nice a front end for
> xmLP.  I've often felt that the lack of nice front-ends has hurt the take-up of
> LitProg (& Emacs does not count as a nice front-end, not for the 95% majority).
> An ideal LitProg editor would be WYSIWYG, so that what you see when editing is
> equivalent to what you would get with a traditional LitProg tool after
> "weaving" the documentation.

I don't know if I still need to draw your attention to LEO 
(http://sourceforge.net/projects/leo). The DTD of Leo output files is
naturally not 1:1 with xmLP, but things like lp:usage attributes can
be generated automatically.

Of course, everyone has their own idea of what LP has to look like,
but after using Leo for a couple of weeks my impression is that of a 
very flexible tool that can be geared towards many structures, including
at least an important subset of the xmLP grammar.

Greetings

\start
Date: Mon, 25 Nov 2002 13:16:07 -0500
From: Bill Page
To: list
Subject:  RE: [xml-litprog-l] Re: noweb, pamphlets, and TeXmacs
Cc: Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

Hello all,

Well, I guess I can retire back to life on the farm
with a clear conscience - seems like it's all been
done!

Seriously, I had no idea that the "state of the art"
had reached this level. I feel like I have just
discovered gold in a most un-expected place - in the
"waste land" called by it's inhabitants "OpenSource".
Waste land, indeed! Not. I guess I have been toiling in
the realm of paid consulting work for too long. Having
just read Dijkstra's "Humble Programmer" article again
after what seems like a whole generation has passed,
I am in a philosophical mood.

So it seems to me that open source (abd GNU etc. etc.)
is what happened *after* the software crisis that
Dijkstra talked about. When the original situation of
expensive hardware plus a little software reversed
dramatically, and the ratio of the cost (and effort)
of software development to the cost of the hardware
went "through the roof", it seems that a large part
of the programming profession went underground. Not
that one should think that the software crisis is over,
far from it, but some amazing and revolutionary ideas
do seem to be re-surfacing...

I have just finished looking at TeXmacs, Leo, Python
and xmLP

  http://www.texmacs.org/
  http://personalpages.tds.net/~edream/front.html
  http://www.python.org/
  http://xmlp.sourceforge.net/

and frankly I am amazed. But of course food tastes
wonderful to someone who is starving. These are exactly
the kind of tools that I was hoping would be available
for a new integrated development/authoring system for
the open source version of Axiom and for mathematical
programming in general. Sure a greated degree of
integration would be nice. But these are open source
tools so (in principle) all that is needed is effort.
Right?

I am especially encouraged by the use of XML and XSLT.
Standards are what made the Web and for that matter the
Internet itself, possible. Yes, standards *are* made to
be broken, but the fantastic (and largely unexpected)
success of the Internet should have taught us something:
It is possible to overcome the Babel (cf. Neal Stephenson,
"Snow Crash"). Mathematical software in the form of Maple,
Mathematica, Maxima, MuPad, Reduce, Axiom/Aldor (and many
many more) is in such a state of Babel - too many languages
and too many conflicting concepts. Of course variety is
necessary in the intellectual ecosystem, but too much
is almost as bad as too little.

I am very much in favor of attempting to apply accepted
standards (where they exist) in projects such as Axiom.
In that regard, let me ask a question:

LaTex is a defacto standard notation for mathematical
markup but MATH/ML is rapidly evolving as a more
"modern" alternative. Should one attempt to adopt such
a radially different (and some say exceedingly verbose)
approach as MATH/ML in the design of a new user
interface for Axiom? How advanced are the graphical
rendering packages? (More open source?) Could MATH/ML
be integrated with a tool like Leo? The alternative
of a LaTex-like interface is already available in
TeXmacs. But the use of XML as a standard visible
"internal" representation format strikes me as very
very desirable. And of course by design MATH/ML is
much more compatible with XML than is LaTex encoding.

How to choose?

Regards,
Bill Page.

http://savannah.nongnu.org/projects/axiom


> On Sun 2002-11-24 (21:27), Anthony B. Coates wrote:
> > ** Reply to message from "Bill Page" 
> <Bill Page> on Sun, 
> > 24 Nov 2002 15:00:24 -0500
> > 
> > A couple of things.  TeXmacs looks nice.  I wish I had as 
> nice a front 
> > end for xmLP.  I've often felt that the lack of nice front-ends has 
> > hurt the take-up of LitProg (& Emacs does not count as a nice 
> > front-end, not for the 95% majority). An ideal LitProg 
> editor would be 
> > WYSIWYG, so that what you see when editing is equivalent to 
> what you 
> > would get with a traditional LitProg tool after "weaving" the 
> > documentation.
> 
> I don't know if I still need to draw your attention to LEO 
> (http://sourceforge.net/projects/leo). The DTD of Leo output 
> files is naturally not 1:1 with xmLP, but things like 
> lp:usage attributes can be generated automatically.
> 
> Of course, everyone has their own idea of what LP has to look 
> like, but after using Leo for a couple of weeks my impression 
> is that of a 
> very flexible tool that can be geared towards many 
> structures, including at least an important subset of the 
> xmLP grammar.
> 
> Greetings
> 
> 
> Johannes
> > 
> 


\start
Date: Tue, 26 Nov 2002 09:56:59 +0000
From: Mike Dewar
To: Bill Page
Subject: RE: [xml-litprog-l] Re: noweb, pamphlets, and Te
Cc: Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit, Mike Dewar

On Mon, Nov 25, 2002 at 01:16:07PM -0500, Bill Page wrote:
<snip>
> LaTex is a defacto standard notation for mathematical
> markup but MATH/ML is rapidly evolving as a more
> "modern" alternative. Should one attempt to adopt such
> a radially different (and some say exceedingly verbose)
> approach as MATH/ML in the design of a new user
> interface for Axiom? How advanced are the graphical
> rendering packages? (More open source?) Could MATH/ML
> be integrated with a tool like Leo? The alternative
> of a LaTex-like interface is already available in
> TeXmacs. But the use of XML as a standard visible
> "internal" representation format strikes me as very
> very desirable. And of course by design MATH/ML is
> much more compatible with XML than is LaTex encoding.

LaTeX is fine as a rendering language but it does not have a regular
syntax and is very hard to manipulate.  I've just spent several months
working with XML documents with embedded fragments of LaTeX for
mathematics and the upshot is that we're removing the LaTeX and
replacing it with MathML.  Also, once you translate to LaTeX, it is
very hard to have any degree of interactivity such as cut-and-paste
since the structure of the rendered version may have little or no
relationship to the underlying data structures.  With MathML/XML you can
annotate the presentation form with the content form (and vice-versa) or
use xref to link related parts of different structures.  In addition you
have access to tools based on XSLT etc.  There is no reason why you
cannot use XSLT to render MathML - and indeed there is a SourceForge
project to do just that (http://sourceforge.net/projects/xsltml).

As far as rendering goes, Mozilla based its MathML rendering on TeX and
is really quite good.  The same code also found its way into Netscape 7.
There are also various plugins available for IE, you can find my
colleague David Carlisle's "universal stylesheet" at the MathML home
page (http://www.w3c.org/Math) which allows you to produce documents
which are portable across several browsers.  By the way David is bot
only a member of the MathMl committee but also one of the authors of
LaTeX2e so we aren't biased!

Having said all that you need to be careful when using MathML for
content markup - the defined symbols are fairly trivial (US high-school
maths) and you need to use one of the extension mechanisms such as
csymbol to extend the namespace for more interesting things.  You can
use OpenMath (http://monet.nag.co.uk/openmath) for this, i.e. make the
definitionURL attribute point to an appropriate OpenMath Content
Dictionary, or do what Maple and Mathematica do and use system-specific
URIs.  

\start
Date: Tue, 26 Nov 2002 12:01:40 +0100 (MET)
From: Joris van der Hoeven
To: list
Subject: Re: noweb, pamphlets, and TeXmacs
Cc: Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit, Mike Dewar

> LaTeX is fine as a rendering language but it does not have a regular
> syntax and is very hard to manipulate.  I've just spent several months
> working with XML documents with embedded fragments of LaTeX for
> mathematics and the upshot is that we're removing the LaTeX and
> replacing it with MathML. 

TeXmacs has reasonably good import and export filters for LaTeX,
and filters for MathML should be available soon.

> As far as rendering goes, Mozilla based its MathML rendering on TeX and
> is really quite good.  The same code also found its way into Netscape 7.

But this allows you only to *render* mathematics, not *editing* it.

> Having said all that you need to be careful when using MathML for
> content markup - the defined symbols are fairly trivial (US high-school
> maths) and you need to use one of the extension mechanisms such as
> csymbol to extend the namespace for more interesting things. You can
> use OpenMath (http://monet.nag.co.uk/openmath) for this, i.e. make the
> definitionURL attribute point to an appropriate OpenMath Content
> Dictionary, or do what Maple and Mathematica do and use system-specific
> URIs.  

I indeed think that the whole system MathML/Openmath is more complex
than necessary. Also, it has mainly been developed with rendering
in mind, not editing. I finally notice that Openmath does not seem
to work very well.

What we can give you quite quickly with TeXmacs is

  1) Adding markup for simple litterate programming of
     the type that we discussed before.

  2) Import and export filters for MathML.

This would allow you to have an integrated frontend/help browser/editor
for Axiom which is reasonably compatible with the outside world.
We will not spend any time on Openmath, unless someone else wants
to do all the work.

\start
Date: Tue, 26 Nov 2002 14:20:09 +0100
From: Michel Lavaud
To: Mike Dewar
Subject: Re:  RE: [xml-litprog-l] Re: noweb, pamphlets, and TeXmacs

Hello Mike,

> > LaTex is a defacto standard notation for mathematical
> > markup but MATH/ML is rapidly evolving as a more
> > "modern" alternative. Should one attempt to adopt such
> > a radially different (and some say exceedingly verbose)
> > approach as MATH/ML in the design of a new user
> > interface for Axiom?
> 
> LaTeX is fine as a rendering language but it does not have a regular
> syntax and is very hard to manipulate.  I've just spent several months
> working with XML documents with embedded fragments of LaTeX for
> mathematics and the upshot is that we're removing the LaTeX and
> replacing it with MathML.  Also, once you translate to LaTeX, it is
> very hard to have any degree of interactivity such as cut-and-paste
> since the structure of the rendered version may have little or no
> relationship to the underlying data structures.  With MathML/XML you can
> annotate the presentation form with the content form (and vice-versa) or
> use xref to link related parts of different structures.

>From the point of view of software developers you are certainly right, but=
 
from the point of view of users and Science, I think you are wrong : 
TeX/LaTeX is a defacto standard notation for mathematics, as Bill Page 
noted, and I think that we ought to start from this point, whatever the 
difficulties, for many reasons, the main one being that software are for 
users, not for developers, so the user's point of view ought to be 
prominent (this is a true for commercial software because the aim is to 
earn as much money as possible, but I think this ought to be also the case=
 
for free software). I give a few reasons, why users might have an opinion 
opposite to yours:

1 - One would have tons of work in maths, physics, chemistry, etc. that 
would go to the rubbish heap or would have to be translated, with the 
inevitable errors inserted by any translator. Errors of one character in a=
 
text can be corrected automatically by humans and software, but error of 
one character in a formula in a scientific article cannot be corrected 
(except by reconstructing the proof) and the consequences can be 
disastrous.  Let just recall that an error of one character in a computer 
program led to the crash of a NASA planetary probe, cf:

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/prof77/html/prse4.htm

There are other examples of this type  (crash of Ariane 5, sink of an oil 
platform etc) and one can imagine easily others, for example the 
consequences of an error in the chemical formula of a medicine, etc.

Your argument based on your difficulties is quite valuable, but the 
question "is a formula in language XXX rendered exactly, today and in the 
long term ?" is much more important in my opinion - all the more in the 
long term.  No human can read a Mathml formula except very simple ones, it=
 
is too much verbose. So one would be condemned to use software to read 
such formulas. Could anybody certify that a MathML formula written with 
today's version could be rendered exactly with a software in hundred years=
 
as it is today? TeX formulas on the contrary can be read by humans 
directly, and moreover TeX is frozen, so this stability and human-
readability makes it a completely reliable way to transmit math formulas 
over very long periods. 

2 - Let just consider the denomination of plants, animals, anatomy : all 
are in Latin, since Linne's work more than 200 years ago. This stability 
in the denomination was a crucial ingredient for the progress of botany, 
biology and life sciences, etc. because everybody - whether he is British,=
 
Chinese,  French or from any country - knows a given living being under a 
unique name. Botanists can still read descriptions of plants that were 
written 200 years ago. Of course, this approach is difficult, as botanists=
 
have to learn Latin, but this is the condition for scientific exactness 
and for having a common and stable language, understood by everybody over 
a very long period. The "sagesse" of botanists, biologists etc. has been 
to keep this (otherwise obsolete) language to allow their science to 
progress and to remain rigorous, instead of unceasingly changing their 
language, which would have restrained the progress and multiply the 
possibility of confusions and errors. 

For the same reason, I think we ought to maintain the usage of TeX for 
documents with mathematical formulas, as the usage of Latin is maintained 
for description of plants, animals etc, despite all the considerations you=
 
give (about your difficulties with TeX) which are, I agree, valuable, but 
negligible as compared to the bad consequences of abandoning TeX in favour=
 
of something else, and then 20 years laters abandoning this "something 
else" for another "something else", etc., etc...

If this point of view worries you too much, let us consider that there are=
 
people who are working on Scientific OCR, that could reconstruct formulas 
from scanned articles in scientific journals. This is a very difficult 
job, but this would be very useful and is worth the study. And it is 
certainly feasible, as any scientist does it daily with his mind.

Well, instead of starting from scanned images to reconstruct formulas, let=
 
us start from formulas in TeX, to produce MathML output today, and to 
produce #!??&@ML output in 20 years (the new language which will have 
superseded MathML at that time among learned computer scientists). This is=
 
probably a difficult job, but certainly much less difficult than 
Scientific OCR. And it is certainly feasible unambiguously also, as one 
can read formulas printed with TeX without any ambiguity.
So, mathematicians, physicists and chemists in 100 years could still be 
able to type their articles in TeX and read the articles that were written=
 
in TeX this year. And efforts to build free archives of scientific 
articles (which might be unimportant for developers but are of utmost 
importance for many users) would not be ruined, too.

3 - Another difference between user's and developer's approaches : 
learning TeX is difficult for the user, but it is justified because it is 
error-free and could stay for ever (if we are sufficiently wise to decide 
it ?). Having to learn a few years later another language is unacceptable 
for most users, I think, even though it might be more convenient for 
developers.

Michel Lavaud
http://www.univ-orleans.fr/EXT/ASTEX

\start
Date: Tue, 26 Nov 2002 13:46:33 +0000
From: Mike Dewar
To: Michel Lavaud
Subject: Re:  RE: [xml-litprog-l] Re: noweb, pamphlets, and TeXmacs

Hi Michel,

I'm not suggesting throwing LaTeX away, but it was never designed to be
used as an output language for software and in general using it that
way leads to problems.  As a language that people write directly in a
text editor its fine, and speaking personally its still the only system
which I use to write documents if I have a choice, but increasingly few
people write documents that way these days.  Like it or not we're moving
to a WYSIWYG world and the "back-end" representation of the mathematics
will be irrelevent.  However that isn't really relevant to this
discussion - the original question was whether a front-end for OpenAxiom
should use LaTeX or MathML as a rendering format.  Users won't care
because they'll never see it, in the same way that they never see
OutputForm in the shell interpreter.  Now if you want an archive format
then thats a different matter but I don't think that writing a document
in LaTeX is any guarentee that it will be readable in 10 years let alone
100.  Make a hard copy on vellum, thats my advice :-)

Cheers, Mike.

On Tue, Nov 26, 2002 at 02:20:09PM +0100, Michel Lavaud wrote:
> Hello Mike,
> 
> > > LaTex is a defacto standard notation for mathematical
> > > markup but MATH/ML is rapidly evolving as a more
> > > "modern" alternative. Should one attempt to adopt such
> > > a radially different (and some say exceedingly verbose)
> > > approach as MATH/ML in the design of a new user
> > > interface for Axiom?
> > 
> > LaTeX is fine as a rendering language but it does not have a regular
> > syntax and is very hard to manipulate.  I've just spent several months
> > working with XML documents with embedded fragments of LaTeX for
> > mathematics and the upshot is that we're removing the LaTeX and
> > replacing it with MathML.  Also, once you translate to LaTeX, it is
> > very hard to have any degree of interactivity such as cut-and-paste
> > since the structure of the rendered version may have little or no
> > relationship to the underlying data structures.  With MathML/XML you can
> > annotate the presentation form with the content form (and vice-versa) or
> > use xref to link related parts of different structures.
> 
> >From the point of view of software developers you are certainly right, but 
> from the point of view of users and Science, I think you are wrong : 
> TeX/LaTeX is a defacto standard notation for mathematics, as Bill Page 
> noted, and I think that we ought to start from this point, whatever the 
> difficulties, for many reasons, the main one being that software are for 
> users, not for developers, so the user's point of view ought to be 
> prominent (this is a true for commercial software because the aim is to 
> earn as much money as possible, but I think this ought to be also the case 
> for free software). I give a few reasons, why users might have an opinion 
> opposite to yours:
> 
> 1 - One would have tons of work in maths, physics, chemistry, etc. that 
> would go to the rubbish heap or would have to be translated, with the 
> inevitable errors inserted by any translator. Errors of one character in a 
> text can be corrected automatically by humans and software, but error of 
> one character in a formula in a scientific article cannot be corrected 
> (except by reconstructing the proof) and the consequences can be 
> disastrous.  Let just recall that an error of one character in a computer 
> program led to the crash of a NASA planetary probe, cf:
> 
> http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/prof77/html/prse4.htm
> 
> There are other examples of this type  (crash of Ariane 5, sink of an oil 
> platform etc) and one can imagine easily others, for example the 
> consequences of an error in the chemical formula of a medicine, etc.
> 
> Your argument based on your difficulties is quite valuable, but the 
> question "is a formula in language XXX rendered exactly, today and in the 
> long term ?" is much more important in my opinion - all the more in the 
> long term.  No human can read a Mathml formula except very simple ones, it 
> is too much verbose. So one would be condemned to use software to read 
> such formulas. Could anybody certify that a MathML formula written with 
> today's version could be rendered exactly with a software in hundred years 
> as it is today? TeX formulas on the contrary can be read by humans 
> directly, and moreover TeX is frozen, so this stability and human-
> readability makes it a completely reliable way to transmit math formulas 
> over very long periods. 
> 
> 2 - Let just consider the denomination of plants, animals, anatomy : all 
> are in Latin, since Linne's work more than 200 years ago. This stability 
> in the denomination was a crucial ingredient for the progress of botany, 
> biology and life sciences, etc. because everybody - whether he is British, 
> Chinese,  French or from any country - knows a given living being under a 
> unique name. Botanists can still read descriptions of plants that were 
> written 200 years ago. Of course, this approach is difficult, as botanists 
> have to learn Latin, but this is the condition for scientific exactness 
> and for having a common and stable language, understood by everybody over 
> a very long period. The "sagesse" of botanists, biologists etc. has been 
> to keep this (otherwise obsolete) language to allow their science to 
> progress and to remain rigorous, instead of unceasingly changing their 
> language, which would have restrained the progress and multiply the 
> possibility of confusions and errors. 
> 
> For the same reason, I think we ought to maintain the usage of TeX for 
> documents with mathematical formulas, as the usage of Latin is maintained 
> for description of plants, animals etc, despite all the considerations you 
> give (about your difficulties with TeX) which are, I agree, valuable, but 
> negligible as compared to the bad consequences of abandoning TeX in favour 
> of something else, and then 20 years laters abandoning this "something 
> else" for another "something else", etc., etc...
> 
> If this point of view worries you too much, let us consider that there are 
> people who are working on Scientific OCR, that could reconstruct formulas 
> from scanned articles in scientific journals. This is a very difficult 
> job, but this would be very useful and is worth the study. And it is 
> certainly feasible, as any scientist does it daily with his mind.
> 
> Well, instead of starting from scanned images to reconstruct formulas, let 
> us start from formulas in TeX, to produce MathML output today, and to 
> produce #!??&@ML output in 20 years (the new language which will have 
> superseded MathML at that time among learned computer scientists). This is 
> probably a difficult job, but certainly much less difficult than 
> Scientific OCR. And it is certainly feasible unambiguously also, as one 
> can read formulas printed with TeX without any ambiguity.
> So, mathematicians, physicists and chemists in 100 years could still be 
> able to type their articles in TeX and read the articles that were written 
> in TeX this year. And efforts to build free archives of scientific 
> articles (which might be unimportant for developers but are of utmost 
> importance for many users) would not be ruined, too.
> 
> 3 - Another difference between user's and developer's approaches : 
> learning TeX is difficult for the user, but it is justified because it is 
> error-free and could stay for ever (if we are sufficiently wise to decide 
> it ?). Having to learn a few years later another language is unacceptable 
> for most users, I think, even though it might be more convenient for 
> developers.

\start
Date: Tue, 26 Nov 2002 15:24:30 +0100 (CET)
From: Bertfried Fauser
To: list
Subject: Re:  RE: [xml-litprog-l] Re: noweb, pamphlets, and TeXmacs

Hi
	as a potential user I follow this discussion with geat interest.
E.g. I downloaded TeXmacs and tried as a first exercise if it can read my
(partially very tricky) LaTeX documents, it failed, even with the more
simpler ones.

	Hence it seems to be a problematic step to go from LaTeX to
TeXmacs. This is a pitty, since I have to maintain my LaTeX articles, and
I do really also appreciate a human readable file format (e.g. MathML is
not human readable for sure)

	To me its not so important if axiom does use LaTeX or not, if it
has e.g. an LaTeX output filter (one way) which should not be an problem.
Currently I do use maple as a filter for LaTeX documents. One can pass a
LaTeX document through maple, passing some arguments on textwidth etc,
which produces (soehow poor) LaTeX output (maple input is given in the
'environment' \begin{mapleinput} comands... \end{mapleinput}). Such a
feature would be fully satisfactory for me. An interactive worksheet
interface might be a very different story. E.g. I would like to see that
axiom can be used over the net from a remote machine, that computations
can be made available over the web etc. For such a purpose, XML and MathML
may be the first joice.

	I see that the WYSIWIG movement is going on, but that is also
coming with a diminished level of sophistication [not a rating, just an
observation]. If a person is really using software like axiom, she can
easily learn something like LaTeX within two weeks. The occassional user
may not the target you are seeking for with such aspecial purpose software
as axiom? One problem I have with maple --and scientific computing,
Germanys maple distributor, agreed during a phone call with this
oppinion-- is that maple goes for the gui and for the mass market
currently. During that effort, the mathematical abilities of maple have
even been _diminished_! (from maple V to 6,7,8 and hopefully 9 will come
back to be as good as V) I fear a little bit that this discussion, which
--please remember-- started with literate programming goes now into a
similar direction.

	By the way, I can LaTeX documents which are now more than 10 years
old still without considerable problems. I think that I will be able to
read ASCII files in ten years still -- otherwise I will write a small
editor myself :) Just advising to make hardcopies means to kill living
documents which evolve in time. My knowledge however still --hopefully--
evolves, so my documents do. LaTeX is ideally suited for that. [For the
reasons of non readability by humans I do > /dev/null all M$.doc files :)]

	So, my personal preference would go for an axiom interface which
is web-standard and easy to export. I could even imagine an axiom _deamon_
runing on some TCP/IP port which can be accessed by a sort of
mozilla/MathML with some additonal active input elements, (like a web
form). Maple goes for MapleNet now, but that's buzz onyl :(

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

\start
Date: Tue, 26 Nov 2002 11:57:26 -0500
From: Bill Page
To: list
Subject:  Maple XML and MATH/ML

Hi,

I am thinking about the proposed standards for representation of
mathematical documents these days in the context of the new
open source Axiom project

  http://savannah.nongnu.org/projects/axiom

so I decided to take a closer look at the Maple release 8
implementation of export to XML and to HTML with MATH/ML. Here
are some links to examples of a very simple Maple worksheet
with the results of these exports

  http://wspage.tripod.com/maple/xml-test1.mws
  http://wspage.tripod.com/maple/xml-test1.html
  http://wspage.tripod.com/maple/xml-test1.xml

Here is what the worksheet contains rendered in standard
ASCII input and output cut-and-paste directly from Maple.

--------

> eq1:=y=alpha*x^n+beta;

                                        n
                      eq1 := y = alpha x  + beta

> eq2:=op(solve({eq1},x));

                                       y - beta
                                    ln(--------)
                                        alpha
                     eq2 := x = exp(------------)
                                         n

> A:=matrix(2,2,(i,j)->a[i,j]);

                           [a[1, 1]    a[1, 2]]
                      A := [                  ]
                           [a[2, 1]    a[2, 2]]

> 

-----------

If you click the 'xml-test1.html' link above, the first
thing you will notice is the download of a java class to render
the strange looking encoded math output format apparently called
XPPMATH, at least that is the tag that is used in both Maple's
internal mws format and in the exported XML.

If you are using an XML enabled browser (e.g. I am using
IE 6.0 on Windows XP at the time I write this), you will see
a pretty printed version of the XML coding. Note: I have made
one small change from the raw Maple output. Maple strings
the XML out in one long unformatted line. I have inserted
some minimal whitespace in the form of new lines at reasonable
places to allow the XML file to be displayed in a readable
manner in ASCII mode.

Observation 1: On vanilla IE 6.0 with no special add-ins the
MATH/ML output does not render properly. There is a missing
closing parenthesis in eq2. Note also that the matrix is
displayed as a graphic and not MATH/ML. Why?

First question: Does anyone know what this encoded format is?
Is there a non-proprietary rendering engine available?

Second question: Why does Maple use this encoded format in it's
XML output? Why doesn't Maple use the MATH/ML mark-up in the
XML file? Perhaps both MATH/ML and XPPMATH should be present?

Observation 2: Although Maple can export to XML and it looks
pretty much complete compared to the native mws format, it
apparently cannot import a worksheet in the format. When I
try to open an XML file (Maple allows an input format of
"Maple worksheet as XML"), all I can get to work is the "text"
format where the XML appears in a Maple text section. Is this
a bug? Am I doing something wrong?

It seems quite likely to me that WMI will be extending
this rudimentary functionality in the next release.

Your comments would be most appreciated.

 http://wspage.tripod.com

\start
Date: Tue, 26 Nov 2002 12:55:16 -0500
From: Bill Page
To: list
Subject:  RE: [maple8] Maple XML and MATH/ML

On Tuesday, November 26, 2002 10:30 AM I wrote:

  http://www.maplesoft.com/standards/MathML/XSL/pmathml.xsl

>...
> Here are some links to examples of a very simple Maple
> worksheet with the results of these exports
> 
>   http://wspage.tripod.com/maple/xml-test1.mws
>   http://wspage.tripod.com/maple/xml-test1.html
>   http://wspage.tripod.com/maple/xml-test1.xml
> 
>... 
> If you click the 'xml-test1.html' link above, the first
> thing you will notice is the download of a java class to render
> the strange looking encoded math output format apparently called
> XPPMATH, at least that is the tag that is used in both Maple's
> internal mws format and in the exported XML.
> 

The more a look at this the more extraordinary things I see
going on. For example, the "html" file above is not really
a properly formatted HTML document at all! (Ref.
http://www.w3.org/TR/REC-xml ). The file generated by Maple
starts with the following *XML* declaration

  <?xml version="1.0"  encoding="iso-8859-1" ?>
  <?xml-stylesheet type="text/xsl"
href="http://www.maplesoft.com/standards/MathML/XSL/mathml.xsl"?> 

and has no doctype declaration at all. In fact, this declaration
is just ignored by the browser which really starts interpreting
the code starting with

  <html xmlns="http://www.w3.org/1999/xhtml">

but if we follow the href on the XML declaration and hack the
stylesheet we find some really interesting (but strange) stuff.

http://www.maplesoft.com/standards/MathML/XSL/mathml.xsl

http://www.maplesoft.com/standards/MathML/XSL/pmathml.xsl

One of the most interesting things I see here is

- <!-- 
Copyright David Carlisle 2001, 2002.

Use and distribution of this code are permitted under the terms of the
 
<ahref="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
W3C Software Notice and License</a>.

  --> 

Also fairly prominent is the statement

<!-- 
 not working, currently
<xsl:when test="system-property('xsl:vendor')='Microsoft' and
/*/@fns:renderer='css'">

< ...

Isn't the penchant for attribution and openness in the Web a
wonderful thing!

But pmathml.xsl is much more interesting

<!-- 
$Id: pmathml.xsl,v 1.6 2002/03/14 23:19:22 davidc Exp $

Copyright David Carlisle 2001, 2002.

Use and distribution of this code are permitted under the terms of the
<a
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
W3C Software Notice and License</a>.

  --> 
<!-- 
 MathPlayer mpdialog code for contributed by
     Jack Dignan and Robert Miner, both of Design Science.

  -->

This XSL stylesheet has some very sophisticat and complex coding
including, but limited to, java and activeX.

Almost all of this clearly seems to be work-in-progress. It
seems pretty amazing to me that this ended up in the current
commercial release of Maple 8 and is still publically
accessibe on the WMI web site. I really wonder what WMI has
in mind here?

Addenda to previous message: Apparently the MATH/ML is being
rendered by a Design Science package related to

  http://www.dessci.com/en/products/mathplayer/default.htm

There products look quite impressive. Too bad not much of
it is open source.

\start
Date: Tue, 26 Nov 2002 19:08:11 +0100
From: Michel Lavaud
To: Mike Dewar
Subject: RE: [xml-litprog-l] Re: noweb, pamphlets, and TeXmacs

Hello Mike,
 
>  Now if you want an archive format

More generally a stable format (is MathML stable?), for archiving of 
course but also for importing, so that one can select for example a TeX 
formula in an old document and drop it in Axiom or Maxima, and get the 
result. The people of Scientific Software already did a good job in 
importing TeX formulas. Unfortunately it's commercial, but it suggests 
it's possible. People of LyX did also work in this direction, but much 
less far (at least at the time when I compared both).

> then thats a different matter but I don't think that writing a document
> in LaTeX is any guarentee that it will be readable in 10 years let alone
> 100.  Make a hard copy on vellum, thats my advice :-)

Next year, it will be TeX's 25th anniversary, so we are closer to 100 than=
 
to 10... But anyway, you're right, I will buy some vellum, just in case 
(hope to use it for MathML ;-)

\start
Date: Tue, 26 Nov 2002 13:57:53 +0000
From: Mike Dewar
To: Joris van der Hoeven
Subject:  Re: noweb, pamphlets, and TeXmacs
Cc: Bill Page , Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit, Mike Dewar

On Tue, Nov 26, 2002 at 12:01:40PM +0100, Joris van der Hoeven wrote:
<snip>
> > As far as rendering goes, Mozilla based its MathML rendering on TeX and
> > is really quite good.  The same code also found its way into Netscape 7.
> 
> But this allows you only to *render* mathematics, not *editing* it.
True, I merely quoted it because of the quality of the markup.  If you
want to edit MathML/OpenMath etc. then there are lots of options:
Mathtype and WebEQ from Design Science, a free add-on to TechExplorer
from IBM (whose name I forget), JOME from the University of Nice, and
several others which I hadn't heard of until I looked at the MathML
software page a couple of minutes ago.  

Quite how useful graphical manipulation of mathematics is is
questionable, but the ability to select/cut/paste sub-expressions in a
graphical environment does seem important to me.

<snip>
> I indeed think that the whole system MathML/Openmath is more complex
> than necessary.
Well that depends what you want to do, other people say that they are
not sophisticated enough for formal applications.  For what I want to do
they're about right ;-)

>                 Also, it has mainly been developed with rendering
> in mind, not editing. I finally notice that Openmath does not seem
???  MathML presentation is by definition about presentation.  OpenMath
and MathML-content are about semantics which is what you need in a piece
of mathematical software.

> to work very well.
In what sense?

\start
Date: Tue, 26 Nov 2002 15:27:54 +0100 (MET)
From: Joris van der Hoeven
To: Mike Dewar
Subject: Re: noweb, pamphlets, and TeXmacs
Cc: Joris van der Hoeven, Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

> Quite how useful graphical manipulation of mathematics is is
> questionable,

For people who got brainwashed by *TeX/*ML, maybe,
but I do not think that this is a philosophical subject
for most other users.

> > I indeed think that the whole system MathML/Openmath is more complex
> > than necessary.
> Well that depends what you want to do, other people say that they are
> not sophisticated enough for formal applications.  For what I want to do
> they're about right ;-)
> 
> >                 Also, it has mainly been developed with rendering
> > in mind, not editing. I finally notice that Openmath does not seem
> ???  MathML presentation is by definition about presentation.  OpenMath
> and MathML-content are about semantics which is what you need in a piece
> of mathematical software.
> 
> > to work very well.
> In what sense?

I'm not going to start a flamewar on this and I will wait for an occasion
(and time) to write a detailed article with my opinions about this matter.

At the moment, I am just interested in investigating what
is missing in TeXmacs to make it a good frontend for Axiom and
maybe a good environment for litterate programming and integrated help.
I have made clear what we can do in that direction: compatability with
MathML and something like Anthony's markup language for the litterate
programming. If Bill Page is willing to do some of the programming,
then that would be great. If you prefer other tools, like Mozilla,
Leo, or I don't know what, fine too, but please tell us so as soon
as possible.

\start
Date: Tue, 26 Nov 2002 22:15:48 +0100 (CET)
From: Martin Rubey
To: Mike Dewar
Subject: Re: noweb, pamphlets, and TeXmacs
Cc: Joris van der Hoeven, Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein, William Sit

> Quite how useful graphical manipulation of mathematics is is
> questionable, but the ability to select/cut/paste sub-expressions in a
> graphical environment does seem important to me.

kdvi just started to make "select" possible. Well, started...

\start
Date: Tue, 26 Nov 2002 19:25:42 -0500
From: Bill Page
To: list
Subject:  testing cvs

Tim,

I've committed a very simple change to the main makefile.pamphlet
at tenkan. This change allows me to build noweb on both Cygwin
and Msys. Let me know if you can get cvs to tell you about the
change I made. If this works, I will be able to try a few more
things over the next few days.

\start
Date: Tue, 26 Nov 2002 20:18:17 -0500
From: Bill Page
To: list
Subject:  MetaPRL
Cc: David Cyganski

Tim,

Thank you very much for the keyword MetaPRL. It's some
amazing stuff alright. So much more to learn now and so
little time ... <sigh> But of course I couldn't resist
downloading some of the papers, documentation and the
package,

  http://cvs.metaprl.org:12000/metaprl/default.html

afterall there are 23 useable hours in each day. Right?

<grin>

\start
Date: Tue, 26 Nov 2002 23:24:05 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: MetaPRL
CC: David Cyganski

Bill,

Just got back from a Meatloaf concert. Great show.
I'll try the CVS thingie, then I gotta get my hour of coma
before I do it all again.

\start
Date: Tue, 26 Nov 2002 23:28:11 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: MetaPRL
CC: David Cyganski

tenkan appears to be down at the moment. i'll try tomorrow. --t

\start
Date: Tue, 26 Nov 2002 23:26:07 -0500
From: William Sit
To: Martin Rubey
Subject: Re:noweb,  pamphlets, and TeXmacs
CC: Mike Dewar, Joris van der Hoeven, Bill Page, Norman Ramsey, Barry Trager, Manuel Bronstein

Martin Rubey wrote:
> 
> > Quite how useful graphical manipulation of mathematics is is
> > questionable, but the ability to select/cut/paste sub-expressions in a
> > graphical environment does seem important to me.
> 
> kdvi just started to make "select" possible. Well, started...

Even so, this is probably display (or word-processor type) cut and
paste. My guess is it would be meaningless to pass a (sub)expression
from a dvi display to say Mathematica or Axiom. To cut and paste an
output expression to an input window and have the expression make
mathematical sense so further computation can be done on it requires
MathML (both presentation and (at least) content are passed). This is
easy for a single computer algebra system (Derive had this years ago),
but to do so across different systems needs a common protocol, and
MathML or OpenML are partial solutions. A TeX expression does not have
an unambiguous mathematical meaning. MathML tags define a unique
mathematical meaning to a subclass of mathematical expression. In some
sense, all the operations involved in a mathematical expression must be
identified by their signatures and operands by their domains. Since
Axiom is strongly typed, it is probably a good candidate to include the
signatures and domain information along with the display information.
But of course, this is again "within-one-CAS-system" approach because
other systems would not understand Axiom signatures. So what would be
needed is a common naming conventions (signatures and domains) for a
large class of mathematical operations and objects. The design of MathML
and OpenML are influenced a lot by Mathematica. Perhaps the next
generation could be influenced by Axiom?

\start
Date: Wed, 27 Nov 2002 10:04:19 +0000
From: Mike Dewar
To: Bill Page
Subject: RE: [maple8] Maple XML and MATH/ML

Hi Bill,

I think the "html" file is a t confused!  The file looks as if its
trying to be XHTML but the body of the file is HTML, not XHTML.

The stylesheet you pointed at was written by my colleague David Carlisle
for the MathML Working Group (of which he is a member) to allow a user
(e.g. Waterloo Maple) to publish documents which can be rendered on a
number of platforms with different rendering strategies.  So on Mozilla,
Amaya etc you get native rendering but on IE you'd use the MathPlayer
plugin.  Its only work in progress in the sense that it will be extended
to cope with new versions as they evolve.  However (a) the version WMI
quote is out-of-date (they have to have a local copy otherwise IE thinks
its a security risk), and (b) they aren't using it anyway and are
rendering via their own plugin which I believe to be based on an old
version of WebEQ.  If you're interested in the real version of the
stylesheet have a look at http://www.w3.org/Math/XSL.

Mike.


On Tue, Nov 26, 2002 at 12:55:16PM -0500, Bill Page wrote:
> On Tuesday, November 26, 2002 10:30 AM I wrote:
> 
>   http://www.maplesoft.com/standards/MathML/XSL/pmathml.xsl
> 
> >...
> > Here are some links to examples of a very simple Maple
> > worksheet with the results of these exports
> > 
> >   http://wspage.tripod.com/maple/xml-test1.mws
> >   http://wspage.tripod.com/maple/xml-test1.html
> >   http://wspage.tripod.com/maple/xml-test1.xml
> > 
> >... 
> > If you click the 'xml-test1.html' link above, the first
> > thing you will notice is the download of a java class to render
> > the strange looking encoded math output format apparently called
> > XPPMATH, at least that is the tag that is used in both Maple's
> > internal mws format and in the exported XML.
> > 
> 
> The more a look at this the more extraordinary things I see
> going on. For example, the "html" file above is not really
> a properly formatted HTML document at all! (Ref.
> http://www.w3.org/TR/REC-xml ). The file generated by Maple
> starts with the following *XML* declaration
> 
>   <?xml version="1.0"  encoding="iso-8859-1" ?>
>   <?xml-stylesheet type="text/xsl"
> href="http://www.maplesoft.com/standards/MathML/XSL/mathml.xsl"?> 
> 
> and has no doctype declaration at all. In fact, this declaration
> is just ignored by the browser which really starts interpreting
> the code starting with
> 
>   <html xmlns="http://www.w3.org/1999/xhtml">
> 
> but if we follow the href on the XML declaration and hack the
> stylesheet we find some really interesting (but strange) stuff.
> 
> http://www.maplesoft.com/standards/MathML/XSL/mathml.xsl
> 
> http://www.maplesoft.com/standards/MathML/XSL/pmathml.xsl
> 
> One of the most interesting things I see here is
> 
> - <!-- 
> Copyright David Carlisle 2001, 2002.
> 
> Use and distribution of this code are permitted under the terms of the
>  
> <ahref="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
> W3C Software Notice and License</a>.
> 
>   --> 
> 
> Also fairly prominent is the statement
> 
> <!-- 
>  not working, currently
> <xsl:when test="system-property('xsl:vendor')='Microsoft' and
> /*/@fns:renderer='css'">
> 
> < ...
> 
> Isn't the penchant for attribution and openness in the Web a
> wonderful thing!
> 
> But pmathml.xsl is much more interesting
> 
> <!-- 
> $Id: pmathml.xsl,v 1.6 2002/03/14 23:19:22 davidc Exp $
> 
> Copyright David Carlisle 2001, 2002.
> 
> Use and distribution of this code are permitted under the terms of the
> <a
> href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
> W3C Software Notice and License</a>.
> 
>   --> 
> <!-- 
>  MathPlayer mpdialog code for contributed by
>      Jack Dignan and Robert Miner, both of Design Science.
> 
>   -->
> 
> This XSL stylesheet has some very sophisticat and complex coding
> including, but limited to, java and activeX.
> 
> Almost all of this clearly seems to be work-in-progress. It
> seems pretty amazing to me that this ended up in the current
> commercial release of Maple 8 and is still publically
> accessibe on the WMI web site. I really wonder what WMI has
> in mind here?
> 
> Addenda to previous message: Apparently the MATH/ML is being
> rendered by a Design Science package related to
> 
>   http://www.dessci.com/en/products/mathplayer/default.htm
> 
> There products look quite impressive. Too bad not much of
> it is open source.

\start
Date: Wed, 27 Nov 2002 19:32:58 +0100
From: Michel Lavaud
To: William Sit
Subject: Re:noweb,  pamphlets, and TeXmacs

Hello William,

> A TeX expression does not have
> an unambiguous mathematical meaning. MathML tags define a unique
> mathematical meaning to a subclass of mathematical expression.

Sorry I don't see exactly what you mean, could you develop a little your 
arguments? In what sense is $x_i$ for example ambiguous? 

\start
Date: Wed, 27 Nov 2002 13:54:56 -0500
From: Tim Daly 
To: Camm Maguire
Subject:  Makefile and CVS

The CVS change worked fine. Please move your comments from the
generated Makefile to the text block above and write them so
a new developer could understand the issue and why the change
exists. They might, for example, have the MKS toolkit which
includes strip.exe. So, for example, instead of:

<<noweb>>=
# Changed to comment out strip symbol table since    -WSP
# executables have a .exe. extension under Windows.   - WSP
...

which was the old "in code" comment model. We now have a tool
for deeply explaining changes in real text. So a better form is:

Fixed the stupid bug
<<noweb>>=
...

Just kidding. But the whole reason for using literate programming and
latex is that we are creating a living document around the "compiled"
form of the Makefile. Makefile files are just machine-generated
output. They shouldn't include comments as the machine won't care and
humans should not be reading them.
 
So a better suggestion (in fuller detail) might be to mark your
changes as a code chunk, create them out of line and document the
need for the change thus:


.........


The noweb makefile will attempt to remove the symbol table of
the constructed executable using the strip program. This program
does not exist on Windows so we cannot use it. Since noweb is
a package maintained outside of Axiom's control we cannot change
the Makefile directly. Instead we apply the following patch:

<<strip fix for windows>>=
	sed 's/strip/#strip/g;s/ELISP=\/dev\/null/ELISP=\/tmp\/null/' makefile > makefile.tmp ; \
	mv makefile makefile.old ; \
	mv makefile.tmp makefile ; \
	sed 's/strip/#strip/g;s/ELISP=\/dev\/null/ELISP=\/tmp\/null/' makefile.nw > makefile.nw.tmp ; \
	mv makefile.nw makefile.nw.old ; \
	mv makefile.nw.tmp makefile.nw ; \
@

<<noweb>>=
noweb:
	@echo 13 making noweb
	@mkdir -p ${OBJ}/noweb
	@mkdir -p ${TMP}
	@mkdir -p ${MNT}/${SYS}/bin
	@( cd ${OBJ}/noweb ; \
<<strip fix for windows>>
	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
	cd ${OBJ}/noweb/src ; \
	./awkname gawk ; \
	${MAKE} BIN=${MNT}/${SYS}/bin LIB=${MNT}/${SYS}/bin/lib \
                MAN=${MNT}/${SYS}/bin/man \
                TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
	@echo The file marks the fact that noweb has been made > noweb

..........


Notice that the explanation will no longer show up in the Makefile.
It will explain why we need to "reach into" another Makefile rather
than change it directly. It takes the patch "out of line" so other
people can remove it later if they wish (by creating a <<noweb-nopatch>>
stanza or some such that they include in their platform files.

Also, just to be painful about this but this change might better
be applied as follows:

(1)
cd ${OBJ}/noweb/src
change the makefile
diff -Naur makefile makefile.wsp >makefile.noweb.strip

(2)
copy makefile.noweb.strip to the $SPAD/zips directory

(3)
modify the <<noweb>>= stanza to read

<<noweb>>=
noweb:
	@echo 13 making noweb
	@mkdir -p ${OBJ}/noweb
	@mkdir -p ${TMP}
	@mkdir -p ${MNT}/${SYS}/bin
	@( cd ${OBJ}/noweb ; \
        patch < ${ZIPS}/makefile.noweb.strip
	tar -zxf ${ZIPS}/noweb-2.10a.tgz ; \
	cd ${OBJ}/noweb/src ; \
	./awkname gawk ; \
	${MAKE} BIN=${MNT}/${SYS}/bin LIB=${MNT}/${SYS}/bin/lib \
                MAN=${MNT}/${SYS}/bin/man \
                TEXINPUTS=${MNT}/${SYS}/bin/tex all install >${TMP}/trace )
	@echo The file marks the fact that noweb has been made > noweb

I have a patch to noweb I'll be applying in the same way so I'll
end up rewriting your patch. Patch is preferred to sed because
patch handles context and is marginally easier to use since you
can "hand patch" the changes if you wish.

I can "export" patch files back to the original projects like
noweb and GCL where they can easily apply them.

And I expect to receive changes in patch form from people who
do not have write access to the CVS. Patch files are automatically
handled by a few tools like emacs.

Patches may also be used between minor versions, although I'm
undecided about that. The shower-committee debate still rages.

Changes to things we actually control, of course, will just get
made to CVS.

I'm being verbose about the suggested changes more for the
developer community benefit than yours. I want to document the
"guidelines" for future reference.

Feel free to argue.

\start
Date: Wed, 27 Nov 2002 13:58:36 -0500
From: Tim Daly 
To: Michel Lavaud
Subject: Re:noweb,  pamphlets, and TeXmacs
CC: William Sit

Michel,

The expression $x_i$ is ambiguous for many reasons. You don't know the
type of x. It could be a vector so x_i is an element. It could be a
symbol so x_i is a symbol. It could be a matrix so x_i could be a
vector, etc.

Without knowing the type of x (and, by the way, of i) and the domain
of discourse x_i says nothing.

\start
Date: Wed, 27 Nov 2002 14:08:24 -0500
From: Tim Daly 
To: list
Subject:  Re: GCL on windows.

Greetings!  GCL Mingw is apparently in decent shape, thanks to Mike
Thomas and David Billinghurst.  Compiles maxima and ACL2.  You can get
the latest snapshot from
ftp://ftp.gnu.org/pub/gnu/gcl/cvs/gcl_mingw32_20021119.zip.

Tim Daly  writes:

> hey *,
> 
> what's the state of this? does gcl run on windows under anything
> (cygwin, mingw, native)?
> 
> Tim
> 
> 
> 
> 

\start
Date: Wed, 27 Nov 2002 16:29:38 -0500
From: Tim Daly 
To: Bill Page
Subject:  Re: [Gcl-devel] Re: GCL on windows.

>Bill Page wrote:

> Just to be clear. MinGW/Msys is not an extension of the
> Windows operating system (like Cygwin is) but rather
> just a minimal development environment that results in
> a native Windows application. Originally there was
> just a native windows GCC compiler called MinGW. Now
> there is a rapidly growing set of utilitys and libraries
> ported from the Linux originals which makes up Msys. So
> far in my experience it is much faster than Cygwin and
> seems to be in a state of very active development where as
> Cygwin is now viewed (by some at least) as a bit "old
> fashioned". A lot of the MinGW/Msys stuff is derived by
> people with Cygwin experience.
> 
> The biggest difficulty that I see in MinGW is the lack
> of the X-windows environment which is (more or less)
> unique to Unix (and part of Cygwin). Microsoft Windows
> itself *is* a windows environment but very different
> from X-windows. So porting Unix graphical applications to
> Microsoft Windows is currently rather difficult. But their
> are some people working on methods to make this easier in
> the future.
> 
> After several tests and trials, I think MinGW/Msys (rather
> than Cygwin) is the best choice for building the Windows
> version of Axiom.

Ok. I'll defer to whatever choice you find appropriate.
The graphics portion of Axiom currently amounts to the
hypertex browser and the drawing software. The interpreter
doesn't really depend on anything since it was developed
to run on a text-only mainframe. Getting interpsys and
the algebra running is the first goal.

The windows version of Axiom used to use IBM's TexExplorer
software but that was not released. I'll cruise around the
web for some combination of tex, graphics & windows software. 
We can't be the first people to need an open-source version
of this.

Magnus has a tcl/tk front end. I believe that tcl/tk software
will run on windows. Do you know if this is true? Perhaps we
can steal the front-end as it is a stand-alone piece of
software.

\start
Date: Wed, 27 Nov 2002 16:39:02 -0500
From: William Sit
To: Tim Daly
Subject: Re:noweb,pamphlets, and TeXmacs
CC: Michel Lavaud

Michel Lavaud wrote:
> 
> Hello William,
> 
> > A TeX expression does not have
> > an unambiguous mathematical meaning. MathML tags define a unique
> > mathematical meaning to a subclass of mathematical expression.
> 
> Sorry I don't see exactly what you mean, could you develop a little your
> arguments? In what sense is $x_i$ for example ambiguous?

Tim Daly wrote:
> 
> Michel,
> 
> The expression $x_i$ is ambiguous for many reasons. You don't know the
> type of x. It could be a vector so x_i is an element. It could be a
> symbol so x_i is a symbol. It could be a matrix so x_i could be a
> vector, etc.
> 
> Without knowing the type of x (and, by the way, of i) and the domain
> of discourse x_i says nothing.
> 
> Tim

Thanks, Tim. In fact, in typesetting, the meaning of the expression
$x_i$ also depends on its surrounding environment. Mathematicians and
physicists create their own notations, typically these are adopted
"universally" IN THE SUBAREA. Physicists typically write $a_{ij} x_i$ to
mean summation as $i$ runs through its range. So even if we know the
domain of both $x$ and of $i$, and the "operator" $\_$ (subscript, which
IS a unary operator with lots of different meanings, for example, $x_i$
could mean the partial derivative of $x$ with respect to the $i$-th
independent variable, or the order $i$ derivative with respect to some
notationally unspecified independent variable), we still won't know what
$x_i$ means in context. Only the human mathematician or physicist can
"read between the symbols".

This, is one reason I say MathML and OpenML are only partial solutions
to the content problem. Fortunately, in computer algebra systems, as in
contrast to typesetting or display, the systems require more precise
meanings and can handle polymorphism and overloading of operators. So
the trick is not to lose such information once an expression is sent to
the display handler.

\start
Date: Wed, 27 Nov 2002 17:18:42 -0500
From: Tim Daly 
To: Bill Page
Subject:  Windows noweb patch

Bill,

I've modified the Makefile.pamphlet in the CVS.
I've added 4 files to the zips subdirectory:
  noweb.modules.c.patch
  noweb.modules.nw.patch
  noweb.src.Makefile.patch
  noweb.src.Makefile.nw.patch

The first problem in noweb is that it elides chunknames that
it does not recognize. Thus in:
   c << 2 && d >> 3
you get the following output:
   c 3
which is clearly incorrect. 
The first two patch files fix that. 

The second problems is that noweb doesn't build cleanly on Windows.
It appears you change 2 things: comment out the strip call and
change all /dev/null to /tmp/null. These changes are fixed by
the second patch.

Since the second set of changes are windows specific you'll find that
the Makefile.pamphlet has a new chunck called <<noweb.Windows>>.
When you make a Windows platform file use this chunkname rather than
the <<noweb>> chunkname.

\start
Date: Wed, 27 Nov 2002 17:29:22 -0500
From: Tim Daly 
To: Sam Tannous
Subject:  Re: Axiom

I've sent a request to have an account created for you.
You'll hear back about it as soon as the sysadmin does it.

Anonymous access uses the username "anonymous", with an empty
password.  "anonymous" only has read access.  So, you can tell your
users to:

cvs -d:pserver:anonymous@axiom.tenkan.org:/home/cvs login
(empty password)
cvs -d:pserver:anonymous@axiom.tenkan.org:/home/cvs co axiom

cd axiom/new/new
make

Let me know what fails.

\start
Date: Wed, 27 Nov 2002 18:01:38 -0500
From: Bill Page
To: list
Subject:  Re: GCL on windows.

Tim,

On Wed, 27 Nov 2002 16:29:38 -0500 you wrote:

> ...
> > [Bill] 
> > The biggest difficulty that I see in MinGW is the lack
> > of the X-windows environment which is (more or less)
> > unique to Unix (and part of Cygwin). Microsoft Windows
> > itself *is* a windows environment but very different
> > from X-windows. So porting Unix graphical applications to
> > Microsoft Windows is currently rather difficult. But their
> > are some people working on methods to make this easier in
> > the future.
> > 
> > After several tests and trials, I think MinGW/Msys (rather
> > than Cygwin) is the best choice for building the Windows
> > version of Axiom.
> 
> Ok. I'll defer to whatever choice you find appropriate.
> The graphics portion of Axiom currently amounts to the
> hypertex browser and the drawing software. The interpreter
> doesn't really depend on anything since it was developed
> to run on a text-only mainframe. Getting interpsys and
> the algebra running is the first goal.
>

Yes, of course.
 
> The windows version of Axiom used to use IBM's
> TexExplorer software but that was not released. I'll
> cruise around the web for some combination of tex,
> graphics & windows software. We can't be the first
> people to need an open-source version of this.
>

Well we have been discussing TeXmacs as a graphical
interface, right? TeXmacs does not currently run in
native windows but a version is planned. A user interested
in a graphical tex front-end to Axiom running on a PC could
still install Cygwin and run TeXmacs to interface with
Axiom running in windows native mode.

Currently, as I understand it, TeXmacs has not "off-the-
shelf" facility to display graphical output from tools
such as GNUplot, etc. But I have seen this discussed
on the TeXmacs developer list.

> Magnus has a tcl/tk front end. I believe that tcl/tk
> software will run on windows. Do you know if this is
> true?

Yes. But these tools are a little "dated". If changes
are needed to Axiom then we might consider other
alternatives. I can check around and let you know what
I find.

If our goal is just to support the existing Axiom graphics
capabilities in a platform independent way, then perhaps
simply re-coding that part of Axiom to interface with an
open source graphics package is all that would be needed.

> Perhaps we can steal the front-end as it is a stand-alone
> piece of software.
> 

What are your current thoughts about TeXmacs? Personally
I still think it is a good match for Axiom and I would be
prepared to devote some effort to helping to extended
TeXmacs capabilities where these would better meet the
requirements of Axiom.

I think it would be good to avoid having to develop an
Axiom specific front-end (even if it is "borrowed" from
some other open source package), if at all possible.

\start
Date: Wed, 27 Nov 2002 18:23:01 -0500
From: Tim Daly 
To: Bill Page
Subject:  Windows front end

> Bill Page wrote:
> 
> ...(snip)...
> 
> Well we have been discussing TeXmacs as a graphical
> interface, right? TeXmacs does not currently run in
> native windows but a version is planned. A user interested
> in a graphical tex front-end to Axiom running on a PC could
> still install Cygwin and run TeXmacs to interface with
> Axiom running in windows native mode.
> 
> Currently, as I understand it, TeXmacs has not "off-the-
> shelf" facility to display graphical output from tools
> such as GNUplot, etc. But I have seen this discussed
> on the TeXmacs developer list.
> 
> > Magnus has a tcl/tk front end. I believe that tcl/tk
> > software will run on windows. Do you know if this is
> > true?
> 
> Yes. But these tools are a little "dated". If changes
> are needed to Axiom then we might consider other
> alternatives. I can check around and let you know what
> I find.
> 
> If our goal is just to support the existing Axiom graphics
> capabilities in a platform independent way, then perhaps
> simply re-coding that part of Axiom to interface with an
> open source graphics package is all that would be needed.
> 
> > Perhaps we can steal the front-end as it is a stand-alone
> > piece of software.
> 
> What are your current thoughts about TeXmacs? Personally
> I still think it is a good match for Axiom and I would be
> prepared to devote some effort to helping to extended
> TeXmacs capabilities where these would better meet the
> requirements of Axiom.
> 
> I think it would be good to avoid having to develop an
> Axiom specific front-end (even if it is "borrowed" from
> some other open source package), if at all possible.

TeXmacs is fine as a front-end. I'm all in favor of it.
However, it doesn't run on Windows at the moment and we're 
gonna take flak from the users who are conditioned to the
TeXexplorer front-end. Helping TeXmacs run on Windows and
work with Axiom is certainly a worthwhile goal.

I'm a command-line oriented person and won't use a GUI even
if it exists nor do I run Windows so I defer to your decisions
in this area. Choose a direction, give it a try and follow your
whims. I'll do what I can to help.

\start
Date: 27 Nov 2002 20:41:12 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re:  Re: Axiom
Cc: Sam Tannous

Greetings!  I just saw this go by, and gave it a try myself.
obj/linux/bin/bootsys appeared to be created successfully.  This also
appeared to be the final result of the build.

Does this accurately reflect the current status?

Take care,

Tim Daly  writes:

> I've sent a request to have an account created for you.
> You'll hear back about it as soon as the sysadmin does it.
> 
> Anonymous access uses the username "anonymous", with an empty
> password.  "anonymous" only has read access.  So, you can tell your
> users to:
> 
> cvs -d:pserver:anonymous@axiom.tenkan.org:/home/cvs login
> (empty password)
> cvs -d:pserver:anonymous@axiom.tenkan.org:/home/cvs co axiom
> 
> cd axiom/new/new
> make
> 
> Let me know what fails.

\start
Date: Wed, 27 Nov 2002 21:09:06 -0500
From: Tim Daly 
To: Camm Maguire
Subject:  Layers

Yes, in the current state of the CVS the end result of the build
process is to create bootsys.

Axiom is built from layers, more for historical reasons than by
design. 

Layer 0 is common lisp. Certain extensions are used and these
exist in libspad.a so each common lisp needs to be extended 
with these extras. 

Thus building layer 0 consists of 
 (1) building noweb so we can parse pamphlet files
 (2) building libspad.a
 (3) building common lisp, resulting in obj/linux/bin/lisp
 
Layer 1 is bootsys. Axiom is partially written in common lisp and
partially written in a syntactic-sugar language called boot. The
boot translator reads boot files and generates common lisp. 
(Actually, MacLisp + Lisp/370 + Lisp/VM + common lisp but lets
not go there). 

The boot translator (in src/boot) is written in boot and thus needs
a boot translator to generate a boot translator. For this purpose
we "cache" the generated lisp code from the previous system and
use it to generate a new copy of the translator. Modifications to
the boot translator are not for the weak of heart.

The src/boot build uses obj/linux/bin/lisp to compile the cached
lisp code. This code is then loaded into a clean copy of lisp
and saved as obj/linux/bin/bootsys.

Layer 2 is depsys. The rest of the system depends on dozens of
macros and functions (maclisp-in-common-lisp, etc). Depsys is
a "compile environment" for all other system files. 

The goal of layer 2 is to generate obj/linux/bin/depsys.

Layer 3 is interpsys. Interpsys is the Axiom interpreter which
is the code layer you talk to at the Axiom command-line prompt.
Interpsys contains hundreds of files and many layers of functionality.

The goal of layer 3 is to generate mnt/linux/bin/interpsys.

Layer 4 is the compiler layer. Parts of this layer have been split out
of the distribution and is now run as a separate project and website.
There are 2 compilers, the "spad" compiler and the "aldor"
compiler. They have a compatible syntax (within the constraints of
their design goals as the spad compiler assumes the interpreter but
the aldor compiler cannot). Either compiler can be used. We use both.
The aldor compiler is available at www.aldor.org. The spad compiler
is built in to the interpsys layer.

Layer 5 is the compiled algebra code. The algebra code goes thru
its own dance in order to build up the type towers. The result of
this process is a directory of library code and a couple of 
daase ("database", shortened because I did a port to DOS once,
a long time ago) files which contain information needed to look
things up.

Layer 6 is the "utilities", like the graphics and hypertex front
end code. 

Layer 7 is the sman facility that runs the whole show.

Eight layers in all, assuming you don't want to argue about what
is and is not a layer. I'm working on layer 2 as we speak.

\start
Date: Thu, 28 Nov 2002 10:13:15 +0000
From: Mike Dewar
To: Tim Daly 
Subject: Re:  Windows front end
Cc: Bill Page

Hi Guys,

You're probably aware of this but, just in case, it may help for me to
point out some of the differences between the Unix and Windows system.

1. Graphics: On Unix this is done with a combination of bespoke Axiom
data structures and some pretty convoluted X-Windows code.  On Windows
we added facilities to create OpenInventor data structures (OpenInventor
is the basis for VRML - the virtual reality markup language).  The
Inventor geometries were then exported to a little application we wrote
based on the standard SceneViewer application you get with many
OpenInventor toolkits.  The results were definitely superior to the Unix
version.

NAG has a visualisation system based on Open Inventor called Iris
Explorer and some of the reasons for going down this route were product
integration and leveraging our internal expertise.  However since VRML
is a well-defined standard it also made Axiom more open.  The
longer-term plan was to do the same on Unix and drop the old Axiom
rendering stuff completely but sadly we never got to do this.

I wouldn't try porting the X-based graphics to Windows but would either
use the OpenInventor stuff and one of the free VRML viewers or use the
same approach with a different standard format.  For 3D graphics the OI
stuff worked pretty-much out-of-the-box, we just added menus for axes,
scales etc.  For 2D plots we had to add some extra code but that wasn't
too hard.

2. The Browser: This is the part of HyperTex which allows you to look up
domains, categories, operations etc. as opposed to the whole HyperTex
environment.  For the Windows version we pushed a lot of the code which
was in the HyperTex application or used Unix scripts into either the
interpreter (via boot code) or in some cases into the underlying Lisp (I
added a grep function based on some existing NAG code for example).
Incidentally this kind of thing will probably give you problems when you
try using different lisps ...

The upshot of this is that all you require from the front end is a
simple forms interface and everything else can be done by the
interpreter, all the old stuff using scripts and C code is obsolete.

3. The Documentation: The documentation for the Windows system was
translated from the Unix version so that it would work inside
TechExplorer (and in some cases we also added code to TechExplorer to
support particular features).  In most cases this was done by a first
pass using sed and then some tidying up via emacs macros, hand edits
etc.  during the proof-reading stage.  

Again there was a long-term plan which was to migrate the HyperTex docs
to SGML which was then our standard documentation format (now it would
be XML) and then generate HyperTex, TechExplorer TeX, vanilla LaTeX as
needed.


So to summarise, its really not necessary to have an X environment under
Windows and, while I don't know anything about TeXmacs, it ought to be
sufficient for your needs if it supports forms.  You will need a
different graphics environment but we found that relatively
straightforward, largely because the object-oriented nature of Inventor
made it easy to model the data structures in Axiom.

Cheers, Mike. 

On Wed, Nov 27, 2002 at 06:23:01PM -0500, Tim Daly wrote:
> 
> > Bill Page wrote:
> > 
> > ...(snip)...
> > 
> > Well we have been discussing TeXmacs as a graphical
> > interface, right? TeXmacs does not currently run in
> > native windows but a version is planned. A user interested
> > in a graphical tex front-end to Axiom running on a PC could
> > still install Cygwin and run TeXmacs to interface with
> > Axiom running in windows native mode.
> > 
> > Currently, as I understand it, TeXmacs has not "off-the-
> > shelf" facility to display graphical output from tools
> > such as GNUplot, etc. But I have seen this discussed
> > on the TeXmacs developer list.
> > 
> > > Magnus has a tcl/tk front end. I believe that tcl/tk
> > > software will run on windows. Do you know if this is
> > > true?
> > 
> > Yes. But these tools are a little "dated". If changes
> > are needed to Axiom then we might consider other
> > alternatives. I can check around and let you know what
> > I find.
> > 
> > If our goal is just to support the existing Axiom graphics
> > capabilities in a platform independent way, then perhaps
> > simply re-coding that part of Axiom to interface with an
> > open source graphics package is all that would be needed.
> > 
> > > Perhaps we can steal the front-end as it is a stand-alone
> > > piece of software.
> > 
> > What are your current thoughts about TeXmacs? Personally
> > I still think it is a good match for Axiom and I would be
> > prepared to devote some effort to helping to extended
> > TeXmacs capabilities where these would better meet the
> > requirements of Axiom.
> > 
> > I think it would be good to avoid having to develop an
> > Axiom specific front-end (even if it is "borrowed" from
> > some other open source package), if at all possible.
> 
> TeXmacs is fine as a front-end. I'm all in favor of it.
> However, it doesn't run on Windows at the moment and we're 
> gonna take flak from the users who are conditioned to the
> TeXexplorer front-end. Helping TeXmacs run on Windows and
> work with Axiom is certainly a worthwhile goal.
> 
> I'm a command-line oriented person and won't use a GUI even
> if it exists nor do I run Windows so I defer to your decisions
> in this area. Choose a direction, give it a try and follow your
> whims. I'll do what I can to help.

\start
Date: Thu, 28 Nov 2002 10:35:20 -0500
From: Tim Daly 
To: Mike Dewar
Subject: Re:  Windows front end
CC: Bill Page
 
> Mike Dewar wrote:
> 
> You're probably aware of this but, just in case, it may help for me to
> point out some of the differences between the Unix and Windows system.

Actually, I'm unaware of what lies ahead as I'm working on the system
layer by layer. I expect life to get much harder once I get out of
the lisp layers. The first announced version is likely to only work
as a command-line interpreter environment. The cross-platform issues
for the graphics and browser are going to be painful, I suspect.

> 1. Graphics: On Unix this is done with a combination of bespoke Axiom
> data structures and some pretty convoluted X-Windows code.  On Windows
> we added facilities to create OpenInventor data structures (OpenInventor
> is the basis for VRML - the virtual reality markup language).  The
> Inventor geometries were then exported to a little application we wrote
> based on the standard SceneViewer application you get with many
> OpenInventor toolkits.  The results were definitely superior to the Unix
> version.

Is the "little application" in the code we have? If not, would NAG
be willing to share it?

> NAG has a visualisation system based on Open Inventor called Iris
> Explorer and some of the reasons for going down this route were product
> integration and leveraging our internal expertise.  However since VRML
> is a well-defined standard it also made Axiom more open.  The
> longer-term plan was to do the same on Unix and drop the old Axiom
> rendering stuff completely but sadly we never got to do this.

I'm happy to hear that work was done to make the graphics more open.
One of the stated goals on the homepage is to "give away" the graphics.
I was planning to enhance the abilities of some other open source
product (like GNUPlot) with the facilities available in Axiom. That
way they gain with new function and we gain because we don't have to
support the graphics any more.

The graphics facility is useful and necessary but the expertise needed
to do it right is a whole other field of research. Scott Morrison did
the graphics and he's no longer following computer algebra.

If you happen to have some useful web and/or book references I'd
appreciate it if you mention them to the group.

I hope to define the input and output formats of the interpreter so
that others can use it. Ideally there would be 3 "pairs" of connections:

Stdin, Stdout for the interpreter/console
Stdin, Stdout for ethernet ports so you can reach the interpreter
  from network based code (and even the browser/graphics applications)
Stdin, Stdout "covers" for linked programs on the same system

If we do that cleanly then all of the other things will just be
stand-alone applications that can communicate with the Axiom interpreter.
That way we can also leverage them for Aldor.
 
> I wouldn't try porting the X-based graphics to Windows but would either
> use the OpenInventor stuff and one of the free VRML viewers or use the
> same approach with a different standard format.  For 3D graphics the OI
> stuff worked pretty-much out-of-the-box, we just added menus for axes,
> scales etc.  For 2D plots we had to add some extra code but that wasn't
> too hard.

I'll take that advice. Do you happen to know of compatible VRML viewers
that work on both Windows and Unix?
 
> 2. The Browser: This is the part of HyperTex which allows you to look up
> domains, categories, operations etc. as opposed to the whole HyperTex
> environment.  For the Windows version we pushed a lot of the code which
> was in the HyperTex application or used Unix scripts into either the
> interpreter (via boot code) or in some cases into the underlying Lisp (I
> added a grep function based on some existing NAG code for example).
> Incidentally this kind of thing will probably give you problems when you
> try using different lisps ...

The browser was a piece of the system that was leading edge
for its time (the web and browsers didn't exist yet). The stated
plan is to "give away" the browser. In this case what that implies
is rewriting the system so it uses a real browser instead of our
home-grown one.

Surely you didn't write lisp that runs on only one platform?! Sigh.
Ah, well, porting is my life :-) I'm gonna be a sherpa when I grow up.
NAG shoulda hired me when they had the chance. I AM glad that you
pushed the scripts and other cruft into lisp.
 
> The upshot of this is that all you require from the front end is a
> simple forms interface and everything else can be done by the
> interpreter, all the old stuff using scripts and C code is obsolete.

This is good news.
 
> 3. The Documentation: The documentation for the Windows system was
> translated from the Unix version so that it would work inside
> TechExplorer (and in some cases we also added code to TechExplorer to
> support particular features).  In most cases this was done by a first
> pass using sed and then some tidying up via emacs macros, hand edits
> etc.  during the proof-reading stage.  

In this world the docs are supposed to be in noweb pamphlets from
which we can generate LaTeX. Hopefully the front-end will handle the
cross-platform issues so we don't have to.

> Again there was a long-term plan which was to migrate the HyperTex docs
> to SGML which was then our standard documentation format (now it would
> be XML) and then generate HyperTex, TechExplorer TeX, vanilla LaTeX as
> needed.

For the browser stuff there is a noweb to html conversion function.
How well that will handle all of our nonsense remains to be seen.
The fact that noweb pamphlets are "pre-final-format" allows us to 
be flexible of our target choices and is one of the reasons I chose it.
Sometimes we want TeX, sometimes HTML and sometimes MathML or XML.
Noweb is designed to allow that. 
 
> So to summarise, its really not necessary to have an X environment under
> Windows and, while I don't know anything about TeXmacs, it ought to be
> sufficient for your needs if it supports forms.  You will need a
> different graphics environment but we found that relatively
> straightforward, largely because the object-oriented nature of Inventor
> made it easy to model the data structures in Axiom.

OpenInventor, eh? Sigh, yet another thing to learn. TeXmacs has
potential but does not currently run on Windows. If it did it would
solve a fair number of issues.

As I said earlier, Axiom is likely to make its first appearance as
a command-line interpreter (no doubt causing us to take some flak).
Rebuilding the rest of the tools is going to be an exercise in
creativity. It will have the unfortunate side-effect that I'll
have to learn Windows :-)

I do appreciate the advice and guidance. It's been years since I've
seen this code.

\start
Date: Thu, 28 Nov 2002 11:25:07 -0500
From: Bill Page
To: Mike Dewar
Subject:  Re: Windows front end

Tim,

On Thu, 28 Nov 2002 10:35:20 -0500 you wrote:
> ... 
> OpenInventor, eh? Sigh, yet another thing to learn.
> TeXmacs has potential but does not currently run on
> Windows. If it did it would solve a fair number of
> issues.
> ...

Actually, TeXmacs *does* run on Windows. The only drawback
is that it requires that the user install at least a
minimal Cygwin environment plus the XFree86 x-server.
What is means in real terms is adding a Cygwin-specific
library (dll) which provides most of the standard Linux
api. Running the x-server opens a new Windows window that
looks (for the most part) just like Linux minus the fancy
window manager (KDE or whatever). TeXmacs runs in this
window and can interact with other windows applications.

The installation is a bit complex since it is not most
people's intention to only install a minimal x-server
environment. But I think I could package it fairly well.
In addition to this added complexity, the main drawback
is a sacrifice of performance compared to native windows
applications. It seems that the Cygwin unix emulation is
not particularly efficient.

\start
Date: Thu, 28 Nov 2002 11:30:12 -0500
From: Tim Daly 
To: Bill Page
Subject:  Windows and TeXmacs

I agree that you can run TeXmacs on a Windows box using
the techniques you've outlined and that is a possible
"first step". By the phrase "TeXmacs doesn't run on Windows"
I was implying that it runs using the native Windows API.

Packaging up the necessary pieces in a zip file so they could
be unzipped into place and appear as a "complete application"
would be a useful thing to do. At least we would know what
pieces are necessary to get a minimally runnable system.

What do you feel are the issues to get it to run in a Mingw
environment?

\start
Date: Thu, 28 Nov 2002 12:14:57 -0500
From: Bill Page
To: Tim Daly 
Subject:  Re: Windows and TeXmacs

Tim,

> Date: Thu, 28 Nov 2002 11:30:12 -0500
> ... 
> What do you feel are the issues to get it [TeXmacs] to
> run in a Mingw environment?
> 

The MinGW environment is just native windows. It has no
special unix emulation layer. To get TeXmacs to compile
under MinGW and run under Windows requires (at least)
some replacement for the x11 library. There does exist
an open source preliminary version of such a replacement
library that interfaces directly with the Windows api
(no x-windows necessary). I have discussed it briefly
with another developer who has used it successfully (with
a few changes/additions). This might be an option for
TeXmacs. David Allouche (texmacs developer) has done a
review of the other requirements for TeXmacs on windows
and (I believe) considers such a port to Windows possible.
However I do not think it is a priority for now.

I have only done some rather unsophisticated C programming
in Windows so I do not have any feeling at all about how
long it might take me (working basically from scratch) to
make such a change. My preference would be for me to
contribute to the effort at some higher level or a small
and externally directed part of it.

\start
Date: Thu, 28 Nov 2002 12:20:06 -0500
From: Tim Daly 
To: Sam Tannous
Subject:  Re: FreeBSD...Re: Axiom

Sam,

The system is trying to extract the platform specific Makefile
from the top level Makefile.pamphlet. To see what is happening
notice that there is a number associated with the line just
before the failure. In this case, the number is "2".

You can see that make is still in the home directory so the
Makefile that is being executed is the top level Makefile.
Edit this Makefile and search for the string "echo 2" and you will
find the last echo line that was successfully executed.

Immediately after that line comes the line:
	@ ${SPADBIN}/notangle -t8 -RMakefile.${SYS} Makefile.pamphlet >Makefile.${SYS}

This is calling notangle from the mnt/linux/bin subdirectory, asking 
notangle to expand the "root" Makefile.Linux. This is the line that
failed (notangle is a shell script that calls markup).

Therefore, the noweb subsystem must not be installed correctly.

Noweb is built once and only once. Subsequent makes will not
rebuild it if it exists.

In order to fix your problem you need to type:

 make clean
 make

The "make clean" will destroy the noweb installation.
The "make" will rebuild it and should work.

Let me know if this fails.

\start
Date: Thu, 28 Nov 2002 13:10:50 -0500
From: Tim Daly 
To: Sam Tannous
Subject:  FreeBSD...Re: Axiom

Another subtle issue has occurred to me.

You mentioned that you actually changed the top level Makefile.pamphlet
Normally if you change the top level Makefile.pamphlet the system will
NOT try to rebuild it automatically. You have to do it by hand by
typing:

export PATH=/spad/mnt/linux/bin:$PATH
export SPAD=/spad/mnt/linux
document Makefile

There is a subtle catch-22 you should be aware of. These instructions
will NOT work in a clean system since noweb does not yet exist.  It
might or might not be related to your problem but I'll explain it
anyway so it is documented.

If you don't have noweb you have to create it first.
Lets assume your install path is /spad and you're using linux
as your platform:

(1) cd /spad
(2) make SPAD=/spad/mnt/linux start

This will make noweb and install it in the /spad subtree.
Axiom is designed to never write outside its subtree.

\start
Date: Thu, 28 Nov 2002 13:38:09 -0500
From: Bill Page
To: Sam Tannous
Subject: Re:  FreeBSD...Re: Axiom

Tim,

There is another problem, which I have so far neglected
to mention in our conversations, that occurs if you
attempt to use a different install path than

  /home/axiomgnu/new

There are several places in the current pamphlet files
where this directory name is hard coded and does not
depend on the environment variables. In order to get it
to compile on my system, I had to create this directory.
After downloading the files from cvs at tenkan I also
had to fix the problem of the /new/new/ path so that the
contents and sub-directoys of

  .../axiom/new/new

ended up in

  /home/axiomgnu/new

( e.g. mv /whereever/axiom/new/new /home/axiom )

Then on my Linux box, at least the make process goes
right through to bootsys.

At least some of the places that the hardcoding occurs
is in the LaTex style file names. You might want to do
a

  find ... | grep '/home/axiomgnu'

command to locate all of these (and a few others) I think.

Let me if you would like help with this.

Also, in the fix for the use of strip in windows systems,
I think a better solution than the one I implemented would
be to introduce a new environment variable for the extension
that is automatically assigned by gcc under Windows (both
Cygwin and Msys). Say $EXE, which would be set to null
in the platform specific files for unix installations and
set to ".exe" for Windows. Then whereever strip x occurs
in the make files, we would need to write strip x${EXE}.

Shall I make this change in what I have now and upload it
to tenkan?

Regards,
Bill Page.
> 
> Another subtle issue has occurred to me.
> 
> You mentioned that you actually changed the top level Makefile.pamphlet
> Normally if you change the top level Makefile.pamphlet the system will
> NOT try to rebuild it automatically. You have to do it by hand by
> typing:
> 
> export PATH=/spad/mnt/linux/bin:$PATH
> export SPAD=/spad/mnt/linux
> document Makefile
> 
> There is a subtle catch-22 you should be aware of. These instructions
> will NOT work in a clean system since noweb does not yet exist.  It
> might or might not be related to your problem but I'll explain it
> anyway so it is documented.
> 
> If you don't have noweb you have to create it first.
> Lets assume your install path is /spad and you're using linux
> as your platform:
> 
> (1) cd /spad
> (2) make SPAD=/spad/mnt/linux start
> 
> This will make noweb and install it in the /spad subtree.
> Axiom is designed to never write outside its subtree.

\start
Date: Thu, 28 Nov 2002 21:16:21 -0500
From: Tim Daly 
To: Bill Page
Subject:  SPAD, strip and dev/null

Bill,

I did a complete walk of the files I uploaded. There are
hardcoded paths in src/scripts/boxup, src/scripts/mytangle,
and src/scripts/myweave. These functions are only used by
me and won't be shipped. I'll remove them from the final
distribution but I'm actively using them for various 
purposes during the construction. As far as I know there
are no other uses for boxup, mytangle and myweave.

There are two uses of "/home/axiomgnu/new" in the root
Makefile.pamphlet which need to be changed. I used to 
compute these dynamically in the distant past but I have
to remember the magic. All you should have to do is set
a shell variable SPAD to the correct path and everything
should work. This will also be fixed before it gets into
the final distribution on savannah.

Make sure you're searching for "/home/axiomgnu" in a clean
distribution. GCL and noweb "capture" the path in their
configure scripts but that should all go away when you do
a make clean.

About the strip & /dev/null....
I'm going to redo that change as it uses /tmp/null instead
and this violates the rule that Axiom never writes outside
its own source tree. I need to use ${TMP}/null instead.
I'll also make the EXE change you suggested.

\start
Date: Fri, 29 Nov 2002 10:24:19 +0000
From: Mike Dewar
To: Tim Daly 
Subject: Re:  Windows front end
Cc: Bill Page

On Thu, Nov 28, 2002 at 10:35:20AM -0500, Tim Daly wrote:
<snip> 
> > 1. Graphics: On Unix this is done with a combination of bespoke Axiom
> > data structures and some pretty convoluted X-Windows code.  On Windows
> > we added facilities to create OpenInventor data structures (OpenInventor
> > is the basis for VRML - the virtual reality markup language).  The
> > Inventor geometries were then exported to a little application we wrote
> > based on the standard SceneViewer application you get with many
> > OpenInventor toolkits.  The results were definitely superior to the Unix
> > version.
> 
> Is the "little application" in the code we have? If not, would NAG
> be willing to share it?
No and no :-(  As I said its based on something which was part of the
Inventor toolkit we were using and that is a commercial product which we
were licensing.  However it shouldn't be too difficult to find a free VRML
viewer and adapt that.  

> I'm happy to hear that work was done to make the graphics more open.
> One of the stated goals on the homepage is to "give away" the graphics.
> I was planning to enhance the abilities of some other open source
> product (like GNUPlot) with the facilities available in Axiom. That
> way they gain with new function and we gain because we don't have to
> support the graphics any more.
I think we looked at GNUPlot and decided it wasn't good enough because
it lacked many of the features for manipulating 3D images that were in
the Unix version.  Using Open Inventor/VRML means you can export images
to industrial-strength visualisation packages which was important to us.
After we released Axiom under Windows, Maple moved their graphics onto
OpenGL (the toolkit Open Inventor is built on) so we're not the only
people who think that this is a good approach :-) Of course GNUplot has
probably come a long way since we looked at it and may be suitable for
your needs, but I doubt its as good as Mathematica and Maple's
offerings.

> The graphics facility is useful and necessary but the expertise needed
> to do it right is a whole other field of research. Scott Morrison did
> the graphics and he's no longer following computer algebra.
Don't underestimate the importance of visualisation and computer
algebra.  Over the years I've met a number of users who chose Axiom
primarily because of its graphics.
 
> If you happen to have some useful web and/or book references I'd
> appreciate it if you mention them to the group.
http://www.web3d.org/vrml/vrml.htm seems to be agood place to start
investigating VRML.
 
> I hope to define the input and output formats of the interpreter so
> that others can use it. Ideally there would be 3 "pairs" of connections:
> 
> Stdin, Stdout for the interpreter/console
> Stdin, Stdout for ethernet ports so you can reach the interpreter
>   from network based code (and even the browser/graphics applications)
> Stdin, Stdout "covers" for linked programs on the same system
> 
> If we do that cleanly then all of the other things will just be
> stand-alone applications that can communicate with the Axiom interpreter.
> That way we can also leverage them for Aldor.
A lot of this works already (its how sman communicates with the
interpreter) and we've experimented with reading and writing OpenMath as
well.  The biggest difficulty might be replacing InputForm which looks simple
enough but has some quite complicated parsing rules.   

> > I wouldn't try porting the X-based graphics to Windows but would either
> > use the OpenInventor stuff and one of the free VRML viewers or use the
> > same approach with a different standard format.  For 3D graphics the OI
> > stuff worked pretty-much out-of-the-box, we just added menus for axes,
> > scales etc.  For 2D plots we had to add some extra code but that wasn't
> > too hard.
> 
> I'll take that advice. Do you happen to know of compatible VRML viewers
> that work on both Windows and Unix?
Well the SceneViewer application which came with our toolkit works on
both (as does our Iris Explorer product which also uses it).  I think
that there are some Java applications for VRML which presumably work on
both, although they might depend on other things such as OpenGL libraries
being available.
  
> The browser was a piece of the system that was leading edge
> for its time (the web and browsers didn't exist yet). The stated
> plan is to "give away" the browser. In this case what that implies
> is rewriting the system so it uses a real browser instead of our
> home-grown one.
> 
> Surely you didn't write lisp that runs on only one platform?! Sigh.
Certainly not, what a disgraceful slur (although I have been known to
write lisp that runs on no platforms at all) :-)  When I said that we
changed the underlying lisp I meant that we added C code to CCL and
exposed it as lisp functions (i.e. the grep commands in CCL aren't part
of Common Lisp). 

You should bear in mind that when we started the porting exercise to CCL
it didn't exist as such, and was in fact CSL (as in the inaptly-named
standard lisp used by Reduce).  I don't think CCL is a complete common
lisp implementation and I'm sure that we used some of the standard lisp
feautures/behaviours somewhere, even though we tried to avoid doing so.

> In this world the docs are supposed to be in noweb pamphlets from
> which we can generate LaTeX. Hopefully the front-end will handle the
> cross-platform issues so we don't have to.
Sounds good :-) 

> As I said earlier, Axiom is likely to make its first appearance as
> a command-line interpreter (no doubt causing us to take some flak).
> Rebuilding the rest of the tools is going to be an exercise in
> creativity. It will have the unfortunate side-effect that I'll
> have to learn Windows :-)
Tell me about it ...

Cheers, Mike.

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.



