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

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Wed, 01 Oct 2003 08:14:22 +0100
From: Mark Murray
To: Tim Daly
Subject: Re: [Gcl-devel] Re: New design for Axiom web site 
Cc: Camm Maguire, Cliff Yapp

Tim Daly writes:
> I don't understand why it is important to use an already installed
> lisp image.  It seems likely to be yet-another-source-of-trouble
> like the X library issues. What am I missing?

The already-installed lisp versions (may) have been hacked to
actually work, and they may be standard didtributions of the lisp
compiler distributed by the OS vendor (.rpm, .deb or FreeBSD "port"
files).

The Axiom copy of lisp is a fork, and an incompatible one to boot,
so us OS people (well, me anyway - I'm with FreeBSD) are trying to
use the one that we already have to get things to work.

After all, when you get (say) X, it doesn't come bundled with the
version of GCC that the XFree86 folks have certified that it will
compile with, right? Instead, over time #ifdef hell has developed,
and configuration stuff has been done to make sure that whatever
package it is has been put together to work with whatever you already
have, as far as practical. Sometimes, of course you have to bail out
and say things like "This needs an ANSI C compiler, K&R won't work,
ever!", but bolting every tool that is needed onto the side of the
package concerned is overkill IMO.

I hear what you say about the extensions, and I understand why you
need them; are Camm's proposals not suitable?

That's the way I'm thinking :-)

\start
Date: 01 Oct 2003 12:38:21 +0200
From: Juergen Weiss
To: list
Subject: Fix for Macroexpansion bug

Hi,

here is a fix for the macro expansion bug. As a test I
recompiled the complete algebra without any change in generated
lisp code.


diff -c -r1.4 compiler.boot
*** compiler.boot       2003/06/20 20:58:11     1.4
--- compiler.boot       2003/09/30 20:07:31
***************
*** 670,686 ****
  compMacro(form,m,e) ==
    $macroIfTrue: local:= true
    ["MDEF",lhs,signature,specialCases,rhs]:= form
!   rhs :=
      rhs is ['CATEGORY,:.] => ['"-- the constructor category"]
      rhs is ['Join,:.]     => ['"-- the constructor category"]
      rhs is ['CAPSULE,:.]  => ['"-- the constructor capsule"]
      rhs is ['add,:.]      => ['"-- the constructor capsule"]
      formatUnabbreviated rhs
    sayBrightly ['"   processing macro definition",'%b,
!     :formatUnabbreviated lhs,'" ==> ",:rhs,'%d]
!   ["MDEF",lhs,signature,specialCases,rhs]:= form:= macroExpand(form,e)
    m=$EmptyMode or m=$NoValueMode =>
!     ["/throwAway",$NoValueMode,put(first lhs,"macro",rhs,e)]
  
  --% SEQ
  
--- 670,685 ----
  compMacro(form,m,e) ==
    $macroIfTrue: local:= true
    ["MDEF",lhs,signature,specialCases,rhs]:= form
!   prhs :=
      rhs is ['CATEGORY,:.] => ['"-- the constructor category"]
      rhs is ['Join,:.]     => ['"-- the constructor category"]
      rhs is ['CAPSULE,:.]  => ['"-- the constructor capsule"]
      rhs is ['add,:.]      => ['"-- the constructor capsule"]
      formatUnabbreviated rhs
    sayBrightly ['"   processing macro definition",'%b,
!     :formatUnabbreviated lhs,'" ==> ",:prhs,'%d]
    m=$EmptyMode or m=$NoValueMode =>
!     ["/throwAway",$NoValueMode,put(first lhs,"macro",macroExpand(rhs,e),e)]
  
  --% SEQ
  
\start
Date: Wed, 1 Oct 2003 07:19:42 -0400
From: Tim Daly
To: Mark Murray, Arthur Norman
Subject: Re: [Gcl-devel] Re: New design for Axiom web site
Cc: Camm Maguire, Cliff Yapp

Arthur, Mark,

You make a very convincing case. The key concern, it appears, is forking.
The hope is to migrate changes back into the common lisp. Unless all of
the common lisps agree on a socket standard I don't see how this can happen
but I am willing to try.

It might be the case that every modern common lisp DOES have socket code
and that the socket support could be rewritten (with #+ for each lisp).
We also use some X library support code which might will generic support.
I'll look at that direction. Does anybody know if GCL has sockets at the
lisp level (not inline C code)? I'd be happy to ditch the C code completely
but only if I know that the functionality can be re-implemented in lisp.

After I finish the book the next task is to get sman (superman, the thing
that actually starts when you start axiom) running so the other processes
can communicate. Dylan's going to look at the graphics process and I will
focus on getting hyperdoc back to life.

In the near term (at least the next year) I suspect we will still need
the sources for any common lisp we build upon. These could be
installed sources.  In the long term I'll plan to push toward using
installed lisps.  (Keep in mind that the long term plan is for Axiom to
run on every common lisp.  The fact that GCL has all the support we
need already built in doesn't mean that we're done.)

In Axiom if you want to use an installed gcl instead of the tar file you just:

cd lsp
ln -s (yourGCLdistributionPath)/gcl-2.17.1 gcl-2.17.1
touch gcldir
cd ..
make GCLVERSION=gcl-2.17.1

The symbolic link will use the already installed sources.
The "touch" will convince Axiom that it does not need to build the lisp again.
The GCLVERSION variable says what version you want to use.

I'll add these instructions to the FAQ in Makefile.pamphlet.

We could make this the default install instructions, I suppose, but
that shifts the burden of building onto the end user whereas it
currently resides in the makefile. If the installed sources were
installed as root then the user will have to install as root which is
currently unnecessary (one should never work as root :-) ) I'll break
out the "patching" portion of the stanza so it can be executed against
pre-installed sources.

If you move to a new, untested version of GCL, the build is likely to
fail late into the Axiom build because lisp won't contain the Axiom
extensions.

About Camm's suggestion: I didn't understand the suggestion (and still don't).
I feel like I "missed a memo" on that one. 

Arthur, what is your feeling about making the Axiom C code part of the
standard CCL distribution? 

\start
Date: 01 Oct 2003 11:28:39 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] Re: New design for Axiom web site
Cc: Mark Murray, Cliff Yapp

Greetings!  You guys type so fast!  I'm going to try to be brief to
catch up...

1) Tim, whatever you feel is best for axiom is best in my book too.
   All the foregoing are offered as suggestions only.  

2) (pros and cons of an external gcl build discussed in a separate
   reply to your other post)
        
Tim Daly writes:

> > Having some kind of useful mechanism of adding extensions seems to be
> > a focal point?
> 
> I suppose. The key problem I've had with adding extensions to gcl
> has been system libraries, not gcl itself. The first attempt at
> system building was on Redhat 7.3 and required an XFree library
> which was not part of the standard build. I had included the rpm
> as part of the CVS zips but was convinced that this was, well,
> lets just say, ummm, inelegant :-)
> 

3) non-lisp C extension modules and libraries can now be linked into
   an externally installed GCL from lisp via compiler::link.
4) An older faslink method can be reenabled if desired with likely
   minimal work.
5) Build dependencies as referred to above are handled automatically
   in most modern distributions.  Look at the Build-Depends: line in
   the debian/control file of the GCL source.  There is an analogous
   line in the Debian axiom package.  IMHO, the vast majority of axiom
   users will never compile it, but install it and its runtime
   dependencies automatically with a single command.  The next largest
   group will compile it, but will do so by downloading the source and
   automatically installing its build-dependencies also with a single
   command.  So I think axiom need not fear having external
   dependencies as long as they are clearly specified, knowing that
   only the 'experts' will ever have to take care of ensuring their
   presence when needed.  I think the 'inelegance' you felt above goes
   right to the heart of the modular software design we're all
   striving towards, and might arguably pertain to a subsidiary lisp
   build as well.

> The Mandrake install is giving me similar library issues as is
> the iMac. I tried getting the latest CVS of GCL but it still
> doesn't build. How did you get the Mac build to succeed?
> 

6) When accessing CVS, please use the 'stable' branch, by adding '-r
   Version_2_6_1' after the 'checkout' command word.  This is
   explained on our temporary distribution site:
        http://people.debian.org/~camm/gcl
   We've just put this together in response to ftp.gnu.org's
   inaccessibility.  And David, thanks for the pointer about the file
   restorations there (!).  But alas, the machine I used to access the
   tree is still unavailable, and I cannot get responses from the ftp
   managers for a new account on whatever new machine is involved.

7) Has Aurelian been in touch with you?

8) If you can provide remote ssh access to your imac, I'll get GCL
   running for you.

> Dynamically adding extensions will mean that the lisp loader
> will have to automatically find and link new system libraries.
> That's quite a large task.

9) If the system libraries are specified, (modern distros use a
   'soname' to denote compatible shared libraries, so this should be
   in the specification, but not the minor point release/bug fix
   release number, i.e. libfoo.so.2, not libfoo.so.2.3), GCL can build
   this link in already via compiler::link.  This method requires a
   restart of the lisp, whereas if we were to resurrect the faslink
   method, a restart would not be necessary.
> 
> > The above will need to find a saved_gcl, no? (I'll fix the FreeBSD port
> > to add this to the installed bits if so).
> 
> The above essentially copies saved_gcl to obj/linux/bin/lisp.
> In some hopeful future you should just be able to find the lisp
> on the path.
> 

10) If you just link the external saved_gcl to obj/linux/bin/lisp, it
    won't have your extensions compiled in.  You will get a saved_gcl
    with these extensions compiled in if you use compiler::link as
    outlined in the long email.

> > The FreeBSD port infrastructure takes care of the details, like installing
> > GCL if its not already there.
> 
> Can you point me to the docs on this? How does this magic happen?
> 

11) At least for Debian, you can look at pbuilder and apt-src.

> > Did you get his long email
> 
> Yes, this morning. (Last night was my anniversary so I was kinda 
> lame about reading email). I'll study it in more detail.
> 

11) Happy anniversary!  Don't you dare even think about this stuff on
    such a blissful occasion :-).

Take care,

\start
Date: Wed, 01 Oct 2003 18:46:38 +0200
From: David Mentre
To: Juergen Weiss
Subject: Re: Fix for Macroexpansion bug

Hello Juergen,

Juergen Weiss writes:

> here is a fix for the macro expansion bug. As a test I
> recompiled the complete algebra without any change in generated
> lisp code.

Thanks Juergen.

I think I have added your patch to the corresponding bug in the
database:
[bug #4871] left hand side macro expansion issue (was: Compiling spad
file causes value stack overflow)
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4871&group_id=2938

Have you tried to compile the remaining algebra files?

\section{Broken Files}
These files need to be added.
\begin{verbatim}

limitps    SIGNEF
primelt    FSPRMELT
nsregset   LAZM3PK
nregset    NORMPK
regset     QCMPACK
regset     REGSET
regset     RSETGCD
sregset    SREGSET
sregset    SRDCMPK
sregset    SFRGCD
sregset    SFQCMPK
transsolve SOLVETRA
asp        ASP29
d01agents  D01AGNT
nsregset   SNTSCAT
nregset    NTSCAT
sregset    SFRTCAT
algcat     CPIMA
combfunc   COMBF
ffnb       INBFF
lodo       LODO
lodo       LODO1
lodo       LODO2
newpoint   SUBSPACE
sttf       STTF
zerodim    LEXTRIPK
zerodim    IRURPK
zerodim    RGCHAIN
zerodim    RURPK
zerodim    ZDSOLVE
\end{verbatim}

\start
Date: Wed, 1 Oct 2003 12:59:01 -0400
From: Tim Daly
To: David Mentre
Subject: Missing algebra

David,

The missing algebra is not "fixed" yet. The problem is slightly more subtle. 

\start
Date: Wed, 1 Oct 2003 09:05:30 -0400
From: Tim Daly
To: Mark Murray
Subject: Re: [Gcl-devel] Re: New design for Axiom web site
Cc: Camm Maguire, Cliff Yapp

> Having some kind of useful mechanism of adding extensions seems to be
> a focal point?

I suppose. The key problem I've had with adding extensions to gcl
has been system libraries, not gcl itself. The first attempt at
system building was on Redhat 7.3 and required an XFree library
which was not part of the standard build. I had included the rpm
as part of the CVS zips but was convinced that this was, well,
lets just say, ummm, inelegant :-)

The Mandrake install is giving me similar library issues as is
the iMac. I tried getting the latest CVS of GCL but it still
doesn't build. How did you get the Mac build to succeed?

Dynamically adding extensions will mean that the lisp loader
will have to automatically find and link new system libraries.
That's quite a large task.

> The above will need to find a saved_gcl, no? (I'll fix the FreeBSD port
> to add this to the installed bits if so).

The above essentially copies saved_gcl to obj/linux/bin/lisp.
In some hopeful future you should just be able to find the lisp
on the path.

> The FreeBSD port infrastructure takes care of the details, like installing
> GCL if its not already there.

Can you point me to the docs on this? How does this magic happen?

> Did you get his long email

Yes, this morning. (Last night was my anniversary so I was kinda 
lame about reading email). I'll study it in more detail.

\start
Date: Wed, 1 Oct 2003 19:00:34 +0200
From: Juergen Weiss
To: David Mentre
Subject: RE: Fix for Macroexpansion bug

Thanks for adding the patch.

I compiled all the algebra files a while ago. The problem
had been the out-of-date database files. It's not related
to the macroexpansion problem. I posted the
results to the list at that time 
(http://www.uni-mainz.de/~weiss/axiom.algebra.jw.20030810.tgz).

> Hello Juergen,
> 
> Juergen Weiss writes:
> 
> > here is a fix for the macro expansion bug. As a test I
> > recompiled the complete algebra without any change in generated
> > lisp code.
> 
> Thanks Juergen.
> 
> I think I have added your patch to the corresponding bug in the
> database:
> [bug #4871] left hand side macro expansion issue (was: Compiling spad
> file causes value stack overflow)
> http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4871&gr
oup_id=2938

Have you tried to compile the remaining algebra files?

\section{Broken Files}
These files need to be added.
\begin{verbatim}

limitps    SIGNEF
primelt    FSPRMELT
nsregset   LAZM3PK
nregset    NORMPK
regset     QCMPACK
regset     REGSET
regset     RSETGCD
sregset    SREGSET
sregset    SRDCMPK
sregset    SFRGCD
sregset    SFQCMPK
transsolve SOLVETRA
asp        ASP29
d01agents  D01AGNT
nsregset   SNTSCAT
nregset    NTSCAT
sregset    SFRTCAT
algcat     CPIMA
combfunc   COMBF
ffnb       INBFF
lodo       LODO
lodo       LODO1
lodo       LODO2
newpoint   SUBSPACE
sttf       STTF
zerodim    LEXTRIPK
zerodim    IRURPK
zerodim    RGCHAIN
zerodim    RURPK
zerodim    ZDSOLVE
\end{verbatim}

\start
Date: Wed, 01 Oct 2003 15:29:26 +0100
From: Mark Murray
To: Tim Daly
Subject: Re: [Gcl-devel] Re: New design for Axiom web site 
Cc: Camm Maguire, Cliff Yapp

Tim Daly writes:

> Dynamically adding extensions will mean that the lisp loader will have
> to automatically find and link new system libraries.  That's quite a
> large task.

Not really. If you add functionality to a C program by using dlopen(3),
the ELF loader takes charge of loading any shared libs required by that
shared object. Can lisp not handle this?

> > The above will need to find a saved_gcl, no? (I'll fix the FreeBSD
> > port to add this to the installed bits if so).
>
> The above essentially copies saved_gcl to obj/linux/bin/lisp.  In some
> hopeful future you should just be able to find the lisp on the path.

Right. Usually, saved_gcl is not installed, so for the time being, I'll
make sure that FreeBSD has one.

> > The FreeBSD port infrastructure takes care of the details, like
> > installing GCL if its not already there.
>
> Can you point me to the docs on this? How does this magic happen?

Docs. Hmm :-). There is rather a lot.

Paraphrasing - there is a makefile wrapper, and a collection of diffs.
Building a port can be broken down into a set of steps:

1) "make fetch" - fetch(1) (like wget(1)) the port distfile(s) from the
nominated master site/mirrors. Cache this in /usr/ports/distfiles.

2) "make checksum" - use md5(1) to make sure you have the right
distribution file(s).

3) "make extract" - unpack the distribution files into a dir called
work/. This may depend on installing required archival software if
the dist file is in an unusual format. The dependancy is handled
automatically. The dependancy requirements are supplied in the wrapper
makefile.

4) "make patch" - apply any patches (local or distributor supplied) to
the unpacked distro.

5) "make configure" - run any necessary configure commands. This may
depend on installing required configuration software (such as automake
or autoconf). The dependancy is handled automatically. The dependancy
requirements are supplied in the wrapper makefile.

6) "make build" - actually build/compile the software. This may
depend on installing required software (libraries, specialised
compilers, etc). The dependancy is handled automatically. The dependancy
requirements are supplied in the wrapper makefile.

7) "make install" - install the software into ${PREFIX} (usually
/usr/local), and register it into /var/db/pkg/<portname>. This may
depend on installing run-time software (data files etc). The dependancy
is handled automatically. The dependancy requirements are supplied in
the wrapper makefile.

8) "make package" - make a binary distribution "package". This is
similar to a .rpm file or a .deb file, and contains meta-information on
what packages this package depends on. The binary package (a compressed
tarball with extra stuff) can be installed on another system with
pkg_add(1). Stash the package in /usr/ports/packages/.

9) "make clean" - rm -rf the work/ subdir created in 1).

Each recursive dependancy install does 1-7, if needed. Sophisicated
tools are available to maintain ports, packages and dependancies.

If the port creator did his job properly, then for anyone to build
the package is a no-brainer.

The usual short-circuit of the above is

$ cd /usr/ports/math/axiom	# or whatever port you want
$ make install			# $ does 1-7 automagically
$ make clean			# we don't need to make a package if
				#   we are a single-user site

... or pkg_add the package of your distribution CD.

> > Did you get his long email
>
> Yes, this morning. (Last night was my anniversary so I was kinda lame
> about reading email). I'll study it in more detail.

Anniversary? Congratulations!! :-) All the best!

\start
Date: Wed, 1 Oct 2003 14:49:51 -0400 
From: Bill Page
To: David Mentre
Subject: RE: Fix for Macroexpansion bug

David,

As Juergen says there does not seem to be any problem
with the remaining algebra files. It is just that Tim's
version of the algebra Makefile does not yet include
them. For now they can be compiled manually (or you can
use Juergen's version of the algebra Makefile).

> Thanks for adding the patch.
> 
> I compiled all the algebra files a while ago. The problem
> had been the out-of-date database files. It's not related
> to the macroexpansion problem. I posted the
> results to the list at that time 
> (http://www.uni-mainz.de/~weiss/axiom.algebra.jw.20030810.tgz).
> 
> > Juergen Weiss writes:
> > 
> > > here is a fix for the macro expansion bug. As a test I
> > > recompiled the complete algebra without any change in generated
> > > lisp code.
> > 
> > Thanks Juergen.
> > 
> > I think I have added your patch to the corresponding bug in the
> > database:
> > [bug #4871] left hand side macro expansion issue (was: 
> Compiling spad
> > file causes value stack overflow)
> > http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4871&gr
> oup_id=2938
> 
> Have you tried to compile the remaining algebra files?
> 
> \section{Broken Files}
> These files need to be added.
> \begin{verbatim}
> 
> limitps    SIGNEF
> primelt    FSPRMELT
> nsregset   LAZM3PK
> nregset    NORMPK
> regset     QCMPACK
> regset     REGSET
> regset     RSETGCD
> sregset    SREGSET
> sregset    SRDCMPK
> sregset    SFRGCD
> sregset    SFQCMPK
> transsolve SOLVETRA
> asp        ASP29
> d01agents  D01AGNT
> nsregset   SNTSCAT
> nregset    NTSCAT
> sregset    SFRTCAT
> algcat     CPIMA
> combfunc   COMBF
> ffnb       INBFF
> lodo       LODO
> lodo       LODO1
> lodo       LODO2
> newpoint   SUBSPACE
> sttf       STTF
> zerodim    LEXTRIPK
> zerodim    IRURPK
> zerodim    RGCHAIN
> zerodim    RURPK
> zerodim    ZDSOLVE
> \end{verbatim}
> 
\start
Date: Wed, 01 Oct 2003 23:14:58 +0200
From: David Mentre
To: list
Subject: Axiom short term roadmap

Hello,

I have started to list tasks that need to be done for a first stable
release of Axiom. You'll find them at:

http://savannah.nongnu.org/pm/task.php?group_project_id=1222&group_id=2938&func=browse

The proposed list is a first start. Of course, everybody is free to add
or remove tasks.

The main idea I had doing this is to keep us on focus for some short
term goals that I think are a prerequisite for the future (community and
Tim's vision on Axiom). Having a stable release will help us setting a
reference point for ports and enhancements.

Some remaining tasks I'm hesitating to put as target for this initial
release:
 
 - external gcl

 - various ports (MacOS X, FreeBSD, Windows, ...)


I think I'll add a mid-term goal (all ports, hyperdvi browser, graphics,
...) and a long term goal (Axiom Journal, Proof Assistant Integration,
zero learning curve interface, ...).


Yours,
d.

PS : I hope I am clear on my intent. The purpose of this email is not to
     say that Camm, Jaap or Mark work is not useful.
-- 

\start
Date: Wed, 1 Oct 2003 13:44:56 -0400
From: Tim Daly
To: Mike Dewar, Bill Page
Subject: Scanned image of book

Mike,

Does NAG own the copyright to the Axiom book?
I know the words were released under the Modified BSD.
Bill Page has offered to upload a scanned image of the book
for use while the new one is being written.
Will NAG allow that?

\start
Date: Wed, 01 Oct 2003 13:42:45 +0100
From: Mark Murray
To: Tim Daly
Subject: Re: [Gcl-devel] Re: New design for Axiom web site 
Cc: Camm Maguire, Cliff Yapp

Tim Daly writes:
> You make a very convincing case. The key concern, it appears, is forking.
> The hope is to migrate changes back into the common lisp. Unless all of
> the common lisps agree on a socket standard I don't see how this can happen
> but I am willing to try.

:-) Whoever said the art of dialogue was dead, was wrong! :-)

Having some kind of useful mechanism of adding extensions seems to be
a focal point?

If lisp compilers all had some way that you could add external functionality
/a la/ dlopen(3), then would this not solve the problem?

> It might be the case that every modern common lisp DOES have socket code
> and that the socket support could be rewritten (with #+ for each lisp).

That would be the best scenario.

> In Axiom if you want to use an installed gcl instead of the tar file you just:
> 
> cd lsp
> ln -s (yourGCLdistributionPath)/gcl-2.17.1 gcl-2.17.1
> touch gcldir
> cd ..
> make GCLVERSION=gcl-2.17.1
> 
> The symbolic link will use the already installed sources.
> The "touch" will convince Axiom that it does not need to build the lisp again.
> The GCLVERSION variable says what version you want to use.

The above will need to find a saved_gcl, no? (I'll fix the FreeBSD port
to add this to the installed bits if so).

> I'll add these instructions to the FAQ in Makefile.pamphlet.

Excellent!

> We could make this the default install instructions, I suppose, but
> that shifts the burden of building onto the end user whereas it
> currently resides in the makefile. If the installed sources were
> installed as root then the user will have to install as root which is
> currently unnecessary (one should never work as root :-) ) I'll break
> out the "patching" portion of the stanza so it can be executed against
> pre-installed sources.

As an alternative install method, it suits FreeBSD very well, as all
a FreeBSD'er needs to do to build it would be

# cd /usr/ports/math/axiom
# make
# make install
# make clean

or, even easier

# portinstall math/axiom

The FreeBSD port infrastructure takes care of the details, like installing
GCL if its not already there.

> If you move to a new, untested version of GCL, the build is likely to
> fail late into the Axiom build because lisp won't contain the Axiom
> extensions.
> 
> About Camm's suggestion: I didn't understand the suggestion (and still don't).
> I feel like I "missed a memo" on that one. 

Did you get his long email

Subject: Re: confusion over patch suggestion

\start
Date: Wed, 01 Oct 2003 22:45:45 +0200
From: David Mentre
To: Bill Page
Subject: Re: Axiom book (partially) available?

Hello Bill,

Bill Page writes:

> I have the resources to produce a scanned PDF format
> copy of the AXIOM book. 

Beware of copyright issues. While Tim has the source of the text of the
book and the rights to produce a new version, the layout of the original
book is still copyrighted by its publisher.

I don't remember the duration of copyright until it falls in the public
domain but I doubt the copyright on the original Axiom book is expired.

In short: you can't do that except if you have the written consent of
the publisher.

Yours,
d.

PS : According to the Gutenberg project, the copyright duration is 50
     years after the death of the author. There is no such thing as a
     free world.

\start
Date: Wed, 1 Oct 2003 20:54:33 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: Missing algebra

Juergen,

Time, mostly. The algebra files reference interval. I got interval to
compile and now have to finish the cleanup task. I'm working on that
in my local build subtree but haven't completed or tested it. Other
tasks are being pushed ahead of it (I uploaded a fix for "algebra
sources in mnt" on monday, (tuesday was an anniversary so I slacked a
bit).  I'm currently cleaning up the "makes" in Makefiles and writing
a FAQ entry for the "installed lisp" issue.  Next I will apply the
Macro patch you sent and set up a build/test/release cycle overnight)
but progress is being made. It should happen RSN (real soon now), that
is, once I do the next cleanup of my subtree, test it, polish it for
upload, and upload it. I haven't forgotten it. Indeed, the main reason
I wanted David to leave it as a bug was that I wanted to have a record
that it is still an outstanding issue.

Tim

\start
Date: Wed, 1 Oct 2003 17:01:01 -0400 
From: Bill Page
To: David Mentre
Subject: RE: Axiom book (partially) available?

David,

Yes, I am very much aware of the copyright issue since
that is directly related to the work I do (electronic
publishing and databases for defence). NAG is named in
the front piece of the book as the holder of the copyright -
odd perhaps, since often it is the publisher, Spriner-Verlag.
I look forward to receiving approval from NAG to make a
scanned version of the book available online.

In the mean time, it seems to me that the usual "fair use"
practices would permit me to at least distribute some
parts (how much??) of the book to members of the Axiom
developer and user groups. After all this is (largely) a
research project.

Perhaps there is not yet such a thing as a "free world",
but I am optimistic that it is getting "freer" (as in
freedom, not free beer ... <grin> )

> Bill Page writes:
> 
> > I have the resources to produce a scanned PDF format
> > copy of the AXIOM book. 
> 
> Beware of copyright issues. While Tim has the source of the 
> text of the book and the rights to produce a new version,
> the layout of the original book is still copyrighted by its
> publisher.
> 
> I don't remember the duration of copyright until it falls in 
> the public domain but I doubt the copyright on the original
> Axiom book is expired.
> 
> In short: you can't do that except if you have the written
> consent of the publisher.
> 
> Yours,
> d.
> 
> PS : According to the Gutenberg project, the copyright
>      duration is 50 years after the death of the author.
>      There is no such thing as a free world.

\start
Date: Wed, 1 Oct 2003 12:01:43 -0400 
From: Bill Page
To: list
Subject: RE: [Texmacs-dev] New tm_axiom.c & question on stderr

TeXmacs Developers;

I have posted a new version of tm_axiom to the Axiom
web site. See Axiom_Texmacs 1.0.2 at

    http://savannah.nongnu.org/files/?group=axiom

This version is compatible with the recent alpha release
of Axiom/OS (i.e. Axiom / Open Source. We need an
appropriate name for this new version of Axiom. What do
you think?). It expects only one initial prompt from
Axiom, not two like the older version of Axiom. It also
incorporates the sophisticated LaTeX equation line breaking
algorithm that was developed specifically for use with
Axiom by Robert Sutor (a major contributor to Axiom).

I have two questions. First, I would like to be able to
pass some command line options to the tm_axiom program
when it is started by TeXmacs. Specifically, for compatiblity
with the older version of Axiom, it would be nice to be
able to adjust the number of intial prompts, for example
by setting it to 2 for the NAG commercial version. Another
option might be setting the line break length. Right now
the value of 4.5 inches is hard coded.

Assuming I can pass these options, the next issue is how
to conveniently set them inside of TeXmacs. The number
of initial prompts only needs to be set when the Axiom
interface is installed or changed. But the line break
length should be easily adjusted by the user and must
relate to a parameter already maintained automatically by
TeXmacs and stored with each document.

The second question I have is: What is the best approach
to implement a new Session menu option that would
re-execute all of the sessions contained in a document?
This is a very common operation when using TeXmacs as
a "worksheet" interface to computer algebra systems. It
needs to be able to re-execute all of the embedded
session commands (for Axiom and other external systems)
starting from the top of the document and working down
to the end. It must make only the minimum change to the
document to update all of the session outputs without
introducing any new session inputs.

Should I try to do this through a scheme script? (Oh no,
more stuff to learn ... <sigh>).

Any help and/or suggestions would be greatly appreciated!

> > > OK, I will try that soon.
> >
> > Tim reminded me that this build may not work on any kind of 
> > linux. Mine is debian 3.0 i686.
> >
> > In any case, we will try to upload several builds on different
> > system. What is your linux system (distribution, version)?
> 
> I will ask tomorrow; I am abroad...
> 

\start
Date: Wed, 1 Oct 2003 13:57:20 -0400 
From: Bill Page
To: Tim Daly
Subject: RE: Axiom book (partially) available?

Tim,

I have the resources to produce a scanned PDF format
copy of the AXIOM book. The result will be a rather
large file (approx. 10 - 20 Mbytes, I guess). In scanned
PDF format, each page is represented as an image. The
system I use normally uses Group IV tiff encoding for
black and white pages, so the result is about 20 Kbytes
per page x 750 pages. Maybe I could set it up for download
as one file per chapter (15 chapters) - about 1 Mbyte
per chapter.

I think that inspite of it's "age" the quality of this
book is very high and would go a long way to satisfying
the demand! for Axiom documentation that releasing the
alpha version has created. Of course this doesn't negate
the desirability of creating (and publishing!) a newer
up to date version. But maybe it would take some of the
pressure off ...

Let me know what you think. I could have it uploaded to
the files section of the Axiom web site later tonight
if you think that this would be ok.

> Hello Tim,
> 
> Is the Axiom book available (even partially) on CVS? Maybe people can
> start reading the first chapters while you finish it?
> 
> Yours,
> d.

\start
Date: Thu, 2 Oct 2003 02:31:03 +0200
From: Juergen Weiss
To: David Mentre
Subject: RE: Missing algebra

Tim,

what's wrong with those algebra files? I could compile
them with no changes.

> The missing algebra is not "fixed" yet. The problem is 
> slightly more subtle. 

\start
Date: Wed, 01 Oct 2003 19:34:16 +0200
From: David Mentre
To: Juergen Weiss
Subject: Re: Fix for Macroexpansion bug

Juergen Weiss writes:

> I compiled all the algebra files a while ago. The problem
> had been the out-of-date database files. It's not related
> to the macroexpansion problem. I posted the
> results to the list at that time 
> (http://www.uni-mainz.de/~weiss/axiom.algebra.jw.20030810.tgz).

Once again, thanks.

I have updated [bug #5379] Missing algebra (was: package
CombinatorialFunction (COMBF) is missing).
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5379&group_id=2938

\start
Date: Wed, 1 Oct 2003 20:08:53 +0200
From: Juergen Weiss
To: Mark Murray
Subject: RE: [Gcl-devel] Re: New design for Axiom web site 
Cc: Camm Maguire, Cliff Yapp

I would also argue in favor of unbundling the lisp system
(gcl). It's not a problem to load compiled C code (for 
example socket extensions) into a lisp system (Camm already
posted the code). It bloats the Axiom distribution
unnecessarily. Eventually we had to add CMU distributions
and others. For commercial lisps on the other hand we
can't do it. The Debian and the FreeBSD package system
take care of dependencies. So it was certainly necessary
to add gcl in the beginning to get started on equal level.
With the necessary fixes/patches applied to gcl it will
not be necessary with the future.

With respect to the build system: Generating the lisp
part of Axiom is not very demanding with respect to
the build system. But as soon as the graphics and
dispatcher and other C code comes in, we will probably
need autoconfig and/or configure on the long run. We 
have to figure out, where X resides, if signal handling
is BSD or SYSV etc. But that's not very pressing at 
the moment.

What we should change immediately is, that the make
variables are not handed down from the toplevel make
step by step. The variables (ENV) should be in a
Makefile.inc, which will get included by every make
file. This will allow to call make in src/interp
or src/algebra selectively during development.

> 
> Tim Daly writes:
> > I don't understand why it is important to use an already installed
> > lisp image.  It seems likely to be yet-another-source-of-trouble
> > like the X library issues. What am I missing?
> 
> The already-installed lisp versions (may) have been hacked to
> actually work, and they may be standard didtributions of the lisp
> compiler distributed by the OS vendor (.rpm, .deb or FreeBSD "port"
> files).
> 
> The Axiom copy of lisp is a fork, and an incompatible one to boot,
> so us OS people (well, me anyway - I'm with FreeBSD) are trying to
> use the one that we already have to get things to work.
> 
> After all, when you get (say) X, it doesn't come bundled with the
> version of GCC that the XFree86 folks have certified that it will
> compile with, right? Instead, over time #ifdef hell has developed,
> and configuration stuff has been done to make sure that whatever
> package it is has been put together to work with whatever you already
> have, as far as practical. Sometimes, of course you have to bail out
> and say things like "This needs an ANSI C compiler, K&R won't work,
> ever!", but bolting every tool that is needed onto the side of the
> package concerned is overkill IMO.
> 
> I hear what you say about the extensions, and I understand why you
> need them; are Camm's proposals not suitable?
> 
> That's the way I'm thinking :-)

\start
Date: Thu, 2 Oct 2003 10:21:09 +0200
From: Juergen Weiss
To: Tim Daly
Subject: RE: Missing algebra

Sorry, I missunderstood your email. I thought, that there
were still other problems.

> Juergen,
> 
> Time, mostly. The algebra files reference interval. I got interval to
> compile and now have to finish the cleanup task. I'm working on that
> in my local build subtree but haven't completed or tested it. Other
> tasks are being pushed ahead of it (I uploaded a fix for "algebra
> sources in mnt" on monday, (tuesday was an anniversary so I slacked a
> bit).  I'm currently cleaning up the "makes" in Makefiles and writing
> a FAQ entry for the "installed lisp" issue.  Next I will apply the
> Macro patch you sent and set up a build/test/release cycle overnight)
> but progress is being made. It should happen RSN (real soon now), that
> is, once I do the next cleanup of my subtree, test it, polish it for
> upload, and upload it. I haven't forgotten it. Indeed, the main reason
> I wanted David to leave it as a bug was that I wanted to have a record
> that it is still an outstanding issue.

\start
Date: Thu, 2 Oct 2003 10:12:16 +0100
From: Mike Dewar
To: Bill Page
Subject: re: [Texmacs-dev] New tm_axiom.c & question on stderr

Hi Bill,

There seems to be a misconception that the NAG version of Axiom puts out
two prompts on startup while the Open version puts out one.  This is not
actually true: the Axiom interpreter (invoked via the command `AXIOMsys'
in the NAG version, and presumably via `axiom' in your version) only
puts out one prompt: the reason you can see two is that sman (the
"Superman" process that manages communication between the interpreter,
hyperdoc, browser, graphics etc.) causes the interpreter to start a new
frame, which forces a new prompt (you can do the same by typing ")frame
new foo").  Once Tim gets sman working the Open version will presumably
work in the same way.  So your new tm_axiom ought to work the same way
with both versions if they are invoked in the equivalent way.

I haven't seen the TeXmacs interface to Axiom but we used to maintain a
TeX-based interface under Windows (based on IBM's TechExplorer) and it
had lots of nice features - a TeX version of the browser, the ability to
execute worksheets etc.  Some of this code was embedded in the front-end
but the browser code, for example, was all in boot.  The main file in
question was br-saturn.boot ("saturn" was IBM's pre-release name for
TechExplorer) and we also used the $saturn variable to test whether we
were in TechExplorer or not in a few places (this was so we could use
the same CCL image files for both the TechExplorer and shell interfaces
of Axiom under Windows).  It might be worth somebody trying to resurrect
this code - the only hitch I can foresee is that we added a grep command
to CCL (coded in C) since Windows doesn't have a grep program, but you
can always spawn off a system command under Unix (which is what the
original IBM version of Axiom did) to get the same result.

Mike.

On Wed, Oct 01, 2003 at 12:01:43PM -0400, Page, Bill wrote:
> TeXmacs Developers;
> 
> I have posted a new version of tm_axiom to the Axiom
> web site. See Axiom_Texmacs 1.0.2 at
> 
>     http://savannah.nongnu.org/files/?group=axiom
> 
> This version is compatible with the recent alpha release
> of Axiom/OS (i.e. Axiom / Open Source. We need an
> appropriate name for this new version of Axiom. What do
> you think?). It expects only one initial prompt from
> Axiom, not two like the older version of Axiom. It also
> incorporates the sophisticated LaTeX equation line breaking
> algorithm that was developed specifically for use with
> Axiom by Robert Sutor (a major contributor to Axiom).
> 
> I have two questions. First, I would like to be able to
> pass some command line options to the tm_axiom program
> when it is started by TeXmacs. Specifically, for compatiblity
> with the older version of Axiom, it would be nice to be
> able to adjust the number of intial prompts, for example
> by setting it to 2 for the NAG commercial version. Another
> option might be setting the line break length. Right now
> the value of 4.5 inches is hard coded.
> 
> Assuming I can pass these options, the next issue is how
> to conveniently set them inside of TeXmacs. The number
> of initial prompts only needs to be set when the Axiom
> interface is installed or changed. But the line break
> length should be easily adjusted by the user and must
> relate to a parameter already maintained automatically by
> TeXmacs and stored with each document.
> 
> The second question I have is: What is the best approach
> to implement a new Session menu option that would
> re-execute all of the sessions contained in a document?
> This is a very common operation when using TeXmacs as
> a "worksheet" interface to computer algebra systems. It
> needs to be able to re-execute all of the embedded
> session commands (for Axiom and other external systems)
> starting from the top of the document and working down
> to the end. It must make only the minimum change to the
> document to update all of the session outputs without
> introducing any new session inputs.
> 
> Should I try to do this through a scheme script? (Oh no,
> more stuff to learn ... <sigh>).
> 
> Any help and/or suggestions would be greatly appreciated!
> 
> > > > OK, I will try that soon.
> > >
> > > Tim reminded me that this build may not work on any kind of 
> > > linux. Mine is debian 3.0 i686.
> > >
> > > In any case, we will try to upload several builds on different
> > > system. What is your linux system (distribution, version)?
> > 
> > I will ask tomorrow; I am abroad...

\start
Date: Thu, 2 Oct 2003 10:31:23 +0100
From: Mike Dewar
To: axiom@tenkan.org
Subject: Re: Scanned image of book
Cc: Bill Page

Tim,

We own the copyright but there is also a question of Springer's rights
to the printed version.  I'm no lawyer but it appears that the book is
still in print in the US so you could be treading on thin ice by
publishing a scanned version on the web.  My advice would be not to do
it.

In any case it seems crazy to go down this route when you could just
make a pdf from the (more up-to-date than published) TeX sources that
you have.  In principle all that you need to do is go to the
development/src/doc/htex directory and run `latex book', however the
version of LaTeX that you really need is a 12 year old IBM installation
so you will have some font and style file issues I'm afraid. There are
some fonts in the doc/dvips directory which may help.

On Wed, Oct 01, 2003 at 01:44:56PM -0400, Tim Daly wrote:
> Mike,
> 
> Does NAG own the copyright to the Axiom book?
> I know the words were released under the Modified BSD.
> Bill Page has offered to upload a scanned image of the book
> for use while the new one is being written.
> Will NAG allow that?
> 
Date: Thu, 2 Oct 2003 07:27:55 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: [Gcl-devel] Re: New design for Axiom web site
Cc: Camm Maguire, Mark Murray, Cliff Yapp

I'll look at this question later today.


> What we should change immediately is, that the make
> variables are not handed down from the toplevel make
> step by step. The variables (ENV) should be in a
> Makefile.inc, which will get included by every make
> file. This will allow to call make in src/interp
> or src/algebra selectively during development.

\start
Date: Thu, 2 Oct 2003 09:14:09 -0400
From: Tim Daly
To: Camm Maguire
Subject: Aurelian

7) Has Aurelian been in touch with you?

Who is Aurelian?

\start
Date: Thu, 2 Oct 2003 09:08:44 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: [Juergen Weiss: RE: [Gcl-devel] Re: New design for Axiom web site]

Juergen,

I looked at the idea of including the ENV information directly into
the lower level Makefiles rather than passing it down the make chain.
The problem is that the make chain sets up more than just the shell
variable environment. The parent makefile ensures that the required
target directories exist and that all other subdirectories are up 
to date. If you try to invoke make in a subdirectory the results are
uncertain.

If you want to try this you could, though I don't recommend, put the
ENV variables in your shell and then invoke make. According to plan
the use of {} around the variables allows them to be overridden by
shell variables.

I have a scheme with will allow you to type:
make PART=algebra
(where algebra is any one of the subdirectories).
This will force the make chain to walk the direct
path to the named subdirectory. This should achieve what you want.
I'll put it on the TODO list.

\start
Date: Thu, 02 Oct 2003 18:46:33 +0200
From: David Mentre
To: Tim Daly
Subject: Re: Aurelian
Cc: Camm Maguire

Hello Tim,

Tim Daly writes:

> 7) Has Aurelian been in touch with you?
>
> Who is Aurelian?

Aurelien Chanudet, the guy who is porting GCL to
MacOS X.

\start
Date: Thu, 2 Oct 2003 19:23:24 +0200
From: Michel Lavaud
To: David Mentre
Subject: Re: Axiom short term roadmap

Hello,
 
> I have started to list tasks that need to be done for a first stable
> release of Axiom. You'll find them at:
> Some remaining tasks I'm hesitating to put as target for this initial
> release:
>  
>  - external gcl
> 
>  - various ports (MacOS X, FreeBSD, Windows, ...)

To extend the basis of users, I think Windows port would be urgent. I 
probably misunderstood some messages, I thought it was almost done? What 
is the present state of the port, and what are the remaining problems?


\start
Date: Thu, 2 Oct 2003 12:54:14 -0400
From: Tim Daly
To: David Mentre
Subject: kudos

Please add Mark Murray to the website kudos list.

\start
Date: Thu, 2 Oct 2003 12:54:52 -0400
From: Tim Daly
To: list
Subject: kudos

Could someone volunteer to tar up the latest CVS as a source tarball
and post it on the download page?

\start
Date: Thu, 2 Oct 2003 13:04:57 -0400
From: Tim Daly
To: Michel Lavaud
Subject: windows

On my desk, at least, the windows port is stalled waiting a running GCL
under mingw. This probably exists but I don't have it yet.

A similar pipeline burble exists with the iMac port. Camm has suggested
downloading Version_2_6_1 which I plan to do later this afternoon.

The Mandrake port is hanging on a missing shared library.

The SuSE port is hanging on an installation hitch. Plus my SuSE version
is 6.4 due to the fact that I can't find iso images online and I can't
connect the machine to the net for a network install.

The BSD port is awaiting the result of Mark Murray's work as I'm
letting him do the heavy lifting there.

And the SCO Unixware port is waiting until the weather in hell
rivals that in heaven.

\start
Date: Thu, 2 Oct 2003 14:03:43 -0400
From: Tim Daly
To: Camm Maguire
Subject: GCL for iMac

Ok, I did a co -r Version_2_6_1
What machine is the iMac OS X supposed to be?
The configure script didn't figure it out.

\start
Date: 02 Oct 2003 16:08:09 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] GCL for iMac
Cc: Aurelien Chanudet

Hi Tim!

First I'm told you need to configure with

./configure --enable-debug --enable-machine=powerpc-macosx
--disable-statsysbfd --enable-custreloc

I haven't yet merged in a few of Aurelian's proposed patches, hope too
soon -- here is his last email on the subject.  Please let me know how
it goes.  I'll add configure defaults for this platform if it works
for you.  Over the long run, we'd rather link with statsysbfd.

=============================================================================
Hi,

You might want to try the following steps to build GCL on Mac OS
X. Note that this port is premature and that I haven't tested it with
Axiom. Stratified garbage collection is not yet fully supported (need
to retrieve the page fault address).

Please, keep me posted on how this goes !

Aurelien

---

1- Get the latest CVS release (2.7.0).

2- Assuming bash, configure your shell as follows :

ulimit -n 512

if [ -z "$LIBRARY_PATH" ]; then
    export LIBRARY_PATH=/sw/lib
else
    export LIBRARY_PATH=/sw/lib:$LIBRARY_PATH
fi
export LIBRARY_PATH

if [ -z "$C_INCLUDE_PATH" ]; then
     C_INCLUDE_PATH=/sw/include
else
     C_INCLUDE_PATH=/sw/include:$C_INCLUDE_PATH
fi
export C_INCLUDE_PATH

export CPPFLAGS="-no-cpp-precomp"

The /sw tricks are used to enable readline support (/sw is Fink's root).

3- Apply the following patches :

--- o/main.c      4 Sep 2003 03:09:39 -0000       1.30
+++ o/main.c      4 Sep 2003 21:52:28 -0000
@@ -111,6 +111,11 @@
      struct rlimit rl;
  #endif

+#if defined(DARWIN)
+        extern void init_darwin_zone_compat ();
+        init_darwin_zone_compat ();
+#endif
+
  #ifdef RECREATE_HEAP
      RECREATE_HEAP
  #endif

--- o/unixfasl.c  15 Feb 2003 00:38:28 -0000      1.4
+++ o/unixfasl.c  4 Sep 2003 21:53:16 -0000
@@ -282,7 +282,7 @@
  static int
  faslink(object faslfile, object ldargstring)
  {
-#if defined(__linux__) && defined(__ELF__)
+#if (defined(__linux__) && defined(__ELF__)) || defined(DARWIN)
    FEerror("faslink() not supported for ELF yet",0);
    return 0;
  #else

--- unixport/makefile    4 Sep 2003 03:09:39 -0000       1.45
+++ unixport/makefile    4 Sep 2003 21:54:00 -0000
@@ -17,6 +17,7 @@

  libgclp.a: $(ODIR)/gcllib.a
         cp $< $@
+       ranlib $@

  gmpfiles: $(shell find ../$(GMPDIR) -name "*.o" |grep -v '\.lib')
         rm -rf gmp
@@ -80,15 +81,15 @@
  init_%.lsp: init_%.lsp.tmp

         cat $< | sed \
-               -e "s,@LI-VERS@,(`cat ../majvers`.`cat ../minvers`)
`date`,1" \
-               -e "s,@LI-MINVERS@,`cat ../minvers`,1" \
-               -e "s,@LI-MAJVERS@,`cat ../majvers`,1" \
-               -e "s,@LI-CC@,\"$(CC) -c $(FINAL_CFLAGS)\",1" \
-               -e "s,@LI-LD@,\"$(CC) -o \",1" \
-               -e "s,@LI-LD-LIBS@,\"$(LD_LIBS_PRE) -l$*
$(LD_LIBS_POST)\",1" \
-               -e "s,@LI-OPT-THREE@,\"$(O3FLAGS)\",1" \
-               -e "s,@LI-OPT-TWO@,\"$(O2FLAGS)\",1" \
-               -e "s,@LI-INIT-LSP@,\"$@\",1" >$@
+               -e "s,@LI-VERS@,(`cat ../majvers`.`cat ../minvers`)
`date`," \
+               -e "s,@LI-MINVERS@,`cat ../minvers`," \
+               -e "s,@LI-MAJVERS@,`cat ../majvers`," \
+               -e "s,@LI-CC@,\"$(CC) -c $(FINAL_CFLAGS)\"," \
+               -e "s,@LI-LD@,\"$(CC) -o \"," \
+               -e "s,@LI-LD-LIBS@,\"$(LD_LIBS_PRE) -l$*
$(LD_LIBS_POST)\"," \
+               -e "s,@LI-OPT-THREE@,\"$(O3FLAGS)\"," \
+               -e "s,@LI-OPT-TWO@,\"$(O2FLAGS)\"," \
+               -e "s,@LI-INIT-LSP@,\"$@\"," >$@

  saved_%:raw_% $(RSYM) init_%.lsp \
                 $(CMPDIR)/cmpmain.lsp \
@@ -108,21 +109,21 @@

  libgcl.a: $(FIRST_FILE) $(OBJS) sys_gcl.o $(LAST_FILE) gmpfiles
bfdfiles
         rm -rf $@
-       ar rs $@ $(filter %.o,$^) $(shell find gmp bfd -name "*.o")
+       libtool -static -o $@ $(filter %.o,$^) $(shell find gmp bfd
-name "*.o")

  libxgcl.a: libgcl.a
         ln -snf $< $@

  libansi_gcl.a: $(FIRST_FILE) $(OBJS) $(ANSIOBJS) sys_ansi_gcl.o
$(LAST_FILE) gmpfiles bfdfiles
         rm -rf $@
-       ar rs $@ $(filter %.o,$^) $(shell find gmp bfd -name "*.o")
+       libtool -static -o $@ $(filter %.o,$^) $(shell find gmp bfd
-name "*.o")

  libpcl_gcl.a: $(FIRST_FILE) $(OBJS) $(PCLOBJS) sys_pcl_gcl.o
$(LAST_FILE) gmpfiles bfdfiles
         rm -rf $@
-       ar rs $@ $(filter %.o,$^) $(shell find gmp bfd -name "*.o")
+       libtool -static -o $@ $(filter %.o,$^) $(shell find gmp bfd
-name "*.o")

  raw_%: lib%.a libgclp.a $(SYSTEM_OBJS) $(EXTRAS)
-       $(CC) -o raw_$*$(EXE) $(filter %.o,$^) \
+       $(CC) -Wl,-headerpad,1f000 -o raw_$*$(EXE) $(filter %.o,$^) \
                 -L. $(EXTRA_LD_LIBS) $(LD_LIBS_PRE) -l$* $(LD_LIBS_POST)

  clean:

4- Configure with :

./configure --enable-debug --enable-machine=powerpc-macosx
--disable-statsysbfd --enable-custreloc

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

Tim Daly writes:

> Ok, I did a co -r Version_2_6_1
> What machine is the iMac OS X supposed to be?
> The configure script didn't figure it out.

\start
Date: 02 Oct 2003 16:33:28 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Aurelian

Hi Tim!  The Mac OS X GCL developer.  I think you wrote to him
earlier?  I cc'ed him on the imac email I sent you earlier today.
Please let me know if you need/want his address.

Take care,

Tim Daly writes:

> 7) Has Aurelian been in touch with you?
> 
> Who is Aurelian?

\start
Date: Thu, 2 Oct 2003 22:40:24 +0200
From: Juergen Weiss
To: list
Subject: hypertex viewer
Cc: Tim Daly

Would it be possible to use texmacs as an hypertexviewer?
It supports math, links.. 

\start
Date: 02 Oct 2003 23:45:41 +0200
From: Juergen Weiss
To: list, Tim Daly
Subject: Fix for case in filenames

The following patch preserves case in filenames during
the build process.

Index: util.lisp.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/util.lisp.pamphlet,v
retrieving revision 1.1
diff -c -r1.1 util.lisp.pamphlet
*** util.lisp.pamphlet	28 Aug 2003 14:23:40 -0000	1.1
--- util.lisp.pamphlet	2 Oct 2003 21:39:10 -0000
***************
*** 44,50 ****
  #+:AKCL
    (in-package "BOOT")
    (push :oldboot *features*)
!   (mapcar #'load-a-file load-files)
    (make-depsys lsp src int obj mnt sys)
    (initroot spad)
    #+:AKCL
--- 44,50 ----
  #+:AKCL
    (in-package "BOOT")
    (push :oldboot *features*)
!   (mapcar #'load load-files)
    (make-depsys lsp src int obj mnt sys)
    (initroot spad)
    #+:AKCL
***************
*** 131,137 ****
  		      :array 400 :string 500 :cfun 100 :cpages 1000
  		      :rpages 1000 :hole 2000)
    <<compiler-notes>>
!   (mapcar #'load-a-file load-files)
    (|resetWorkspaceVariables|)
    (|initHist|)
    (|initNewWorld|)
--- 131,137 ----
  		      :array 400 :string 500 :cfun 100 :cpages 1000
  		      :rpages 1000 :hole 2000)
    <<compiler-notes>>
!   (mapcar #'load load-files)
    (|resetWorkspaceVariables|)
    (|initHist|)
    (|initNewWorld|)
***************
*** 142,159 ****
  #+:CCL
    (resethashtables)
    (setq *load-verbose* nil)
!   (|setBootAutloadProperties| comp-functions (mapcar #'filename-downcase
! 						     comp-files))
!   (|setBootAutloadProperties| parse-functions (mapcar #'filename-downcase
! 						      parse-files))
!   (|setBootAutloadProperties| browse-functions (mapcar #'filename-downcase
! 						       browse-files))
!   (|setBootAutloadProperties| translate-functions (mapcar #'filename-downcase
! 						       translate-files))
!   (|setNAGBootAutloadProperties| nagbr-functions (mapcar #'filename-downcase
! 						       nagbr-files))
!   (|setBootAutloadProperties| asauto-functions (mapcar #'filename-downcase
! 						       asauto-files))
    (setf (symbol-function 'boot::|addConsDB|) #'identity)
    (resethashtables) ; the databases into core, then close the streams
   )
--- 142,153 ----
  #+:CCL
    (resethashtables)
    (setq *load-verbose* nil)
!   (|setBootAutloadProperties| comp-functions comp-files)
!   (|setBootAutloadProperties| parse-functions parse-files)
!   (|setBootAutloadProperties| browse-functions browse-files)
!   (|setBootAutloadProperties| translate-functions translate-files)
!   (|setNAGBootAutloadProperties| nagbr-functions nagbr-files)
!   (|setBootAutloadProperties| asauto-functions asauto-files)
    (setf (symbol-function 'boot::|addConsDB|) #'identity)
    (resethashtables) ; the databases into core, then close the streams
   )
Index: Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/Makefile.pamphlet,v
retrieving revision 1.3
diff -c -r1.3 Makefile.pamphlet
*** Makefile.pamphlet	5 Sep 2003 22:14:19 -0000	1.3
--- Makefile.pamphlet	2 Oct 2003 21:39:11 -0000
***************
*** 525,531 ****
  	@ echo '(load "${OUT}/nocompil")' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/util")' >> ${OUT}/makedep.lisp
  	@ echo '(in-package "BOOT")' >> ${OUT}/makedep.lisp
! 	@ echo '(build-depsys (quote (${DEP})) "${SPAD}" "${GCLDIR}" "${SRC}" "${INT}" "${OBJ}" "${MNT}" "${SYS}")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/postpar.${O}") (compile-file "${OUT}/postpar.${LISP}" :output-file "${OUT}/postpar.${O}"))' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/postpar")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/parse.${O}") (compile-file "${OUT}/parse.${LISP}" :output-file "${OUT}/parse.${O}"))' >> ${OUT}/makedep.lisp
--- 525,531 ----
  	@ echo '(load "${OUT}/nocompil")' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/util")' >> ${OUT}/makedep.lisp
  	@ echo '(in-package "BOOT")' >> ${OUT}/makedep.lisp
! 	@ echo '(build-depsys (quote ($(patsubst %, "%", ${DEP}))) "${SPAD}" "${GCLDIR}" "${SRC}" "${INT}" "${OBJ}" "${MNT}" "${SYS}")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/postpar.${O}") (compile-file "${OUT}/postpar.${LISP}" :output-file "${OUT}/postpar.${O}"))' >> ${OUT}/makedep.lisp
  	@ echo '(load "${OUT}/postpar")' >> ${OUT}/makedep.lisp
  	@ echo '(unless (probe-file "${OUT}/parse.${O}") (compile-file "${OUT}/parse.${LISP}" :output-file "${OUT}/parse.${O}"))' >> ${OUT}/makedep.lisp
***************
*** 599,605 ****
  	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> ${OUT}/makeint.lisp
! 	@ echo '(build-interpsys (append (quote (${OBJS})) (quote (${ASCOMP})) (quote (${INOBJS}))) (quote (${OPOBJS})) (quote (${OCOBJS})) (quote (${BROBJS})) (quote (${TRANOBJS})) (quote (${NAGBROBJS})) (quote (${ASAUTO}))  "${SPAD}"  "${LSP}" "${SRC}" "${INT}" "${OBJ}" "${MNT}" "${SYS}")' >> ${OUT}/makeint.lisp
  	@ echo '(in-package "SCRATCHPAD-COMPILER")' >> ${OUT}/makeint.lisp
  #	@ echo '(|shoeInternFile| "${MNT}/${SYS}/doc/msgs/co-eng.msgs")' >> ${OUT}/makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> ${OUT}/makeint.lisp
--- 599,605 ----
  	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> ${OUT}/makeint.lisp
! 	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${SPAD}"  "${LSP}" "${SRC}" "${INT}" "${OBJ}" "${MNT}" "${SYS}")' >> ${OUT}/makeint.lisp
  	@ echo '(in-package "SCRATCHPAD-COMPILER")' >> ${OUT}/makeint.lisp
  #	@ echo '(|shoeInternFile| "${MNT}/${SYS}/doc/msgs/co-eng.msgs")' >> ${OUT}/makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> ${OUT}/makeint.lisp

\start
Date: Thu, 2 Oct 2003 17:53:43 -0400
From: Bill Page
To: Weiss, Juergen
Subject: RE: hypertex viewer

Juergen,

My answer would be "yes, in principle".

TeXmacs is quite sophisticatd in the way it displays
mathematics and it has a fairly good facility to import
LaTeX files but it's internal file format is not based
on LaTeX. We would have to convert the existing files
to TeXmacs format and fix the links etc.

With the ability of TeXmacs to actually execute Axiom
commands and to serve as a "worksheet" interface to
Axiom, I think it would be a natural thing to have it
do the hypertex browsing as well.

I would be willing to try to convert some of the
existing files to TeXmacs format as an experiment.
Where can I get the files?

Cheers,
Bill Page.

> 
> Would it be possible to use texmacs as an hypertexviewer?
> It supports math, links.. 

\start
Date: Thu, 2 Oct 2003 15:07:57 -0700
From: Jaap Weel
To: list
Subject: Missing files in tarball

Using axiom-debian-3.0-linux-i386-cvs-2003-09-28.tar.gz

(1) -> )copyright
cat: /home/weel/axiom/mnt/linux/lib/copyright: No such file or directory
(1) -> )quit


This seems like a very minor problem that's purely there because the 
tarball had the lib/ directory removed entirely. Maybe the copyright 
file should go somewhere else?

\start
Date: Fri, 3 Oct 2003 10:06:07 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: windows

Hi Tim.

| On my desk, at least, the windows port is stalled waiting a running GCL
| under mingw. This probably exists but I don't have it yet.

A prebuilt 2.6.1 installer is at Camm's temp web site:

         http://people.debian.org/~camm/gcl/stable-binary/

\start
Date: Fri, 3 Oct 2003 00:59:40 -0400
From: "Bill Page" <Bill Page>
To: Mike Thomas
Subject: RE: windows

Mike,

When I tried the install of prebuild GCL 2.6.1 on my
Windows XP system I got the following DOS window and
error message:

-----------

GCL (GNU Common Lisp)  (2.6.1) Fri Sep 19 10:41:07 EAST 2003
Licensed under GNU Library General Public License
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

Error: Cannot create the file c:/lang/gcl261/bin/gcl.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LET.
Broken at OPEN.  Type :H for Help.
>>

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

This didn't happen in previous builds. Can I get
around this somehow?

> 
> Hi Tim.
> 
> | On my desk, at least, the windows port is stalled waiting a running 
> | GCL under mingw. This probably exists but I don't have it yet.
> 
> A prebuilt 2.6.1 installer is at Camm's temp web site:
> 
         http://people.debian.org/~camm/gcl/stable-binary/

\start
Date: Fri, 3 Oct 2003 15:20:43 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: windows

Hi Bill.

This is a classic example of why I shouldn't test an installer on my build
machine - there is a hard-wired path problem which I thought I had fixed,
but...

The workaround seems to be to set the install directory to

  c:/lang/gcl261/

at the start of the installer run, rather than accepting the default.

Sorry for the trouble,

Mike Thomas.


| Mike,
|
| When I tried the install of prebuild GCL 2.6.1 on my
| Windows XP system I got the following DOS window and
| error message:
|
| -----------
|
| GCL (GNU Common Lisp)  (2.6.1) Fri Sep 19 10:41:07 EAST 2003
| Licensed under GNU Library General Public License
| Dedicated to the memory of W. Schelter
|
| Use (help) to get some basic information on how to use GCL.
|
| Error: Cannot create the file c:/lang/gcl261/bin/gcl.
| Fast links are on: do (si::use-fast-links nil) for debugging
| Error signalled by LET.
| Broken at OPEN.  Type :H for Help.
| >>
|
| ------------
|
| This didn't happen in previous builds. Can I get
| around this somehow?
| >
| >
| > Hi Tim.
| >
| > | On my desk, at least, the windows port is stalled waiting a running
| > | GCL under mingw. This probably exists but I don't have it yet.
| >
| > A prebuilt 2.6.1 installer is at Camm's temp web site:
| >
|          http://people.debian.org/~camm/gcl/stable-binary/

\start
Date: Fri, 3 Oct 2003 01:24:32 -0400
From: Bill Page
To: Mike Thomas
Subject: RE: windows

Yes, that did it. Thanks!

> 
> The workaround seems to be to set the install directory to
> 
>   c:/lang/gcl261/
> 
> at the start of the installer run, rather than accepting the default.
> 

\start
Date: Fri, 3 Oct 2003 15:32:21 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: windows - newer package on it's way

Hi again.

| This is a classic example of why I shouldn't test an installer on my build
| machine - there is a hard-wired path problem which I thought I had fixed,
| but...

In fact I had fixed it, I just realised that I accidentally uploaded an
older archive.  The new one will hopefully make it onto Camm's site within a
day.  It will have the date stamp 20030929.

Until then, use that workaround anyway.

|
| The workaround seems to be to set the install directory to
|
|   c:/lang/gcl261/
|
| at the start of the installer run, rather than accepting the default.
|
| Sorry for the trouble,
|
| |
| | Mike,
| |
| | When I tried the install of prebuild GCL 2.6.1 on my
| | Windows XP system I got the following DOS window and
| | error message:
| |
| | -----------
| |
| | GCL (GNU Common Lisp)  (2.6.1) Fri Sep 19 10:41:07 EAST 2003
| | Licensed under GNU Library General Public License
| | Dedicated to the memory of W. Schelter
| |
| | Use (help) to get some basic information on how to use GCL.
| |
| | Error: Cannot create the file c:/lang/gcl261/bin/gcl.
| | Fast links are on: do (si::use-fast-links nil) for debugging
| | Error signalled by LET.
| | Broken at OPEN.  Type :H for Help.
| | >>
| |
| | ------------
| |
| | This didn't happen in previous builds. Can I get
| | around this somehow?
| |
| | > Hi Tim.
| | >
| | > | On my desk, at least, the windows port is stalled waiting a running
| | > | GCL under mingw. This probably exists but I don't have it yet.
| | >
| | > A prebuilt 2.6.1 installer is at Camm's temp web site:
| | >
| |          http://people.debian.org/~camm/gcl/stable-binary/

\start
Date: Fri, 03 Oct 2003 18:49:18 +0200
From: David Mentre
To: Tim Daly
Subject: Re: kudos

Tim Daly writes:

> Please add Mark Murray to the website kudos list.

done.

\start
Date: Fri, 03 Oct 2003 19:06:49 +0200
From: David Mentre
To: Juergen Weiss
Subject: Re: Fix for case in filenames

Juergen Weiss writes:

> The following patch preserves case in filenames during
> the build process.

I have added your patch to the bug database:
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5059&group_id=2938
[bug #5059] Axiom does not compile with upshifted characters in path

Could you next time use 'diff -Naur' to produce your patch? Unified diff
(-u option) is much easier to understand. Moreover, it is the prefered
form requested by our benevolent dictator (aka Tim).

\start
Date: Fri, 03 Oct 2003 18:58:31 +0200
From: David Mentre
To: Tim Daly
Subject: Re: windows

Hello Tim,

Tim Daly writes:

> The Mandrake port is hanging on a missing shared library.

Which library is missing?

> The SuSE port is hanging on an installation hitch. Plus my SuSE version
> is 6.4 due to the fact that I can't find iso images online and I can't
> connect the machine to the net for a network install.

SuSE doesn't play the free software game. I don't see why we should do
free work for them (except of course for ATWD[1]).

[1] ATWD: Axiom Total Word Domination

\start
Date: Fri, 03 Oct 2003 19:11:20 +0200
From: David Mentre
To: Jaap Weel
Subject: Re: Missing files in tarball

Jaap Weel writes:

> (1) -> )copyright
> cat: /home/weel/axiom/mnt/linux/lib/copyright: No such file or directory
> (1) -> )quit

I have added the bug to the database:
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4581&group_id=2938
[bug #4581] )summary and )copyright does not work

\start
Date: Fri, 03 Oct 2003 19:16:43 +0200
From: David Mentre
To: Tim Daly
Subject: Re: kudos

Hi Tim,

Tim Daly writes:

> Could someone volunteer to tar up the latest CVS as a source tarball
> and post it on the download page?

Done.

I notice you uploaded an ungzipped (despite its .tgz suffix) source tree
at the root of the download section.

I have gzipped, renamed and moved it into
axiom_cvs.pkg/cvs_2003-10-02/axiom-src-cvs-2003-10-02.tar.gz

It is now in the Axiom_cvs section.

\start
Date: Fri, 3 Oct 2003 14:52:17 -0400
From: Bill Page
To: Mike Dewar
Subject: [Texmacs-dev] New tm_axiom.c & question on stderr

Mike,

So if I understand you correctly, what TeXmacs really aught
to do is to invoke just the interpreter via AXIOMsys - not
the whole "Superman" thing. Right? This way, there will
always only be one prompt. The fact that TeXmacs used to
expect two prompts was an accident due to the fact that it
(incorrectly) invoked more that what is really required for
the TeXmacs-Axiom interface.

So, both the old and new versions of Axiom should be compatible
with the new version of the tm_axiom.c program *provided* we
agree to call the new Axiom interpreter by the name AXIOMsys.
We should reserve the name 'axiom' for the invoking Superman
when/if it becomes available in the new open source version.

So far I a very pleased with the combination of TeXmacs and
Axiom. I am so used to working with a Maple/Matematica style
"worksheet" interface, that play with the command line mode
of Axiom (or even Maple for that matter) just seems too awkward.
And of course TeXmacs has the advantage that it can simultaneously
interface with a large number of open source computer algebra
and related packages, include gnuplot, macsyma, R (statistics),
etc. and *also* Maple - all from one worksheet environment!

The Axiom tutorial tex files that you sent look promising
for conversion to TeXmacs format. I will spend a bit of time
on that over the next few days.

Thanks.

Bill Page.

> Hi Bill,
> 
> There seems to be a misconception that the NAG version of 
> Axiom puts out two prompts on startup while the Open version 
> puts out one.  This is not actually true: the Axiom 
> interpreter (invoked via the command `AXIOMsys' in the NAG 
> version, and presumably via `axiom' in your version) only 
> puts out one prompt: the reason you can see two is that sman 
> (the "Superman" process that manages communication between 
> the interpreter, hyperdoc, browser, graphics etc.) causes the 
> interpreter to start a new frame, which forces a new prompt 
> (you can do the same by typing ")frame new foo").  Once Tim 
> gets sman working the Open version will presumably work in 
> the same way.  So your new tm_axiom ought to work the same 
> way with both versions if they are invoked in the equivalent
> way.
> 
> I haven't seen the TeXmacs interface to Axiom but we used to 
> maintain a TeX-based interface under Windows (based on IBM's 
> TechExplorer) and it had lots of nice features - a TeX 
> version of the browser, the ability to execute worksheets 
> etc.  Some of this code was embedded in the front-end but the 
> browser code, for example, was all in boot.  The main file in 
> question was br-saturn.boot ("saturn" was IBM's pre-release name
> for TechExplorer) and we also used the $saturn variable to test 
> whether we were in TechExplorer or not in a few places (this 
> was so we could use the same CCL image files for both the 
> TechExplorer and shell interfaces of Axiom under Windows).  
> It might be worth somebody trying to resurrect this code - 
> the only hitch I can foresee is that we added a grep command 
> to CCL (coded in C) since Windows doesn't have a grep 
> program, but you can always spawn off a system command under 
> Unix (which is what the original IBM version of Axiom did) to 
> get the same result.

\start
Date: Fri, 3 Oct 2003 14:59:05 -0400
From: Tim Daly
To: Mike Dewar
Subject: tutorial

Mike,

A minor nit... is the tutorial being released under the Axiom modified BSD?

\start
Date: Sat, 4 Oct 2003 11:21:44 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: tutorial

Yes, there should be a copyright notice in each file.
Mike.

On Fri, Oct 03, 2003 at 02:59:05PM -0400, Tim Daly wrote:
> Mike,
> 
> A minor nit... is the tutorial being released under the Axiom modified BSD?

\start
Date: Sat, 04 Oct 2003 12:44:56 +0200
From: David Mentre
To: Bill Page
Subject: TeX output bug (was: re: kudos)
Cc: Bill Page

Bill Page writes:

> Yes, something as simple as
>
>   )set output tex on
>   elt("A",1)
>
> shows the problem. 

Bill, I obtain:

$$
#\A 
\leqno(1)
$$

What should be the right output (for the bug database)?

\start
Date: Sat, 04 Oct 2003 12:42:48 +0200
From: David Mentre
To: Tim Daly
Subject: Axiom source distribution (was: Re: kudos)
Cc: Tim Daly Jr.

David Mentre writes:

> I have gzipped, renamed and moved it into
> axiom_cvs.pkg/cvs_2003-10-02/axiom-src-cvs-2003-10-02.tar.gz

The uploaded file is about 59 MB.

I just realized that several releases of GCL are included in this
directory:

-rwxr-xr-x axiom/axiom  2468549 2002-11-04 21:12:41 axiom/zips/gcl-2.4.1.tgz
-rwxr-xr-x axiom/axiom  2901224 2002-11-21 01:41:45 axiom/zips/gcl-2.4.3.tgz
-rwxr-xr-x axiom/axiom  9759328 2003-03-20 16:32:01 axiom/zips/gcl-2.5.2.tgz
-rwxr-xr-x axiom/axiom  9846811 2003-06-25 05:38:17 axiom/zips/gcl-2.5.3.tar.gz
-rwxr-xr-x axiom/axiom 10017819 2002-11-21 03:52:12 axiom/zips/gcl-2.5.tgz

I'll repack the source tree with only one GCL release.

In my own compilation of Axiom, gcl-2.5.2 is used. Is it right?

\start
Date: Sat, 04 Oct 2003 13:02:14 +0200
From: David Mentre
To: Tim Daly
Subject: Re: Axiom source distribution
Cc: Tim Daly Jr

David Mentre writes:

> The uploaded file is about 59 MB.
>
> I just realized that several releases of GCL are included in this
> directory:

In the same way, ADVI is not currently used. It will free about 4 MB of
download time.

\start
Date: Sat, 4 Oct 2003 11:14:55 -0400
From: Bill Page
To: David Mentre, Bill Page
Subject: RE: TeX output bug (was: re: kudos)

David,

The LaTeX output of

  elt("A",1)

should just be

$$
A
\leqno(1)
$$

Note that this is directly related to the bug that
I posted earlier

 
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5614&group_id==
293
8

BTW, I really like what you have done with the Axiom
home page!

Cheers,
Bill Page.

> > Yes, something as simple as
> >
> >   )set output tex on
> >   elt("A",1)
> >
> > shows the problem.
> 
> Bill, I obtain:
> 
> $$
> #\A 
> \leqno(1)
> $$
> 
> What should be the right output (for the bug database)?

\start
Date: Sat, 4 Oct 2003 11:18:39 -0400
From: Bill Page
To: Mike Dewar
Subject: re: tutorial

Mike, Tim;

My experiment with TeXmacs with the tutorial files is
turning out to be very promising. The conversion is
quite straight-forward. TeXmacs style customization
ability seems to be able to accommodate most of the
embedded non-standard LaTeX. I should have a draft for
review later this weekend.

How should I handle the copyright notice in these
files? Perhaps there should be a link on each page
to a separate copyright notice?

> Yes, there should be a copyright notice in each file.
> Mike.
> 
> On Fri, Oct 03, 2003 at 02:59:05PM -0400, Tim Daly wrote:
> > Mike,
> > 
> > A minor nit... is the tutorial being released under the 
> Axiom modified 
> > BSD?

\start
Date: Sat, 4 Oct 2003 11:25:28 -0400
From: Bill Page
To: David Mentre
Subject: bug list

David,

I think the following bug is "fixed"

http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4584&group_id=293
8

it was apparently due to a problem with the use of
incompatible database files. There "value stack overflows"
no longer occur with the database files provided by
Juergen and which have been incorporated into the CVS.

Tim, is this correct? If so, I think we should close it.

\start
Date: Sat, 4 Oct 2003 11:26:28 -0400
From: Tim Daly
To: Bill Page
Subject: re: tutorial

Bill,

All copyright notices in source files now say:

/* See LICENSE.AXIOM for Copyright */

I had several dozen email discussions about this. Embedding the copyright
text into the source files does NOT change the copyright to be "more
effective" in any way and is complete overkill. The copyright notices
were collected into the LICENSE directory so they could be consistently
managed.

Please replace all copyright text, no matter where it occurs, by the above text.
Of course, if the copyright is not NAG's copyright you need to change it
appropriately. If it is a new copyright notice that is not in the LICENSE
subdirectory then let me handle it.

\start
Date: 04 Oct 2003 12:36:07 -0400
From: Camm Maguire
To: Aurelien Chanudet
Subject: Re: [Gcl-devel] native relocation on Mac OS X

Great work Aurelian!

1) Do you have access to a publicly accesible ftp directory which I
   may poll in the webpage autoupdate script?  If you upload files
   with, say, the name gcl_.*_macosx.tar.gz there, where .* is a
   version string, the script will install the latest built binary
   tarball on the website.

Aurelien Chanudet writes:

> Hi all,
> 
> As a first step towards using BFD to perform native relocation on Mac
> OS X, I've written some code to load, link and natively relocate
> object files on Mac OS X. As a result, fasloading can now be achieved
> without using the external ld linker.
> 

I think there is a small confusion -- you've been using cust-reloc
thus far, and this method, as well as the bfd method, do not use the
external ld (or ld.so).  Only images using dlopen *must* build maxima,
acl2, and axiom via the external ld (e.g. the alternate maxima gcl
link, the compiler::link patches I've posted to the axiom list
recently under the section labeled '2)').  Other images *can* use the
external ld linking method if they prefer, but *native* relocation and
image saving with a simple call to save-system works as well and is
generally preferred.  You might want to look at the longish post I
submitted recently to the axiom list.


> This took me longer than expected, because I had to manually address
> relocation overflows that might occur when the branch displacement
> does not fit in 24 bits. I know gcc 3.3 has a "-mlongcall" flag but
> I'm still using gcc 3.1 for some other reason. (Apple's gcc has its
> own "-mlongbranch" flag, but this didn't help, though.)
> 

I've found that some of the acl2 tests on powerpc-linux fail unless I
use -mlongcall for the same reason.  configure puts in this switch
automatically for ppc linux.

2) At some point, we need to setup configure defaults for your macosx
   build.

> The first good news is that Maxima 5.9.0 now successfully compiles
> without the alternate linking mechanism. "make check" chokes on
> "Problem 43". I suspect this corresponds to the 3rd issue listed under
> the "Know issues" section of the "NEWS" file included in the source
> directory.
> 

Should be one known failure in maxima's 'make check'.

> The second good news is that acl2 also compiles fine. I've run "make
> check" yet for acl2, as this took me over one night the last time I
> did it, but I'm planning to.
> 

Great!

3) Are you in touch with Tim Daly regarding GCL/Mac/axiom?

4) Is your latest posted patch list the latest?  I'd like to merge in
   any changes you've needed.

5) Is your bfd linking working though a patch to the GCL bfd tree,
   i.e. you use locbfd?  If so, perhaps we could convince BFD upstream
   to apply it?

> Aurelien

\start
Date: Sat, 04 Oct 2003 19:53:19 +0200
From: David Mentre
To: Bill Page
Subject: Re: TeX output bug
Cc: Antoine Hersen

Bill Page writes:

> Note that this is directly related to the bug that
> I posted earlier
>
>  
> http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5614&group_id=2938

Oops, you're right. I had forgotten.

> BTW, I really like what you have done with the Axiom
> home page!

I'm not alone. Antoine has done most if not all of the design. Many
thanks for both of us.

\start
Date: 04 Oct 2003 21:00:26 +0200
From: Juergen Weiss
To: list
Subject: Patches and Fixes to some Makefiles

INTERP.EXPOSED is remade every time make is run

Index: Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/interp/Makefile.pamphlet,v
retrieving revision 1.3
diff -u -a -r1.3 Makefile.pamphlet
--- Makefile.pamphlet   5 Sep 2003 22:14:19 -0000       1.3
+++ Makefile.pamphlet   4 Oct 2003 18:46:27 -0000
@@ -6274,12 +6274,12 @@
 
 \end{verbatim}
 <<databases>>=
-${MNT}/${SYS}/algebra/INTERP.EXPOSED: ${MID}/algebra/INTERP.EXPOSED
-       @ echo 614 making ${MNT}/${SYS}/algebra from ${MID}/algebra/INTERP.EXPOSED 
+${MNT}/${SYS}/algebra/INTERP.EXPOSED: ${MID}/../algebra/INTERP.EXPOSED
+       @ echo 614 making ${MNT}/${SYS}/algebra from ${MID}/../algebra/INTERP.EXPOSED 
        @ cp ${MID}/../algebra/INTERP.EXPOSED ${MNT}/${SYS}/algebra/INTERP.EXPOSED
 
-${MID}/algebra/INTERP.EXPOSED: ${SRC}/algebra/INTERP.EXPOSED.pamphlet
-       @ echo 614a making ${MID}/algebra/INTERP.EXPOSED from ${SRC}/algebra/INTERP.EXPOSED.pamphlet
+${MID}/../algebra/INTERP.EXPOSED: ${SRC}/algebra/INTERP.EXPOSED.pamphlet
+       @ echo 614a making ${MID}/../algebra/INTERP.EXPOSED from ${SRC}/algebra/INTERP.EXPOSED.pamphlet
        @ ${SPADBIN}/notangle ${SRC}/algebra/INTERP.EXPOSED.pamphlet >${MID}/../algebra/INTERP.EXPOSED
 
 ${MID}/exposed.lsp: ${SRC}/algebra/exposed.lsp.pamphlet

There are some typos in the algebra/Makefile 

Index: Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/algebra/Makefile.pamphlet,v
retrieving revision 1.2
diff -u -a -r1.2 Makefile.pamphlet
--- Makefile.pamphlet   29 Sep 2003 03:16:22 -0000      1.2
+++ Makefile.pamphlet   4 Oct 2003 18:54:15 -0000
@@ -8518,7 +8548,7 @@
        @ echo 0 making ${MID}/D01AGNT.spad from ${IN}/d01agents.spad.pamphlet
        @(cd ${MID} ; \
        rm -rf D01AGNT.NRLIB ; \
-       ${SPADBIN}/notangle -R"package D01AGNT D01AgentsPackage" ${IN}/d01agents.spad.pamphlet >D01AGNT.spad )
+       ${SPADBIN}/notangle -R"package D01AGNT d01AgentsPackage" ${IN}/d01agents.spad.pamphlet >D01AGNT.spad )
 
 @
 <<INTFTBL.o (O from NRLIB)>>=
@@ -11357,7 +11387,7 @@
 <<expr2ups.spad (SPAD from IN)>>=
 ${OUTSRC}/expr2ups.spad: ${IN}/expr2ups.spad.pamphlet
        @ echo 0 making ${OUTSRC}/expr2ups.spad from ${IN}/expr2ups.spad.pamphlet
-       @(cd ${MID} ; \
+       @(cd ${OUTSRC} ; \
        ${SPADBIN}/notangle ${IN}/expr2ups.spad.pamphlet >expr2ups.spad )
 
 @
@@ -28649,7 +28679,7 @@
        @ echo 0 making ${MID}/SRDCMPK.spad from ${IN}/sregset.spad.pamphlet
        @(cd ${MID} ; \
        rm -rf SRDCMPK.NRLIB ; \
-       ${SPADBIN}/notangle -R"package SRDCMPK SquareFreeRegularSetDecompositionPackge" ${IN}/sregset.spad.pamphlet >SRDCMPK.spad )
+       ${SPADBIN}/notangle -R"package SRDCMPK SquareFreeRegularSetDecompositionPackage" ${IN}/sregset.spad.pamphlet >SRDCMPK.spad )
 
 @
 <<SREGSET.o (O from NRLIB)>>=
@@ -32199,7 +32229,7 @@
        @ echo 0 making ${MID}/RGCHAIN.spad from ${IN}/zerodim.spad.pamphlet
        @(cd ${MID} ; \
        rm -rf RGCHAIN.NRLIB ; \
-       ${SPADBIN}/notangle -R"package RGCHAIN LexTriangularPackage" ${IN}/zerodim.spad.pamphlet >RGCHAIN.spad )
+       ${SPADBIN}/notangle -R"domain RGCHAIN RegularChain" ${IN}/zerodim.spad.pamphlet >RGCHAIN.spad )
 
 @
 <<RURPK.o (O from NRLIB)>>=

This is a patch adds the missing algebra files. It's an
preliminary hotfix only.

Index: Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/algebra/Makefile.pamphlet,v
retrieving revision 1.2
diff -u -a -r1.2 Makefile.pamphlet
--- Makefile.pamphlet   29 Sep 2003 03:16:22 -0000      1.2
+++ Makefile.pamphlet   4 Oct 2003 18:54:15 -0000
@@ -1011,7 +1011,37 @@
   ${OUT}/IRRF2F.o   ${OUT}/LAPLACE.o  ${OUT}/LIMITPS.o  ${OUT}/LODEEF.o   \
   ${OUT}/NODE1.o    ${OUT}/ODECONST.o ${OUT}/ODEINT.o   ${OUT}/REP.o      \
   ${OUT}/SOLVERAD.o ${OUT}/SULS.o     ${OUT}/SUPXS.o    ${OUT}/ULS.o      \
-  ${OUT}/ULSCONS.o  ${OUT}/UPXS.o     ${OUT}/UPXSCONS.o ${OUT}/UTS.o 
+  ${OUT}/ULSCONS.o  ${OUT}/UPXS.o     ${OUT}/UPXSCONS.o ${OUT}/UTS.o      \
+  ${OUT}/SIGNEF.o \
+  ${OUT}/FSPRMELT.o \
+  ${OUT}/REGSET.o \
+  ${OUT}/RSETGCD.o \
+  ${OUT}/SFRTCAT.o \
+  ${OUT}/SFRGCD.o \
+  ${OUT}/SFQCMPK.o \
+  ${OUT}/SREGSET.o \
+  ${OUT}/LAZM3PK.o \
+  ${OUT}/NORMPK.o \
+  ${OUT}/QCMPACK.o \
+  ${OUT}/SRDCMPK.o \
+  ${OUT}/SOLVETRA.o \
+  ${OUT}/ASP29.o \
+  ${OUT}/D01AGNT.o \
+  ${OUT}/NTSCAT.o \
+  ${OUT}/SNTSCAT.o \
+  ${OUT}/CPIMA.o \
+  ${OUT}/COMBF.o \
+  ${OUT}/INBFF.o \
+  ${OUT}/LODO.o \
+  ${OUT}/LODO1.o \
+  ${OUT}/LODO2.o \
+  ${OUT}/SUBSPACE.o \
+  ${OUT}/STTF.o \
+  ${OUT}/LEXTRIPK.o \
+  ${OUT}/IRURPK.o \
+  ${OUT}/RGCHAIN.o \
+  ${OUT}/RURPK.o \
+  ${OUT}/ZDSOLVE.o 
 
 @

\start
Date: Sat, 4 Oct 2003 23:02:36 +0200
From: Juergen Weiss
To: list
Subject: function MANEXP missing in sf.spad

Seems that the lisp function MANEXP is missing
in gcl and cmu lisp. The function is called 
from sf.spad function manexp. It seems that
integer-decode-float is almost a replacement
for manexp. Is there any documentation what
manexp or MANEXP is supposed to do?

\start
Date: Sat, 4 Oct 2003 23:21:53 +0100 (GMT Daylight Time)
From: Arthur Norman
To: Juergen Weiss
Subject: Re: function MANEXP missing in sf.spad

On Sat, 4 Oct 2003, Weiss, Juergen wrote:
> Seems that the lisp function MANEXP is missing
> in gcl and cmu lisp. The function is called
> from sf.spad function manexp. It seems that
> integer-decode-float is almost a replacement
> for manexp. Is there any documentation what
> manexp or MANEXP is supposed to do?
>
> Juergen Weiss
>
The code I ended up with was

static Lisp_Object Lmanexp(Lisp_Object nil, Lisp_Object a)
{
    int x;
    double f;
    if (! is_float(a))  aerror1("arg is not a floating-point number", a);
    f = float_of_number(a);
    f = frexp(f, &x);
    errexit();
    return onevalue(cons(make_boxfloat(f,TYPE_DOUBLE_FLOAT),
                         fixnum_of_int(x)));
}

Ie it expects a float, splits into integer and fraction part and returns a
cons of the fraction as a double-precision number and the integer part as
an integer. My implementation only supports values wheer the integer part
is small enough to be a fixnum, and does what C does wrt "fractional
part". Right now I do not recall exactly where the spec came from but that
was what went into CSL to support the NAG effort on Axiom.

\start
Date: Sun, 05 Oct 2003 10:33:14 +0200
From: David Mentre
To: Juergen Weiss
Subject: Re: Patches and Fixes to some Makefiles

Hello Juergen,

Juergen Weiss writes:

> INTERP.EXPOSED is remade every time make is run

> There are some typos in the algebra/Makefile 

I have added both patches as a new bug:
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5743&group_id=2938
[bug #5743] Makefile issues: INTERP.EXPOSED is remade every time & typos
in the algebra/Makefile 

> This is a patch adds the missing algebra files. It's an
> preliminary hotfix only.

I left this one out because I was not sure about this status. What do
you mean by "preliminary hotfix only"? Or should I add it to [bug #5379]
"Missing algebra (was: package CombinatorialFunction (COMBF) is
missing)" that's containing your comment on the out-of-date database
issue? 

\start
Date: Sun, 05 Oct 2003 10:37:20 +0200
From: David Mentre
To: Tim Daly
Subject: re: Axiom source distribution

David Mentre writes:

> David Mentre writes:
>
>> The uploaded file is about 59 MB.
>>
>> I just realized that several releases of GCL are included in this
>> directory:
>
> In the same way, ADVI is not currently used. It will free about 4 MB of
> download time.

Ok, I have uploaded a source tree without the unused gcl and advi. It's
new size is 21.35MB instead of 49 MB. Much more reasonable. :)

If somebody has some spare CPU time, it would be nice to give it a try,
to check I have not left out required parts.

\start
Date: Sun, 05 Oct 2003 10:43:13 +0200
From: David Mentre
To: Bill Page
Subject: Re: bug list

Bill Page writes:

> I think the following bug is "fixed"
>
> http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4584&group_id=293
> 8
>
> it was apparently due to a problem with the use of
> incompatible database files. There "value stack overflows"
> no longer occur with the database files provided by
> Juergen and which have been incorporated into the CVS.
>
> Tim, is this correct? If so, I think we should close it.

You're right Bill. The proposed patch in bug #4584 is included in the
source tree as patch zips/gcl-2.5.2.o.main.c.patch and applied during
build process.

I close the bug.

\start
Date: Sun, 5 Oct 2003 11:19:05 +0200
From: Juergen Weiss
To: David Mentre
Subject: RE: Patches and Fixes to some Makefiles

I'm not exactly sure which mechanism Tim 
uses to order the files. So I labeled the
patch as preliminary.
> 
> Hello Juergen,
> 
> Juergen Weiss writes:
> 
> > INTERP.EXPOSED is remade every time make is run
> 
> > There are some typos in the algebra/Makefile 
> 
> I have added both patches as a new bug:
> http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5743&gr
oup_id=2938
[bug #5743] Makefile issues: INTERP.EXPOSED is remade every time & typos
in the algebra/Makefile 

> This is a patch adds the missing algebra files. It's an
> preliminary hotfix only.

I left this one out because I was not sure about this status. What do
you mean by "preliminary hotfix only"? Or should I add it to [bug #5379]
"Missing algebra (was: package CombinatorialFunction (COMBF) is
missing)" that's containing your comment on the out-of-date database
issue? 

\start
Date: Sun, 5 Oct 2003 11:20:28 -0400
From: Tim Daly
To: list
Subject: recent changes

INTERP.EXPOSED is gone from everywhere
Duplicate macros no longer cause stack overflows
Makefiles now use ${MAKE} everywhere
All .input files are lowercased

\start
Date: Sun, 05 Oct 2003 18:04:39 +0200
From: David Mentre
To: Tim Daly
Subject: Re: recent changes

Hello Tim,

Tim Daly writes:

> INTERP.EXPOSED is gone from everywhere

Ok, I have added a comment to bug #5743.


> Duplicate macros no longer cause stack overflows

This closes [bug #4871] "left hand side macro expansion issue (was:
Compiling spad file causes value stack overflow) "

> Makefiles now use ${MAKE} everywhere

Oops, the bug was already closed.

> All .input files are lowercased

Not related to any bug that I know of.


We have 22 bugs remaining, of which 16 have a Severity of "5-Major" or
above (i.e. they are release critical).

\start
Date: Sun, 5 Oct 2003 14:26:45 -0400
From: Tim Daly
To: list
Subject: *yearweek*

"Bug 4587 )lisp *yearweek* is broken" can now be closed.
I've updated the explanation in src/interp/Makefile.pamphlet.

\start
Date: Mon, 6 Oct 2003 09:43:09 +0100
From: Mike Dewar
To: Bill Page
Subject: Re: [Texmacs-dev] New tm_axiom.c & question on	stderr

Hi Bill,

Thats absolutely right.  In the NAG version of the software `axiom' was
just a shell script which started sman with various options.

The only problem I can envisage is that without sman you cannot use
the unix graphics or browser (hyperdoc will work on its own provided it
doesn't need to communicate with the running Axiom interpreter).  For
our own TeX-based interface on Windows we dispensed with sman completely
and had everything running smoothly through TechExplorer except for the
graphics which needed an external program to display (SceneViewer, an
OpenGL renderer which we licensed from Template Graphics Software).

Mike.

On Fri, Oct 03, 2003 at 02:52:17PM -0400, Bill Page wrote:
> Mike,
> 
> So if I understand you correctly, what TeXmacs really aught
> to do is to invoke just the interpreter via AXIOMsys - not
> the whole "Superman" thing. Right? This way, there will
> always only be one prompt. The fact that TeXmacs used to
> expect two prompts was an accident due to the fact that it
> (incorrectly) invoked more that what is really required for
> the TeXmacs-Axiom interface.
> 
> So, both the old and new versions of Axiom should be compatible
> with the new version of the tm_axiom.c program *provided* we
> agree to call the new Axiom interpreter by the name AXIOMsys.
> We should reserve the name 'axiom' for the invoking Superman
> when/if it becomes available in the new open source version.
> 
> So far I a very pleased with the combination of TeXmacs and
> Axiom. I am so used to working with a Maple/Matematica style
> "worksheet" interface, that play with the command line mode
> of Axiom (or even Maple for that matter) just seems too awkward.
> And of course TeXmacs has the advantage that it can simultaneously
> interface with a large number of open source computer algebra
> and related packages, include gnuplot, macsyma, R (statistics),
> etc. and *also* Maple - all from one worksheet environment!
> 
> The Axiom tutorial tex files that you sent look promising
> for conversion to TeXmacs format. I will spend a bit of time
> on that over the next few days.
> 
> Thanks.
> 
> Bill Page.
> 
> > Hi Bill,
> > 
> > There seems to be a misconception that the NAG version of 
> > Axiom puts out two prompts on startup while the Open version 
> > puts out one.  This is not actually true: the Axiom 
> > interpreter (invoked via the command `AXIOMsys' in the NAG 
> > version, and presumably via `axiom' in your version) only 
> > puts out one prompt: the reason you can see two is that sman 
> > (the "Superman" process that manages communication between 
> > the interpreter, hyperdoc, browser, graphics etc.) causes the 
> > interpreter to start a new frame, which forces a new prompt 
> > (you can do the same by typing ")frame new foo").  Once Tim 
> > gets sman working the Open version will presumably work in 
> > the same way.  So your new tm_axiom ought to work the same 
> > way with both versions if they are invoked in the equivalent
> > way.
> > 
> > I haven't seen the TeXmacs interface to Axiom but we used to 
> > maintain a TeX-based interface under Windows (based on IBM's 
> > TechExplorer) and it had lots of nice features - a TeX 
> > version of the browser, the ability to execute worksheets 
> > etc.  Some of this code was embedded in the front-end but the 
> > browser code, for example, was all in boot.  The main file in 
> > question was br-saturn.boot ("saturn" was IBM's pre-release name
> > for TechExplorer) and we also used the $saturn variable to test 
> > whether we were in TechExplorer or not in a few places (this 
> > was so we could use the same CCL image files for both the 
> > TechExplorer and shell interfaces of Axiom under Windows).  
> > It might be worth somebody trying to resurrect this code - 
> > the only hitch I can foresee is that we added a grep command 
> > to CCL (coded in C) since Windows doesn't have a grep 
> > program, but you can always spawn off a system command under 
> > Unix (which is what the original IBM version of Axiom did) to 
> > get the same result.
> > 
> > Mike.

\start
Date: Mon, 06 Oct 2003 18:28:46 +0200
From: David Mentre
To: Tim Daly
Subject: Re: *yearweek*

Tim Daly writes:

> "Bug 4587 )lisp *yearweek* is broken" can now be closed.
> I've updated the explanation in src/interp/Makefile.pamphlet.

Bug closed.

\start
Date: Tue, 7 Oct 2003 01:48:25 -0400 
From: Bill Page
To: Dylan Thurston
Subject: RE: [Axiom-mail] Looking for beginning with axiom.

Axiom Users;

I have completed a first draft of the "Axiom with TeXmacs"
tutorial. You can download it from Axiom_Tutorial at

  http://savannah.nongnu.org/files/?group=axiom

This draft includes information about graphics and the
library browser although these functions have not yet been
implemented in the current alpha release of Axiom. Some of
this functionality may change depending how or if these
functions are integrated with TeXmacs.

The problem with inconsistent application of the
axiom-tutorial.ts stylesheet should now be corrected.

For reference and convenience, I have also included a single
PDF file containing the entire tutorial. It is not necessary
to install TeXmacs or Axiom in order to view this PDF file.

As usual, I am very interested in your comments, suggestions,
corrections and criticisms.
> 
> On Mon, Oct 06, 2003 at 10:21:15AM -0400, Bill Page wrote:
> > Are you still having this problem? It sounds like TeXmacs
> > is not loading the 'axiom-tutorial.ts' stylesheet where
> > these things are defined. Make sure that the file
> > 'axiom-tutorial.ts' is in the same directory as
> > 'tutorialTOC.tm'.
> 
> It's still happening.  It doesn't happen on the main table of 
> contents,
> but when I get to oneStep01.tm I get all those tags.  I tried copying
> axiom-tutorial.ts into the oneStep directory, but it didn't help.
> 
> It also doesn't happen everywhere; there are some places where I see
> AXIOM.

\start
Date: Tue, 7 Oct 2003 09:49:46 -0400
From: Tim Daly
To: Hans Peter Wuermli
Subject: Lost mail? GET-CURRENT-DIRECTORY bug

Hans Peter Wuermli wrote:

> I tried to post a question to the mail-list, but it didn't seem to arrive. 
> The mailing address I chose was "axiom-mail@nongnu.org" and the subject: 
> ")library XY => System errror".
> 
> Do I have to subscribe to the mailing lists, before I can post?

Yes, I believe the mailing lists are set up so that you have to
subscribe although I can't find an option that states that fact.
Otherwise we'd all get rich, have cheap medicine, and be as handsome
as I am naturally. :-) I checked the archives and, indeed, your mail
was never archived.

> 
> P.S. This was the message:
> 
> Quote
> I am using axiom compiled from CVS of 2003-10-3 (on a Debian machine) and 
> trying to run library code found on the Internet (itovsn3). The library 
> command causes an error:
> 
> (1) -> )library BSD
>  
>    >> System error:
>    GET-CURRENT-DIRECTORY is invalid as a function.
> 
> protected-symbol-warn called with (NIL)
> 
> Could someone maybe give me a hint what's going wrong? 

The lousy, untalented, worthless, good-for-nothing lead developer
let the code get out the door without extensive testing? Well,
that's the most likely reason. It's a bug. We'll record it and
get it fixed.

\start
Date: Tue, 7 Oct 2003 09:56:00 -0400
From: Tim Daly
To: Francois Maltey
Subject: Re: several lines in a xterm

Francis Maltey wrote:

> axiom inside texmacs is fine and I can type several lines with 
> [shift-return]. But I prefer use my old emacs or an xterm and I can't do so.
> 
> How can I input one command in several lines.
> Must I do a file and type after )read file.input ?
> Is there another possibility with pipe ?
> 
> Must my emacs add a _ at the end of every line, and then how can I 
> input an if...then...else ? 
> 
> Thanks a lot if you have an idea.

if you type:

if (1 = 1) _
then output 2 _
else output 3

to an axiom prompt inside an emacs buffer the IF statement is recognized.
The trailing _ is the line continuation character for the axiom read function.
I always work in emacs and generally use Ctrl-x 2 to split the screen,
run axiom in one buffer and edit code in the other. 
(Ctrl-x o jumps to the other buffer).
(Ctrl-x 1 will return to single-buffer mode).

\start
Date: Tue, 7 Oct 2003 10:19:14 -0400
From: Tim Daly
To: Francois Maltey
Subject: Re: partfrac, expand, combine,	rewrite and simplify.

> // 1 //
> I use mupad and I find very pretty the only 4 commands :
>   expand, combine, rewrite and simplify (with or without an option)
> 
> expand (binomial (n, 3))                          -> n(n-1)(n-2)/6
> expand (sin (2*x))                                -> 2 sin(x) cos(x)
> 
> combine (sin(x)^2, sincos)                        ->(1-cos(2x))/2
> 
> rewrite (..., opt) with opt=exp, sincos, sinhcosh, etc.
>   for rewriting
> 
> simplify tries to simplify, but it's not so sure.
> 
> In axiom I find a lot of functions as factorials, htrigs, expandTrigProducts
> but no pretty front-end function. Is there ?
> What tells axiom about such general functions ?
> 

Unfortunately your question doesn't seem to have a simple answer.
I've never used mupad but it appears that the functions you mention
are using a tree-like representation of the expression and allow you
to manipulate the tree.

Axiom produces answers whose appearance depends on the type. For example:

-> (x+1)/17

  1      1
 -- x + --
 17     17
               Type: Polynomial Fraction Integer

so the first input gets output as a polynomial of the form A*x+B
where A=1/17 and B=1/17.

-> %::Fraction(Polynomial(Integer))

 x + 1
 -----
   17
               Type: Fraction Polynomial Integer

(% is the last result. "::" does type conversion)

We then asked for a fraction whose numerator and denominator are 
polynomials over the integers. So we wanted a fraction of the form:
(A*x+B)/(C*x+D) and got one with A=1, B=1, C=0, D=17

The output you get depends on the type you request.


> // 2 //
> I call partfrac the transform as 2x^3 / (1-x^2) = 1/(1-x) - 1/(1+x) - 2x
> 
> What is its name in axiom ?

The partialFraction function will create a partial fraction thus:

-> partialFraction(7,12)

       3   1
  1 - -- + -
       2   3
      2
                  Type: PartialFraction Integer

If you need more help let me know and I'll try to resolve the problem.

\start
Date: Tue, 7 Oct 2003 12:24:48 -0400
From: Dylan Thurston
To: Tim Daly
Subject: re: partfrac, expand, combine, rewrite and simplify.
Cc: Francois Maltey

On Tue, Oct 07, 2003 at 10:19:14AM -0400, Tim Daly wrote:
> > // 2 //
> > I call partfrac the transform as 2x^3 / (1-x^2) = 1/(1-x) - 1/(1+x) -=
 2x
> > 
> > What is its name in axiom ?
> 
> The partialFraction function will create a partial fraction thus:
> 
> -> partialFraction(7,12)
> 
>        3   1
>   1 - -- + -
>        2   3
>       2
>                   Type: PartialFraction Integer

Right, but this doesn't help with the actual problem!  Apparently to
convince partialFraction to work on polynomials you need to provide some
type information.

Furthermore, I think there's a bug here:

------
(8) -> partialFraction((2*x^3), (1-x^2))
   There are 1 exposed and 1 unexposed library operations named 
      partialFraction having 2 argument(s) but none was determined to 
      be applicable. [snippage]
(8) -> partialFraction((2*x^3)::UP(x, FRAC INT), (1-x^2))

                 2x
   (8)  - 2x - ------
                2
               x  - 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
r)
(9) -> partialFraction((2*x^3), (1-x^2)::UP(x, FRAC INT))

                 1       1
   (9)  - 2x - ----- - -----
               x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
r)
------

Why didn't input (8) above actually do the partial fraction expansion?

\start
Date: Tue, 7 Oct 2003 13:16:51 -0400
From: Dylan Thurston
To: list
Subject: Display bug for Factored Integer's

I think this behaviour is broken:

----
(10) -> factor(15)

   (10)  3 5
                                                       Type: Factored Integ=
er
(11) -> )set output tex on
(11) -> factor(15)

   (11)  3 5
$$
3 \  5 
\leqno(11)
$$

                                                       Type: Factored Integ=
er
----

This is made worse by the TeXmacs interface, which strips out the '\ 's, so=
 the
answer comes out as '35'.  (Personally, I think the extra space is very ugly,
and should not be put in by Axiom in the first place.)

\start
Date: Tue, 07 Oct 2003 19:36:33 +0200
From: David Mentre
To: Bill Page
Subject: Re: [Axiom-mail] Looking for beginning with axiom.

Hello Bill,

Bill Page writes:

> I have completed a first draft of the "Axiom with TeXmacs"
> tutorial. You can download it from Axiom_Tutorial at

A lot of work! I've just browsed quickly through the tutorial but it
seems very complete. Many thanks Bill.

> For reference and convenience, I have also included a single
> PDF file containing the entire tutorial. It is not necessary
> to install TeXmacs or Axiom in order to view this PDF file.

Good idea. A minor glitch: the produced PDF file is of poor visual
quality on a computer screen. The embedded fonts are bitmap and thus
cannot be anti-aliased on screen (as I have seen on Acrobat Reader on
Windows platform).

How have you produced the PDF? Through LaTeX? I have tried the latex
export on the tutorialTOC.tm document but it does not include the other
chapters. I also tried tutorialFULL.tm but the produced latex document
is empty.

If you can produce a latex file corresponding to the tutorial, pdflatex
shall produce a better PDF. And using the hyperref package, you might
also have links inside the PDF document. 

\start
Date: Tue, 7 Oct 2003 12:56:51 -0400
From: Tim Daly
To: Dylan Thurston
Subject: Re: partfrac, expand, combine,	rewrite and simplify.
Cc: Francois Maltey

Dylan Thurston wrote:

>On Tue, Oct 07, 2003 at 10:19:14AM -0400, Tim Daly wrote:
>> > // 2 //
>> > I call partfrac the transform as 2x^3 / (1-x^2) = 1/(1-x) - 1/(1+x) -=
> 2x
>> > 
>> > What is its name in axiom ?
>> 
>> The partialFraction function will create a partial fraction thus:
>> 
>> -> partialFraction(7,12)
>> 
>>        3   1
>>   1 - -- + -
>>        2   3
>>       2
>>                   Type: PartialFraction Integer
>
>Right, but this doesn't help with the actual problem!  Apparently to
>convince partialFraction to work on polynomials you need to provide some
>type information.
>
>Furthermore, I think there's a bug here:
>
>------
>(8) -> partialFraction((2*x^3), (1-x^2))
>   There are 1 exposed and 1 unexposed library operations named 
>      partialFraction having 2 argument(s) but none was determined to 
>      be applicable. [snippage]
>(8) -> partialFraction((2*x^3)::UP(x, FRAC INT), (1-x^2))
>
>                 2x
>   (8)  - 2x - ------
>                2
>               x  - 1
>               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
>r)
>(9) -> partialFraction((2*x^3), (1-x^2)::UP(x, FRAC INT))
>
>                 1       1
>   (9)  - 2x - ----- - -----
>               x - 1   x + 1
>               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
>r)
>------
>
>Why didn't input (8) above actually do the partial fraction expansion?

Dylan,

(1) -> )d op partialFraction

There is one exposed function called partialFraction :
   [1] (D1,Factored D1) -> PartialFraction D1 from PartialFraction D1
            if D1 has EUCDOM

There are 2 unexposed functions called partialFraction :
   [1] (Fraction Polynomial D4,Symbol) -> Any from 
            PartialFractionPackage D4
            if D4 has Join(EuclideanDomain,CharacteristicZero)
   [2] (Polynomial D5,Factored Polynomial D5,Symbol) -> Any
            from PartialFractionPackage D5
            if D5 has Join(EuclideanDomain,CharacteristicZero)

First, I make a couple variables to hold the expressions.
This lets me figure out what the interpreter type is by default:

(1) -> a:=2*x^3

          3
   (1)  2x
                                                     Type: Polynomial Integer
(2) -> b:=1-x^2

           2
   (2)  - x  + 1
                                                     Type: Polynomial Integer

The signature listed above requires that the first argument type 
must be a EuclideanDomain (EUCDOM):

(3) -> Polynomial(Integer) has EUCDOM

   (3)  false
                                                                Type: Boolean
POLY(INT) is not a EUCDOM.
However, the type you provided is a EUCDOM.

(4) -> UP(x,FRAC INT) has EUCDOM

   (4)  true

                                                                Type: Boolean
So we can make variables that are the correct type:

(5) -> aa:UP(x,FRAC INT):=2*x^3

          3
   (5)  2x
                               Type: UnivariatePolynomial(x,Fraction Integer)
(6) -> bb:UP(x,FRAC INT):=1-x^2

           2
   (6)  - x  + 1
                               Type: UnivariatePolynomial(x,Fraction Integer)

And the call succeeds:

(7) -> partialFraction(aa,bb)

                 1       1
   (7)  - 2x - ----- - -----
               x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Integer)

So partialFraction can create the correct call signature. I suspect the
interpreter created some intermediate type that it couldn't coerce to
the required target type. I agree that it should have been able to 
give the factored output but did not.

If you really want to see the struggles the interpreter is going thru try:

)lisp (setq |$monitorNewWorld| t)

and you can see the interpreter trying to find the correct signature
using various coercions. 

I'll put this problem on the list of things to look at but it won't be
in the near future as I'm trying to correct a major distribution problem
and get some documentation available. If you get any insight I'd like
to know.

\start
Date: Tue, 07 Oct 2003 19:42:38 +0200
From: David Mentre
To: Tim Daly
Subject: Re: Lost mail? GET-CURRENT-DIRECTORY bug
Cc: Hans Peter Wuermli

Tim Daly writes:

>> (1) -> )library BSD
>>  
>>    >> System error:
>>    GET-CURRENT-DIRECTORY is invalid as a function.
>> 

>  It's a bug. We'll record it and get it fixed.

Recorded as bug #5784.
http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=5784&group_id=2938

I have the same behavior.

\start
Date: Tue, 7 Oct 2003 13:06:10 -0400
From: Tim Daly
To: Dylan Thurston, David Mentre
Subject: factor bug (actually a tex bug)

Dylan,

Yes, tex output is broken. The bug appears to be that elt of a string
in common lisp generates escaped characters. I have it "in process"
on one of my development trees but I'm working to fix an important problem 
raised by NAG at the moment so the debugging of this is stalled. Because
I'm changing almost every file and I have to "push" these changes into my
several parallel development trees I'll be busy for most of this week.

David, could you list this as a separate bug just in case it is not related
to the previous tex output bug?

\start
Date: Tue, 07 Oct 2003 20:05:18 +0200
From: David Mentre
To: Dylan Thurston
Subject: Re: Display bug for Factored Integer's

Dylan Thurston writes:

> (10) -> factor(15)
>
>    (10)  3 5
>                                                        Type: Factored Integer
> (11) -> )set output tex on
> (11) -> factor(15)
>
>    (11)  3 5
> $$
> 3 \  5 
> \leqno(11)
> $$
>
>                                                        Type: Factored Integer

Bug recorded as bug #5786.

\start
Date: Tue, 07 Oct 2003 20:06:45 +0200
From: David Mentre
To: Tim Daly
Subject: Re: factor bug (actually a tex bug)

Tim Daly writes:

> David, could you list this as a separate bug just in case it is not related
> to the previous tex output bug?

You want me to record in a separate bug that: "tex output is broken. The
bug appears to be that elt of a string in common lisp generates escaped
characters"?

\start
Date: Tue, 7 Oct 2003 20:50:19 +0200
From: Michel Lavaud
To: list
Subject: re: [Axiom-mail] Looking for beginning with axiom.

Hello,

> Good idea. A minor glitch: the produced PDF file is of poor visual
> quality on a computer screen. The embedded fonts are bitmap and thus
> cannot be anti-aliased on screen (as I have seen on Acrobat Reader on
> Windows platform).

Yes, this is a defect of Acrobat Reader. It can be avoided by viewing the 
pdf with Ghostscript+GSview/ghostview instead (Ghostscript can do 
antialising).

\start
Date: Tue, 7 Oct 2003 14:23:10 -0400
From: Tim Daly
To: Francois Maltey
Subject: Re: partfrac, expand, combine,	rewrite and simplify.

Francois wrote:
>Daly wrote :
>
>> Unfortunately your question doesn't seem to have a simple answer.
>> I've never used mupad but it appears that the functions you mention
>> are using a tree-like representation of the expression and allow you
>> to manipulate the tree.
>...
>
>Thanks a lot for theses details. 
>May I explain why I ask theses questions ?
>
>I'm a mathematical teacher one year after baccalaurat in France.
>In my classroom I must use maple, but for my students mupad is more easy.
>mupad is less expensive and more open than maple, but not free. 

We are talking to various Linux vendors (and will contact Microsoft
and Apple once the ports are done) to try to get Axiom available as
part of the standard distribution. This will ensure that students 
have a free, general purpose computer algebra system already available
on every computer.

Axiom can be compiled and run on Debian and RedHat. Other ports are
underway and will be announced on the 
<A HREF="http://savannah.nongnu.org/projects/axiom">Axiom website</A>.

>So I'm looking for a CAS wich can do every student calculus as
>integrate, differentiate, sum, solver, matrix... and I'm looking
>if the free axiom can do so in future.
>
>Axiom seems to have a lot of avantages.
>Today I can't make any exercice in my classroom with axiom,
>but my question is "Will it possible to do so in some times ?"

I am the lead developer on another computer algebra system called Magnus
which has a "zero learning curve" interface. That is, the interface is
designed to be immediately useful to the student without classroom
instruction. 

I'm also a research professor at City College of New York. Our institute
<A HREF="zerbra.sci.ccny.cuny.edu/web/caiss/main.htm">CAISS</A> is
working to develop a series of front ends for a wide range of math
and science courses. The focus is on the course material made available
by MIT's <A HREF="ocw.mit.edu">Open Courseware</A> effort. Since MIT's
material is free it gives teachers a good reference for their coursework.
In particular, Gilbert Strang (MIT, math) has a Linear Algebra course
that includes video lectures. These are essential to motivating the
student to both learn on their own and use the software. Hopefully
more of the math and science courses will include video in the future.
(MIT's video lectures are probably not useful in France, however).

We currently have a statistics course (CAISS-Stat) as our first 
test example. The idea is to develop specialized menu-driven front
ends for Axiom that make simplifying assumptions. This makes it
easier to build specific functions, label them in menus as expand, 
combine, etc. A whole series of these CAISS-math packages are expected. 

Since the menus are trivial to change and trivial to associate with
any function we expect that professors will be able to change the
system to match their particular course.

Until we have this available you have to consider types.  You can
write programs in Axiom and it is possible to write the kinds of
functions you want as long as you create the correct types. Axiom
knows how to do the things you want but you have to work in the
correct types.

I'll look at the other items you mentioned in your email as soon as
I get the chance.

\start
Date: Tue, 7 Oct 2003 15:12:01 -0400
From: Dylan Thurston
To: Tim Daly
Subject: Re: partfrac, expand, combine,	rewrite and simplify.
Cc: Francois Maltey

On Tue, Oct 07, 2003 at 12:56:51PM -0400, Tim Daly wrote:
> (5) -> aa:UP(x,FRAC INT):=2*x^3
> 
>           3
>    (5)  2x
>                                Type: UnivariatePolynomial(x,Fraction Inte=
ger)
> (6) -> bb:UP(x,FRAC INT):=1-x^2
> 
>            2
>    (6)  - x  + 1
>                                Type: UnivariatePolynomial(x,Fraction Inte=
ger)
> 
> And the call succeeds:
> 
> (7) -> partialFraction(aa,bb)
> 
>                  1       1
>    (7)  - 2x - ----- - -----
>                x - 1   x + 1
>                Type: PartialFraction UnivariatePolynomial(x,Fraction Inte=
ger)
> 
> So partialFraction can create the correct call signature. I suspect the
> interpreter created some intermediate type that it couldn't coerce to
> the required target type. I agree that it should have been able to 
> give the factored output but did not.

Note that there is some behaviour which seems to definitely be a bug.  To
continue your example:

(32) -> partialFraction(aa,bb)

                  1       1
   (32)  - 2x - ----- - -----
                x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
r)
(33) -> partialFraction(2*x^3,bb)

                  1       1
   (33)  - 2x - ----- - -----
                x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
r)

These are fine, but:

(34) -> partialFraction(aa,1-x^2)

                  2x
   (34)  - 2x - ------
                 2
                x  - 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
r)

This must be a bug, since the output is not actually a PartialFraction!
(I'm curious if this happens with the NAG version.)

The fact that partialFraction(2*x^3,1-x^2) doesn't work is more of a
wishlist item, since it doesn't give a wrong answer.  Note that
explicitly making the coefficients fractional works:

(3) -> partialFraction(x^3/2, (x^2-1)/2)

              1       1
              -       -
              2       2
   (3)  x + ----- + -----
            x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
r)

But we can see the same bug I mentioned above if only the numerator has
a fraction:

(4) -> partialFraction(x^3/2, x^2-1)

                1
                - x
        1       2
   (4)  - x + ------
        2      2
              x  - 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Intege=
r)


> If you really want to see the struggles the interpreter is going thru try:
> 
> )lisp (setq |$monitorNewWorld| t)
> 
> and you can see the interpreter trying to find the correct signature
> using various coercions. 

Thanks!  It looks pretty painful, though: I tried to follow it, but failed.

\start
Date: Tue, 7 Oct 2003 14:51:27 -0400
From: Tim Daly
To: Dylan Thurston
Subject: partialFraction behavior in Axiom
Cc: Francois Maltey

Yes, 

aa:UP(x,FRAC INT):=2*x^3
partialFraction(aa,1-x^2)

also fails in the NAG version. I'm almost certain it is an issue of 
the interpreter walking itself into some corner of the type system
and failing to find a good resolution. The usual answer is to give
it more information as you did by declaring the types. I'll have to
contemplate the "painful" output and see where it goes astray.

However, this is related to the general issue of automatic coercions,
types, and simplifications. Somebody needs to write a complete type
graph independent of systems like Axiom (which would be a PhD thesis
or two). Then we could code it up in a less adhoc form. We could
answer questions like "under what conditions can you coerce from a 
fraction of polynomials over integers to polynomials over fractions
of integers?" for knarly things like multivariate polynomials. What
is not apparent on the surface is that some of these coercions go thru
intermediate types before reaching the final output (basically a walk
of the type lattice). The problem is very hard.

\start
Date: Tue, 07 Oct 2003 22:49:07 +0200
From: David Mentre
To: Michel Lavaud
Subject: re: [Axiom-mail] Looking for beginning with axiom.

Hello Michel,

Michel Lavaud writes:

>> Good idea. A minor glitch: the produced PDF file is of poor visual
>> quality on a computer screen. The embedded fonts are bitmap and thus
>> cannot be anti-aliased on screen (as I have seen on Acrobat Reader on
>> Windows platform).
>
> Yes, this is a defect of Acrobat Reader. It can be avoided by viewing the 
> pdf with Ghostscript+GSview/ghostview instead

I'm not sure it is entire Acrobat's fault. I have been able to produce,
under linux, latex documents that can be seen very well under Acrobat. 

But, as I said, it is just a minor point compared to the work that Bill
has done. I just wondered how he has made the PDF.

\start
Date: Tue, 7 Oct 2003 18:28:54 -0400 
From: Bill Page
To: David Mentre
Subject: Re: [Axiom-mail] Looking for beginning with axiom.

David,

I used TeXmacs to create a master document into which
all the sections of the tutorial are linked (included).
TeXmacs treats this as a single document for producing
the table of contents (I didn't use this) and the index
(which I did use). The it can also be printed as a single
large document, even though all of the pieces are edited
individually. I produced the PDF file from the postscript
output file generated by TeXmacs by passing it through
the ghostscript ps2pdf filter.

You are right that the quality of the PDF file when
viewed using Acrobat under Windows looks rather "thin
and spotty" on the screen. But if it is printed it looks
fine. This is a known "problem with TeXmacs". But Michel
is right that this is not really a TeXmacs problem per se
but rather a limitation of older versions of Adobe Acrobat
which could display standard LaTeX fonts very well. The
new version Adobe Acrobat reader 6.0 is VERY MUCH better.
And ghostview has been able to view these files properly
in all the versions available over the last couple of
years.

It is also true what you said David, that it is possible
to get around the limitations of the older version by
using LaTeX and dvi2pdf. This results in substitutions of
fonts for ones more compatible with Windows. But as far
as I can see, this is no longer necessary with Acrobat
Reader 6.0. And if you don't like Acrobat for some
reason ... then you can install Ghostscript 8 and
ghostview under Windows and get the essentially the
same thing.

I was quite disappointed with the limitations current
version of TeXmacs when it came to producing LaTeX
format files. The export from the master document did
not work at all and the export from individual section
files included many incorrect LaTeX codes. So I wasn't
able to compile them at all.

The HTML output from this version of TeXmacs however
is much improved. Only some relatively minor editing
would be required to make a fairly decent web compatible
HTML document. But this includes correcting all the
links in the document which were not converted at all
and a few special symbols that are not available. So
it is not entirely trivial and would involve some
compromises.

I would have liked to use either LaTeX or HTML in order
to produce a combined document with navigation without
TeXmacs but not in this version, I guess. Anyway, I think
the main point of the tutorial is to specifically to use
in *live* with TeXmacs and Axiom. And this seems to
work pretty well, although I did run into the limitation
of some of the "missing" algebra files part way through
the tutorial. So I stopped converting the input to
"live" format and depended in the rest of the tutorial
on just the embedded LaTeX encoded examples (very
similar to live since they were apparently captured
in an online session). Of course readers are free to
break in to using Axiom at any point in the tutorial
just by clicking the Session/Axiom menu option (or the
session button). The results of what they do will
be inserted into the tutorial, although not saved
unless specifically saved by the user in another file.

In fact, I hope the tutorial will gradually be multiplied,
improved, and adapted by people who find it useful. I
think we should maintain some kind of "master copy" on
the Axiom web site, but otherwise the generous copyright
provisions of NAG (which apparently legally must be
maintained) and the BSD licensing etc. would seem to
encourage it's proliferation.

> Michel Lavaud writes:
> 
> >> Good idea. A minor glitch: the produced PDF file is of poor
> >> visual quality on a computer screen. The embedded fonts are 
> >> bitmap and thus cannot be anti-aliased on screen (as I have
> >> seen on Acrobat Reader on Windows platform).
> >
> > Yes, this is a defect of Acrobat Reader. It can be avoided 
> > by viewing the pdf with Ghostscript+GSview/ghostview instead
> 
> I'm not sure it is entire Acrobat's fault. I have been able 
> to produce, under linux, latex documents that can be seen
> very well under Acrobat. 
> 
> But, as I said, it is just a minor point compared to the work 
> that Bill has done. I just wondered how he has made the PDF.

\start
Date: Tue, 7 Oct 2003 21:43:45 -0400
From: Tim Daly
To: Bill Page
Subject: re: [Axiom-mail] Looking for beginning with axiom.

Bill,

At some future point we should discuss how much work it would be to
put the book into a texmacs version. I'm a bit buried this week and
likely next as well. I haven't had a chance to try your demo yet
although I did download the pdf. It appears that line-breaking needs
to be slightly smarter. The line breaker algorithm should probably
be put into Axiom with a ")set linebreak on " command so it works
with all tex output and not just under texmacs.

I did like the pdf. Looks like good work. I'll try it as soon as I
get the chance.

\start
Date: Wed, 8 Oct 2003 00:07:36 -0400 
From: Bill Page
To: Dylan Thurston,Francois Maltey
Subject: POLY INT =\\= UP(x,INT) (was: [Axiom-math] partialFraction behavi or in Axiom)

Tim, Dylan and Francois;

This is an interesting discussion and I am glad that we
have *finally* reached the stage of discussions about
Axiom and not just scrambling to get something running
and "out the door"... Yah!

First, there were several emails back and forth that
already covered some of this, but here's my view:

I think a good definition of 'partfrac' for AXIOM is

  partFrac(ex,x) ==
    partialFraction(numer ex, (denom ex)::UP(x, FRAC INT))

Yes, you do have to help AXIOM with some type conversion
information.

But no, I don't think that there is a bug. We have

  POLY INT has EUCDOM  ----------> false
  UP(x, FRAC INT) has EUCDOM ----> true

Apparently POLY INT does not have enough structure.
Specifying x and the FRAC INT domain adds the needed
structure.

I think that this should be/could be so is quite
deeply routed in the design of Axiom and it's type
system. The distinction between

  x^2 - 1

as something of type: POLY INT versus what appears
as essentially the same thing

  x^2 - 1

as something of type: UP(x,FRAC INT) actually occurs
very frequently in Axiom (e.g 1::Float, 1.0::Integer).
Unfortunately it is something rather subtle and not
easily explained (rationalized?) to the novice user,
yet seems essential for new Axiom users to learn this as
soon as possible - that's one reason why I was really
quite impressed by the quality of the NAG Axiom for
Windows tutorial, because it is the first Axiom tutorial
I have seen that tries to address this.

There is also the problem that Fran=E7ois brings up
involving the presumptions of those users who have
been previously exposed to one of the other popular
computer algebra systems (e.g. Maple, MuPad, Mathematica,
Maxima ... ) which do not share Axiom's strongly typed
metaphor. (I am one of these people. <grin>) Such a users
looks for general operations on expressions like "expand",
"simplify", "combine" etc. and for the most part finds
them missing from Axiom! To convince some of these users
about the wisdom of Axiom's approach may require some
specially written tutorials and comparisons. And I think
our current discussion is a step toward this.

But inspite of the apparently complexity of Axiom's
current type system (which I agree is largely due it's
poor state of documentation and more than a little ad
hocracy) I think Axiom is still immature with respect to
some of the common operations that beginning Axiom users
(but with previous experience) will expect to see. For
example involving the binomial(p,q) function discussed
by Fran=E7ois. There seems to be a whole in Axiom's type
system that does not allow it to deal conveniently with
this case nor with factorials in general. We need to
have clear documentation on the structure of the
algebra and it's type system so that it will be more
clear where this new functionality would be most
efficiently and effacatiously added. As Tim frequently
points out, Axiom is a "long term project"... <sigh>

--------

Let me mention a few simple things of this nature
that surprized me. I have to admit that I really don't
understand some of the Axiom ideas. It is hard to
separate what I don't understand from what I think
might be wrong. But none of these things are serious
problems in the long run. Yet they are examples of the
kind of thing that prevents people from becoming
comfortable with Axiom quickly.

Consider that we can write examples of Axiom types as
follows (assumming no other previous information):

  )clear all

  1        Type: PositiveInteger
  x        Type: Variable x
  x+1      Type: Polynomial Integer
  sin(x)   Type: Expression Integer

Clearly Axiom is trying to choose types that are somehow
"smallest" or most conservative. Surely UP(x,PI) is smaller
than POLY INT. No? How about (sin x)::EXPR PI. Why is
POLY PI an invalid type?

And what about the type Axiom associates with something
like:

  sin(1)    Type: Expression Integer

This "expression" contains no variables!

We have

  sqrt(-1)   Type: AlgebraicNumber

Isn't sin(1) also a Number of of some kind? But I
can not write:

  sin(1)::Float

while

  sqrt(-1)::Complex Float

is converted to (or at least represented) as i.
But why not

  sqrt(-1)::Complex Integer

And while I'm complaining ... it seems very strange
that I cannot by default use the name Real like

  POLY Real

although I can write

  POLY Integer

Ok, I know I should write Float instead of Real, but
surely that must be rather irritating to the pure
mathematicians, no?

Now suppose I assign a type to a variable:

  x:Integer

Then I try to use it in:

  x+1

why does Axiom complain that "x is declared as an
Integer but has not been given a value"? What is
different from before? Why doesn't Axiom treat this
as something with

   x+1    Type: Expression Integer

or even

   x+1    Type: Integer Expression Integer

since it "knows" that x is of Type: Integer and 1 is
of Type: PositiveInteger ?

This is exactly the kind of "type" information
that would be useful if we were to try to perform
correct manipulations of expressions like

  binomial(x,y)

I would like to write

  (x,y,z):Matrix Float
  (a,b):Float

and then expect to be able to write

  a*z*x*y*b

to yield

  a*b*z*x*y

If I haven't said what x, y, and z stand for (i.e.
their types), then why does Axiom simply

  z*x*y

to

  x*y*z

?

In all this seem to be a lot of hidden assumptions
and ad hoc behaviour at a fairly basic level. Yes,
I know that Axiom has been used sucessfully for some
fairly advanced mathematical research projects, but
at this fundamental level things seem rather complex
to the new user ...

Systems like Maple and Mathematica have had a lot more
resources in recent years to smooth out some of these
rough edges. With Axiom's recent resurrection from the
ashes, it seems like we have a good opportunity to
address some of these issues.

I am still rather uncertain whether the changes need
to be towards an algebra system that is simpler and
more rigorous but quite possibly less powerful (like
the Aldor project) or whether there should be more
emphasis on tools and techniques that allow one to deal
with the complexity more efficiently and to thereby
successfully build even larger and more complex algebraic
structures (even loops!) in an ongoing manner. I think
clearly that Tim has opted for the latter. Right Tim?

-----

Another subject.

There are a few technical problems with the TeXmacs-
Axiom interface. Most of these can be easily cleaned
up, I think given a little available time. But I think
I disagree with you Dylan about the case of

> factor 15

$$
3 \  5 
\leqno(11)
$$

It seems to me that the space inserted by Axiom is
correct, although in some cases (such as in the case
of single character symbols) it might be replaced with
a "thin" or "medium" space \, \; instead of a "full"
space \ . I think that it is not correct that it currently
disappears in Axiom. (Do you agree?) There is currently
some logic in Sutor's linebreak code (which I encorporated
in the tm_axiom interface) to replace \ with \cdot in
certain cases involving line-broken products. I think
that there is a lot of room to improve and expand on
these typographic issues in the next versions of
tm_axiom.

At first I thought that it might be good if we could get
the TeXmacs folks (Joris) to agree to support the tm_axiom
interface. But now I am thinking more in terms of
recommending that we accept it as a new and more or less
integral part of Axiom and that we should maintain it
along with the other Axiom user interface code. I don't
know if there is really a licensing issue as such, but we
should note that TeXmacs is GPL (and therefore so is the
 revised tm_axiom which was based on their version), not
BSD. (Forget I mentioned this ... )

Sorry for the long email. It's been a long day.

Cheers,
Bill Page.

> 
> Yes, 
> 
> aa:UP(x,FRAC INT):=2*x^3
> partialFraction(aa,1-x^2)
> 
> also fails in the NAG version. I'm almost certain it is an
> issue of the interpreter walking itself into some corner of
> the type system and failing to find a good resolution. The
> usual answer is to give it more information as you did by
> declaring the types. I'll have to contemplate the "painful"
> output and see where it goes astray.
> 
> However, this is related to the general issue of automatic
> coercions, types, and simplifications. Somebody needs to
> write a complete type graph independent of systems like Axiom
> (which would be a PhD thesis or two). Then we could code it
> up in a less adhoc form. We could answer questions like
> "under what conditions can you coerce from a fraction of
> polynomials over integers to polynomials over fractions
> of integers?" for knarly things like multivariate polynomials.
> What is not apparent on the surface is that some of these
> coercions go thru intermediate types before reaching the
> final output (basically a walk of the type lattice). The
> problem is very hard.

\start
Date: Wed, 8 Oct 2003 01:39:19 -0400
From: Tim Daly
To: Bill Page
Subject: opus 1, act 1
Cc: Francois Maltey

Well, that's a long email. I'll have to reply in smaller chunks as 
it is after midnight and I've gotta get to work early tomorrow.

>I think that this should be/could be so is quite
>deeply routed in the design of Axiom and it's type
>system. The distinction between
>
>  x^2 - 1
>
>as something of type: POLY INT versus what appears
>as essentially the same thing
>
>  x^2 - 1
>
>as something of type: UP(x,FRAC INT) actually occurs
>very frequently in Axiom (e.g 1::Float, 1.0::Integer).
>Unfortunately it is something rather subtle and not
>easily explained (rationalized?) to the novice user,

Think of it in terms of Java code. You can have two classes
(POLYINT and UPxFRACINT) that have the same print representation
but different properties.

I suppose that POLY(INT) is similar to UP(x,INT) since the coefficients
are integers. There is a way to coere INTs to FRAC(INT)s (the
denominator becomes 1). However notice that FRAC(INT) does not occur
at the top level of the "type tower". That is, to coerce
UP(x, INT) to UP(x,FRAC INT) you have to "reach into" the type tower
and convert something below the top level type of UP. This is a hard
problem in general and there is no good theory I'm aware of that says
how to do this in a theoretically correct way.

>yet seems essential for new Axiom users to learn this as
>soon as possible - that's one reason why I was really
>quite impressed by the quality of the NAG Axiom for
>Windows tutorial, because it is the first Axiom tutorial
>I have seen that tries to address this.

The book talks about it. It is not easy to understand if you are
not both a programmer and a mathematician. Programmers "get it" in the
sense of Java types. Mathematicians "get it" in the sense of 
categories. Neither is fully correct.

I've been making the point as part of our 30 year planning horizon
that we really need a new department that is a cross between the
math and comp. sci. departments. Call it computational mathematics.
There are a boatload of issues that only a computational mathematician
cares about (program proof, correctness, complexity, type coercions,
type lattices, algorithmic mathematics, lambda reductions, etc).
We need to give the correct background to the next generation and
we need research in these issues done by PhD students.

>There is also the problem that Franois brings up
>involving the presumptions of those users who have
>been previously exposed to one of the other popular
>computer algebra systems (e.g. Maple, MuPad, Mathematica,
>Maxima ... ) which do not share Axiom's strongly typed
>metaphor. (I am one of these people. <grin>) Such a users
>looks for general operations on expressions like "expand",
>"simplify", "combine" etc. and for the most part finds
>them missing from Axiom! To convince some of these users
>about the wisdom of Axiom's approach may require some
>specially written tutorials and comparisons. And I think
>our current discussion is a step toward this.

I think it was Knuth that said "Teaching BASIC to beginning
programmers causes brain damage and the student will never
recover". The 4Ms have created the illusion that you can 
freely compute results without worrying about the issues that
Axiom struggles with. I believe that this illusion makes it
very difficult to build ever-larger systems. If you can't 
appeal to some theory then the complexity alone will overwhelm
your efforts. Think of the benefits of a strongly typed language
like Java vs a typeless language like BASIC. You can build 
programs in BASIC but you eventually hit the wall when the 
complexity gets high. Java lets you get further. By analogy
I'm arguing that the 4Ms make simple things simple but complex
things ever harder and that Axiom reverses that. I claim that
Axiom scales and the more theory we develop the better it scales.

Of course all of this theory does not help the beginner use Axiom.
At my institute (CAISS at City College of New York) we are planning
to build a series of simple menu-driven front ends for Axiom in a
large variety of courses. The front end hides the complexity because
it only works in a single type (e.g. Expression or POLY(INT)) that
is sufficient for the beginner. Because the operations are all in
one type the issue of type conversion is diminished.

>But inspite of the apparently complexity of Axiom's
>current type system (which I agree is largely due it's
>poor state of documentation and more than a little adhocracy

Yes, the interpreter uses some adhoc methods to try to guess 
what type you might want. It selects functions based on the
type of its arguments as well as the type of the result so it
has to work very hard if you don't give it enough information.
The problem is that YOU have underspecified the input. The
interpreter has to guess and sometimes it does it badly. 

There is no general theory that underpins all of Axiom's type lattice.
We need to create one. The mathematics is pretty sound but there are
a lot of "computational" issues with the mathematics that need work.

>(but with previous experience) will expect to see. For
>example involving the binomial(p,q) function discussed
>by Franois. There seems to be a whole in Axiom's type
>system that does not allow it to deal conveniently with
>this case nor with factorials in general. We need to
>have clear documentation on the structure of the
>algebra and it's type system so that it will be more
>clear where this new functionality would be most
>efficiently and effacatiously added. As Tim frequently
>points out, Axiom is a "long term project"... <sigh>

It is possible to build a series of cover functions that always
work in one type. That will eliminate most of the problems you
are seeing. Expression(Polynomial(Fraction(Integer))) is a type
tower that is probably general enough to do what you want. Of 
course the cover functions will have to coerce things back and
forth internally to use the existing functions (such as you did
with partfrac).

>Clearly Axiom is trying to choose types that are somehow
>"smallest" or most conservative. Surely UP(x,PI) is smaller
>than POLY INT. No? How about (sin x)::EXPR PI. Why is
>POLY PI an invalid type?

POLY takes an argument which is a RING.
You can ask Axiom about these properties thus:

-> )show POLY

  Polynomial R: Ring    

which means that Polynomial requires an argument which is of type Ring.
So we can ask Axiom about INT and PI:

-> INT has RING

  true

-> PI has RING
  
  false

So when you try to construct POLY(PI) Axiom checks the category of
PI to see if is a Ring. It isn't (it lacks inverses). So Axiom will
not let you construct an incorrect type. The same mechanism keeps
you from constructing Polynomials of files, or matricies of streams.
Files don't have the properties necessary to be a Ring and Polynomials
assume their coefficients are Rings. When you operate on Polynomials
the operations for the coefficients (e.g. subtracting) are done by
looking up the operation "in the coefficient domain". If you do:

)show PI

you'll see that PositiveInteger does not support subtraction so
it does not make sense to build Polynomials over PositiveIntegers.
In general if you can construct the type tower the operations will
be correct. This is the big advantage of Axiom over the 4Ms.

Sleep calls. More later. 

\start
Date: Wed, 8 Oct 2003 12:45:12 -0400 
From: Bill Page
To: Tim Daly
Subject: RE: opus 1, act 1

Tim,

On Wednesday, October 08, 2003 1:39 AM you wrote:

> ...
> > The distinction between
> >
> >  x^2 - 1
> >
> >as something of type: POLY INT versus what appears
> >as essentially the same thing
> >
> >  x^2 - 1
> >
> >as something of type: UP(x,FRAC INT) actually occurs
> >very frequently in Axiom (e.g. 1::Float, 1.0::Integer).
> >Unfortunately it is something rather subtle and not
> >easily explained (rationalized?) to the novice user,
> 
> Think of it in terms of Java code. You can have two
> classes (POLYINT and UPxFRACINT) that have the same
> print representation but different properties.

Yes and no. I do not think fondly of the Java programming
language. Pardon my opinions, but it seems to me that
Java is largely a failed experiment in portable interpreter/
compiler design that was too much hyped by the corporate
establishment (first SUN and then later others). For the
most part the promises of code reusability and portability
have yet to be attained.

Now that Maple version 9 has been commercially released,
I think I can safely mention that I have been involved in
about 6 months of beta testing of a new graphical user
interface for Maple written entirely in Java "for portability".
The experience was frustrating and the results largely
unsatisfactory (in my opinion). But it has been shipped to
customers along with the older "classical" interface which
was written in C. At least they still have that option for
now.

I like Java in small quantities, e.g. embedded as simple
scripts inside web pages. But for hacking, give me Perl
and for a better approach give me Python (more Lisp-like).
Dropping Java was one of the good things that Microsoft
actually did. Sorry. It's just an "issue" for me.

> 
> I suppose that POLY(INT) is similar to UP(x,INT) since
> the coefficients are integers. There is a way to coerce
> INTs to FRAC(INT)s (the denominator becomes 1). However
> notice that FRAC(INT) does not occur at the top level of
> the "type tower". That is, to coerce UP(x, INT) to
> UP(x,FRAC INT) you have to "reach into" the type tower
> and convert something below the top level type of UP.
> This is a hard problem in general and there is no good
> theory I'm aware of that says how to do this in a
> theoretically correct way.

But there is something else here - specifying the variable(s)
in the polynomial. Without doing that we can not distinguish
between

  a x + a^2

and

  x a + x^2

So POLY INT and UP(x,INT) are clearly different. It is
tempting to think of this a purely a "syntactic" type
difference but I think it becomes a matter of semantics
in AXIOM.

> ... 
> I think it was Knuth that said "Teaching BASIC to
> beginning programmers causes brain damage and the
> student will never recover".

Indeed! "Re-learning" is often more difficult that "learning".

> The 4Ms have created the illusion that you can freely
> compute results without worrying about the issues that
> Axiom struggles with.

I think will have to admit that so far it is a pretty
convincing "illusion"! I continue to be amazed at what
is possible with "modern" computer algebra systems -
and also what remains unreasonably difficult...

> I believe that this illusion makes it very difficult to
> build ever-larger systems. If you can't appeal to some
> theory then the complexity alone will overwhelm your
> efforts. Think of the benefits of a strongly typed language
> like Java vs a typeless language like BASIC. You can build 
> programs in BASIC but you eventually hit the wall when the 
> complexity gets high. Java lets you get further.

Oh, oh. The Java example again ...

> By analogy I'm arguing that the 4Ms make simple things
> simple but complex things ever harder and that Axiom
> reverses that. I claim that Axiom scales and the more
> theory we develop the better it scales.
>

I don't know. Some simple things are still unreasonably
hard in Maple and other similar systems. And getting
started in Axiom is really rather simple, no? I am
optimistic that a more complete, logical and well
documented type system for AXIOM could go a long way
towards making at least the same set of simple things
simple in Axiom as well.
 
> Of course all of this theory does not help the beginner
> use Axiom. At my institute (CAISS at City College of New
> York) we are planning to build a series of simple
> menu-driven front ends for Axiom in a large variety of
> courses.

I am very sceptical of this. Both Mathematica and Maple
(for example see Maplets) have tried this. It does seem
to be of interest in the "teaching circles" but my
interest in it for applications in theoretical physics
is zero.

> The front end hides the complexity because it only
> works in a single type (e.g. Expression or POLY(INT)) that
> is sufficient for the beginner. Because the operations are
> all in one type the issue of type conversion is diminished.

Isn't that like "cutting off AXIOM's nose to suit it's
face" ?? <grin>

> 
> It is possible to build a series of cover functions that
> always work in one type. That will eliminate most of the
> problems you are seeing. Expression
>    Polynomial(Fraction(Integer))
> is a type tower that is probably general enough to do what
> you want. Of course the cover functions will have to coerce
> things back and forth internally to use the existing
> functions (such as you did with partfrac).

Maybe. Perhaps I will try to write a few more like this
and see if it really does provide a more "4M" type of
user layer.

> 
> >Clearly Axiom is trying to choose types that are somehow
> >"smallest" or most conservative. Surely UP(x,PI) is
> >smaller than POLY INT. No? How about (sin x)::EXPR PI.
> >Why is POLY PI an invalid type?
> 
> POLY takes an argument which is a RING.

Yes, of course you are right. But there is still the
issue of specifying the polynomial variables. It seems to
me that AXIOM could choose UP(x ...), MPOLY([x,y, ... ),
or DMP([x,y, ... ) instead of POLY. This might help some
automatic coercions.

> ... 
> So when you try to construct POLY(PI) Axiom checks the
> category of PI to see if is a Ring. It isn't (it lacks
> inverses). So Axiom will not let you construct an incorrect
> type. The same mechanism keeps you from constructing
> Polynomials of files, or matricies of streams. Files
> don't have the properties necessary to be a Ring and
> Polynomials assume their coefficients are Rings. When
> you operate on Polynomials the operations for the
> coefficients (e.g. subtracting) are done by looking up
> the operation "in the coefficient domain".

Yes. The discussion of Files and Polynomials in the
same breath is probably quite a mental stretch for
most beginning AXIOM users (I am now used to this ...)
And the example seems a bit contrived, but I get your
point.

\start
Date: Wed, 8 Oct 2003 15:06:59 -0400 
From: Bill Page
To: Tim Daly
Subject: AXIOM book and TeXmacs (was: Looking for beginning with axiom.)

Tim,

TeXmacs does a pretty good job of importing TeX/LaTeX
into TeXmacs format (but not so good in the other
direction in the current version), so I think it should
be quite easy to put the AXIOM book into this format.
The tutorial files provided by Mike at NAG where in
LaTeX form with a few special tags. TeXmacs handled
the conversion very well. If you want me to give it
a try, just send me a few sample files.

Putting the LaTeX line breaker algorithm into Axiom
sounds fine. In fact it seems curious the Sutor chose
to do it in classic C code rather than in Axiom itself.
Although I have to admit that I find the way Axiom
generates LaTeX rather obscure! And for now improving
and maintaining the tm_axiom.c program seems much
easier.

I am also interested in David's idea of trying to
encorporate the HyperDoc browser function into the
TeXmacs - Axiom interface.

And of course then there is the graphics. TeXmacs can
accept and insert graphics generated by external programs
in postscript format. Can Axiom's graphics program
produce postscript output?
> 
> At some future point we should discuss how much work it would be to
> put the book into a texmacs version. I'm a bit buried this week and
> likely next as well. I haven't had a chance to try your demo yet
> although I did download the pdf. It appears that line-breaking needs
> to be slightly smarter. The line breaker algorithm should probably
> be put into Axiom with a ")set linebreak on " command so it works
> with all tex output and not just under texmacs.
> 
> I did like the pdf. Looks like good work. I'll try it as soon as I
> get the chance.

\start
Date: Wed, 8 Oct 2003 15:20:11 -0400
From: Dylan Thurston
To: list
Subject: Compilation problems

(I tried sending this before, but it didn't seem to go through.)

I've been trying to compile the CVS version of axiom (because the
Debian package does not have COMBF.o), on my Debian installation.
Problems I've encountered so far (runing AXIOM=linux make):

(a) The makefiles seem to expect the directory
(top)/mnt/linux/src/algebra to exist already.

(b) creating the NRLIB files from the spad files fails, because
interpsys fails to run.  After some experimentation, it seems that
with the following environemnt variables set:

O=o AXIOMXLROOT=linux/compiler SPAD=/a/usr/local/src/axiom/mnt/linux =
OBJ=/a/usr/local/src/axiom/obj SPD=/a/usr/local/src/axiom MNT=/a/usr/=
local/src/axiom/mnt DAASE=/a/usr/local/src/axiom/src/share INC=/a/usr/l=
ocal/src/axiom/src/include LISP=lsp BYE=bye SPADBIN=/a/usr/local/src/=
axiom/mnt/linux/bin AXIOM=linux

(where /usr/local/src/axiom is the top of the tree), interpsys finds
the daase files but fails to find the autloads: the makefile runs this
command:

(cd /a/usr/local/src/axiom/int/algebra ; echo ')co AHYP.spad' | /a/usr/loca=
l/src/axiom/obj/linux/bin/interpsys )

which fails to find the autloads: interpsys ends with

(1) ->    Loading linux/autoload/apply.
 
   >> System error:
   Cannot open the file /a/usr/local/src/axiom/int/algebra/./linux/algebra/=
linux/autoload/apply.

If I unset the AXIOM environment variable, interpsys gets farther.

Can someone who understands the Makefile better than me help me here?

\start
Date: Thu, 9 Oct 2003 09:17:53 -0400
From: Tim Daly
To: Bill Page
Subject: graphics

Bill,

The graphics program generates .ps files.
I'm nearing the point where I can extract the graphics code.
I'm going to give responsibility for that whole subsystem to Dylan.

I'll send you a portion of the book latex shortly (by boat :-) ).
We should talk about the way to handle a book-sized object in texmacs.

\start
Date: Thu, 9 Oct 2003 09:21:32 -0400
From: Tim Daly
To: Bill Page
Subject: lattice drawing program

Bill,

Re: lattices. I vaguely remember a program that allowed you to navigate
a lattice by magnifying portions under the mouse cursor. It was as if
the whole lattice was wrapped around a ball and you portion of the ball
closest to you was easier to read than the rest. I can't remember where
I saw it. Windows XP has a much cheesier version in their taskbar.

re: a willing grad student
guffaw.

\start
Date: Thu, 9 Oct 2003 09:24:48 -0400
From: Tim Daly
To: Dylan Thurston
Subject: build bug

Dylan,

Try making the pathname absolute. And it needs to include the mnt directory
thus:

AXIOM=/usr/local/axiom/mnt/linux

\start
Date: Thu, 9 Oct 2003 10:20:13 -0400
From: Tim Daly
To: Bill Page, Dylan Thurston
Subject: categorical design, aldor, and the type system

Dylan, Bill,

re: Aldor rewrite. 

Many people, including myself, have tried to reconstruct and/or
rewrite the Axiom type system in Aldor. This is unlikely for at least
4 reasons.

First, the type system is reasonable but adhoc since it doesn't have a
one to one correspondence with theory. (e.g. what is a RNG?)

Second, there are types that are mathematical but their implementation
depends on various data structures for efficient implementation so
there isn't even a guiding theory.

Third, an Aldor implementation would be a library not an
interpreter/compiler combination so the user would have to perform
type coercion and simplification, which is very hard to get right.

Fourth, and to the last point, there are hundreds of man-years of
research in Axiom. A clean-room rewrite would need the many great
talents that have already contributed to Axiom (although there are new
talented people) and would never get funded (because computer algebra
"has been done"). And since Axiom work isn't usually recognized by
university departments (unlike, say, bourbaki contributions) it is
unlikely that such a massive, coordinated effort can exist. (A point
which I'm ignoring as I hope to attract free research for the love of
it :-) ).

Aldor is a great language and it is a very seductive idea to do Axiom
over and try to "get it right" but that implies covering a LOT of old
ground before you develop new work. Plus we don't even know or agree
about what is "right". I think there is a lot of new mathematics that
needs to be researched and a lot of mathematics (like symbolic
summation) that Axiom needs which exists but is not implemented in
Axiom.

re: type system

We need to examine what exists in depth and decide what the best
algorithms are for type conversion. I figure we can do this by
understanding the existing type lattice, codifying the adhoc
algorithms current in use, and developing a "coercion theory"
that shows what the algorithms should do. That way we aren't
just "patching" the problem. We're developing a theory that needs
to exist. To this end I've started collecting the raw data of
the existing type signatures so we can do the first step.

\start
Date: Thu, 9 Oct 2003 10:25:03 -0400
From: Tim Daly
To: Bill Page, Dylan Thurston
Subject: categorical design

Bill,

It is perfectly possible to develop an independent type hierarchy
that lives along side of the existing hierarchy. Indeed the could
interact where convenient (e.g. using data structures in common
so already-implemented algorithms can be used).

\start
Date: Thu, 9 Oct 2003 10:31:55 -0400
From: Tim Daly
To: Bill Page, Dylan Thurston
Subject: coerce, cast, partial fractions

Bill,

re: coerce vs casting

I wouldn't equate coercions with type casting. First, type casting in
languages like C "reinterpret" the bits. Coercions reinterpret the
type and potentially rewrite the representation. Second, type casting
traditionally references the "top level type" whereas Axiom can reach
into the type tower and move an "internal" type (e.g. UP(x,INT) to
UP(x,FRAC INT)).

re: partial fractions

If I understand the partialFraction answer (perhaps I don't) the
result given is a partial fraction as far as Axiom is concerned.
Partial fractions work on the factored equation and it appears
that Axiom doesn't think it can factor the equation over the
target domain so the partial fraction uses the "fully factored"
value. The issue appears to be that the target domain chosen by
the interpreter is one in which there are no factors. Or perhaps
it is just a street-level bug :-)

\start
Date: Thu, 9 Oct 2003 13:39:16 -0400
From: Dylan Thurston
To: Tim Daly
Subject: Re: coerce, cast, partial fractions

On Thu, Oct 09, 2003 at 10:31:55AM -0400, Tim Daly wrote:
> If I understand the partialFraction answer (perhaps I don't) the
> result given is a partial fraction as far as Axiom is concerned.
> Partial fractions work on the factored equation and it appears
> that Axiom doesn't think it can factor the equation over the
> target domain so the partial fraction uses the "fully factored"
> value. The issue appears to be that the target domain chosen by
> the interpreter is one in which there are no factors. Or perhaps
> it is just a street-level bug :-)

But how could x^2-1 not be factorizable in any reasonable domain?

I can see that AXIOM might pick a domain where it doesn't know how to
factor, but I would be very surprised to see one coming from an
expression like this!

\start
Date: Thu, 9 Oct 2003 13:40:18 -0400
From: Dylan Thurston
To: list
Subject: Re: categorical design, aldor, and the type system

On Thu, Oct 09, 2003 at 10:20:13AM -0400, Tim Daly wrote:
> re: type system
> 
> We need to examine what exists in depth and decide what the best
> algorithms are for type conversion. I figure we can do this by
> understanding the existing type lattice, codifying the adhoc
> algorithms current in use, and developing a "coercion theory"
> that shows what the algorithms should do. That way we aren't
> just "patching" the problem. We're developing a theory that needs
> to exist. To this end I've started collecting the raw data of
> the existing type signatures so we can do the first step.

Hmm?  Surely the algorithm used for doing automatic type coercions is
independent of the existing heirarchy?

\start
Date: Thu, 9 Oct 2003 13:19:53 -0400
From: Tim Daly
To: Dylan Thurston
Subject: Re: coerce, cast, partial fractions

I'm not claiming that the math is right, just trying to figure out
why it didn't factor the expression. It certainly is a bug.

\start
Date: Thu, 9 Oct 2003 21:54:31 -0400
From: Bill Page
To: Tim Daly
Subject: RE: categorical design, aldor, and the type system

Tim,

On Thursday, October 09, 2003 10:20 AM you wrote:
> 
> re: Aldor rewrite. 
> 
> Many people, including myself, have tried to reconstruct 
> and/or rewrite the Axiom type system in Aldor. This is 
> unlikely for at least 4 reasons.
>

I agree that this is probably not a reasonable prospect. On
the other hand, I have contemplated the opposite possibility,
that is to re-import back into Axiom the new Aldor type
library. This might be a much smaller project since the new
Aldor type library was re-designed recently (last year?)
and is still quite primative and limited compared to Axiom
as a whole.

Last time I mentioned this you gave a muffled answer which
I took to mean either of two things: 1) you weren't interested
or thought it not worthwhile, or 2) there has been some
discussions with people working on the Aldor project about
this possibility and so far there is "not good agreement".

Since I think that the relationship between Axiom and Aldor
is an interesting subject, I would be glad to hear more
about this situtation when you feel you can or when you
have time to discuss it.
 
> First, ...
> 
> Second, ...
> 
> Third, an Aldor implementation would be a library not an 
> interpreter/compiler combination so the user would have to 
> perform type coercion and simplification, which is very hard 
> to get right.

I am not sure I understand your point. As you have pointed
out, Axiom also compiles it's library (It was from this that
the notion of Aldor as a separte compiler originally arose,
right?). And Axiom also usually (when it can) compiles the
functions provided by the user at "run- time". I understand
that it some cases Axiom is not able to compile user provided
code and then resorts to "interpreter" mode. I take this to
mean that it attempts to delay resolution of types until the
function is actually applied. This sort of interpreter mode
is still unique to Axiom, I think.

> 
> Fourth, ...
> 
> Aldor is a great language and it is a very seductive idea to 
> do Axiom over and try to "get it right" but that implies 
> covering a LOT of old ground before you develop new work. 
> Plus we don't even know or agree about what is "right".
> ...

"Uncle". You've convinced me! <grin>  But seriously I never
was actually quite thinking along these lines. I have become
convinced that it is probably possible to work from "within"
Axiom to extend and change it more gradually along certain
lines with a true or at least more "categorial implementation"
only as a longer term goal.

\start
Date: Thu, 9 Oct 2003 22:34:30 -0400
From: Bill Page
To: Tim Daly
Subject: RE: categorical design
Cc: Bertfried Fauser

Tim,

On Thursday, October 09, 2003 10:25 AM you wrote:
> 
> It is perfectly possible to develop an independent type 
> hierarchy that lives along side of the existing hierarchy. 
> Indeed the could interact where convenient (e.g. using data 
> structures in common so already-implemented algorithms can be
> used).
> 

Yes, this is (more or less) what I was contemplating,
although it may be that for a "categorial" imlementation
in the long run very little of the algebra that now exists in
Axiom would be of much use because the changes must occur
at a very top level in the type lattice - at the level of
SetCategory.

Note: I used the word "categorial" (not a typing error).
This was a convention used by a few category theorists some
years ago when there was the possibility of being confused
over other uses of the word "category" and especially to
avoid the use of the word "categorical" which sounds
unnecessarily pejorative and non-technical. <grin>

More specifically, I am thinking that it may be possible to
build on Axiom by intially going even higher up to define
a new categorial level at the top and then building up to
SetCategory on which almost all the rest of Axiom currently
hangs. (This might include Aggregate and some other top level
Axiom categories as well.) So initially only SetCategory and
Aggregate become defined in terms of this new deeper level.
But gradually one could redefine some of the lower types to
depend on types higher up in the new categorial level. And
this way gradually shift SetCategory and it's properly related
types lower down in the hierachy.

This might sound fairly simple, but the problem of course
is that really the category SET is a rather complex object
categorially speaking.

But even more speculatively speaking, I have come to realize
that what we more or less naturally assume to be a type hierachy
(lattice) is not really a lattice at all in the case of Axiom -
it contains loops! Your current method of "breaking" these
loops is quite simple since in most respects the existing
loops in Axiom are quite simple (This is a claim that I can
not yet actually substantiate.) But if we can assume a more
general approach to "solving" such specification loops (e.g.
by the iterative "fixed point" approach I mentioned many
emails ago). Then *maybe* it makes sense to actually begin
now by redefining SetCategory (and a few other top level
Axiom categories) in terms of some of the lower level ones.

This latter strategy would of course introduce some serious
and potentially non-trivial loops in the "hierachy". And
the trouble is that I am really not sure I understand well
enough what it means to deal in general terms with type
specifications given in this manner. Now that seems like a
serious mathematical/computer science research subject to
me!

I would like to hear more from you (and other longer term
Axiom builders/hackers) about the loops in Axiom's type
system. Are these "errors" which need to be eliminated?
Or are they a new more powerful method of defining types?

Is it true that recent formal developments in mathematics
support the idea that such loops are really a necessary
and fundamental part of mathematics? What do you think
Bertfried? I think it was you who suggested this first here.

\start
Date: Thu, 9 Oct 2003 22:54:30 -0400
From: Bill Page
To: Bill Page
Subject: RE: categorical design
Cc: Bertfried Fauser

BTW, if I haven't already mentioned it here (or even if
I have ... <grin> ) I would like to recommend a good and
easily available book on category theory and type systems.
See the book

  Categories Types and Structures
  by Asperti and Longo
  MIT Press, 1991

Now available for download at:

  http://www.di.ens.fr/users/longo/download.html

\start
Date: Thu, 9 Oct 2003 23:47:27 -0400
From: Tim Daly
To: Bill Page
Subject: Re: categorical design
Cc: Bertfried Fauser

Bill,

re: categorical redesign.

My view of this is to think of Axiom's mathematics as a general
graph rather than as a lattice with loops. Think of drawing the
whole of the algebra on the surface of a sphere. Picking one of 
several defined starting points (sets, categories) in the algebra 
would be like rotating the ball until the chosen point is at the
north pole. Everything else is defined in terms of that pole.
Choosing a new point would be like rotating the sphere to 
adjust it to the new "north pole" and everything in the graph
now flows from that point. A loop in the algebra goes all the
way around the sphere and you can choose any point in the loop
as fundamental. The choices I made to "break the loop" were
arbitrary.

I'm not sure if the graph-mapped-onto-a-surface resonates with
you but that's how I think about it. (The surface need not be a
sphere, of course).

\start
Date: Fri, 10 Oct 2003 16:04:12 +0200 (CEST)
From: Bertfried Fauser
To: Tim Daly
Subject: Re: categorical design

Dear Bill,

	I judge myself not an expert in category theory (though I heavily
use it) and I am certainly not aware of the complexity of AXIOMs type
system (yet). But perhaps the following may help:

a) There is not "category theory" per se. Many people do quite different
(and sometimes contradicting) things with categories. Hence with "category
theory" there has to come meta information to make sure its used the
_polictical correct_ way. I had some problems with other mathematicians
whene I used categories not that way ;-)
-- Set Based category theory, ie the older version. This is still based on
   the idea (Bourbaki by the way) that all of mathematics should be based
   on set theory (in my eyes a contradictinmg paradigm to quantum mechanics).
   Nevertheless, this treatment came up with homological algebra and went
   into categories which are *not* af type set at all....
-- Function based category theory (still a new branch of mathematics,
   started by William Lawvere and others, using *constructivistic* ideas
   of Brouwer [hence a generic computational approch, one should think]).
   The idea is to define functions as elementary objects and then compute
   from scratch what kind of (sometimes awkward!) objects may be
   manipulated by these functions (domains and codomains may be categories
   itself). It does not make a choice of a _basic category_ but leaves
   this open.
	Regarding AXIOM, a valuable choice would be a topos. Topi (Lawvere
   calls them toposes, which is linguistical barbaric ;-) Constitute a
   sort of category which is very close to Set, but slightly larges, just
   axiomatizing the basic structures of Set. Its a general experience,
   that if you axiomatize mathematical structures in a categorial way
   then you get more general structures due to isomorphism invariance of
   these _objects_.

b) From matroid theory (which encodes very basic facts about linear and
general dependance of objects) one learns that there is something like a
cryptomorphism spoiling the idea that mathematics is a well ordrere (or
even partially ordered) lattice. Indeed you find complicate isomorphisms
from one axiom system into another which maps basic structures to very
complicated ones and vice versa (Tim's 'shere', by the way a very
complicated topological problem to detect on which (hyper)surface a graph
may live).
	Hence I guess that there will be no generic or cannonical choice
for an starting point in the type lattice, but it should be a matter of
taste and adjusted to the problems you want to attack.

c) Isomorphisms problem.
	It is a general *problem* (dealt with under the name of
_categorification_ to 'categorify' a mathematical structure, say the
natural numbers. Since this is a generalization it is neither canonical
nor unique and needs meta input (experience or even information from
physics ie experiments) if the math shall be related to soemthing
reasonable. A current problem is to categorify the theory of categories (a
typical mathematical thinking <grin>) which leads to n-category theory,
which I am try to employ in quantum physics. This is unsolved mathematical
reasearch, ....

d) Isomorphisms implementation problem.
	From my own experiments with CAS (eg Maple) there is anothe
rproblem for actual computations. Having defined a mathematical category,
you have set up an abstract structure of relations between functions.
However, if you want to implement this, you need _elements_ on which such
functions can act. That is you need a modell for your category, such
modells may be *tremendously* different and it might be a practical
impossible task to construct an isomorphsims (type conversion) between
such elements *even if you can mathematically prove they are of the same
kin*!
	Moreover, you find *non representable* categories, which cannot be
represented over the category Set, which are quite awkward object. I do
not yet see how to impelemt such categories is a CAS.
	A further example is that patological objects migcome into play.
Zbigniew Oziewicz and I do search for years now a categorial description
of Clifford algebras. But reasonable axioms *include* some further
algebras with quite obscure behaviour which you would not like to address
by this name. If you introduce base (ie elements represnting the algebra)
this diaspears, but I do not yet know why..... Such problems will arise if
a strickt mathematical type system would be implemented.

Hence the AXIOM types may still have a need to be based on some
representations, which is a second layer of non abstractnes (after the
choice of a starting 'north pole' in the type graph. I see currently no
way around this (but I am not an expert in type-ing ;-) )

hope this is informative for you, otherwise I apologize

\start
Date: 10 Oct 2003 09:51:59 -0400
From: Camm Maguire
To: Tim Daly
Subject: CVS build broken? -- errortrap

Greetings!  Just went to build a fresh cvs snapshot Debian package
yesterday (to include some of the tutorial documentation developed --
this stuff is great!), and the build appears to be broken due to
missing files:

313 making /fix/g/camm/axiom/axiom-0.0.0cvs/int/input/eqtbl.input from /fix/g/camm/axiom/axiom-0.0.0cvs/src/input/eqtbl.input.pamphlet
312 making /fix/g/camm/axiom/axiom-0.0.0cvs/mnt/linux/input/eqtbl.input from /fix/g/camm/axiom/axiom-0.0.0cvs/int/input/eqtbl.input
315 making /fix/g/camm/axiom/axiom-0.0.0cvs/int/input/equation.input from /fix/g/camm/axiom/axiom-0.0.0cvs/src/input/equation.input.pamphlet
314 making /fix/g/camm/axiom/axiom-0.0.0cvs/mnt/linux/input/equation.input from /fix/g/camm/axiom/axiom-0.0.0cvs/int/input/equation.input
make[4]: *** No rule to make target `/fix/g/camm/axiom/axiom-0.0.0cvs/src/input/errortrap.input.pamphlet', needed by `/fix/g/camm/axiom/axiom-0.0.0cvs/int/input/errortrap.input'.  Stop.
make[4]: Leaving directory `/fix/g/camm/axiom/axiom-0.0.0cvs/src/input'
make[3]: *** [inputdir] Error 2
make[3]: Leaving directory `/fix/g/camm/axiom/axiom-0.0.0cvs/src'
make[2]: *** [srcdir] Error 2
make[2]: Leaving directory `/fix/g/camm/axiom/axiom-0.0.0cvs'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/fix/g/camm/axiom/axiom-0.0.0cvs'
make: *** [build-stamp] Error 2
debuild: fatal error at line 469:
dpkg-buildpackage failed!

\start
Date: Fri, 10 Oct 2003 09:25:32 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: CVS build broken? -- errortrap

I'll look at it. I just did a massive update for NAG and it built
locally before I uploaded it. It looks like a missing stanza in 
the Makefile. Sorry about that. -- t

\start
Date: Fri, 10 Oct 2003 16:02:54 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: CVS build broken? -- errortrap

Camm,

I fixed it, I believe. I added files to the upload and I forgot to
cvs add these last two files. Do you happen to know if cvs can
tell if whether there are files in the tree that have not been
added to the cvs?

\start
Date: 10 Oct 2003 16:14:19 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: CVS build broken? -- errortrap

Greetings, and thanks!

Yes, when you do a cvs 'diff' (I usually use 'cvs -z9 -q diff -u'),
you see the modifications explicitly.  If you do a 'cvs update', no
files that you've modified from the repository will be overwritten,
but they will be listed with a 'M' flag for 'modified'.  Any files
present not in the repository appear with a '?' flag, and any files in
the repository which you've deleted result in a warning message.  the
last two categories appear identically in a cvs diff too.

Tim Daly writes:

> Camm,
> 
> I fixed it, I believe. I added files to the upload and I forgot to
> cvs add these last two files. Do you happen to know if cvs can
> tell if whether there are files in the tree that have not been
> added to the cvs?

\start
Date: 10 Oct 2003 19:23:47 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: CVS build broken? -- errortrap

Hi Tim!  The build works again, thanks!

This is just to confirm that the missing COMBF and source file export
issues we discussed earlier are still extant, right?

Take care,

Tim Daly writes:

> Camm,
> 
> I fixed it, I believe. I added files to the upload and I forgot to
> cvs add these last two files. Do you happen to know if cvs can
> tell if whether there are files in the tree that have not been
> added to the cvs?

\start
Date: Fri, 10 Oct 2003 19:47:19 -0400
From: Dylan Thurston
To: Camm Maguire
Subject: Re: CVS build broken? -- errortrap

On Fri, Oct 10, 2003 at 07:23:47PM -0400, Camm Maguire wrote:
> Hi Tim!  The build works again, thanks!
> 
> This is just to confirm that the missing COMBF and source file export
> issues we discussed earlier are still extant, right?

I've successfully applied some of the patches Juergen Weiss posted
earlier to fix this.  (Well, I'm still compiling with the latest CVS
files.)  Shall I repost the patches?  Some of them were in a slightly
odd format.

\start
Date: Sat, 11 Oct 2003 03:34:46 -0400
From: William Sit
To: Dylan Thurston
Subject: re: coerce, cast, partial fractions

Dylan Thurston wrote:
> 
> On Thu, Oct 09, 2003 at 10:31:55AM -0400, Tim Daly wrote:
> > If I understand the partialFraction answer (perhaps I don't) the
> > result given is a partial fraction as far as Axiom is concerned.
> > Partial fractions work on the factored equation and it appears
> > that Axiom doesn't think it can factor the equation over the
> > target domain so the partial fraction uses the "fully factored"
> > value. The issue appears to be that the target domain chosen by
> > the interpreter is one in which there are no factors. Or perhaps
> > it is just a street-level bug :-)
> 
> But how could x^2-1 not be factorizable in any reasonable domain?
> 
> I can see that AXIOM might pick a domain where it doesn't know how to
> factor, but I would be very surprised to see one coming from an
> expression like this!
> 
Surely, x^2 -1 can be factored in POLY INT and Axiom behaves correctly. So the
problem is not with factoring.

Remember that algorithms in Axiom are categorical. From the documentation in
partialFraction:

"For a general euclidean domain, it is not known how to factor the denominator.
Thus the function partialFraction takes as its second argument an element of
Factored(R)."

It also states that the requirement for R to be a euclidean domain is to
normalize the denominator.

The fact that SOME domains (or denominators) can be factored is irrelevant to
Axiom.

An example is:
a = DMP([x,y], FRAC INT) does not have EuclideanDomain
b = DMP([x], FRAC INT) does not have EuclideanDomain
c = UP(x, FRAC INT) has EuclideanDomain

even though mathematically, b and c are the same. But categorically, the DMP
constructor does not have EuclideanDomain. Of course, nothing prevents us from
saying something like:
  DMP(varlist, ring) ...
  if size?(varlist,1) then EuclideanDomain
or if size?(varlist,1) then UnivariatePolynomialCategory

but this is not done.

Expression Integer has EuclideanDomain returns true.  Why?
It seems to inherit this from FunctionSpace(Integer), but I searched the sources
fspace.spad and expr.spad and neither reference EuclideanDomain directly. (This
shows how difficult it is to construct the graph of hierarchy based on source
files).

The problem with partialFraction not working over R = POLY INT is because POLY
INT does not belong to the category EuclideanDomain (it is multivariate).

However, there is definitely something wrong with the interpreter. In the NAG
2.3 version, I actually have:

G82322 (3) -> )clear all
   All user variables and function definitions have been cleared.
G82322 (1) -> up:= UP(x,FRAC INT)

   (1)  UnivariatePolynomial(x,Fraction Integer)
                                                                 Type: Domain
G82322 (2) -> a:up:=1-x^2

           2
   (2)  - x  + 1
                               Type: UnivariatePolynomial(x,Fraction Integer)
G82322 (3) -> b:up:=2*x^3

          3
   (3)  2x
                               Type: UnivariatePolynomial(x,Fraction Integer)
G82322 (4) -> partialFraction(b,factor(a))

                 1       1
   (4)  - 2x - ----- - -----
               x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Integer)
G82322 (5) -> partialFraction(b,a)

                 1       1
   (5)  - 2x - ----- - -----
               x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Integer)
G82322 (6) -> partialFraction(2*x^3::up, 1-x^2::up)

              3
            2x
   (6)  - ------
           2
          x  - 1
                                     Type: PartialFraction Expression Integer
G82322 (7) -> partialFraction(b,a)

                 1       1
   (7)  - 2x - ----- - -----
               x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Integer)


I did (7) just to make sure that (5) does not come because of (4) (and (7) does
not come because of (6)).

But why do (5) and (6) behave differently? Aren't these two syntactically the
same? In each case the second parameter need to be coerced to Factored(R) but
the two R's are different in (5) and (6).  The behavior in the NAG 2.3 version
is also different from the one reported by Tim Daly :

Tim:(8) -> partialFraction((2*x^3)::UP(x, FRAC INT), (1-x^2))

                 2x
   (8)  - 2x - ------
                2
               x  - 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Integer)
Tim:(9) -> partialFraction((2*x^3), (1-x^2)::UP(x, FRAC INT))

                 1       1
   (9)  - 2x - ----- - -----
               x - 1   x + 1
               Type: PartialFraction UnivariatePolynomial(x,Fraction Integer)

I have:
partialFraction(2*x^3::UP(x, FRAC INT), 1-x^2)


              3
            2x
   (6)  - ------
           2
          x  - 1
                                     Type: PartialFraction Expression Integer

but I also got Tim's (9) the same.

\start
Date: Sat, 11 Oct 2003 03:44:40 -0400
From: William Sit
To: Dylan Thurston
Subject: Re: [Axiom-developer]Re: categorical design, aldor, and the type system

Dylan Thurston wrote:
> 
> On Thu, Oct 09, 2003 at 10:20:13AM -0400, Tim Daly wrote:
> > re: type system
> >
> > We need to examine what exists in depth and decide what the best
> > algorithms are for type conversion. I figure we can do this by
> > understanding the existing type lattice, codifying the adhoc
> > algorithms current in use, and developing a "coercion theory"
> > that shows what the algorithms should do. That way we aren't
> > just "patching" the problem. We're developing a theory that needs
> > to exist. To this end I've started collecting the raw data of
> > the existing type signatures so we can do the first step.
> 
> Hmm?  Surely the algorithm used for doing automatic type coercions is
> independent of the existing heirarchy?

The hyperdoc system can list all the domains, categories and packages that
contain signatures of a particular exported function. Is there any coordination
between hyperdoc and the interpreter? It seems that the hyperdoc maintains some
database of domains, etc and is this different from the one used by the
interpreter? 

\start
Date: Sat, 11 Oct 2003 11:32:37 -0400
From: Dylan Thurston
To: William Sit
Subject: Re: coerce, cast, partial fractions

On Sat, Oct 11, 2003 at 03:34:46AM -0400, William Sit wrote:
> Dylan Thurston wrote:
> > 
> > On Thu, Oct 09, 2003 at 10:31:55AM -0400, Tim Daly wrote:
> > > If I understand the partialFraction answer (perhaps I don't) the
> > > result given is a partial fraction as far as Axiom is concerned.
> > > Partial fractions work on the factored equation and it appears
> > > that Axiom doesn't think it can factor the equation over the
> > > target domain so the partial fraction uses the "fully factored"
> > > value. The issue appears to be that the target domain chosen by
> > > the interpreter is one in which there are no factors. Or perhaps
> > > it is just a street-level bug :-)
> > 
> > But how could x^2-1 not be factorizable in any reasonable domain?
> > 
> > I can see that AXIOM might pick a domain where it doesn't know how to
> > factor, but I would be very surprised to see one coming from an
> > expression like this!
> > 
> Surely, x^2 -1 can be factored in POLY INT and Axiom behaves correctly. S=
o the
> problem is not with factoring.
> 
> Remember that algorithms in Axiom are categorical. From the documentation=
 in
> partialFraction:
> 
> "For a general euclidean domain, it is not known how to factor the denomi=
nator.
> Thus the function partialFraction takes as its second argument an element=
 of
> Factored(R)."
> 
> It also states that the requirement for R to be a euclidean domain is to
> normalize the denominator.

Sure, that's why the second argument is supposed to be factored _before_
partialFraction is called.  It's not being factored; this is not a bug
in partialFraction, but a bug someplace else.

Specifically, from the output with ')lisp (setq |$monitorNewWorld| t)',
the problem probably lies in whatever is going on in this stanza:
----------
---->Factored UnivariatePolynomial(x,Fraction Integer)----> searching op ta=
ble for:
   coerce : UnivariatePolynomial(x,Fraction Integer) -> % from  Factored Un=
ivariatePolynomial(x,Fraction Integer)
<----#<compiled-function |FR;coerce;R$;43|>(Factored,UnivariatePolynomial(x=
,Fraction Integer))
----------
This looks like it should be calling the standard 'coerce' from
UP(x, FRAC INT) to FR UP(x, FRAC INT), which should do the factorization
(according to all the documentation I read), but doesn't!  (Or maybe the
coercion function from the 'Factored' domain doesn't actually do the
factorization itself?)

Compare this to what happens when we try to do this coercion explicitly:
----------
(4) -> aa:UP(x, FRAC INT) := x^2-1

   (4)  x  - 1
                               Type: UnivariatePolynomial(x,Fraction Intege=
r)

(5) -> aa::FR UP(x, FRAC INT)
---->RationalFactorize UnivariatePolynomial(x,Fraction Integer)----> search=
ing op table for:
   factor : UnivariatePolynomial(x,Fraction Integer) -> Factored Univariate=
Polynomial(x,Fraction Integer) from  RationalFactorize UnivariatePolynomial=
(x,Fraction Integer)
<----#<compiled-function |RATFACT;factor;RPF;1|>(RationalFactorize,Univaria=
tePolynomial(x,Fraction Integer))

---->Factored UnivariatePolynomial(x,Fraction Integer)----> searching op ta=
ble for:
   coerce : % -> OutputForm from  Factored UnivariatePolynomial(x,Fraction =
Integer)
<----#<compiled-function |FR;coerce;$Of;35|>(Factored,UnivariatePolynomial(=
x,Fraction Integer))
   (5)  (x - 1)(x + 1)
                      Type: Factored UnivariatePolynomial(x,Fraction Intege=
r)
----------
Somehow, a different routine ('RationalFactorize') is being called.

\start
Date: Sat, 11 Oct 2003 15:59:37 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: CVS build broken? -- errortrap

Camm,

I'm working on the COMBF issue now.

\start
Date: Mon, 13 Oct 2003 14:06:54 -0400
From: Dylan Thurston
To: list
Subject: Small TeX output patch

While going through the TeXmacs tutorial, I've noticed several display
bugs.  I already reported one to the BTS (#5906), but here's another
small fix, which fixes the display of infinity.

Test case input:
)set output tex on
plusInfinity()

Desired output:
$$
\infty
\legno(1)
$$


---------- snip here ------------
Index: tex.spad.pamphlet
==========================
==========================
=================
RCS file: /cvsroot/axiom/axiom/src/algebra/tex.spad.pamphlet,v
retrieving revision 1.2
diff -u -r1.2 tex.spad.pamphlet
--- tex.spad.pamphlet   9 Oct 2003 10:45:03 -0000       1.2
+++ tex.spad.pamphlet   13 Oct 2003 17:44:55 -0000
@@ -140,11 +140,11 @@
     specialStrings : L S :=
       ["cos", "cot", "csc", "log", "sec", "sin", "tan",
         "cosh", "coth", "csch", "sech", "sinh", "tanh",
-          "acos","asin","atan","erf","...","$"]
+          "acos","asin","atan","erf","...","$", "infinity"]
     specialStringsInTeX : L S :=
       ["\cos","\cot","\csc","\log","\sec","\sin","\tan",
         "\cosh","\coth","\csch","\sech","\sinh","\tanh",
-          "\arccos","\arcsin","\arctan","\erf","\ldots","\$"]
+          "\arccos","\arcsin","\arctan","\erf","\ldots","\$","\infty"]
 
     -- local function signatures
 
---------- snip here ------------

However, I'm a little concerned about this (and the general approach):
after all, if you type "infinity" at the prompt, it gets interpreted as
a variable named "infinity", not as an element of OrderedCompletion.
The same goes for "sin", of course:

--------------
   (4)  sin
$$
\sin 
\leqno(4)
$$

                                                           Type: Variable s=
in
--------------

The output really should be similar to what I would get if I typed
"sine" (which is currently buggy, but that's another issue), but because
the code patched above looks only at the text of the string to be output
(which is the only thing available to it), and not the type that was
producing the output, there are sure to be display glitches.

For the moment, I think the patch above should be applied, but a
long-term project would be to rethink how TeX output is produced to
deal with situations like this in a more principled way.

Also, another project would be to remove the "latex" command, which
seems to be an abortive attempt at another method of producing LaTeX
output.  It's not used much, and should be incorporated into one of the
other mechanisms, and even things as simple as "latex (x+y)" produce
"Unimplemented".

(I'm not sure what the etiquette is.  Should I just go ahead and file
the bugs myself, and will anybody notice if I do?  Is there a way for me
to subscribe to the BTS?  I count three bugs here:
1) Patch for output of "infinity";
2) Revamp output mechanisms so that "sin" as a variable is treated
   differently from "sin" the trigonometric function; and
3) Remove the "latex" function from Category SetCategory.)

\start
Date: Mon, 13 Oct 2003 14:17:16 -0400
From: Tim Daly
To: Dylan Thurston
Subject: Re: Small TeX output patch

> For the moment, I think the patch above should be applied, but a
> long-term project would be to rethink how TeX output is produced to
> deal with situations like this in a more principled way.

I'll apply the patch you sent.

> Also, another project would be to remove the "latex" command, which
> seems to be an abortive attempt at another method of producing LaTeX
> output.  It's not used much, and should be incorporated into one of the
> other mechanisms, and even things as simple as "latex (x+y)" produce
> "Unimplemented".

Perhaps we should write up how tex and latex work so we understand
the machinery better first. I have looked at it, Bill has looked at
it, and you have looked at it. Some boot code knows about tex as
well as some of the algebra code. Even some of the lisp code gets
involved (the ELT bug in strings). I agree we need to rethink this
but rather than add another version perhaps we should do deep 
surgery and redesgn it.

> (I'm not sure what the etiquette is.  Should I just go ahead and file
> the bugs myself, and will anybody notice if I do?  Is there a way for me
> to subscribe to the BTS?  I count three bugs here:

David Mentre is the "bug czar". We can do it any way he wants.
David?

\start
Date: Mon, 13 Oct 2003 20:41:29 +0200
From: David Mentre
To: Tim Daly
Subject: Re: Small TeX output patch

Tim Daly writes:

>> (I'm not sure what the etiquette is.  Should I just go ahead and file
>> the bugs myself, and will anybody notice if I do?  Is there a way for me
>> to subscribe to the BTS?  I count three bugs here:
>
> David Mentre is the "bug czar". We can do it any way he wants.
> David?

:)

Dylan, yes, you should fill the bug yourself. Both Tim and I receive an
email when a new bug is filled, so yes your bug is noticed[1]. If you
have a savannah account, I _think_ you can add yourself to the CC: of
the bug (so being informed of new information on your bug).

Even if you don't think this is a real bug but a needed redesign or a
missing functionnality, you can add it as a "feature request", with a
low bug Severity (I usually use 1 to 3). 

If you fill a bug or a feature request, please give example of the given
command and both the failing and expected output. It helps a lot to
understand the bug. Your example with "fi"'s ligature in your latest bug
report is a good example of that.

[1] And once me or another Axiom hacker will start doing Q&A, the BTS
    will be the definitive reference point.

\start
Date: Mon, 13 Oct 2003 19:16:46 -0400
From: Dylan Thurston
To: David Mentre
Subject: Re: Small TeX output patch

On Mon, Oct 13, 2003 at 08:41:29PM +0200, David MENTRE wrote:
> Tim Daly writes:
> 
> >> (I'm not sure what the etiquette is.  Should I just go ahead and file
> >> the bugs myself, and will anybody notice if I do?  Is there a way for =
me
> >> to subscribe to the BTS?  I count three bugs here:
> >
> > David Mentre is the "bug czar". We can do it any way he wants.
> > David?
> 
> Dylan, yes, you should fill the bug yourself.

OK, I filed the second two, longer-term bugs; it seems as though the
"infinity" problem is already done.

> ... Both Tim and I receive an email when a new bug is filled, so yes
> your bug is noticed[1]. If you have a savannah account, I _think_ you
> can add yourself to the CC: of the bug (so being informed of new
> information on your bug).

I didn't see how to do this.  But also, I would like to get
notifications of new bugs (and maybe also CVS updates) myself; is this
possible?

> Even if you don't think this is a real bug but a needed redesign or a
> missing functionnality, you can add it as a "feature request", with a
> low bug Severity (I usually use 1 to 3). 

I don't think I have the permissions to set the bug Severity, or I would
have done so...

> If you fill a bug or a feature request, please give example of the given
> command and both the failing and expected output. It helps a lot to
> understand the bug. Your example with "fi"'s ligature in your latest bug
> report is a good example of that.

I saw a place to put test code showing the problem, but no place for
failing and expected output.  Where should I put that?  In the
description of the bug itself?

Also, is it possible to submit bugs by e-mail, the way I can with
Debian?

\start
Date: Tue, 14 Oct 2003 18:39:56 +0200
From: David Mentre
To: Dylan Thurston
Subject: About Savannah bug reports (was: Re: Small TeX	output patch)

Hello Dylan,

Dylan Thurston writes:

> I didn't see how to do this.  But also, I would like to get
> notifications of new bugs (and maybe also CVS updates) myself; is this
> possible?

Yes. It is _possible_ (but not quickly done). We just need to create a
new mailing list (axiom-dev-announce for example), and subscribe to it
the BTS. For CVS updates, it is possible to install the CVSreport
program, available on Savannah. I already have done it for another
Savannah project. 

Should I do this for Axiom?

> I don't think I have the permissions to set the bug Severity, or I would
> have done so...

Oh yes. Maybe. I usually log onto savannah with project administrator
rights, so I might see some fields that other users don't. I have check:
I cannot make it available for non project member.

In other word, if you create a Savannah account and I add you as a
project member, you'll have access to those fields.

But otherwise, I set the severity when looking at bugs. You can also add
a comment in the bug report itself.

> I saw a place to put test code showing the problem, but no place for
> failing and expected output.  Where should I put that?  In the
> description of the bug itself?

Yes, in the "Original Submission:" part.

I would place the failing output into "Error message:" part.

All those rules are just guides and should be adapted to any specific
case.


> Also, is it possible to submit bugs by e-mail, the way I can with
> Debian?

I don't think so. You should submit a bug report on the savannah project
on Savannah. ;)

\start
Date: Tue, 14 Oct 2003 18:48:06 +0200
From: David Mentre
To: Dylan Thurston
Subject: Re: About Savannah bug reports

David Mentre writes:

> In other word, if you create a Savannah account and I add you as a
> project member, you'll have access to those fields.

ok, I've just seen that you have solve this issue. ;)

\start
Date: Tue, 14 Oct 2003 19:22:33 +0200
From: David Mentre
To: list
Subject: On literate programming (or the use of noweb)

Hello,

I have recently used literate programming and more specifically
noweb. I'd like to share my experience, from a software engineering
point of view. If you find this boring, just skip this email.

I have used noweb on:

 - a network processing program in C

 - a client/server in Objective Caml (with some XDR (C-like syntax))

 - a formal model in Promela (for Spin verifier)


I use deliberately a very restricted form of chunk inclusion. Basically:

 Explanation on f1...                        (1)
<<my_file.lisp>>=
(defun f1 ...)
@

 Explanation on f2...
<<my_file.lisp>>=
(defun f2 ...)
@

 Explanation on the complicated algo using f1 and f2...
<<my_file.lisp>>=
(f1 () (f2 ...))
@

It is just concatenation of various code chunks in a file. 

In fact, I find the other use of noweb chunks:

<<my chunk>>=                                (2)
(defun f...)
@

<<my_file.lisp>>=
(map ... <<my chunk>> ...)
@

...*very* dangerous. It is just a simple text expansion as would do a C
#define. You lose, for example, all the good properties of Lisp macro
definition with macro parameters renaming.


I also try to stick as much as possible to the programming language that
I am using. For example, OCaml uses text scope for parameters
definition, so I avoid using noweb chunks to define functions in
different order. Each file in the original language as its counterpart
as noweb file. 

One issue I have done on the literate C program was that all the modules
of the C program were in the same noweb source file. After some times,
it was a total mess.

Of course, each rule has its exceptions. For example, Promela hasn't any
capabilities to define functions, so I have used noweb chunks to define
some kind of macro.


To conclude, I would advise the following rules for the use of noweb
into the Axiom project:

 1. avoid as much as possible the definition of code chunk which are
    _included_ in other chunks. Prefer concatenation of code chunks. In
    short, prefer form (1) over (2);

 2. restrict yourself to the capabilities of your language. For example,
    define and use Lisp macros and not noweb chunks as lisp macros.


What is your opinion?


I hope it brings something to the general issue of software design and
coding.

\start
Date: Tue, 14 Oct 2003 14:20:28 -0400
From: Tim Daly
To: David Mentre
Subject: chunking

In fact chunks (except in makefiles) chunks are only used to 
"lift" pieces of text from the main <<*>> chunk for explanation.
I'm unaware of any place where I use chunks within chunks.

The primary use of chunking is to reorder the program source into
a document-style of explanation. If I'm working on the system and
get a deeper understanding of a function, heavily modify a function,
or generally have something special to say I will lift the function
into a chunk, make it a section or subsection, and include documentation.

Within the top level makefile (only, as far as I know) the
chunk-within-chunk pattern is used to customize the Makefile.${SYS}
chunks. Since this involves repeated code that has to be included
in many different outputs it is useful to define the chunk in one
place and use it in multiple places. 

\start
Date: Tue, 14 Oct 2003 17:41:16 -0400
From: Dylan Thurston
To: list
Subject: Left shifts of negative numbers

I have investigated Bug #4733 (rounding of negative numbers).  The
problem is unexpected behaviour of 'shift' with negative arguments:
'shift(-7,-1)' is -4, while the code in the 'truncate' function in
float.spad.pamphlet clearly expects the answer to be -3 in this case.
The definition of what 'shift' should do in IntegerNumberSystem is
ambiguous about what should happen with negative arguments, but in
integer.spad.pamphlet 'shift' is actually implemented with a call to the
lisp function 'ash'; according to the standard I found on the web (see
http://www.lispworks.com/reference/HyperSpec/Body/f_ash.htm#ash), 'ash'
should have the opposite behaviour: '(ash -7 -1)' should be -4 (as GCL
implements).

Presumably the correct fix involves changing 'shift' so that it rounds
towards 0 when both arguments are negative (and documenting how it
actually behaves), rather than changing the code in float.spad to deal
with the current behaviour?  What will other axiom code expect?  Most of
the instances in the algebra tree seem to apply 'shift' only when the
first argument is positive.

\start
Date: Tue, 14 Oct 2003 19:06:07 -0400
From: Bill Page
To: Dylan Thurston
Subject: RE: Left shifts of negative numbers

Dylan,

[ Some of your emails arrive as text file attachments to
otherwise empty emails (such as this one) and other times
as ordinary email? Are you sending an unusual format to
the axioim mailing list? (e.g. HTML or "rich text" format). ]

I agree with your analysis. Note that a similar but
different defintion of shift is given in si.spad.pamphlet
(SingleInteger)

  shift(x,n) == QSLEFTSHIFT(x,n)$Lisp

In Axiom both

  -> )lisp (ASH -7 -1)

and

  -> )lisp (QSLEFTSHIFT -7 -1)

return -4. Oddly, I could not find any definition for
QSLEFTSHIFT. ASH is an "arithmetic" shift. I looked for
a Lisp function for "logical" shift (as found in some
machine architectures) but did not find any. In Axiom
I can write

  -> ASH(-7,-1)$Lisp

but

  -> QSLEFTSHIFT(-7,-1)$Lisp

says: "QSLEFTSHIFT is not a lisp function ..." ???

Maybe some of the Lisp programmers here can give us a
clue as to why?

Failing finding a native Lisp function that does the
job, how about defining it as

  shift(x,y) == integer(ASH(x-1,y)$Lisp)+1

> I have investigated Bug #4733 (rounding of negative numbers).
> The problem is unexpected behaviour of 'shift' with negative
> arguments: 'shift(-7,-1)' is -4, while the code in the
> 'truncate' function in float.spad.pamphlet clearly expects the
> answer to be -3 in this case. The definition of what 'shift'
> should do in IntegerNumberSystem is ambiguous about what should
> happen with negative arguments, but in integer.spad.pamphlet
> 'shift' is actually implemented with a call to the lisp function
> 'ash'; according to the standard I found on the web (see

http://www.lispworks.com/reference/HyperSpec/Body/f_ash.htm#ash

> ), 'ash' should have the opposite behaviour: '(ash -7 -1)'
> should be -4 (as GCL implements).
>
> Presumably the correct fix involves changing 'shift' so that
> it rounds towards 0 when both arguments are negative (and
> documenting how it actually behaves), rather than changing
> the code in float.spad to deal with the current behaviour?
> What will other axiom code expect?  Most of the instances in
> the algebra tree seem to apply 'shift' only when the first
> argument is positive.

\start
Date: Tue, 14 Oct 2003 20:00:42 -0400
From: Bill Page
To: Dylan Thurston
Subject: RE: Left shifts of negative numbers

Dylan,

You wrote:

>...
> An alternative is
> 
>   shift(x,y) == -integer(ASH(-x,y)$LISP)
> 
> which might be clearer.
> 

I think

  shift(x,y) == sign(x)*integer(ASH(sign(x)*x,y)$Lisp

should be ok for all cases?

\start
Date: Tue, 14 Oct 2003 21:32:10 -0400
From: Dylan Thurston
To: list
Subject: Differential equations?

Has anyone successfully run any differential equation examples?  See
bug #5975, but there's no useful information there.

\start
Date: Tue, 14 Oct 2003 22:02:49 -0400
From: Tim Daly
To: Bill Page
Subject: Re: algebra cycles again (was: Left shifts of	negative numbers)

I'm buried on three other paths so I can't research this at the moment.
Things to know:

1 QSLEFTSHIFT is a lisp macro (vmlisp.lisp) so it won't show up in 
  open code and is only used during compile time. The QS* functions
  are heavily type-specified so that the lisp compiler can generate
  optimal code.
  
2 The shift function in SingleInteger has the SPADreplace property
  (see SINT.NRLIB/code.lsp). That means that algebra code that uses
  shift will be replaced by a call to QSLEFTSHIFT at compile time.
  The line you are looking for reads:

  (PUT (QUOTE |SINT;shift;3$;44|) (QUOTE |SPADreplace|) (QUOTE QSLEFTSHIFT))

  In the interpreter you'll find the symbol |SINT;shift;3$;44|
  has the property |SPADreplace| on the property list 
  with the value QSLEFTSHIFT
  which the compiler uses to open-code the shift function.

3 Bootstrap issues make the change harder. You have to be sure that
  algebra code has not compiled the previous macro definition of
  QSLEFTSHIFT inline (and there is no indication if it has that 
  you will be able to see without reading the generated code).

4 shift is HIGHLY optimized. if you change it you need to use lisp
  disassemble to examine the code generated by the compiler. The
  SINT domain is on the critical path for nearly everything.

The moral is to change it carefully, optimize the hell out of it,
and test it heavily.

\start
Date: Tue, 14 Oct 2003 22:18:17 -0400
From: Tim Daly
To: Dylan Thurston
Subject: Re: algebra cycles again (was: Left shifts of	negative numbers)

Dylan,

Unfortunately I can't even look further at the issue now. I'm buried.

\start
Date: Tue, 14 Oct 2003 19:40:52 -0400
From: Bill Page
To: Dylan Thurston
Subject: algebra cycles again (was: Left shifts of negative numbers)

Dylan,

On Tuesday, October 14, 2003 7:19 PM you wrote:

> ... 
> > Failing finding a native Lisp function that does the
> > job, how about defining it as
> > 
> >   shift(x,y) == integer(ASH(x-1,y)$Lisp)+1
> 
> In the case when x and y are both negative, I think this gives the
> "round towards zero" semantics that seem to be expected.  An
> alternative is
> 
>   shift(x,y) == -integer(ASH(-x,y)$LISP)
> 
> which might be clearer.
> 

Ok, I will buy that.

Unfortunately INT, SINT, and NNI are all bootstrapped so
replacing the code and testing is a little more involved.
Do you want to try it, or shall I?

BTW, I noticed that in the algebra/Makefile.pamphlet Tim
uses

 SETCAT -> SINT -> UFD -> GCDDOM -> COMRING -> RING ->
   RNG -> ABELGRP -> CABMON -> ABELMON -> ABELSG -> SETCAT

as an example of cycle in Axiom's type system. It occurs
to me that perhaps changes such as you suggested (removing
the Latex stuff from SETCAT) might help to eliminate *some*
of this sort of thing.

I am still not sure whether cycles of this kind are a
good thing or a bad thing ...

\start
Date: Tue, 14 Oct 2003 21:30:40 -0400
From: Dylan Thurston
To: Bill Page
Subject: Re: Left shifts of negative numbers

On Tue, Oct 14, 2003 at 09:09:50PM -0400, Page, Bill wrote:
> Does
> 
>   shift(x,y) == -integer(ASH(-x,y)$Lisp
> 
> involve two (potential long) integer multiplications?
> I.e. -1*integer(ASH(-1*x,y)$Lisp

I don't know whether adding/subtracting 1 or negation will be faster,
but either one should be faster than any multiplication (unless
multiplication by -1 is special cased somewhere).  There are no carries
to worry about.

I suspect the additions are probably faster, actually.

\start
Date: Tue, 14 Oct 2003 22:48:28 -0400
From: Dylan Thurston
To: list
Subject: Re: Left shifts of negative numbers

On Tue, Oct 14, 2003 at 07:06:07PM -0400, Page, Bill wrote:
> [ Some of your emails arrive as text file attachments to
> otherwise empty emails (such as this one) and other times
> as ordinary email? Are you sending an unusual format to
> the axioim mailing list? (e.g. HTML or "rich text" format). ]

It's because I habitually sign my e-mails, and that's how the mailing
list software deals with it.  I'll stop if it's too annoying.

> ... Oddly, I could not find any definition for
> QSLEFTSHIFT.

It's defined as a macro equivalent to ash for fixnum's in
src/interp/vmlisp.lisp.pamphlet.

> Failing finding a native Lisp function that does the
> job, how about defining it as
> 
>   shift(x,y) == integer(ASH(x-1,y)$Lisp)+1

In the case when x and y are both negative, I think this gives the
"round towards zero" semantics that seem to be expected.  An
alternative is

  shift(x,y) == -integer(ASH(-x,y)$LISP)

which might be clearer.

\start
Date: Tue, 14 Oct 2003 22:48:12 -0400
From: Dylan Thurston
To: list
Subject: Re: Left shifts of negative numbers

On Tue, Oct 14, 2003 at 08:00:42PM -0400, Page, Bill wrote:
> I think
> 
>   shift(x,y) == sign(x)*integer(ASH(sign(x)*x,y)$Lisp
> 
> should be ok for all cases?

Yes, but I think we should avoid multiplications here.  Remember that
the integers may be long...

\start
Date: Tue, 14 Oct 2003 22:23:20 -0400
From: Bill Page
To: Dylan Thurston
Subject: RE: algebra cycles again (was: Left shifts of negative numbers)
Cc: Bill Page

Dylan, Tim;

Now Tim has scared me too! <grin>

I am in favour of just changing the use of shift
in float.spad.

> 
> On Tue, Oct 14, 2003 at 10:02:49PM -0400, Tim Daly wrote:
> > 4 shift is HIGHLY optimized. if you change it you need to use lisp
> >   disassemble to examine the code generated by the compiler. The
> >   SINT domain is on the critical path for nearly everything.
> 
> OK.  It seems like maintaining the behaviour float.spad seems to be
> expecting is going to be slower than the current situation.  How
> loudly will anyone object if we leave 'shift' so that it does what
> Common Lisp calls an 'arithmetic shift' (i.e., shift(-7,-1) = -4), and
> change the code in float.spad?

\start
Date: Tue, 14 Oct 2003 22:49:52 -0400
From: Dylan Thurston
To: Bill Page
Subject: Re: algebra cycles again (was: Left shifts of negative numbers)

On Tue, Oct 14, 2003 at 10:23:20PM -0400, Page, Bill wrote:
> Dylan, Tim;
> 
> Now Tim has scared me too! <grin>
> 
> I am in favour of just changing the use of shift
> in float.spad.

OK, I'll do that when I get a chance, as well as taking a look at the
code in contfrac.spad.pamphlet, which was the only other use of 'shift'
I saw that might be affected by this issue.

\start
Date: Tue, 14 Oct 2003 21:09:50 -0400
From: Bill Page
To: Dylan Thurston
Subject: RE: Left shifts of negative numbers

Does

  shift(x,y) == -integer(ASH(-x,y)$Lisp

involve two (potential long) integer multiplications?
I.e. -1*integer(ASH(-1*x,y)$Lisp


> 
> Yes, but I think we should avoid multiplications here.
> Remember that the integers may be long...

\start
Date: Tue, 14 Oct 2003 22:48:00 -0400
From: Dylan Thurston
To: list
Subject: Re: algebra cycles again (was: Left shifts of negative numbers)

On Tue, Oct 14, 2003 at 07:40:52PM -0400, Page, Bill wrote:
> Unfortunately INT, SINT, and NNI are all bootstrapped so
> replacing the code and testing is a little more involved.
> Do you want to try it, or shall I?

That scares me a bit.  Can you do it, and record the steps involved?

But I don't think NNI (NonNegativeInteger) should need any changes,
since there's no difference when the arguments are positive...

Maybe it's worth writing some code to check that the generated .lisp
files are the same as the cached ones?  Or is that already written?

> BTW, I noticed that in the algebra/Makefile.pamphlet Tim
> uses
> 
>  SETCAT -> SINT -> UFD -> GCDDOM -> COMRING -> RING ->
>    RNG -> ABELGRP -> CABMON -> ABELMON -> ABELSG -> SETCAT
> 
> as an example of cycle in Axiom's type system. It occurs
> to me that perhaps changes such as you suggested (removing
> the Latex stuff from SETCAT) might help to eliminate *some*
> of this sort of thing.

Well, this one would go away if the 'hash' function were removed from
SETCAT.  It's the obvious weak link in that chain; the others are all
very reasonable.  (Except that integers mod a power of 2
are not actually a UFD...)

I thought at first that the 'hash' function was better than 'latex',
but now I see that that's not true: if the type doesn't support proper
equality testing, it's not safe to use hash, and if it does, then
there's always a fall-back (although slower) algorithm, and by having
a separate 'Hashable' class and checking 'if T has Hashable then ...'
you could arrange for all algorithms to run as fast in practice.

> I am still not sure whether cycles of this kind are a
> good thing or a bad thing ...

There may be cases when cycles are necessary, but I don't think this
is one.

\start
Date: Tue, 14 Oct 2003 22:29:55 -0400
From: Bill Page
To: Tim Daly
Subject: RE: algebra cycles again (was: Left shifts of negative numbers)

Tim,

Thanks for taking the time to explain all this.

I was especially mystified by the code in float.spad that
defines:

  shift(x:%,n:I) == [x.mantissa,x.exponent+n]

but you wrote:

> ...
> Things to know:
> 
> ...   
> 2 The shift function in SingleInteger has the SPADreplace property
>   (see SINT.NRLIB/code.lsp). That means that algebra code that uses
>   shift will be replaced by a call to QSLEFTSHIFT at compile time.
>   The line you are looking for reads:
> 
>   (PUT (QUOTE |SINT;shift;3$;44|) (QUOTE |SPADreplace|) 
> (QUOTE QSLEFTSHIFT))
> 
>   In the interpreter you'll find the symbol |SINT;shift;3$;44|
>   has the property |SPADreplace| on the property list 
>   with the value QSLEFTSHIFT
>   which the compiler uses to open-code the shift function.
> 

Wow! I think that explains a lot...

\start
Date: Tue, 14 Oct 2003 23:47:32 -0400
From: Bill Page
To: list
Subject: RE: algebra cycles again (was: Left shifts of negative numbers)

On Tuesday, October 14, 2003 10:30 PM I wrote:
> 
> I was especially mystified by the code in float.spad that
> defines:
> 
>   shift(x:%,n:I) == [x.mantissa,x.exponent+n]
> 

On second (or is it third?) thought, this is not really
mysterious. The above definition of shift is for the
case where the first argument is a Float. This definition
is correct and not directly affected by the problem with
shift for negative integer arguments.

\start
Date: Tue, 14 Oct 2003 21:01:44 -0400
From: Dylan Thurston
To: Bill Page
Subject: Re: Left shifts of negative numbers

On Tue, Oct 14, 2003 at 08:00:42PM -0400, Page, Bill wrote:
> I think
> 
>   shift(x,y) == sign(x)*integer(ASH(sign(x)*x,y)$Lisp
> 
> should be ok for all cases?

Yes, but I think we should avoid multiplications here.  Remember that
the integers may be long...

\start
Date: Tue, 14 Oct 2003 23:52:18 -0400
From: Tim Daly
To: Bill Page
Subject: Re: algebra cycles again (was: Left shifts of negative numbers)

didn't mean to scare anyone. it is just that there are several 
things that are not apparent. i'd recommend trying to build a
system with your changes, look at the generated lisp code,
look at the compiled code, look at where the code you are 
changing is used in the rest of the library, etc. 
and ask questions. i can't tell you everything but i can give
you guys some idea of the issues if you ask particular questions.

\start
Date: Tue, 14 Oct 2003 23:57:31 -0400
From: Bill Page
To: Dylan Thurston
Subject: Re: algebra cycles again

Dylan,

On Tuesday, October 14, 2003 10:48 PM you wrote:

[about modifying spad files that involve a bootstrap]

> ... 
> Maybe it's worth writing some code to check that the
> generated .lisp files are the same as the cached ones?
> Or is that already written?

No, as far as I know this hasn't been written. But I
agree that it would be a good idea. However it is
apparently not trivial since the symbols in the generated
lisp code do not seem to be the same as those in the
at least the current bootstrap lisp code. Perhaps the
current bootstrap lisp code was not generated by GCL?

If re-generating the bootstrap code from the newly
compiled bootstrapped modules will stablize the names,
then a comparison (the next time around) would be
fairly trivial. Otherwise a more intellegence "equivalence"
test might be required.

In any case, if we really do need to depend on iteratively
compiling the algebra code containing cycles to a "fixed
point" solution, then such a comparison will ultimately
have to be written.

> 
> > BTW, I noticed that in the algebra/Makefile.pamphlet Tim
> > uses
> > 
> >  SETCAT -> SINT -> UFD -> GCDDOM -> COMRING -> RING ->
> >    RNG -> ABELGRP -> CABMON -> ABELMON -> ABELSG -> SETCAT
> > 
> > as an example of cycle in Axiom's type system. It occurs
> > to me that perhaps changes such as you suggested (removing
> > the Latex stuff from SETCAT) might help to eliminate *some*
> > of this sort of thing.
> 
> Well, this one would go away if the 'hash' function were
> removed from SETCAT.  It's the obvious weak link in that
> chain; the others are all very reasonable.  (Except that
> integers mod a power of 2 are not actually a UFD...)
> 
> I thought at first that the 'hash' function was better than
> 'latex', but now I see that that's not true: if the type
> doesn't support proper equality testing, it's not safe to
> use hash, and if it does, then there's always a fall-back
> (although slower) algorithm, and by having a separate
> 'Hashable' class and checking 'if T has Hashable then ...'
> you could arrange for all algorithms to run as fast in
> practice.

I tentatively agree with you about this. I think it would
be worth a test to see what impact removing the hash function
from SETCAT might have on the rest of the type system.

> 
> > I am still not sure whether cycles of this kind are a
> > good thing or a bad thing ...
> 
> There may be cases when cycles are necessary, but I don't
> think this is one.
> 

\start
Date: Wed, 15 Oct 2003 00:23:42 -0400
From: Bill Page
To: list
Subject: RE: algebra cycles again (was: Left shifts of negative numbers)

Axiom Developers,

In case you didn't get the automatic notice...
I've posted a patch to float.spad.pamphlet at

https://savannah.nongnu.org/patch/index.php?group_id=2938
&func=detailpatch&patch_id 74

to correct Bug #4733 (rounding of negative numbers).
After applying the patch, just re-compile Axiom using
the command

  make

in the axiom root directory.

So far I have done only preliminary testing.

Dylan, I let you continue to analyze contfrac.
Thanks.
> 
> On Tue, Oct 14, 2003 at 10:23:20PM -0400, Page, Bill wrote:
> > Dylan, Tim;
> > 
> > Now Tim has scared me too! <grin>
> > 
> > I am in favour of just changing the use of shift
> > in float.spad.
> 
> OK, I'll do that when I get a chance, as well as taking a look
> at the code in contfrac.spad.pamphlet, which was the only other
> use of 'shift' I saw that might be affected by this issue.

\start
Date: Wed, 15 Oct 2003 18:43:29 +0200
From: David Mentre
To: Tim Daly
Subject: Re: chunking

Hello Tim,

Tim Daly writes:

> The primary use of chunking is to reorder the program source into
> a document-style of explanation. 

That's what I wanted to avoid: moving code chunks to fits the
documentation. In my modest experience, it is better to follow usual
coding practice for the given language. I may be wrong. Time will tell.

\start
Date: Wed, 15 Oct 2003 12:34:06 -0400
From: Tim Daly
To: David Mentre
Subject: re: coerce, cast, partial fractions

David Mentre writes:
> Tim Daly writes:
> 
> > The primary use of chunking is to reorder the program source into
> > a document-style of explanation. 
> 
> That's what I wanted to avoid: moving code chunks to fits the
> documentation. In my modest experience, it is better to follow usual
> coding practice for the given language. I may be wrong. Time will tell.

Knuth invented the machinery for literate programming because he felt
that the explanation of code should be arranged for the human needs
not for machine requirements. If you look at the TeX literate sources
you'll find he completely rearranges all of TeX to fit the need to
explain design choices.

I expect the Axiom code to be embedded in research papers (see
dhmatrix.spad.pamphlet) and textbook sources. The code should appear
"at the natural location" for the explanation.

So the whole point of chunking is the ability to move code.

If you don't move the code then all you have are "inline comments"
rather than literate programs. Inline comments are insufficient
to handle mixing research results, which are the primary items of
interest, with reduction to practice (that is, the code) which is
secondary and subject to change.

So far we have almost no research results embedded in the algebra
code so code chunking is only used to implement bootstrapping.
I expect this to change in the future. I have permission to use
several research papers and when I get the world stable I plan
to start with the research papers to re-chunk and rewrite the
algebra. We want the algebra directory to combine the mathematics
with the code. Otherwise no-one will be able to maintain and
extend the system. There is hardly a word of text about the
theory behind the integration code, not a comment about extending
the field of constants, not a hint of practical concerns of
intermediate expression swell, no discussion of missing cases.
The code is "just there". 

Beyond the math research there are computational mathematics issues
that need to be explained. For instance, how are domains created
by the compiler? What optimizations take place, where are they
done, and why? (See my note about SINT yesterday. I'm one of the
few people who know what these optimizations are, where they are,
why they are important, )

Think of Axiom as a huge mathematical library of textbooks
rather than a huge pile of code.

\start
Date: Wed, 15 Oct 2003 13:30:07 -0400
From: Dylan Thurston
To: David Mentre
Subject: re: chunking

On Wed, Oct 15, 2003 at 06:43:29PM +0200, David MENTRE wrote:
> Hello Tim,
> 
> Tim Daly writes:
> 
> > The primary use of chunking is to reorder the program source into
> > a document-style of explanation. 
> 
> That's what I wanted to avoid: moving code chunks to fits the
> documentation. In my modest experience, it is better to follow usual
> coding practice for the given language. I may be wrong. Time will tell.

I have some limited experience with Haskell literate programs.  Haskell
does not provide any mechanism to move chunks in literate programs, but
in practice it is not at all an issue: since definitions are almost
invariably short and can appear in any order, there are few constraints
on natural writing style.  Axiom may well be the same way, with the
possible exception of the interface/implementation split.

\start
Date: Wed, 15 Oct 2003 20:36:34 +0200
From: David Mentre
To: Tim Daly
Subject: re: coerce, cast, partial fractions

Tim Daly writes:

> Knuth invented the machinery for literate programming because he felt
> that the explanation of code should be arranged for the human needs
> not for machine requirements. If you look at the TeX literate sources
> you'll find he completely rearranges all of TeX to fit the need to
> explain design choices.

But sometimes machine requirements help understand human needs. It was
at least my feeling for literate OCaml code.

How many people have read the TeX book and understood it? Don't forget
that Knuth has designed his tools at a time were languages were quite
restricted. Nowadays, we have more elaborated tools, at the language
level. 

I have tried to read Knuth book on graph algorithms (which is also using
literate programming). I found his code hard to follow. Just my own
experience.

> I expect the Axiom code to be embedded in research papers (see
> dhmatrix.spad.pamphlet) and textbook sources. The code should appear
> "at the natural location" for the explanation.

I'll take a more deep look at dhmatrix.spad.pamphlet.

> So the whole point of chunking is the ability to move code.
>
> If you don't move the code then all you have are "inline comments"
> rather than literate programs. Inline comments are insufficient
> to handle mixing research results, which are the primary items of
> interest, with reduction to practice (that is, the code) which is
> secondary and subject to change.

Ok, you are probably right. But my own feeling is that inline comment is
sufficient for most of the code. This does not preclude the use of more
well chosen code chunk for very difficult points or introductory
overview.

PS: Tim, what have you done at the CVS tree? It seems that the whole
    Axiom source tree need to be recompiled.

\start
Date: Wed, 15 Oct 2003 14:29:23 -0400
From: Tim Daly
To: David Mentre
Subject: literate programs

I claim that Axiom is different from most programs. Most programs
can be supported by inline comments. Java code (sorry Bill) is
a good example. The Javadoc mechanism is sufficient to document
the various class files in a disciplined way. I can generally
figure out how to use a class given the Javadoc.

Axiom is different. Axiom programming requires that you understand
both math and computer science. You need to understand the math theory
to make, modify, and maintain the math. Javadoc (and inline comments)
will not be sufficient. 

I also claim (as long as I'm making wild, unsubstantiated claims)
that all computational mathematics software will eventually require
literate programming to keep the expertise with the code.

We've all been trained to think of the code as important.
However, in the long term the mathematical and comp-sci research
results are important. The reduction to practice (the code) needs
to evolve and any instance is less important.

re: changing all of the files
At NAG's request I restored all of the original copyright and license
text. It took about a week and touched almost every file. Sorry about 
that.

\start
Date: Wed, 15 Oct 2003 16:50:33 -0400
From: Tim Daly
To: Joris van der Hoeven
Subject: Re: Axiom
Cc: Bill Page

Joris,

RE: startup problem

You AXIOM variable is set wrong. You must have had a NAG version installed
at some point. Check your .bashrc file (or other shell startup file).
It is probably reset in there.


RE: binary version

We do have a binary version available but it only seems to work on Redhat 9. 
Visit axiom.tenkan.org for the executable binary.

Does anyone know what would be needed to create a statically linked lisp?


RE: configure, make, make install

configure has nothing to do. You have to set the AXIOM variable.
We could include a configure shell script that prints "set the AXIOM variable".

make exists and is used. 

I'll look into an "install" stanza in the root Makefile. Consider it a bug
until this gets fixed.

The whole "configure, make, make install" has an underlying assumption
that you are working in C. We're working mostly in Lisp. In theory I should
be using lisp defsystem rather than makefiles. 

RE: failed compile.

The GCL 2.5.2 build failed. saved_gcl is the name of the gcl 2.5.2 lisp
executable. Make says "Commande introuvable" (which I can't translate).
Redhat 9 ships with GCC 3.2.2 whereas your GCC version is downlevel.
Even my Redhat 7.3 system shipped with GCC 2.96. 

\start
Date: Wed, 15 Oct 2003 23:47:07 +0200
From: David Mentre
To: Tim Daly
Subject: Re: Axiom
Cc: Bill Page

Tim Daly writes:

> Does anyone know what would be needed to create a statically linked
> lisp?

Not tested: do 'CFLAGS=--static ./configure' at configure step when
            building GCL. 

Another approach: 'CC="gcc --static" ./configure', still at configure
            level for GCL.

I think second approach has more chance to work correctly.

> Make says "Commande introuvable" (which I can't translate).
             ^^"Command not found"

\start
Date: Wed, 15 Oct 2003 23:25:14 -0400
From: Tim Daly
To: Dylan Thurston, David Mentre
Subject: infinity in tex mode

Dylan,

I applied your change, rebuilt the system, tested it, and uploaded
the changed file to CVS.

David,

The tex infinity bug should be closed.

\start
Date: Thu, 16 Oct 2003 12:15:51 +0200 (CEST)
From: Joris van der Hoeven
To: Tim Daly
Subject: Re: Axiom
Cc: Bill Page, Joris van der Hoeven

> RE: binary version
>
> We do have a binary version available but it only seems to work on Redhat 9.
> Visit axiom.tenkan.org for the executable binary.
>
> Does anyone know what would be needed to create a statically linked lisp?

For RedHat distributions, you should also create an RPM.
I understand that all this is quite a burdern, but I really think that
this should be your highest priority now that Axiom compiles for you.

> The whole "configure, make, make install" has an underlying assumption
> that you are working in C. We're working mostly in Lisp. In theory I should
> be using lisp defsystem rather than makefiles.

Yet, ./configure, make, make install is the (GNU) standard for other
languages too. GNU Emacs is written in lisp too...

\start
Date: Thu, 16 Oct 2003 06:42:29 -0400
From: Tim Daly
To: Joris van der Hoeven, Camm Maguire
Subject: Re: Axiom
Cc: Bill Page

Joris,

Re: rpms 

An rpm is coming. Documentation is my highest priority (Bill Page
did an Axiom tutorial using TeXmacs. Your feedback is welcome).
My schedule is more shortest-job-first so minor changes happen
in a reasonable amount of time. I'm unskilled in making rpms
so I have to try making a few first anyway.

Re: configure

I'll understand your point and will consider it further.

Re: sorry

Don't worry. If you have problems and you are an experienced 
"build-from-sources" user then we have more work to do.
I appreciate your feedback.

Re: removing mnt/linux

I suppose the "make install" should make the AXIOM variable disappear.
The "axiom" command is supposed to be a shell script and will be again
in the future. I need to change this soon so it'll be on the shortest
job list.

Re: "last really stable version of gcc"

Yeah, I understand. I'm in a struggle to compile Magnus which is a 
huge C++ program that died of code-rot because some damn fool 
decided to change the C++ language "standard". But my attitude is
that you have to keep up with the changes so I really have no choice
but to buy a new C++ book, get educated, and rewrite the code. Pain,
pain, endless pain. 

\start
Date: Thu, 16 Oct 2003 06:43:23 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: static lisp and rpms

Camm, 

do you have any advice on building a static lisp?
I'm going to try David's suggestion (CC="gcc -static").

\start
Date: Thu, 16 Oct 2003 12:50:07 +0200 (CEST)
From: Joris van der Hoeven
To: Tim Daly
Subject: Re: Axiom
Cc: Camm Maguire, Bill Page, Joris van der Hoeven

> An rpm is coming.

Great.

> Documentation is my highest priority (Bill Page
> did an Axiom tutorial using TeXmacs. Your feedback is welcome).

Will do.

> My schedule is more shortest-job-first so minor changes happen
> in a reasonable amount of time. I'm unskilled in making rpms
> so I have to try making a few first anyway.

Count between one day and two days of work.

> Re: configure
>
> I'll understand your point and will consider it further.

Thanks.

> Re: removing mnt/linux
>
> I suppose the "make install" should make the AXIOM variable disappear.

Yes, but it is good to have a directory structure which is as clean
as possible too. I see no point in having these useless unary directories
mnt and linux around in a binary tarball.

> Re: "last really stable version of gcc"
>
> Yeah, I understand. I'm in a struggle to compile Magnus which is a
> huge C++ program that died of code-rot because some damn fool
> decided to change the C++ language "standard". But my attitude is
> that you have to keep up with the changes so I really have no choice
> but to buy a new C++ book, get educated, and rewrite the code. Pain,
> pain, endless pain.

The point is that the whole gcc-3.* series has been *severely bugged*.
In my case, all code is conform to the previous and current C++,
but the new C++ optimizer just sucks. Things seem to improve a bit
in the very last versions though.

\start
Date: Thu, 16 Oct 2003 13:00:04 +0200 (CEST)
From: Joris van der Hoeven <Joris van der Hoeven>
To: Tim Daly
Subject: tm_axiom
Cc: Camm Maguire, Bill Page, Joris van der Hoeven

What happened with the tm_axiom script since our last discussion?
Do we have something which is compatible with both Axioms now?
As soon as this is the case, I will include it in TeXmacs.

\start
Date: Thu, 16 Oct 2003 07:05:39 -0400
From: Tim Daly
To: Joris van der Hoeven
Subject: Re: tm_axiom
Cc: Camm Maguire, Bill Page

Joris,

I believe the decision was that we should make it part of the axiom
distribution rather than texmacs. There is a legacy issue because
of the previous Axiom (which has been off the market for 2 years)
is still being considered. I have to get a copy of the latest version.

I suppose the current answer is that tm_axiom will become part of
the distribution and magically installed as part of "make install".
Heck, we could even use "configure" to find texmacs. :-)

\start
Date: Thu, 16 Oct 2003 13:14:10 +0200 (CEST)
From: Joris van der Hoeven
To: Tim Daly
Subject: Re: tm_axiom
Cc: Camm Maguire, Bill Page

> I suppose the current answer is that tm_axiom will become part of
> the distribution and magically installed as part of "make install".

That is OK with me, but what do we do with the old version of Axiom?
Just let it burn in hell?

> Heck, we could even use "configure" to find texmacs. :-)

You may want to use `texmacs --path` or `texmacs --binpath`.

\start
Date: Thu, 16 Oct 2003 07:23:31 -0400
From: Tim Daly
To: Joris van der Hoeven
Subject: Re: tm_axiom
Cc: Camm Maguire, Bill Page

re: NAG Axiom

I've offered to pick up support for the prior Axiom, including if
necessary, providing gratis contract work thru NAG. The response
is that would require access to sources that were not released and
they cannot do that. I don't understand why a contract employee
can't see source code but that's the decision.

I can still support the current NAG Axiom users for algebra.
They can recompile changes to the algebra files and install them.
Currently all of the algebra sources are in old Axiom format
under mnt/linux/src/algebra.

re: texmacs and tm_axiom

Suppose I had tm_axiom in the current directory.
Suppose I had texmacs installed in /usr/local/texmacs.
Can you give me a idea of "install" instructions for tm_axiom into texmacs?

\start
Date: Thu, 16 Oct 2003 07:56:03 -0400
From: Tim Daly
To: list
Subject: synthesis

*,

There are several requests under consideration.

David and Joris have been calling for a "configure" command.
Dylan and Bill have been trying to set up tm_axiom with texmacs.
Camm and Juergen have asked to use the already installed lisp.
Joris would like a static version of the system.
Dylan would like the make variables to be available everywhere.
I've been wondering about platform-specific complexity.

I may have the names wrong but the point is that I'm now convinced
that I have to change direction.

./configure can be used to attack all of these problems.
So I'll write up an initial script, post it, and we can play with it.

\start
Date: Thu, 16 Oct 2003 14:51:36 +0200 (CEST)
From: Joris van der Hoeven 
To: Tim Daly
Subject: Re: tm_axiom
Cc: Camm Maguire, Bill Page, Andrey G. Grozin

> re: NAG Axiom
>
> I've offered to pick up support for the prior Axiom, including if
> necessary, providing gratis contract work thru NAG. The response
> is that would require access to sources that were not released and
> they cannot do that. I don't understand why a contract employee
> can't see source code but that's the decision.
>
> I can still support the current NAG Axiom users for algebra.
> They can recompile changes to the algebra files and install them.
> Currently all of the algebra sources are in old Axiom format
> under mnt/linux/src/algebra.

OK, so without any cooperation from NAG, we should probably
drop the old tm_axiom, except if Andrey Grozin finds a way to
keep it working.

> re: texmacs and tm_axiom
>
> Suppose I had tm_axiom in the current directory.
> Suppose I had texmacs installed in /usr/local/texmacs.
> Can you give me a idea of "install" instructions for tm_axiom into texmacs?

First of all, you should really distribute the entire axiom plugin if
you want to distribute the tm_axiom file. In the current distribution,
this means all what you have in $TEXMACS_PATH/plugins/axiom,
where $TEXMACS_PATH=/usr/local/texmacs for you. In general,
plugins are either installed in $TEXMACS_PATH/plugins (when the user
has root privileges) or in $HOME/.TeXmacs/plugins (for ordinary users).
So you should first try the first and then the second.

\start
Date: Thu, 16 Oct 2003 14:14:54 +0100
From: Mike Dewar
To: Joris van der Hoeven
Subject: Re: tm_axiom
Cc: Camm Maguire, Bill Page, Andrey G. Grozin

On Thu, Oct 16, 2003 at 02:51:36PM +0200, Joris van der Hoeven wrote:
<snip>
> OK, so without any cooperation from NAG, we should probably
> drop the old tm_axiom, except if Andrey Grozin finds a way to
> keep it working.
As I've said several time already the NAG version of Axiom behaves
exactly the same way as the new version as far as I can see.  The only
difference is if you invoke it via the `sman' program rather than
directly, in which case you see two prompts, one for each frame started.  
This would apply equally to both versions, unless sman is changed.

So I don't think its a question of supporting the NAG and Open versions,
its a case of whether you want to be able to use the TeXmacs interface
and sman at the same time.  I believe that our "AXIOMsys" script
provides the same functionality as your "axiom" program.

I find it frustrating to be accused of not cooperating - we have made
every scrap of source code available that we could.  Some of the
remainder we can still use ourselves but not distribute in source form.
However there is other material that we can no longer use ourselves
either, so while the idea of carrying on some kind of voluntary support
network for existing sites is nice it is completely impractical.

\start
Date: 16 Oct 2003 09:34:21 -0400
From: Camm Maguire
To: Tim Daly
Subject: re: Axiom
Cc: Bill Page, Joris van der Hoeven

Greetings!

Tim Daly writes:

> Joris,
> 
> Re: rpms 
> 
> An rpm is coming. Documentation is my highest priority (Bill Page
> did an Axiom tutorial using TeXmacs. Your feedback is welcome).
> My schedule is more shortest-job-first so minor changes happen
> in a reasonable amount of time. I'm unskilled in making rpms
> so I have to try making a few first anyway.
> 

BTW, to the extent the Debian packaging is accepted, an rpm can be
made from it with the program 'alien'.

> Re: "last really stable version of gcc"
> 
> Yeah, I understand. I'm in a struggle to compile Magnus which is a 
> huge C++ program that died of code-rot because some damn fool 
> decided to change the C++ language "standard". But my attitude is
> that you have to keep up with the changes so I really have no choice
> but to buy a new C++ book, get educated, and rewrite the code. Pain,
> pain, endless pain. 
> 

Of course, we might get one of the energetic maxima lisp hackers to
write a c++2cl a la f2cl which they used to compile parts of slatec
into lisp maxima -- anyone for a lisp Magnus project? :-).  I fully
realize this suggestion is just short of ridiculous -- for humor value
only!

\start
Date: 16 Oct 2003 09:28:00 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: static lisp and rpms

Greetings!

Latest 2.6.1 and CVS HEAD has a --enable-static configure option.
There may be some issues when using readline in this mode, but I
haven't yet had a chance to plumb the bottom of that.

Take care,

Tim Daly writes:

> Camm, 
> 
> do you have any advice on building a static lisp?
> I'm going to try David's suggestion (CC="gcc -static").

\start
Date: Thu, 16 Oct 2003 16:10:11 +0200 (CEST)
From: Joris van der Hoeven
To: Mike Dewar
Subject: Re: tm_axiom
Cc: Camm Maguire, Andrey G. Grozin, Bill Page

> > OK, so without any cooperation from NAG, we should probably
> > drop the old tm_axiom, except if Andrey Grozin finds a way to
> > keep it working.
> As I've said several time already the NAG version of Axiom behaves
> exactly the same way as the new version as far as I can see.  The only
> difference is if you invoke it via the `sman' program rather than
> directly, in which case you see two prompts, one for each frame started.
> This would apply equally to both versions, unless sman is changed.
>
> So I don't think its a question of supporting the NAG and Open versions,
> its a case of whether you want to be able to use the TeXmacs interface
> and sman at the same time.  I believe that our "AXIOMsys" script
> provides the same functionality as your "axiom" program.
>
> I find it frustrating to be accused of not cooperating - we have made
> every scrap of source code available that we could.  Some of the
> remainder we can still use ourselves but not distribute in source form.
> However there is other material that we can no longer use ourselves
> either, so while the idea of carrying on some kind of voluntary support
> network for existing sites is nice it is completely impractical.

I am sorry for having accused NAG; I just find it frustrating to
have two tm_axioms for two versions of axiom and nobody able to
produce a tm_axiom which works for both (for whatever reasons).
In the current situation, I honestly do not know what
I am supposed to do.

So I wait for a patch from anyone who is interested in keeping
the old interface alive. Probably one should modify line 266 of
the tm_axiom.c we currently distribute, together with the patches
by David & Bill. If I do not have any patch which works with both
versions within one month from now, then I will exclusively support
the free version of axiom, since this seems to be the only version
which is under active development.

\start
Date: Thu, 16 Oct 2003 09:42:15 -0400
From: Tim Daly
To: Joris van der Hoeven, Bill Page
Subject: tm_axiom
Cc: Mike Dewar

Joris,

I'd rather you continue the support of NAG's version.
If someone installs the free version then the spiffy
new "configure" script can replace the tm_axiom file.

Joris and Bill,

Since I haven't been involved in the texmacs/axiom work 
I need some help setting up the correct configure script.
Where can I find "the entire axiom plugin"? 

\start
Date: Thu, 16 Oct 2003 10:21:05 -0400
From: Bill Page
To: Mike Dewar, Joris van der Hoeven
Subject: Re: tm_axiom
Cc: Camm Maguire, Bill Page, Andrey G. Grozin

Mike,

I expect that no one really intended to imply that NAG
was "not co-operating". As you say, this is very far from
the truth. I think it was a wonderful and bold decision
to make Axiom open source. And I am sure it will be to
everyone's advantage that you, personally, and NAG also
continues to work together with everyone in the open
source Axiom project. Thank you again.

About tm_axiom. What we need to do is just standardize
the *name* of the Axiom interpret sans sman etc. I
propose that starting with the next update to the alpha
version of open source Axiom, we use AXIOMsys as you
suggested, in order to be compatible with the NAG version
of Axiom. (Case insensitive platforms like Windows will
treat this as AXIOMSYS. That should be ok).

Then we will change the new version of tm_axiom so that
it start AXIOMsys. And it should work for both.

Cheers,
Bill Page.

> 
> On Thu, Oct 16, 2003 at 02:51:36PM +0200, Joris van der Hoeven
> wrote:
> <snip>
> > OK, so without any cooperation from NAG, we should probably
> > drop the old tm_axiom, except if Andrey Grozin finds a way to
> > keep it working.
> As I've said several time already the NAG version of Axiom
> behaves exactly the same way as the new version as far as I can
> see.  The only difference is if you invoke it via the `sman'
> program rather than directly, in which case you see two prompts,
> one for each frame started. This would apply equally to both
> versions, unless sman is changed.
> 
> So I don't think its a question of supporting the NAG and 
> Open versions, its a case of whether you want to be able to use
> the TeXmacs interface and sman at the same time.  I believe
> that our "AXIOMsys" script provides the same functionality
 as your "axiom" program.
> 
> I find it frustrating to be accused of not cooperating - we have
> made every scrap of source code available that we could.  Some
> of the remainder we can still use ourselves but not distribute
> in source form. However there is other material that we can no
> longer use ourselves either, so while the idea of carrying on
> some kind of voluntary support network for existing sites is
> nice it is completely impractical.

\start
Date: Thu, 16 Oct 2003 16:30:17 +0200 (CEST)
From: Joris van der Hoeven
To: Tim Daly
Subject: Re: tm_axiom
Cc: Mike Dewar, Andrey G. Grozin, Bill Page

> I'd rather you continue the support of NAG's version.
> If someone installs the free version then the spiffy
> new "configure" script can replace the tm_axiom file.

That could be a solution, although I find it a bit dirty,
since it requires overiding the existing plugin.
Another solution might be to give both plugins a different name.
We could rename the old axiom as "NAG Axiom".

> Since I haven't been involved in the texmacs/axiom work
> I need some help setting up the correct configure script.
> Where can I find "the entire axiom plugin"?

In $TEXMACS_PATH/plugins/axiom

\start
Date: Thu, 16 Oct 2003 10:48:47 -0400
From: Bill Page
To: Tim Daly
Subject: RE: tm_axiom
Cc: Mike Dewar, Joris van der Hoeven

Tim,

On Thursday, October 16, 2003 9:42 AM you wrote:
> ... 
> Since I haven't been involved in the texmacs/axiom work 
> I need some help setting up the correct configure script.
> Where can I find "the entire axiom plugin"? 
> 

I should probably wait for Joris to answer in detail, but
here is what I know...

In TeXmacs version 1.0.2, after installation the axiom
plug-in seems to be in two parts.

  /usr/share/TeXmacs/plugins/axiom
    - constains two sub-directories, packages and progs
      - packages contains a sub-directory session which
        in turn, constains the axiom stylesheet axiom.ts
      - progs contains some scheme initialization scripts
    - no need to change either of these (yet) for the new
      version of tm_axiom, maybe in a future version

  /usr/libexec/TeXmacs/bin
    - constains the executable filter files including
      tm_axiom
    - right now all I do is replace the tm_axiom program
      found here with the new one compiled from the tm_axiom.c
      source on Savannah.

On Thursday, October 16, 2003 10:30 AM Joris wrote:

> ...
> > Where can I find "the entire axiom plugin"?
> 
> In $TEXMACS_PATH/plugins/axiom

On my RedHat 8.0 linux system the version of TeXmacs installed
from the 1.0.2 RPM does not have any associated environment
variable called TEXMACS_PATH. Are you referring to the source
distribution, Joris?

\start
Date: Thu, 16 Oct 2003 10:12:32 -0400
From: Tim Daly
To: Joris van der Hoeven
Subject: Re: tm_axiom
Cc: Mike Dewar, Andrey G. Grozin, Bill Page

Joris,

I agree that renaming the old version to "NAG Axiom" is probably
cleaner (unless we figure out a way to unify them).

I have a bunch of future "requirements" for texmacs (like fully
supporting the literate programming style) which I need to discuss
with you. I have a paragraph or two from another private discussion
which I'll send to you. It hints at where I'd like to see Axiom's
front end systems go. They're on my home machine so I'll send them
later tonight.

\start
Date: Thu, 16 Oct 2003 15:59:01 +0100
From: Mike Dewar
To: Joris van der Hoeven
Subject: re: tm_axiom
Cc: Camm Maguire, Andrey G. Grozin, Bill Page

Joris,

I think that you're missing the point.  Its not a case of having two
tm_axioms for two versions of axiom, its a case of having two tm_axioms
for two different ways of invoking *the same* axiom.  It just happens
that the open version of axiom is still incomplete and doesn't yet
exhibit both forms of behaviour.

I don't quite understand what the problem is in any case.  You can
always turn prompts off completely (")set message prompt none") if you
like (in axiom.input or mysyns.input depending on whether its a
system-wide change or not).

If you really need exactly one prompt, then you can add the following to
the axiom.input/mysyns.input file, which will suppress the initial
prompt when Axiom is started by sman (i.e. when the $SpadServer variable
is set).

)lisp (DEFUN MKPROMPT NIL (COND ((and |$SpadServer| (|BOOT-EQUAL| |$interpreterFrameName| '|initial|)) (MAKESTRING "")) ((|BOOT-EQUAL| |$inputPromptType| '|none|) (MAKESTRING "")) ((|BOOT-EQUAL| |$inputPromptType| '|plain|) (MAKESTRING "-> ")) ((|BOOT-EQUAL| |$inputPromptType| '|step|) (STRCONC (MAKESTRING "(") (STRINGIMAGE |$IOindex|) (MAKESTRING ") -> "))) ((|BOOT-EQUAL| |$inputPromptType| '|frame|) (STRCONC (STRINGIMAGE |$interpreterFrameName|) (MAKESTRING " (") (STRINGIMAGE |$IOindex|) (MAKESTRING ") -> "))) ('T (STRCONC (STRINGIMAGE |$interpreterFrameName|) (MAKESTRING " [") (SUBSTRING (CURRENTTIME) 8 NIL) (MAKESTRING "] [") (STRINGIMAGE |$IOindex|) (MAKESTRING "] -> ")))) )

Its a bit ugly since it all has to be on one line but should work ...  

On Thu, Oct 16, 2003 at 04:10:11PM +0200, Joris van der Hoeven wrote:
> 
> > > OK, so without any cooperation from NAG, we should probably
> > > drop the old tm_axiom, except if Andrey Grozin finds a way to
> > > keep it working.
> > As I've said several time already the NAG version of Axiom behaves
> > exactly the same way as the new version as far as I can see.  The only
> > difference is if you invoke it via the `sman' program rather than
> > directly, in which case you see two prompts, one for each frame started.
> > This would apply equally to both versions, unless sman is changed.
> >
> > So I don't think its a question of supporting the NAG and Open versions,
> > its a case of whether you want to be able to use the TeXmacs interface
> > and sman at the same time.  I believe that our "AXIOMsys" script
> > provides the same functionality as your "axiom" program.
> >
> > I find it frustrating to be accused of not cooperating - we have made
> > every scrap of source code available that we could.  Some of the
> > remainder we can still use ourselves but not distribute in source form.
> > However there is other material that we can no longer use ourselves
> > either, so while the idea of carrying on some kind of voluntary support
> > network for existing sites is nice it is completely impractical.
> 
> I am sorry for having accused NAG; I just find it frustrating to
> have two tm_axioms for two versions of axiom and nobody able to
> produce a tm_axiom which works for both (for whatever reasons).
> In the current situation, I honestly do not know what
> I am supposed to do.
> 
> So I wait for a patch from anyone who is interested in keeping
> the old interface alive. Probably one should modify line 266 of
> the tm_axiom.c we currently distribute, together with the patches
> by David & Bill. If I do not have any patch which works with both
> versions within one month from now, then I will exclusively support
> the free version of axiom, since this seems to be the only version
> which is under active development.

\start
Date: Thu, 16 Oct 2003 17:01:51 +0200 (CEST)
From: Joris van der Hoeven
To: Bill Page
Subject: RE: tm_axiom
Cc: Mike Dewar

> > > Where can I find "the entire axiom plugin"?
> >
> > In $TEXMACS_PATH/plugins/axiom
>
> On my RedHat 8.0 linux system the version of TeXmacs installed
> from the 1.0.2 RPM does not have any associated environment
> variable called TEXMACS_PATH. Are you referring to the source
> distribution, Joris?

I refer to the static binary tarball. If you use an rpm,
then the binaries get split from the data, as you explained very well.

\start
Date: Thu, 16 Oct 2003 17:13:04 +0200 (CEST)
From: Joris van der Hoeven
To: Tim Daly
Subject: Re: tm_axiom
Cc: Mike Dewar, Andrey G. Grozin, Bill Page

> Yes, it is old-fashioned. There have been discussions about changing it
> and I believe several people on the list have investigated it. Dylan
> has looked at it deeply enough to understand where to patch simple
> things. There is also work by Bill to look at the line-breaking algorithm
> as well as discussion about embedding line-breaking into Axiom's tex code.

I have looked a bit at Bill's intro too. It seems that the LaTeX
generation has lots of problems. For instance, it even attempts to
line break formulas at the interior of big parenthesis...
The TeXamcs-specific \* for multiplication is also missing.
You should try to make the LaTeX generation as easy as possible and
let TeXmacs do the formatting and line-breaking.

\start
Date: Thu, 16 Oct 2003 17:17:57 +0200 (CEST)
From: Joris van der Hoeven
To: Andrey G. Grozin
Subject: Re: tm_axiom
Cc: Mike Dewar, Bill Page

> My idea about supporting both free and old NAG Axiom in TeXmacs is very
> simple (though not very clean, probably). Let's change the (new)
> tm_axiom.c slightly, in such a way that it can accept a command-line
> argument. If there is no argument (argc==1), let it expect one prompt at
> the beginning, thus nicely interacting with the free version. If there is
> an argument (argc>1), let it expect two prompts. Then those who want to
> use the old NAG axiom can change the command-line to, e.g.,
> tm_axiom nag in the plugin.

That is OK with me too.

> It would be good (and not only here) to allow user to supply command-line
> arguments when starting a session.

You may now configure variant sessions, as I explained you.
This should be sufficient for a while.

Is there a way to detect automatically with which version of axiom
we are dealing? Can we use both at the same time?

\start
Date: Thu, 16 Oct 2003 10:26:44 -0400
From: Tim Daly
To: Andrey G. Grozin
Subject: Re: tm_axiom
Cc: Mike Dewar, Bill Page, Joris van der Hoeven

> My idea about supporting both free and old NAG Axiom in TeXmacs is very 
> simple (though not very clean, probably). Let's change the (new) 
...[snip]...

I like the suggestion.

> One additional thought about the new tm_axiom. Currently, TeX-generation 
> in Axiom produces horribly old-fashioned TeX, not modern LaTeX. It 
> produces such monsters as
> {\root 3 \of x}
> TeXmacs does not understand this (rightfully, I think). The new tm_axiom 
> tries to work around such issues. It would be much better to improve TeX 
> generation in the free Axiom. Or to leave TeX generation as it stands, 
> copy it into LaTeX generation, and improve it.                        

Yes, it is old-fashioned. There have been discussions about changing it
and I believe several people on the list have investigated it. Dylan
has looked at it deeply enough to understand where to patch simple
things. There is also work by Bill to look at the line-breaking algorithm
as well as discussion about embedding line-breaking into Axiom's tex code.

>                                                This should be not too 
> difficult.

An old irish fellow once said: There is no such thing as a simple job.

\start
Date: Thu, 16 Oct 2003 17:08:26 +0200 (CEST)
From: Joris van der Hoeven
To: Mike Dewar
Subject: Re: tm_axiom
Cc: Camm Maguire, Andrey G. Grozin, Bill Page

Andrey: could you please try to patch your tm_axiom.c program
in order to make it compatible with everybody? I think that this
should be most easy for you, using what Mike, David and Bill have
been saying... Notice that you can find a binary tarball at

	http://savannah.nongnu.org/files/?group=axiom

for the free version of Axiom. Just download

	axiom-debian-3.0-linux-i386-cvs-2003-09-28.tar.gz

and set the AXIOM and PATH environement variables as needed.

If supporting both versions of axiom in a single plugin turns out
to be too difficult, I can also rename axiom -> nag-axiom for
NAG's version of Axiom.

> I think that you're missing the point.  Its not a case of having two
> tm_axioms for two versions of axiom, its a case of having two tm_axioms
> for two different ways of invoking *the same* axiom.  It just happens
> that the open version of axiom is still incomplete and doesn't yet
> exhibit both forms of behaviour.
>
> I don't quite understand what the problem is in any case.  You can
> always turn prompts off completely (")set message prompt none") if you
> like (in axiom.input or mysyns.input depending on whether its a
> system-wide change or not).
>
> If you really need exactly one prompt, then you can add the following to
> the axiom.input/mysyns.input file, which will suppress the initial
> prompt when Axiom is started by sman (i.e. when the $SpadServer variable
> is set).
>
> )lisp (DEFUN MKPROMPT NIL (COND ((and |$SpadServer| (|BOOT-EQUAL| |$interpreterFrameName| '|initial|)) (MAKESTRING "")) ((|BOOT-EQUAL| |$inputPromptType| '|none|) (MAKESTRING "")) ((|BOOT-EQUAL| |$inputPromptType| '|plain|) (MAKESTRING "-> ")) ((|BOOT-EQUAL| |$inputPromptType| '|step|) (STRCONC (MAKESTRING "(") (STRINGIMAGE |$IOindex|) (MAKESTRING ") -> "))) ((|BOOT-EQUAL| |$inputPromptType| '|frame|) (STRCONC (STRINGIMAGE |$interpreterFrameName|) (MAKESTRING " (") (STRINGIMAGE |$IOindex|) (MAKESTRING ") -> "))) ('T (STRCONC (STRINGIMAGE |$interpreterFrameName|) (MAKESTRING " [") (SUBSTRING (CURRENTTIME) 8 NIL) (MAKESTRING "] [") (STRINGIMAGE |$IOindex|) (MAKESTRING "] -> ")))) )
>
> Its a bit ugly since it all has to be on one line but should work ...

\start
Date: Thu, 16 Oct 2003 11:29:38 -0400
From: Bill Page
To: Joris van der Hoeven
Subject: RE: tm_axiom
Cc: Mike Dewar, Andrey G. Grozin

Joris,

On Thursday, October 16, 2003 11:13 AM you wrote:
> 
> > Yes, it is old-fashioned. There have been discussions about
> > changing it and I believe several people on the list have
> > investigated it. Dylan has looked at it deeply enough to
> > understand where to patch simple things. There is also work
> > by Bill to look at the line-breaking algorithm as well as
> > discussion about embedding line-breaking into Axiom's tex
> > code.
> 
> I have looked a bit at Bill's intro too. It seems that the
> LaTeX generation has lots of problems. For instance, it even
> attempts to line break formulas at the interior of big
> parenthesis...

You are talking about the LaTeX generation of the line-break
routines that I inserted into the new version of tm_axiom,
right? If so, you are right that this line-break code has
only been properly tested on a subset of TeX/LaTeX output
produced by Axiom, enven though the "C" code is actually
quite old. As I understand from Tim and from the comments
in the code, it was written some years ago by Robert Sutor
(a primary Axiom developer) specifically to produce the
LaTeX output that became part of the Axiom Book.

> The TeXamcs-specific \* for multiplication is also missing.
> You should try to make the LaTeX generation as easy as
> possible and let TeXmacs do the formatting and line-breaking.
> 

I do not understand how to let TeXmacs do the line-breaking.
Without the line-break code that I inserted into tm_axiom,
TeXmacs seems to do exactly the same thing as LaTeX with the
long math lines - they just run off the page on the left.
Can you tell me how to get TeXmacs to break some long LaTeX
code that is passed through the plugin interface? Or where
should I read about this?

In general I agree that we should improve the TeX/LaTeX
generated by Axiom, but when I first tried this by submitting
a patch to get right of the \root{n} \of {x} horror, Tim
pointed out to me there are some "legacy" programs that
might be broken by such changes.

\start
Date: Thu, 16 Oct 2003 11:34:08 -0400
From: Bill Page
To: Joris van der Hoeven, Andrey G. Grozin
Subject: RE: tm_axiom
Cc: Mike Dewar

Joris, and Andrey,

> > If there is an argument (argc>1), let it expect two
> > prompts. Then those who want to use the old NAG axiom
> > can change the command-line to, e.g., tm_axiom nag in
> > the plugin.
> 
> That is OK with me too.

This is a good idea but no very "user configuration friendly".

> 
> > It would be good (and not only here) to allow user to 
> > supply command-line arguments when starting a session.
>

Yes.
 
> You may now configure variant sessions, as I explained you.
> This should be sufficient for a while.
>

???
 
> Is there a way to detect automatically with which version
> of axiom we are dealing? Can we use both at the same time?
>

Please understand what Mike Dewar is trying to tell you:

  It is not necessary to detect which version.

All that is necessary is to just start

   AXIOMsys

instead of the whole group of three (or more?) processes
that are usually started in the NAG commercial version.
tm_axiom only interfaces with one of these - the Axiom
interpret itself.

\start
Date: Thu, 16 Oct 2003 23:02:20 +0200
From: Antoine Hersen
To: list
Subject: GCL configuration

Hello,

I am using Gentoo linux and in order to pass gcl compilation I had to
change its ./configure which now look loke this :

./configure --enable-vssize=65536*2 --disable-statsysbfd
--enable-readline --enable-maxpage=128*1024 --enable-locbfd

I dont understand what excatly it's changing, will I run into trouble
later ?

\start
Date: Sun, 19 Oct 2003 18:29:00 +0200
From: David Mentre
To: Tim Daly
Subject: Re: infinity in tex mode
Cc: Dylan Thurston

Hello Tim & Dylan,

Tim Daly writes:

> David,
>
> The tex infinity bug should be closed.

In fact, there was no open bug on TeX infinity. 

\start
Date: Sun, 19 Oct 2003 12:59:18 -0400
From: Tim Daly
To: David Mentre
Subject: Re: infinity in tex mode
Cc: Dylan Thurston

> > David,
> >
> > The tex infinity bug should be closed.
> 
> In fact, there was no open bug on TeX infinity. 

yeehaa! i'm finally getting ahead of the bugs :-)

\start
Date: Sun, 19 Oct 2003 21:56:00 +0200
From: David Mentre
To: Tim Daly
Subject: On statically linked Axiom

Hello Tim,

I was trying my trick to build a statically linked Axiom but the
compilation failed at one step. After building a fresh gcl (which is
indeed static), I erased obj/linux/bin/interpsys and
obj/linux/bin/depsys to force their recompilation. Recompilation of
depsys fails with following error message:

make[3]: Entering directory `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/src/interp'
3 making /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/bin/depsys

>
Loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/makedep.lisp
Loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/sys-pkg.lsp
Finished loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/sys-pkg.lsp
Loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/nocompil.lsp
Finished loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/nocompil.lsp
Loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/util.o

Error: Undefined symbol
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at LOAD.  Type :H for Help.
>>4 /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/bin/depsys created
63 making /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/macros.o from /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/int/interp/macros.lisp
/bin/sh: /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/bin/depsys: No such file or directory
make[3]: *** [/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/macros.o] Error 127
make[3]: Leaving directory `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom'
make: *** [all] Error 2

Do you see what could have gone wrong?

\start
Date: Sun, 19 Oct 2003 17:58:15 -0400
From: Tim Daly
To: David Mentre
Subject: Re: On statically linked Axiom

David,

You must have tried to build GCL outside of Axiom. 
It appears that you didn't link the Axiom library to the lisp image.
This happens as part of the lisp build process when Axiom does the build.

Axiom untars GCL then applies the patches in the zips directory.
One of the patches modifies the GCL build so that it includes Axiom's code
in the GCL image. If you build GCL by hand you have to make the modifications
by hand. This is one of the hard issues about using any pre-installed lisp.

To solve the problem modify the top level Makefile.pamphlet to 
include the --static flag (or whatever mods you made to get GCL to be
static), then do 

make clean
make

\start
Date: Mon, 20 Oct 2003 18:51:29 +0200
From: David Mentre
To: Tim Daly
Subject: Re: On statically linked Axiom

Tim Daly writes:

> You must have tried to build GCL outside of Axiom. 

No. I just made a 'make' inside the axiom/ directory.

> It appears that you didn't link the Axiom library to the lisp image.
> This happens as part of the lisp build process when Axiom does the build.
>
> Axiom untars GCL then applies the patches in the zips directory.

Yes, this was done.

> One of the patches modifies the GCL build so that it includes Axiom's code
> in the GCL image. If you build GCL by hand you have to make the modifications
> by hand. This is one of the hard issues about using any pre-installed lisp.

What I have done:

 1. applied following patch:

--- axiom-i386-dm/axiom/lsp/Makefile.pamphlet	Mon Sep 29 21:03:10 2003
+++ axiom-static-i386-dm/axiom/lsp/Makefile.pamphlet	Sun Oct 19 21:08:18 2003
@@ -122,7 +122,7 @@
 relocating object files.
 <<gclConfigureMake>>=
 	@(cd ${GCLVERSION} ; \
-	./configure --enable-vssize=65536*2 --enable-statsysbfd --enable-readline --enable-maxpage=128*1024 ; \
+	CC="gcc --static" ./configure --enable-vssize=65536*2 --enable-statsysbfd --enable-readline --enable-maxpage=128*1024 ; \
 	${ENV} ${MAKE} ; \
 	cp unixport/saved_gcl ${OUT}/lisp )
 @


 2. erased lsp/gcldir and lsp/gcl-2.5.2/

 3. erased obj/linux/bin/depsys and obj/linux/bin/interpsys

 4. make

(and yes, I have setup the $AXIOM variable)

> To solve the problem modify the top level Makefile.pamphlet to 
> include the --static flag (or whatever mods you made to get GCL to be
> static), then do 
>
> make clean

I wanted to avoid that. Compiling algebra takes 12h on my old machine. 

I retry with a 'make clean'. To be continued.... :)

Thanks to have taken a look at this issue.

\start
Date: Mon, 20 Oct 2003 23:15:53 +0200
From: David Mentre
To: Tim Daly
Subject: Re: On statically linked Axiom

David Mentre writes:

> I retry with a 'make clean'. To be continued.... :)

I tried again after a make clean and I obtain once again the same error
message:


make[3]: Entering directory `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/src/interp'
5 invoking make in /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/src/interp with parms:
SYS= linux
LSP= /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/lsp
PART= cprogs
SPAD= /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/mnt/linux
SRC= /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/src
INT= /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/int
MID= /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/int/interp
OUT= /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp
OBJ= /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj
MNT= /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/mnt
O=o LISP=lsp BYE=bye

>
Loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/makeint.lisp
Loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/sys-pkg.lsp
Finished loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/sys-pkg.lsp
Loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/nocompil.lsp
Finished loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/nocompil.lsp
Loading /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/interp/util.o

Error: Undefined symbol
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at LOAD.  Type :H for Help.
>>6 /home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/bin/interpsys created
cp: cannot stat `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/bin/interpsys': No such file or directory
make[3]: *** [/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/obj/linux/bin/interpsys] Error 1
make[3]: Leaving directory `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/david/pub/axiom-libre/axiom-static-i386-dm/axiom'
make: *** [all] Error 2


I don't know if it is related to the static GCL or a more fundamental
error in axiom build system.

\start
Date: Mon, 20 Oct 2003 20:57:41 -0400
From: Tim Daly
To: David Mentre
Subject: Re: On statically linked Axiom

David,

I'll try a static build here. 
The result will take a while as I only have a slow system available.

\start
Date: Mon, 20 Oct 2003 23:18:23 -0400
From: Tim Daly
To: David Mentre
Subject: Re: On statically linked Axiom

David,

I see the same result you get.
I'll look into it further.

\start
Date: Mon, 20 Oct 2003 23:45:28 -0400
From: Tim Daly
To: David Mentre
Subject: Re: On statically linked Axiom

David,

The statically linked GCL image has a problem:

make file foo.lisp:

(defun test (st) (read-char st))

at lisp prompt:

>(compile-file "foo.lisp")
>(load "foo.o")

Error: Undefined symbol
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at LOAD.  Type :H for Help.
>>

replacing READ-CHAR by READ succeeds.

So the problem appears to be the compiled reference to the READ-CHAR
function and has nothing to do with Axiom. This looks like a GCL bug.

\start
Date: 20 Oct 2003 22:28:38 +0200
From: Wolfgang Zocher
To: list
Subject: pamphlet-noweb-latex

Hi all,

when I produce tex-files from algebra-pamphlets the \spad - command and
commands like \em, \tt etc. are going to deliver wrong representations in the
resulting latex-file, i.e. \spad {G} is translated to \\spad\{G\}. This is
obviously wrong - the first form (\spad {G}) or {\spad G} is right. 

Inspection of noweb.sty shows that the characters \ and {} have a special
meaning and it seems to me that this must be wrong. However, I'm very new to
literate programming and all the tools belonging to LP. 

Is there anybody out there who can clarify this issue??

\start
Date: Tue, 21 Oct 2003 08:50:27 -0400
From: Tim Daly
To: Wolfgang Zocher, David Mentre
Subject: \spad

It's not your fault. There is a problem with the tex tag.
The problem is that Axiom has its own tag definitions which
are not (yet) in the axiom.sty file. I'll look into it.

David,

Could you add this as a bug?

\start
Date: 21 Oct 2003 15:49:27 +0200
From: Wolfgang Zocher
To: Tim Daly
Subject: Re: \spad

Hi Tim,

I've added the \spad fault as bug. I hope I've done this the right way :-)

\start
Date: Tue, 21 Oct 2003 11:35:49 -0400
From: Bill Page
To: Tim Daly
Subject: Unused old versions of GCL in CVS

Tim,

I recently refreshed my copy of the Axiom CVS and I could
not help but notice (download speed!) that there are four
unused version of GCL in the CVS totaling more than 25 Mb.
Can you see any reason for keeping 2.4.1, 2.4.3 and 2.5?
Also I see that the naming convention for 2.5.3 is different
(.tar.gz). Am I correct that this version is also not used?

I would offer to clean this up and maybe also move things
to the most recent version of GCL (2.6.1-15) - or do you
already have plans for that? But I am a little unsure about
how to remove things from CVS.

\start
Date: Tue, 21 Oct 2003 11:59:41 -0400
From: Tim Daly
To: Bill Page
Subject: other GCL versions

Bill,

There are several versions of GCL in the repository because
I do builds on multiple versions when bug testing. Most of
those bugs were related to package issues which should all
be fixed by now.

There was a bug in the 2.5.3 build that kept me from using that version.

The current build is on 2.5.2 but will move to 2.6 when I get a
chance.  I will remove the other versions tonight.

\start
Date: Tue, 21 Oct 2003 12:00:54 -0400
From: Tim Daly
To: Bill Page
Subject: other GCL versions

Bill,

Is 2.6 stable?

\start
Date: Tue, 21 Oct 2003 12:11:38 -0400
From: Tim Daly
To: Bill Page
Subject: other GCL versions

Bill,

In answer to your implied question about deleting files from CVS
this appears to work:

cvs update                  make sure you have the latest
cd (where)                  go to the file's directory
rm filename                 remove the file first
cvs delete filename         tell cvs to delete the file
cd (top)                    go to the top level directory containing CVS
cvs ci -m"removed filename" do a checkin

\start
Date: Tue, 21 Oct 2003 13:42:12 -0400
From: Bill Page
To: Tim Daly
Subject: RE: other GCL versions

Tim,

Yes, according to the new GCL version numbering scheme
x.y.z-w is stable if y is an even number. The previous
stable version (I think) was 2.5.4 which was prior to
the introduction of the new numbering scheme.

The current *unstable* development version of GCL is
2.7.0-11.

Check for the most recent stuff at

  http://people.debian.org/~camm/gcl/

Note: These are not just debian files.

Cheers,
Bill Page.

> 
> Bill,
> 
> Is 2.6 stable?

\start
Date: Tue, 21 Oct 2003 13:37:56 -0400
From: Bill Page
To: Tim Daly
Subject: RE: other GCL versions

Tim,

Yes, according to the new GCL version numbering scheme
x.y.z-w is stable if y is an even number. The previous
stable version (I think) was 2.5.4 which was prior to
the introduction of the new numbering scheme.

The current *unstable* development version of GCL is
2.7.0-11.

Check for the most recent stuff at

  http://people.debian.org/~camm/gcl/

Note: These are not just debian files.

Cheers,
Bill Page.

> Bill,
> 
> Is 2.6 stable?

\start
Date: Tue, 21 Oct 2003 14:22:17 -0400
From: Bill Page
To: Tim Daly
Subject: Re: On statically linked Axiom (was: static lisp and rpms)
Cc: Camm Maguire

Tim, David,

You might recall that on Thursday, October 16, 2003 9:28 AM
Camm Maquire wrote:

> 
> Latest 2.6.1 and CVS HEAD has a --enable-static configure 
> option. There may be some issues when using readline in this 
> mode, but I haven't yet had a chance to plumb the bottom of
> that.
> 

On Monday, October 20, 2003 11:45 PM Tim wrote:

> 
> The statically linked GCL image has a problem:
> 
> make file foo.lisp:
> 
> (defun test (st) (read-char st))
> 
> at lisp prompt:
> 
> >(compile-file "foo.lisp")
> >(load "foo.o")
> 

I tried this under Windows with GCL 2.6.1 which is statically
linked without readline by default (I think?). It worked fine.

So it seems that moving to 2.6.1, building with the new
.\configure --enable-static option and eliminating readline
might correct your static linking problem.

\start
Date: Tue, 21 Oct 2003 13:49:51 -0400
From: Tim Daly
To: Bill Page
Subject: GCL 2.6.1 and static

Bill,

I just downloaded the sources for GCL-2.6.1. I'll do two builds
tonight, one for Axiom and if that succeeds, one to try the static build.
If either (or both) succeed I'll upload a new version based on GCL-2.6.1
and trash the other GCLs.

\start
Date: Tue, 21 Oct 2003 20:29:24 +0200
From: David Mentre
To: Tim Daly
Subject: re: On statically linked Axiom

Tim Daly writes:

> So the problem appears to be the compiled reference to the READ-CHAR
> function and has nothing to do with Axiom. This looks like a GCL bug.

Ok. I suppose this was done on gcl 2.5.2 included with Axiom CVS and
which is now an old version of gcl.

As Camm already told use that stable gcl 2.6.x has support for static
binary (./configure --static), I propose to postpone support of
statically linked Axiom until one of use integrates gcl 2.6.x into
Axiom.

\start
Date: Tue, 21 Oct 2003 13:37:56 -0400
From: Bill Page
To: Tim Daly
Subject: RE: other GCL versions

Tim,

Yes, according to the new GCL version numbering scheme
x.y.z-w is stable if y is an even number. The previous
stable version (I think) was 2.5.4 which was prior to
the introduction of the new numbering scheme.

The current *unstable* development version of GCL is
2.7.0-11.

Check for the most recent stuff at

  http://people.debian.org/~camm/gcl/

Note: These are not just debian files.

Cheers,
Bill Page.

> Bill,
> 
> Is 2.6 stable?

\start
Date: Wed, 22 Oct 2003 08:56:16 -0400
From: Tim Daly
To: list
Subject: porting

*,

HP offers a site to try out various versions of Linux.
http://www.testdrive.compaq.com/os/linux

Does anyone have access to this site?
Is is possible to run the Axiom build on each system
and save the console output?

\start
Date: Wed, 22 Oct 2003 10:16:24 -0400
From: Dylan Thurston
To: list
Subject: Re: porting

On Wed, Oct 22, 2003 at 08:56:16AM -0400, Tim Daly wrote:
> 
> Does anyone have access to this site?
> Is is possible to run the Axiom build on each system
> and save the console output?

You can sign up yourself, at
http://www.testdrive.compaq.com/accounts/register.shtml
or is this a request for someone else to do it?

I believe that the Debian packages have already been built on all the
architectures they offer, however.

(By the way, are you aware just how much console output the Axiom build
produces?  It's really ludicrous.)

\start
Date: Wed, 22 Oct 2003 09:58:36 -0400
From: Tim Daly
To: list
Subject: porting

Dylan,

I did sign up for the HP site, actually. I've been trying to
port to some of these platforms locally but I lack the experience
with their "mindset" or can't reach their distribution sites
(e.g. debian and SuSE) because my systems are standalone.

Yeah, the console output could probably be redirected (and I do
redirect the pamphlet build output by default) or reduced. But
it contains just enough output to debug a failed build. Fortunately
I no longer work on my teletype :-). I suppose I could figure out
how to set a "user" flag to suppress output. I'll put it on the
todo list.

\start
Date: Thu, 23 Oct 2003 07:40:29 -0400
From: Tim Daly
To: list
Subject: gcl-2.6.1

*,

Axiom is now based on gcl-2.6.1
The cvs has been updated.
I've removed gcl-2.* compressed tar files (except for gcl-2.5.2).
I'll remove 2.5.2 once 2.6.1 has been shown stable.

\start
Date: Thu, 23 Oct 2003 11:32:34 -0400
From: Tim Daly
To: TestDrive@hp.com
Subject: Axiom build

Tim,

I've successfully transferred the source files. Thanks.

I'm using TestDrive servers to ensure that Axiom runs on HP 
hardware/software combinations. The Axiom build makes heavy
use of the C compiler. I can nice the process to 19 but I'd
rather do the builds when the servers are lightly used. Do
you have "off hour" times (say at night) that you might
recommend?

Is the /house/timdaly file system NFS shared? The Axiom build
is designed to take advantage of this by caching system-independent
work.

Once I've verified that Axiom runs everywhere is there someone I
can contact about including Axiom in HP distributions? The system
is free, is of commercial quality (it used to be commercial code),
and I'm willing to support it.

\start
Date: Thu, 23 Oct 2003 12:46:43 -0400
From: Dylan Thurston
To: Tim Daly
Subject: Re: synthesis

On Thu, Oct 16, 2003 at 07:56:03AM -0400, Tim Daly wrote:
> There are several requests under consideration.
> 
> David and Joris have been calling for a "configure" command.
> Dylan and Bill have been trying to set up tm_axiom with texmacs.
> Camm and Juergen have asked to use the already installed lisp.
> Joris would like a static version of the system.
> Dylan would like the make variables to be available everywhere.
> I've been wondering about platform-specific complexity.
> 
> I may have the names wrong but the point is that I'm now convinced
> that I have to change direction.
> 
> ./configure can be used to attack all of these problems.
> So I'll write up an initial script, post it, and we can play with it.

It occurs to me that you have a lot on your plate right now (with the
documentation and all), and that there are probably other people on the
list with more experience setting up autoconf than you.  Perhaps this
would be a good task for someone else?

[Or if you've already done this, that's great too.]

I don't have experience with autoconf, but I'd be happy to learn.

\start
Date: Thu, 23 Oct 2003 12:12:14 -0400
From: Tim Daly
To: Dylan Thurston
Subject: configure

Dylan,

Great. Give it a try. I've looked at autoconf in detail but it was 
nearly 2 years ago but I can answer some questions about it. I think
Camm has also suffered thru it so he may have answers you need. In
any case, feel free to ask.

\start
Date: 23 Oct 2003 12:55:41 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: On statically linked Axiom (was: static lisp and rpms)

Greetings!  OK, thanks for the report -- I've just committed a fix in
cvs 2.6.1 and head.  The patch is in two parts, one loads weak symbols
as well as undefined symbols into the bfd symbol table, and the other
maps the 't' and 'nil stream descriptors properly in optimized
references to read-char.  These will be in the next stable and
unstable release on the temp site.

Take care,

Index: read.d
===================================================================
RCS file: /cvsroot/gcl/gcl/o/read.d,v
retrieving revision 1.14.4.1.2.2.2.2
diff -u -r1.14.4.1.2.2.2.2 read.d
--- read.d	14 Sep 2003 02:30:45 -0000	1.14.4.1.2.2.2.2
+++ read.d	23 Oct 2003 16:37:07 -0000
@@ -2298,19 +2298,30 @@
 @)
 
 object
-read_byte1(str,eof)
-object str,eof;
-{if (stream_at_end(str))
-   return eof;
- return make_fixnum(readc_stream(str));}
+read_byte1(strm,eof)
+object strm,eof;
+{
+  if (strm == Cnil)
+    strm = symbol_value(sLAstandard_inputA);
+  else if (strm == Ct)
+    strm = symbol_value(sLAterminal_ioA);
+  if (stream_at_end(strm))
+    return eof;
+  return make_fixnum(readc_stream(strm));
+}
 
 object
-read_char1(str,eof)
-object str,eof;
-{if (stream_at_end(str))
-   return eof;
- return code_char(readc_stream(str));}
-
+read_char1(strm,eof)
+object strm,eof;
+{
+  if (strm == Cnil)
+    strm = symbol_value(sLAstandard_inputA);
+  else if (strm == Ct)
+    strm = symbol_value(sLAterminal_ioA);
+  if (stream_at_end(strm))
+    return eof;
+  return code_char(readc_stream(strm));
+}
 
 @(defun copy_readtable (&optional (from `current_readtable()`) to)
 @
Index: sfasli.c
===================================================================
RCS file: /cvsroot/gcl/gcl/o/sfasli.c,v
retrieving revision 1.10.4.2.2.1
diff -u -r1.10.4.2.2.1 sfasli.c
--- sfasli.c	6 Sep 2003 17:22:50 -0000	1.10.4.2.2.1
+++ sfasli.c	23 Oct 2003 16:37:07 -0000
@@ -59,7 +59,7 @@
     if (!*q[u]->name)
       continue;
 
-    if (strncmp(q[u]->section->name,"*UND*",5))
+    if (strncmp(q[u]->section->name,"*UND*",5) && ! q[u]->flags & BSF_WEAK)
       continue;
 
     if ((c=(char *)strstr(q[u]->name,"@@"))) {


Bill Page writes:

> Tim, David,
> 
> You might recall that on Thursday, October 16, 2003 9:28 AM
> Camm Maquire wrote:
> 
> > 
> > Latest 2.6.1 and CVS HEAD has a --enable-static configure 
> > option. There may be some issues when using readline in this 
> > mode, but I haven't yet had a chance to plumb the bottom of
> > that.
> > 
> 
> On Monday, October 20, 2003 11:45 PM Tim wrote:
> 
> > 
> > The statically linked GCL image has a problem:
> > 
> > make file foo.lisp:
> > 
> > (defun test (st) (read-char st))
> > 
> > at lisp prompt:
> > 
> > >(compile-file "foo.lisp")
> > >(load "foo.o")
> > 
> 
> I tried this under Windows with GCL 2.6.1 which is statically
> linked without readline by default (I think?). It worked fine.
> 
> So it seems that moving to 2.6.1, building with the new
> .\configure --enable-static option and eliminating readline
> might correct your static linking problem.

\start
Date: Thu, 23 Oct 2003 12:30:00 -0400
From: Tim Daly
To: Camm Maguire
Subject: static build  and HP TestDrive hp156 console

Thanks.

I just built and tested a non-static version of the system using
2.6.1 and it works fine (modulo the fact that the files were renamed).
The 2.6.1 version is in the CVS and will be the default build.
The static version failed as mentioned. I'll try a static rebuild 
(possibly tonight).

I am doing compiles using HP's TestDrive server farm.
Just out of wild hope I tried it on one of their 64bit Itanium machines.
I've attached the console log. It blew up quite early in the build
because it couldn't recognize the machine type. Under Schelter's 
regime it used to be the case that you set the machine type by typing
./add-defs foo
Can you tell me how the machine type is decided now?

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

bash-2.05b# telnet hp156
Trying 192.233.54.156...
Connected to hp156.
Escape character is '^]'.
Debian GNU/Linux 3.0 spe156.testdrive.hp.com
spe156 login: timdaly
Password: 

Last login: Thu Oct 23 12:02:44 2003 from rio.sci.ccny.cuny.edu on pts/1
Linux spe156 2.4.18-mckinley-smp #1 SMP Thu Jul 11 12:51:02 MDT 2002 ia64 unknown
---------------------------------------
The Testdrive program is here to enable you to get direct access via the
internet to Compaq's high end AlphaServers and Proliant servers.  We thank
you for your time trying out our equipment and encourage
suggestions.  Please send all comments and feedback to
testdrive@compaq.com.

Rules of the Program
--------------------
We do not allow the following:
1. Running password crackers, dnetc clients, seti, distrib.net, etc.

2. Bringing down our machines, cracking, etc.  We have no doubt that you
can break into the machines if you really want to, but why.  When you
bring down a machine you take away a free and valuable resource from the
open source community.  So please, think before you act.

3. Long running, CPU bound processes are not encouraged.  The 
Testdrive program is not intended as a benchmark nor production
environment.  
Programs that consume significant amounts of system resources only make
other 
users Testdrive experiences less useful.  Experiencing the power of Compaq 
systems should be taken in moderation for everyone's benefit! :-)

4. Abusive file storage.  Testdrive is not intended as an ISP/ASP
environment.  
User areas are not backed up, and cannot be restored.  Users with large 
amount of disk usage should understand they are simply consuming their 
fellow testers resources.

Connections and File Moving
---------------------------
We only allow ftp and telnet in to the testdrive program. No outgoing
connections are allowed.

To move a file, ftp into any of our testdrive machines, and use a put to
place the files in your house directory.  From there they will be
available on all machines.

For fast local access from individual machines to your files, use the /tmp
directory on the local machine.

Thanks again for Testdriving

Testdrive Team
spe156> bash
bash-2.05a$ pwd
/house/timdaly
bash-2.05a$ cd axiom
bash-2.05a$ echo $AXIOM
/house/timdaly/axiom/mnt/linux
bash-2.05a$ make
13 making noweb
patching file modules.c
mnt.o: In function `emitfile':
mnt.o(.text+0xc72): the use of `tmpnam' is dangerous, better use `mkstemp'
make[1]: [install-shell] Error 1 (ignored)
make[1]: [install-code] Error 1 (ignored)
/bin/sh: texhash: command not found
make[1]: [install-elisp] Error 1 (ignored)
0 SPAD=/house/timdaly/axiom/mnt/linux SYS=linux SPD=/house/timdaly/axiom LSP=/house/timdaly/axiom/lsp GCLDIR=/house/timdaly/axiom/lsp/gcl-2.5.2 SRC=/house/timdaly/axiom/src INT=/house/timdaly/axiom/int OBJ=/house/timdaly/axiom/obj MNT=/house/timdaly/axiom/mnt ZIPS=/house/timdaly/axiom/zips TMP=/house/timdaly/axiom/obj/tmp SPADBIN=/house/timdaly/axiom/mnt/linux/bin INC=/house/timdaly/axiom/src/include CCLBASE=/house/timdaly/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /house/timdaly/axiom/obj/tmp/trace GCLVERSION=gcl-2.5.2
10 copying /house/timdaly/axiom/src/scripts to /house/timdaly/axiom/mnt/linux/bin
1 making a linux system, PART=cprogs SUBPART=everything
2 Environment SPAD=/house/timdaly/axiom/mnt/linux SYS=linux SPD=/house/timdaly/axiom LSP=/house/timdaly/axiom/lsp GCLDIR=/house/timdaly/axiom/lsp/gcl-2.5.2 SRC=/house/timdaly/axiom/src INT=/house/timdaly/axiom/int OBJ=/house/timdaly/axiom/obj MNT=/house/timdaly/axiom/mnt ZIPS=/house/timdaly/axiom/zips TMP=/house/timdaly/axiom/obj/tmp SPADBIN=/house/timdaly/axiom/mnt/linux/bin INC=/house/timdaly/axiom/src/include CCLBASE=/house/timdaly/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /house/timdaly/axiom/obj/tmp/trace GCLVERSION=gcl-2.5.2
make[1]: Entering directory `/house/timdaly/axiom'
11 checking directory structure
12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=awk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/house/timdaly/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/house/timdaly/axiom/src/share
18 making /house/timdaly/axiom/src
make[2]: Entering directory `/house/timdaly/axiom/src'
1 making /house/timdaly/axiom/src/scripts
make[3]: Entering directory `/house/timdaly/axiom/src/scripts'
1 making /house/timdaly/axiom/src/scripts
make[3]: Leaving directory `/house/timdaly/axiom/src/scripts'
5 making /house/timdaly/axiom/src/lib
make[3]: Entering directory `/house/timdaly/axiom/src/lib'
2 making /house/timdaly/axiom/int/lib/bsdsignal.c from /house/timdaly/axiom/src/lib/bsdsignal.c.pamphlet
3 making /house/timdaly/axiom/obj/linux/lib/bsdsignal.o from /house/timdaly/axiom/int/lib/bsdsignal.c
8 making /house/timdaly/axiom/int/lib/cursor.c from /house/timdaly/axiom/src/lib/cursor.c.pamphlet
9 making /house/timdaly/axiom/obj/linux/lib/cursor.o from /house/timdaly/axiom/int/lib/cursor.c
11 making /house/timdaly/axiom/int/lib/edin.c from /house/timdaly/axiom/src/lib/edin.c.pamphlet
12 making /house/timdaly/axiom/obj/linux/lib/edin.o from /house/timdaly/axiom/int/lib/edin.c
14 making /house/timdaly/axiom/int/lib/fnct_key.c from /house/timdaly/axiom/src/lib/fnct_key.c.pamphlet
15 making /house/timdaly/axiom/obj/linux/lib/fnct_key.o from /house/timdaly/axiom/int/lib/fnct_key.c
17 making /house/timdaly/axiom/int/lib/halloc.c from /house/timdaly/axiom/src/lib/halloc.c.pamphlet
18 making /house/timdaly/axiom/obj/linux/lib/halloc.o from /house/timdaly/axiom/int/lib/halloc.c
20 making /house/timdaly/axiom/int/lib/openpty.c from /house/timdaly/axiom/src/lib/openpty.c.pamphlet
21 making /house/timdaly/axiom/obj/linux/lib/openpty.o from /house/timdaly/axiom/int/lib/openpty.c
23 making /house/timdaly/axiom/int/lib/pixmap.c from /house/timdaly/axiom/src/lib/pixmap.c.pamphlet
24 making /house/timdaly/axiom/obj/linux/lib/pixmap.o from /house/timdaly/axiom/int/lib/pixmap.c
26 making /house/timdaly/axiom/int/lib/prt.c from /house/timdaly/axiom/src/lib/prt.c.pamphlet
27 making /house/timdaly/axiom/obj/linux/lib/prt.o from /house/timdaly/axiom/int/lib/prt.c
29 making /house/timdaly/axiom/int/lib/sockio-c.c from /house/timdaly/axiom/src/lib/sockio-c.c.pamphlet
30 making /house/timdaly/axiom/obj/linux/lib/sockio-c.o from /house/timdaly/axiom/int/lib/sockio-c.c
32 making /house/timdaly/axiom/int/lib/spadcolors.c from /house/timdaly/axiom/src/lib/spadcolors.c.pamphlet
33 making /house/timdaly/axiom/obj/linux/lib/spadcolors.o from /house/timdaly/axiom/int/lib/spadcolors.c
35 making /house/timdaly/axiom/int/lib/util.c from /house/timdaly/axiom/src/lib/util.c.pamphlet
36 making /house/timdaly/axiom/obj/linux/lib/util.o from /house/timdaly/axiom/int/lib/util.c
38 making /house/timdaly/axiom/int/lib/wct.c from /house/timdaly/axiom/src/lib/wct.c.pamphlet
39 making /house/timdaly/axiom/obj/linux/lib/wct.o from /house/timdaly/axiom/int/lib/wct.c
41 making /house/timdaly/axiom/int/lib/XDither.c from /house/timdaly/axiom/src/lib/XDither.c.pamphlet
42 making /house/timdaly/axiom/obj/linux/lib/XDither.o from /house/timdaly/axiom/int/lib/XDither.c
44 making /house/timdaly/axiom/int/lib/XShade.c from /house/timdaly/axiom/src/lib/XShade.c.pamphlet
45 making /house/timdaly/axiom/obj/linux/lib/XShade.o from /house/timdaly/axiom/int/lib/XShade.c
47 making /house/timdaly/axiom/int/lib/XSpadFill.c from /house/timdaly/axiom/src/lib/XSpadFill.c.pamphlet
48 making /house/timdaly/axiom/obj/linux/lib/XSpadFill.o from /house/timdaly/axiom/int/lib/XSpadFill.c
5 making /house/timdaly/axiom/int/lib/cfuns-c.c from /house/timdaly/axiom/src/lib/cfuns-c.c.pamphlet
6 making /house/timdaly/axiom/obj/linux/lib/cfuns-c.o from /house/timdaly/axiom/int/lib/cfuns-c.c
1 making /house/timdaly/axiom/obj/linux/lib/libspad.a
make[3]: Leaving directory `/house/timdaly/axiom/src/lib'
make[2]: Leaving directory `/house/timdaly/axiom/src'
0 PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=awk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/house/timdaly/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/house/timdaly/axiom/src/share
10 copying /house/timdaly/axiom/src/scripts to /house/timdaly/axiom/mnt/linux/bin
19 making /house/timdaly/axiom/lsp
make[2]: Entering directory `/house/timdaly/axiom/lsp'
2 building gcl-2.5.2
3 applying EXTRAS patch to h/linux.defs
patching file linux.defs
4 setup ini files for EXTRAS patch
5 applying HAVE_XDR patch to h/linux.h
patching file linux.h
6 applying libspad.a patch to unixport/makefile
patching file makefile
7 applying toploop patch to unixport/init_gcl.lsp
patching file init_gcl.lsp.in
8 applying object_to_float patch
patching file cmpaux.c
9 applying in-package patch
patching file package.d
10 applying EXIT patch
18 applying MAX_STACK_SIZE patch
patching file main.c
11 applying tail-recursive noise patch
patching file cmpflet.lsp
12 applying tail-recursive noise patch
patching file cmpcall.lsp
creating cache ./config.cache
checking host system type... ia64-unknown-linux-gnu
host=ia64-unknown-linux-gnu
enable_machine=
Exactly one loader option must be chosen: dlopen=yes statsysbfd=yes dynsysbfd=no locbfd=no custreloc=no
make[3]: Entering directory `/house/timdaly/axiom/lsp/gcl-2.5.2'
rm -f bin/gcl xbin/gcl
MGCLDIR=`echo /house/timdaly/axiom/lsp/gcl-2.5.2 | sed -e 'sX^\([a-z]\):X/\1Xg'` ; \
GCLDIR=`echo /house/timdaly/axiom/lsp/gcl-2.5.2` ; \
make install-command "INSTALL_LIB_DIR=$GCLDIR" "prefix=$GCLDIR" "BINDIR=$MGCLDIR/unixport"
make[4]: Entering directory `/house/timdaly/axiom/lsp/gcl-2.5.2'
rm -f /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gcl
(echo '#!/bin/sh' ; \
if gcc --version | grep -q -i mingw ; then echo "export C_INCLUDE_PATH=`echo $INSTALL_LIB_DIR`/h"; else echo "export C_INCLUDE_PATH=/house/timdaly/axiom/lsp/gcl-2.5.2/h:\$C_INCLUDE_PATH"; fi ;\
echo exec /house/timdaly/axiom/lsp/gcl-2.5.2/unixport/ \\ ; \
echo '   -dir' /house/timdaly/axiom/lsp/gcl-2.5.2/unixport/ \\ ; \
echo '   -libdir' /house/timdaly/axiom/lsp/gcl-2.5.2/ \\ ; \
echo '   -eval '\''(setq si::*allow-gzipped-file* t)'\' \\ ;\
! [ -d "" ] || echo '   -eval '\''(setq si::*tk-library* '\"\"')'\' \\;\
[ "" = "" ] || echo '   -eval '\''(si::init-readline)'\' \\;\
echo '     '\"\$@\" ) > /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gcl;
echo '#' other options: -load "/tmp/foo.o" -load "jo.lsp" -eval '"(joe 3)"' >> /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gcl
chmod a+x /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gcl
rm -f /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gclm.bat
if gcc --version | grep -q mingw ; then (echo '@SET cd='; \
 echo '@SET promp%prompt%'; \
 echo '@PROMPT SET cd'; \
 echo '@CALL>%temp%.\setdir.bat'; \
 echo '@'; \
 echo '% do not delete this line %'; \
 echo '@ECHO off'; \
 echo 'PROMPT %promp'; \
 echo 'FOR %%c IN (CALL DEL) DO %%c %temp%.\setdir.bat'; \
 echo 'set cwd=%cd%'; \
 echo 'set libdir=%cd%\..\lib\gcl-2.5.0'; \
 echo 'set unixportdir=%libdir%\unixport'; \
 echo 'path %cd%\..\mingw\bin;%PATH%'; \
 echo "start %unixportdir%\saved_gcl.exe -dir %unixportdir% -libdir %libdir% -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9" ) > /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gclm.bat ; fi
rm -f /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gclfinal.bat
if gcc --version | grep -q -i mingw ; then (echo 'ECHO path %1\mingw\bin;%PATH% > gcli.bat'; \
 echo "ECHO start %1\lib\gcl-2.5.0\unixport\saved_gcl.exe -dir %1\lib\gcl-2.5.0\unixport -libdir %1\lib\gcl-2.5.0 -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9 >> gcli.bat" ) > /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gclfinal.bat ; fi
make[4]: Leaving directory `/house/timdaly/axiom/lsp/gcl-2.5.2'
(cd xbin ; cp ../bin/gcl .)
cd cmpnew && make collectfn.o
make[4]: Entering directory `/house/timdaly/axiom/lsp/gcl-2.5.2/cmpnew'
../unixport/saved_gcl ../unixport/ -compile collectfn.lsp
make[4]: ../unixport/saved_gcl: Command not found
make[4]: *** [collectfn.o] Error 127
make[4]: Leaving directory `/house/timdaly/axiom/lsp/gcl-2.5.2/cmpnew'
make[3]: *** [cmpnew/collectfn.o] Error 2
make[3]: Leaving directory `/house/timdaly/axiom/lsp/gcl-2.5.2'
cp: cannot stat `unixport/saved_gcl': No such file or directory
make[2]: *** [gcldir] Error 1
make[2]: Leaving directory `/house/timdaly/axiom/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/house/timdaly/axiom'
make: *** [all] Error 2
bash-2.05a$ uname -a
uname -a
Linux spe156 2.4.18-mckinley-smp #1 SMP Thu Jul 11 12:51:02 MDT 2002 ia64 unknown
bash-2.05a$ exit
exit
exit
spe156> exit
exit
spe156> logout
Connection closed by foreign host.

\start
Date: 23 Oct 2003 14:22:45 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: static build  and HP TestDrive hp156 console

Greetings!

You're in luck -- axiom ia64 lives, at least on Debian, which is most
likely exactly the machine you are running.

This is a configure script default error -- just add
--disable-statsysbfd --enable-dlopen to the configure flags.
Currently needed (alas) on mips(el), ia64, hppa, and alpha. 

One additional annoyance remains on ia64 -- the ld.so 'function
descriptors' are dynamically generated, which means that unless the
shared libs at runtime are exactly the same as at build time, you can
lose big.  Emacs had a similar issue, as they like us make images with
unexec, which stores function addresses in the executable's .data
section.  Was the original motivation for the static build option, but
alas again, this does not seem to work with dlopen (naturally).
Probably the shortest way out is to implement
bfd_relocate_section_contents on this machine, but so far there are no
users (I know of), and this is low priority, esp. with the appearance
of amd64, which is fully supported in 64bit mode.

Please let me know if you have probs.

Tim Daly writes:

> Thanks.
> 
> I just built and tested a non-static version of the system using
> 2.6.1 and it works fine (modulo the fact that the files were renamed).
> The 2.6.1 version is in the CVS and will be the default build.
> The static version failed as mentioned. I'll try a static rebuild 
> (possibly tonight).
> 
> I am doing compiles using HP's TestDrive server farm.
> Just out of wild hope I tried it on one of their 64bit Itanium machines.
> I've attached the console log. It blew up quite early in the build
> because it couldn't recognize the machine type. Under Schelter's 
> regime it used to be the case that you set the machine type by typing
> ./add-defs foo
> Can you tell me how the machine type is decided now?
> 
> =====================================================================
> 
> bash-2.05b# telnet hp156
> Trying 192.233.54.156...
> Connected to hp156.
> Escape character is '^]'.
> Debian GNU/Linux 3.0 spe156.testdrive.hp.com
> spe156 login: timdaly
> Password: 
> 
> Last login: Thu Oct 23 12:02:44 2003 from rio.sci.ccny.cuny.edu on pts/1
> Linux spe156 2.4.18-mckinley-smp #1 SMP Thu Jul 11 12:51:02 MDT 2002 ia64 unknown
> ---------------------------------------
> The Testdrive program is here to enable you to get direct access via the
> internet to Compaq's high end AlphaServers and Proliant servers.  We thank
> you for your time trying out our equipment and encourage
> suggestions.  Please send all comments and feedback to
> testdrive@compaq.com.
> 
> Rules of the Program
> --------------------
> We do not allow the following:
> 1. Running password crackers, dnetc clients, seti, distrib.net, etc.
> 
> 2. Bringing down our machines, cracking, etc.  We have no doubt that you
> can break into the machines if you really want to, but why.  When you
> bring down a machine you take away a free and valuable resource from the
> open source community.  So please, think before you act.
> 
> 3. Long running, CPU bound processes are not encouraged.  The 
> Testdrive program is not intended as a benchmark nor production
> environment.  
> Programs that consume significant amounts of system resources only make
> other 
> users Testdrive experiences less useful.  Experiencing the power of Compaq 
> systems should be taken in moderation for everyone's benefit! :-)
> 
> 4. Abusive file storage.  Testdrive is not intended as an ISP/ASP
> environment.  
> User areas are not backed up, and cannot be restored.  Users with large 
> amount of disk usage should understand they are simply consuming their 
> fellow testers resources.
> 
> Connections and File Moving
> ---------------------------
> We only allow ftp and telnet in to the testdrive program. No outgoing
> connections are allowed.
> 
> To move a file, ftp into any of our testdrive machines, and use a put to
> place the files in your house directory.  From there they will be
> available on all machines.
> 
> For fast local access from individual machines to your files, use the /tmp
> directory on the local machine.
> 
> Thanks again for Testdriving
> 
> Testdrive Team
> spe156> bash
> bash-2.05a$ pwd
> /house/timdaly
> bash-2.05a$ cd axiom
> bash-2.05a$ echo $AXIOM
> /house/timdaly/axiom/mnt/linux
> bash-2.05a$ make
> 13 making noweb
> patching file modules.c
> mnt.o: In function `emitfile':
> mnt.o(.text+0xc72): the use of `tmpnam' is dangerous, better use `mkstemp'
> make[1]: [install-shell] Error 1 (ignored)
> make[1]: [install-code] Error 1 (ignored)
> /bin/sh: texhash: command not found
> make[1]: [install-elisp] Error 1 (ignored)
> 0 SPAD=/house/timdaly/axiom/mnt/linux SYS=linux SPD=/house/timdaly/axiom LSP=/house/timdaly/axiom/lsp GCLDIR=/house/timdaly/axiom/lsp/gcl-2.5.2 SRC=/house/timdaly/axiom/src INT=/house/timdaly/axiom/int OBJ=/house/timdaly/axiom/obj MNT=/house/timdaly/axiom/mnt ZIPS=/house/timdaly/axiom/zips TMP=/house/timdaly/axiom/obj/tmp SPADBIN=/house/timdaly/axiom/mnt/linux/bin INC=/house/timdaly/axiom/src/include CCLBASE=/house/timdaly/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /house/timdaly/axiom/obj/tmp/trace GCLVERSION=gcl-2.5.2
> 10 copying /house/timdaly/axiom/src/scripts to /house/timdaly/axiom/mnt/linux/bin
> 1 making a linux system, PART=cprogs SUBPART=everything
> 2 Environment SPAD=/house/timdaly/axiom/mnt/linux SYS=linux SPD=/house/timdaly/axiom LSP=/house/timdaly/axiom/lsp GCLDIR=/house/timdaly/axiom/lsp/gcl-2.5.2 SRC=/house/timdaly/axiom/src INT=/house/timdaly/axiom/int OBJ=/house/timdaly/axiom/obj MNT=/house/timdaly/axiom/mnt ZIPS=/house/timdaly/axiom/zips TMP=/house/timdaly/axiom/obj/tmp SPADBIN=/house/timdaly/axiom/mnt/linux/bin INC=/house/timdaly/axiom/src/include CCLBASE=/house/timdaly/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /house/timdaly/axiom/obj/tmp/trace GCLVERSION=gcl-2.5.2
> make[1]: Entering directory `/house/timdaly/axiom'
> 11 checking directory structure
> 12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=awk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/house/timdaly/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/house/timdaly/axiom/src/share
> 18 making /house/timdaly/axiom/src
> make[2]: Entering directory `/house/timdaly/axiom/src'
> 1 making /house/timdaly/axiom/src/scripts
> make[3]: Entering directory `/house/timdaly/axiom/src/scripts'
> 1 making /house/timdaly/axiom/src/scripts
> make[3]: Leaving directory `/house/timdaly/axiom/src/scripts'
> 5 making /house/timdaly/axiom/src/lib
> make[3]: Entering directory `/house/timdaly/axiom/src/lib'
> 2 making /house/timdaly/axiom/int/lib/bsdsignal.c from /house/timdaly/axiom/src/lib/bsdsignal.c.pamphlet
> 3 making /house/timdaly/axiom/obj/linux/lib/bsdsignal.o from /house/timdaly/axiom/int/lib/bsdsignal.c
> 8 making /house/timdaly/axiom/int/lib/cursor.c from /house/timdaly/axiom/src/lib/cursor.c.pamphlet
> 9 making /house/timdaly/axiom/obj/linux/lib/cursor.o from /house/timdaly/axiom/int/lib/cursor.c
> 11 making /house/timdaly/axiom/int/lib/edin.c from /house/timdaly/axiom/src/lib/edin.c.pamphlet
> 12 making /house/timdaly/axiom/obj/linux/lib/edin.o from /house/timdaly/axiom/int/lib/edin.c
> 14 making /house/timdaly/axiom/int/lib/fnct_key.c from /house/timdaly/axiom/src/lib/fnct_key.c.pamphlet
> 15 making /house/timdaly/axiom/obj/linux/lib/fnct_key.o from /house/timdaly/axiom/int/lib/fnct_key.c
> 17 making /house/timdaly/axiom/int/lib/halloc.c from /house/timdaly/axiom/src/lib/halloc.c.pamphlet
> 18 making /house/timdaly/axiom/obj/linux/lib/halloc.o from /house/timdaly/axiom/int/lib/halloc.c
> 20 making /house/timdaly/axiom/int/lib/openpty.c from /house/timdaly/axiom/src/lib/openpty.c.pamphlet
> 21 making /house/timdaly/axiom/obj/linux/lib/openpty.o from /house/timdaly/axiom/int/lib/openpty.c
> 23 making /house/timdaly/axiom/int/lib/pixmap.c from /house/timdaly/axiom/src/lib/pixmap.c.pamphlet
> 24 making /house/timdaly/axiom/obj/linux/lib/pixmap.o from /house/timdaly/axiom/int/lib/pixmap.c
> 26 making /house/timdaly/axiom/int/lib/prt.c from /house/timdaly/axiom/src/lib/prt.c.pamphlet
> 27 making /house/timdaly/axiom/obj/linux/lib/prt.o from /house/timdaly/axiom/int/lib/prt.c
> 29 making /house/timdaly/axiom/int/lib/sockio-c.c from /house/timdaly/axiom/src/lib/sockio-c.c.pamphlet
> 30 making /house/timdaly/axiom/obj/linux/lib/sockio-c.o from /house/timdaly/axiom/int/lib/sockio-c.c
> 32 making /house/timdaly/axiom/int/lib/spadcolors.c from /house/timdaly/axiom/src/lib/spadcolors.c.pamphlet
> 33 making /house/timdaly/axiom/obj/linux/lib/spadcolors.o from /house/timdaly/axiom/int/lib/spadcolors.c
> 35 making /house/timdaly/axiom/int/lib/util.c from /house/timdaly/axiom/src/lib/util.c.pamphlet
> 36 making /house/timdaly/axiom/obj/linux/lib/util.o from /house/timdaly/axiom/int/lib/util.c
> 38 making /house/timdaly/axiom/int/lib/wct.c from /house/timdaly/axiom/src/lib/wct.c.pamphlet
> 39 making /house/timdaly/axiom/obj/linux/lib/wct.o from /house/timdaly/axiom/int/lib/wct.c
> 41 making /house/timdaly/axiom/int/lib/XDither.c from /house/timdaly/axiom/src/lib/XDither.c.pamphlet
> 42 making /house/timdaly/axiom/obj/linux/lib/XDither.o from /house/timdaly/axiom/int/lib/XDither.c
> 44 making /house/timdaly/axiom/int/lib/XShade.c from /house/timdaly/axiom/src/lib/XShade.c.pamphlet
> 45 making /house/timdaly/axiom/obj/linux/lib/XShade.o from /house/timdaly/axiom/int/lib/XShade.c
> 47 making /house/timdaly/axiom/int/lib/XSpadFill.c from /house/timdaly/axiom/src/lib/XSpadFill.c.pamphlet
> 48 making /house/timdaly/axiom/obj/linux/lib/XSpadFill.o from /house/timdaly/axiom/int/lib/XSpadFill.c
> 5 making /house/timdaly/axiom/int/lib/cfuns-c.c from /house/timdaly/axiom/src/lib/cfuns-c.c.pamphlet
> 6 making /house/timdaly/axiom/obj/linux/lib/cfuns-c.o from /house/timdaly/axiom/int/lib/cfuns-c.c
> 1 making /house/timdaly/axiom/obj/linux/lib/libspad.a
> make[3]: Leaving directory `/house/timdaly/axiom/src/lib'
> make[2]: Leaving directory `/house/timdaly/axiom/src'
> 0 PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=awk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/house/timdaly/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/house/timdaly/axiom/src/share
> 10 copying /house/timdaly/axiom/src/scripts to /house/timdaly/axiom/mnt/linux/bin
> 19 making /house/timdaly/axiom/lsp
> make[2]: Entering directory `/house/timdaly/axiom/lsp'
> 2 building gcl-2.5.2
> 3 applying EXTRAS patch to h/linux.defs
> patching file linux.defs
> 4 setup ini files for EXTRAS patch
> 5 applying HAVE_XDR patch to h/linux.h
> patching file linux.h
> 6 applying libspad.a patch to unixport/makefile
> patching file makefile
> 7 applying toploop patch to unixport/init_gcl.lsp
> patching file init_gcl.lsp.in
> 8 applying object_to_float patch
> patching file cmpaux.c
> 9 applying in-package patch
> patching file package.d
> 10 applying EXIT patch
> 18 applying MAX_STACK_SIZE patch
> patching file main.c
> 11 applying tail-recursive noise patch
> patching file cmpflet.lsp
> 12 applying tail-recursive noise patch
> patching file cmpcall.lsp
> creating cache ./config.cache
> checking host system type... ia64-unknown-linux-gnu
> host=ia64-unknown-linux-gnu
> enable_machine=
> Exactly one loader option must be chosen: dlopen=yes statsysbfd=yes dynsysbfd=no locbfd=no custreloc=no
> make[3]: Entering directory `/house/timdaly/axiom/lsp/gcl-2.5.2'
> rm -f bin/gcl xbin/gcl
> MGCLDIR=`echo /house/timdaly/axiom/lsp/gcl-2.5.2 | sed -e 'sX^\([a-z]\):X/\1Xg'` ; \
> GCLDIR=`echo /house/timdaly/axiom/lsp/gcl-2.5.2` ; \
> make install-command "INSTALL_LIB_DIR=$GCLDIR" "prefix=$GCLDIR" "BINDIR=$MGCLDIR/unixport"
> make[4]: Entering directory `/house/timdaly/axiom/lsp/gcl-2.5.2'
> rm -f /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gcl
> (echo '#!/bin/sh' ; \
> if gcc --version | grep -q -i mingw ; then echo "export C_INCLUDE_PATH=`echo $INSTALL_LIB_DIR`/h"; else echo "export C_INCLUDE_PATH=/house/timdaly/axiom/lsp/gcl-2.5.2/h:\$C_INCLUDE_PATH"; fi ;\
> echo exec /house/timdaly/axiom/lsp/gcl-2.5.2/unixport/ \\ ; \
> echo '   -dir' /house/timdaly/axiom/lsp/gcl-2.5.2/unixport/ \\ ; \
> echo '   -libdir' /house/timdaly/axiom/lsp/gcl-2.5.2/ \\ ; \
> echo '   -eval '\''(setq si::*allow-gzipped-file* t)'\' \\ ;\
> ! [ -d "" ] || echo '   -eval '\''(setq si::*tk-library* '\"\"')'\' \\;\
> [ "" = "" ] || echo '   -eval '\''(si::init-readline)'\' \\;\
> echo '     '\"\$@\" ) > /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gcl;
> echo '#' other options: -load "/tmp/foo.o" -load "jo.lsp" -eval '"(joe 3)"' >> /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gcl
> chmod a+x /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gcl
> rm -f /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gclm.bat
> if gcc --version | grep -q mingw ; then (echo '@SET cd='; \
>  echo '@SET promp%prompt%'; \
>  echo '@PROMPT SET cd'; \
>  echo '@CALL>%temp%.\setdir.bat'; \
>  echo '@'; \
>  echo '% do not delete this line %'; \
>  echo '@ECHO off'; \
>  echo 'PROMPT %promp'; \
>  echo 'FOR %%c IN (CALL DEL) DO %%c %temp%.\setdir.bat'; \
>  echo 'set cwd=%cd%'; \
>  echo 'set libdir=%cd%\..\lib\gcl-2.5.0'; \
>  echo 'set unixportdir=%libdir%\unixport'; \
>  echo 'path %cd%\..\mingw\bin;%PATH%'; \
>  echo "start %unixportdir%\saved_gcl.exe -dir %unixportdir% -libdir %libdir% -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9" ) > /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gclm.bat ; fi
> rm -f /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gclfinal.bat
> if gcc --version | grep -q -i mingw ; then (echo 'ECHO path %1\mingw\bin;%PATH% > gcli.bat'; \
>  echo "ECHO start %1\lib\gcl-2.5.0\unixport\saved_gcl.exe -dir %1\lib\gcl-2.5.0\unixport -libdir %1\lib\gcl-2.5.0 -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9 >> gcli.bat" ) > /house/timdaly/axiom/lsp/gcl-2.5.2/bin/gclfinal.bat ; fi
> make[4]: Leaving directory `/house/timdaly/axiom/lsp/gcl-2.5.2'
> (cd xbin ; cp ../bin/gcl .)
> cd cmpnew && make collectfn.o
> make[4]: Entering directory `/house/timdaly/axiom/lsp/gcl-2.5.2/cmpnew'
> ../unixport/saved_gcl ../unixport/ -compile collectfn.lsp
> make[4]: ../unixport/saved_gcl: Command not found
> make[4]: *** [collectfn.o] Error 127
> make[4]: Leaving directory `/house/timdaly/axiom/lsp/gcl-2.5.2/cmpnew'
> make[3]: *** [cmpnew/collectfn.o] Error 2
> make[3]: Leaving directory `/house/timdaly/axiom/lsp/gcl-2.5.2'
> cp: cannot stat `unixport/saved_gcl': No such file or directory
> make[2]: *** [gcldir] Error 1
> make[2]: Leaving directory `/house/timdaly/axiom/lsp'
> make[1]: *** [lspdir] Error 2
> make[1]: Leaving directory `/house/timdaly/axiom'
> make: *** [all] Error 2
> bash-2.05a$ uname -a
> uname -a
> Linux spe156 2.4.18-mckinley-smp #1 SMP Thu Jul 11 12:51:02 MDT 2002 ia64 unknown
> bash-2.05a$ exit
> exit
> exit
> spe156> exit
> exit
> spe156> logout
> Connection closed by foreign host.

\start
Date: Thu, 23 Oct 2003 22:39:08 +0200
From: David Mentre
To: Tim Daly
Subject: Error on INTERP.EXPOSED when building from scratch

Hello Tim,

I tried to build Axiom from scratch (with gcl 2.6.1) on my powerpc
machine and the build failed with following error message on
INTERP.EXPOSED.

make[3]: Entering directory `/home/david/pub/axiom-libre/axiom-powerpc/axiom/src/interp'
make[3]: *** No rule to make target `/home/david/pub/axiom-libre/axiom-powerpc/axiom/src/algebra/INTERP.EXPOSED.pamphlet', needed by `/home/david/pub/axiom-libre/axiom-powerpc/axiom/int/interp/algebra/INTERP.EXPOSED'.  Stop.
make[3]: Leaving directory `/home/david/pub/axiom-libre/axiom-powerpc/axiom/src/interp'
make[2]: *** [interpdir] Error 2

I thought that INTERP.EXPOSED was gone[1]. Would the issue related to
powerpc arch?

[1] http://mail.nongnu.org/archive/html/axiom-developer/2003-10/msg00068.html

\start
Date: Thu, 23 Oct 2003 16:44:13 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Error on INTERP.EXPOSED when building from scratch

David,

INTERP.EXPOSED is gone. Did you do a cvs update before the build?

\start
Date: Thu, 23 Oct 2003 17:13:26 -0400
From: Bill Page
To: Tim Daly, David Mentre
Subject: RE: Error on INTERP.EXPOSED when building from scratch

Tim,

I had the same problem as David when I downloaded the CVS to
a virgin machine last week. There is still a reference to
src/algebra/INTERP.EXPOSED in the src/interp/Makefile. I solved
it (temporarily) by copying INTERP.EXPOSED.pamphlet into
src/algebra from an earlier distribution.

Bill Page.

> David,
> 
> INTERP.EXPOSED is gone. Did you do a cvs update before the build?

\start
Date: Thu, 23 Oct 2003 17:18:45 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Error on INTERP.EXPOSED when building from scratch

Bill, 

I just tried:

cd /tmp

cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom/src/interp/Makefile.pamphlet

cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom/src/interp/Makefile.pamphlet

cd axiom/src/interp

fgrep -i interp.exposed Makefile.pamphlet

and find no reference. I'm confused.

\start
Date: Thu, 23 Oct 2003 18:02:55 -0400
From: Bill Page
To: Tim Daly
Subject: RE: Error on INTERP.EXPOSED when building from scratch

Tim,

You are right. It is gone. (but it was there last week...)
<grin>

BTW, thanks very much for your work on GCL 2.6.1!

I have started work again on the Windows port. Until your
update of the CVS, I was working with the Windows binary
version of GCL 2.6.1. I have got as far as building
interpsys, but I get a "memory may be damaged" error when
it trys to compile the first spad file (AHYP.spad). Maybe
this is due to the ad hoc way I tried to get around linking
the cfuns-c external routines.

Now I will start again, compile GCL 2.6.1 under MSYS and
linking in the externals.

Cheers,
Bill Page.

> Bill, 
> 
> I just tried:
> 
> cd /tmp
> 
> cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co 
> axiom/src/interp/Makefile.pamphlet
> 
> cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co 
> axiom/src/interp/Makefile.pamphlet
> 
> cd axiom/src/interp
> 
> fgrep -i interp.exposed Makefile.pamphlet
> 
> and find no reference. I'm confused.

\start
Date: Thu, 23 Oct 2003 18:20:33 -0400
From: Tim Daly
To: Bill Page
Subject: GCL 2.6.1 on Windows XP
Cc: Camm Maguire

Bill,

I believe that both you and David had a problem. 
I probably uploaded a bad Makefile.pamphlet.

Re: Windows GCL-2.6.1 
I downloaded Camm's image but it won't run under Windows XP.

If you get a chance could you jot down the steps you take to
build GCL on Windows? I tried to get make to work but got nowhere.
Windows XP make me so enfeebled that I can't seem to figure out
how to get any of my tools working. I guess that's why the code
name for this version was Kryptonite :-) I have both mingw and
cygwin installed.

\start
Date: Thu, 23 Oct 2003 18:47:48 -0400
From: Bill Page
To: Tim Daly
Subject: RE: GCL 2.6.1 on Windows XP
Cc: Camm Maguire

Tim,

Did you download?
 
http://people.debian.org/~camm/gcl/stable-binary/gcl_2.6.1.mingw32_japi_xdr_
20030929.zip

Unzip it and run the install program. It installed and
runs under Windows XP for me with no problems (although
an earlier version did fail on the install unless you
installed it into a directory named c:/lang).

What kind of "won't run" did you get when you tried it?

About Windows - just think of it like travelling to a
foriegn country where no one speaks your language ...

Details of building GCL from scratch under MSYS and notes
on required patches to AXIOM to follow later (tonight if
possible).

Cheers,
Bill.

> I believe that both you and David had a problem. 
> I probably uploaded a bad Makefile.pamphlet.
> 
> Re: Windows GCL-2.6.1 
> I downloaded Camm's image but it won't run under Windows XP.
> 
> If you get a chance could you jot down the steps you take to
> build GCL on Windows? I tried to get make to work but got nowhere.
> Windows XP make me so enfeebled that I can't seem to figure out
> how to get any of my tools working. I guess that's why the code
> name for this version was Kryptonite :-) I have both mingw and
> cygwin installed.

\start
Date: 23 Oct 2003 19:06:59 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: GCL 2.6.1 on Windows XP
Cc: Bill Page

Greetings!  Alas I'm equally enfeebled on Windows, and of course none
of the deb binaries will run there.  But we have our staunch Mike
Thomas to help you when needed.

Take care, 

Tim Daly writes:

> Bill,
> 
> I believe that both you and David had a problem. 
> I probably uploaded a bad Makefile.pamphlet.
> 
> Re: Windows GCL-2.6.1 
> I downloaded Camm's image but it won't run under Windows XP.
> 
> If you get a chance could you jot down the steps you take to
> build GCL on Windows? I tried to get make to work but got nowhere.
> Windows XP make me so enfeebled that I can't seem to figure out
> how to get any of my tools working. I guess that's why the code
> name for this version was Kryptonite :-) I have both mingw and
> cygwin installed.

\start
Date: Thu, 23 Oct 2003 21:29:05 -0400
From: Bill Page
To: Tim Daly
Subject: RE: GCL 2.6.1 on Windows XP
Cc: Camm Maguire

Tim,

On Thursday, October 23, 2003 6:48 PM I wrote:
> 
> Did you download?
> 
>   
> http://people.debian.org/~camm/gcl/stable-binary/gcl_2.6.1.min
> gw32_japi_xdr_20030929.zip
> 
> Unzip it and run the install program. It installed and
> runs under Windows XP for me with no problems (although
> an earlier version did fail on the install unless you
> installed it into a directory named c:/lang).
> 

I have just tried this and I see that the problem with the
install directory still exists. When the install scripts
asks where you want to install GCL, tell it

  c:/lang/gcl261

instead of the default, then the install will complete
normally.

I understood that Mike Thomas was going to upload a corrected
version a couple of weeks ago but perhaps it has not yet made
it to debian.

\start
Date: Thu, 23 Oct 2003 23:27:33 -0400
From: Tim Daly
To: David Mentre
Subject: ports

David,

Thanks to HP's TestDrive program we have shown that Axiom 
successfully builds and runs on the following systems:

 Slackware Linux 8.0.01 on Intel
 ProLiant ML530 2@800MHz
 Linux spe160 2.4.20 #20 Mon Mar 17 22:55:24 PST 2003 i686 unknown


 Red Hat Linux 8.0 on Intel 
 ProLiant ML530 2@1.0GHz 
 Red Hat Enterprise Linux ES release 2.1 (Panama)
 Kernel 2.4.9-e.12smp on an i686
 Linux spe141.testdrive.hp.com 2.4.9-e.12smp #1 SMP Tue Feb 11 02:24:10 EST 2003 i686 unknown

Could you update the "ports" webpage?
I've also saved the complete image of the build tree so we
can create binary files for these distributions.


More are on the way. 

\start
Date: Thu, 23 Oct 2003 23:52:38 -0400
From: Tim Daly
To: Camm Maguire
Subject: GCL-2.5.2 build

Camm,

The version I'm porting to the various HP systems is GCL-2.5.2
(mostly because I'm doing many things in parallel and 2.6.1
is on a different thread of work). 

I get warnings (not errors) of the form:

cmpcall.c: In function `LnkTL124':
cmpcall.c:1949: warning: dereferencing type-punned pointer will break strict-aliasing rules

The message is output hundreds of times during the build for many files.
It does not seem to affect the result but I'm passing it along anyway.

\start
Date: Fri, 24 Oct 2003 02:32:24 -0400
From: Bill Page
To: Tim Daly
Subject: RE: GCL 2.6.1 on Windows XP

Tim,

On Thursday, October 23, 2003 6:21 PM you asked
> 
> If you get a chance could you jot down the steps you take
> to build GCL on Windows? I tried to get make to work but
> got nowhere. Windows XP make me so enfeebled that I can't
> seem to figure out how to get any of my tools working.
> I guess that's why the code name for this version was
> Kryptonite :-) I have both mingw and cygwin installed.
> 

Well, this will get you started with GCL. With these
patches, the make at least starts the build of Axiom
but fails because of Windows use of file names that contain
a C:/xxx (GCL thinks this is a package name).  I've solved
this by passing strings instead of symbols.

So in the next message I will send you at least one more
set of patches for this and also a patch to boot to handle
the carriage return (char = 13) found in Windows text files.

Detailed steps:

1) Go to http://www.mingw.org/download.shtml and download

  http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download

  http://prdownloads.sf.net/mingw/MSYS-1.0.9.exe?download

  http://prdownloads.sf.net/mingw/msysDTK-1.0.1.exe?download

  http://prdownloads.sf.net/mingw/gcc-core-3.3.1-20030804-1.tar.gz?download

2) Install these files in the same order as above. I just
accept the default locations. The last one should be extracted
into c:/mingw and overwrites the older version of gcc. When you
are done, you should be able to start MSYS and a get

  $ gcc -v
  gcc version 3.3.1 (mingw special 20030804-1)

3) Copy the current Axiom CVS into you MSYS home directory.

4) Now you need to apply the patches given below.

5) Set the AXIOM environment variable

  echo 'export AXIOM=`pwd -W`/mnt/windows' > .profile
  . .profile

6) And start your engines!

  make clean
  make

Let me know how it goes. Don't be afraid to ask if some
Windows silliness doesn't make sense to you.

Cheers,
Bill Page.

patch1.windows:
---------------

This patch modifies the main Axiom Makefile for Windows.
You need to do this in order to "bootstrap" noweb. Note
the use of the MSYS -W option on pwd. This produces a
windows compatible path name.

diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/Makefile axiom/Makefile
--- axiom-save/Makefile	Fri Oct 24 00:48:05 2003
+++ axiom/Makefile	Thu Oct 23 19:41:02 2003
@@ -1,4 +1,4 @@
-SPD=$(shell pwd)
+SPD=$(shell pwd -W)
 SYS=$(notdir $(AXIOM))
 SPAD=${SPD}/mnt/${SYS}
 LSP=${SPD}/lsp
@@ -11,7 +11,7 @@
 INT=${SPD}/int
 OBJ=${SPD}/obj
 MNT=${SPD}/mnt
-ZIPS=${SPD}/zips
+ZIPS=${shell pwd}/zips
 TMP=${OBJ}/tmp
 SPADBIN=${MNT}/${SYS}/bin
 INC=${SPD}/src/include
@@ -49,6 +49,9 @@
 	cd ${OBJ}/noweb/src/c ; \
 	cp ${ZIPS}/noweb.modules.c.patch . ; \
 	patch <noweb.modules.c.patch ; \
+	cd ${OBJ}/noweb/src ; \
+	cp ${ZIPS}/noweb.src.Makefile.patch . ; \
+	patch <noweb.src.Makefile.patch ; \
 	cd ${OBJ}/noweb/src ; \
 	${MAKE} BIN=${MNT}/${SYS}/bin LIB=${MNT}/${SYS}/bin/lib \
                 MAN=${MNT}/${SYS}/bin/man \

This patch adds a windows section to the Makefile pamphlet
file.

diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/Makefile.pamphlet axiom/Makefile.pamphlet
--- axiom-save/Makefile.pamphlet	Fri Oct 24 00:48:05 2003
+++ axiom/Makefile.pamphlet	Thu Oct 23 19:45:08 2003
@@ -1849,6 +1849,55 @@
 <<clean>>
 
 @
+
+\subsection{Makefile.windows}
+Annoyingly enough it seems that GCL uses a default extension of .lsp
+rather than .lisp so we add the {\bf LISP} variable here. We need to
+depend on the default extension behavior because the system build
+will load either the interpreted or compiled form of a file depending
+on which is available. This varies at different stages of the build.
+<<Makefile.windows>>=
+# System dependent Makefile for the Intel/Windows/MSYS platform
+# Platform variable
+PLF:=MSYSplatform
+# C compiler flags
+CCF:="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF}
-I/usr/X11/include"
+#CCF:=-g -fno-strength-reduce -Wall -D_GNU_SOURCE  -D${PLF}
-I/usr/X11/include
+# Loader flags
+LDF:= -L/usr/X11R6/lib 
+# C compiler to use
+CC:=gcc 
+AWK=awk
+RANLIB=ranlib
+TOUCH=touch
+TAR=tar
+AXIOMXLROOT=${AXIOM}/compiler
+O=o
+BYE=bye
+LISP=lsp
+DAASE=${SRC}/share
+
+ENV=PLF=${PLF} CCF=${CCF} LDF=${LDF} CC=${CC} AWK=${AWK} RANLIB=${RANLIB} \
+    TOUCH=${TOUCH} TAR=${TAR} AXIOMXLROOT=${AXIOMXLROOT} O=${O} BYE=${BYE}
\
+    LISP=${LISP} DAASE=${DAASE}
+
+all: rootdirs noweb srcsetup lspdir srcdir
+	@echo 45 Makefile.linux called
+	@echo 46 Environment : ${ENV} 
+	@echo 47 finished system build on `date` | tee >lastBuildDate
+
+<<rootdirs>>
+<<noweb.windows>>
+<<literate commands>>
+<<srcsetup>>
+<<src>>
+<<lsp>>
+<<document>>
+<<clean>>
+
+@
+
+
 \eject
 \begin{thebibliography}{99}
 \bibitem{1} CMUCL {\bf http://www.cons.org/cmucl}


This patch adds a patch to the lisp Makefile for mingw.defs
similiar to to one of linux.defs (see below). It removes one
of the windows incompatibe GCL ./configure options. It also
avoids trying to link sockio-c since we are not able to compile
it as it stands under windows. Perhaps it can be re-written
for windows, but maybe a better solution would be to use GCL's
built-in session stuff - help!

Let's just cross our fingers and hope that this omission
doesn't bit us too hard later in the build.

diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/lsp/Makefile.pamphlet axiom/lsp/Makefile.pamphlet
--- axiom-save/lsp/Makefile.pamphlet	Fri Oct 24 00:48:12 2003
+++ axiom/lsp/Makefile.pamphlet	Fri Oct 24 01:13:10 2003
@@ -20,7 +20,8 @@
 This patch is to {\bf h/386-linux.defs} to include two 
 global variables, {\bf EXTRAS} and {\bf EXTRA\_LIB}
 \begin{verbatim}
-EXTRAS = ${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o
+EXTRAS = ${OBJ}/${SYS}/lib/cfuns-c.o
+# ${OBJ}/${SYS}/lib/sockio-c.o
 EXTRA_LIB=${OBJ}/${SYS}/lib/libspad.a
 \end{verbatim}
 The {\bf EXTRAS} variable is used to include two files into the
@@ -45,6 +46,9 @@
 	@(cd ${GCLVERSION}/h ; \
 	  echo 3 applying EXTRAS patch to h/linux.defs ; \
 	  patch <${SPD}/zips/${GCLVERSION}.h.linux.defs.patch )
+	@(cd ${GCLVERSION}/h ; \
+	  echo 3a applying EXTRAS patch to h/mingw.defs ; \
+	  patch <${SPD}/zips/${GCLVERSION}.h.mingw.defs.patch )
 	@(echo 4 setup ini files for EXTRAS patch ; \
 	  touch ${OBJ}/${SYS}/lib/cfuns-c.ini ; \
 	  touch ${OBJ}/${SYS}/lib/sockio-c.ini )
@@ -174,7 +178,7 @@
 relocating object files.
 <<gclConfigureMake>>=
 	@(cd ${GCLVERSION} ; \
-	./configure --enable-vssize=65536*2 --enable-statsysbfd
--enable-readline --enable-maxpage=128*1024 ; \
+	./configure --enable-vssize=65536*2 --enable-readline
--enable-maxpage=128*1024 ; \
 	${ENV} ${MAKE} ; \
 	cp unixport/saved_gcl ${OUT}/lisp )
 @


This patch changes the lib Makefile to avoid compiling
C code that doesn't work under Windows. Note also the 
assing of the platform conditional define to gcc.

diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/src/lib/Makefile.pamphlet axiom/src/lib/Makefile.pamphlet
--- axiom-save/src/lib/Makefile.pamphlet	Fri Oct 24 00:48:35 2003
+++ axiom/src/lib/Makefile.pamphlet	Thu Oct 23 23:15:58 2003
@@ -102,9 +102,10 @@
 
 AR=	${OUT}/bsdsignal.o  ${OUT}/cursor.o ${OUT}/edin.o     \
         ${OUT}/fnct_key.o   ${OUT}/halloc.o ${OUT}/openpty.o  \
-        ${OUT}/pixmap.o     ${OUT}/prt.o    ${OUT}/sockio-c.o \
-        ${OUT}/spadcolors.o ${OUT}/util.o   ${OUT}/wct.o      \
-        ${OUT}/XDither.o    ${OUT}/XShade.o ${OUT}/XSpadFill.o 
+        ${OUT}/pixmap.o     ${OUT}/prt.o     \
+        
+#	${OUT}/sockio-c.o ${OUT}/spadcolors.o ${OUT}/util.o ${OUT}/XDither.o
${OUT}/XShade.o
+# ${OUT}/wct.o ${OUT}/XSpadFill.o 
 
 OTHER=	${OUT}/cfuns-c.o
 
@@ -130,7 +131,7 @@
 ${OUT}/bsdsignal.o: ${MID}/bsdsignal.c
 	@echo 3 making ${OUT}/bsdsignal.o from ${MID}/bsdsignal.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/bsdsignal.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/bsdsignal.c )
 
 @
 
@@ -164,7 +165,7 @@
 ${OUT}/cfuns-c.o: ${MID}/cfuns-c.c
 	@echo 6 making ${OUT}/cfuns-c.o from ${MID}/cfuns-c.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/cfuns-c.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/cfuns-c.c )
 
 @
 
@@ -193,7 +194,7 @@
 ${OUT}/cursor.o: ${MID}/cursor.c
 	@echo 9 making ${OUT}/cursor.o from ${MID}/cursor.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/cursor.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/cursor.c )
 
 @
 
@@ -222,7 +223,7 @@
 ${OUT}/edin.o: ${MID}/edin.c
 	@echo 12 making ${OUT}/edin.o from ${MID}/edin.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/edin.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/edin.c )
 
 @
 
@@ -251,7 +252,7 @@
 ${OUT}/fnct_key.o: ${MID}/fnct_key.c
 	@echo 15 making ${OUT}/fnct_key.o from ${MID}/fnct_key.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/fnct_key.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/fnct_key.c )
 
 @
 
@@ -280,7 +281,7 @@
 ${OUT}/halloc.o: ${MID}/halloc.c
 	@echo 18 making ${OUT}/halloc.o from ${MID}/halloc.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/halloc.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/halloc.c )
 
 @
 
@@ -309,7 +310,7 @@
 ${OUT}/openpty.o: ${MID}/openpty.c
 	@echo 21 making ${OUT}/openpty.o from ${MID}/openpty.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/openpty.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/openpty.c )
 
 @
 
@@ -338,7 +339,7 @@
 ${OUT}/pixmap.o: ${MID}/pixmap.c
 	@echo 24 making ${OUT}/pixmap.o from ${MID}/pixmap.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/pixmap.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/pixmap.c )
 
 @
 
@@ -367,7 +368,7 @@
 ${OUT}/prt.o: ${MID}/prt.c
 	@echo 27 making ${OUT}/prt.o from ${MID}/prt.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/prt.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/prt.c )
 
 @
 
@@ -401,7 +402,7 @@
 ${OUT}/sockio-c.o: ${MID}/sockio-c.c
 	@echo 30 making ${OUT}/sockio-c.o from ${MID}/sockio-c.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/sockio-c.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/sockio-c.c )
 
 @
 
@@ -430,7 +431,7 @@
 ${OUT}/spadcolors.o: ${MID}/spadcolors.c
 	@echo 33 making ${OUT}/spadcolors.o from ${MID}/spadcolors.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/spadcolors.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/spadcolors.c )
 
 @
 
@@ -460,7 +461,7 @@
 ${OUT}/util.o: ${MID}/util.c
 	@echo 36 making ${OUT}/util.o from ${MID}/util.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/util.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/util.c )
 
 @
 
@@ -489,7 +490,7 @@
 ${OUT}/wct.o: ${MID}/wct.c
 	@echo 39 making ${OUT}/wct.o from ${MID}/wct.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/wct.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/wct.c )
 
 @
 
@@ -518,7 +519,7 @@
 ${OUT}/XDither.o: ${MID}/XDither.c
 	@echo 42 making ${OUT}/XDither.o from ${MID}/XDither.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/XDither.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/XDither.c )
 
 @
 
@@ -547,7 +548,7 @@
 ${OUT}/XShade.o: ${MID}/XShade.c
 	@echo 45 making ${OUT}/XShade.o from ${MID}/XShade.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/XShade.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/XShade.c )
 
 @
 
@@ -576,7 +577,7 @@
 ${OUT}/XSpadFill.o: ${MID}/XSpadFill.c
 	@echo 48 making ${OUT}/XSpadFill.o from ${MID}/XSpadFill.c
 	@( cd ${OUT} ; \
-	gcc -c -I${INC} ${MID}/XSpadFill.c )
+	gcc -c -D${PLF} -I${INC} ${MID}/XSpadFill.c )
 
 @


Here are some preliminary patches to the C code that
we can compile under Windows.
 
diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/src/lib/bsdsignal.c.pamphlet axiom/src/lib/bsdsignal.c.pamphlet
--- axiom-save/src/lib/bsdsignal.c.pamphlet	Fri Oct 24 00:48:35 2003
+++ axiom/src/lib/bsdsignal.c.pamphlet	Thu Oct 23 20:13:46 2003
@@ -44,6 +44,9 @@
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
 @
+\section{Windows}
+The signal function is not available under Windows.
+
 <<*>>=
 <<license>>
 
@@ -64,6 +67,9 @@
 bsdSignal(int sig,SignalHandlerFunc action,int restartSystemCall)
 #endif
 {
+#if defined(MSYSplatform)
+  return (SignalHandlerFunc) -1;
+#else
   struct sigaction in,out;
   in.sa_handler = action;
   /* handler is reinstalled - calls are restarted if restartSystemCall */
@@ -81,6 +87,7 @@
   
   return (sigaction(sig, &in, &out) ? (SignalHandlerFunc) -1 : 
 	  (SignalHandlerFunc) out.sa_handler);
+#endif
 }
 @
 \eject


diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/src/lib/cfuns-c.c.pamphlet axiom/src/lib/cfuns-c.c.pamphlet
--- axiom-save/src/lib/cfuns-c.c.pamphlet	Fri Oct 24 00:48:35 2003
+++ axiom/src/lib/cfuns-c.c.pamphlet	Thu Oct 23 22:05:52 2003
@@ -168,23 +168,29 @@
             if (geteuid() == buf.st_uid) {
                 return (2 * ((buf.st_mode & S_IWUSR) != 0));
             }
+#if defined(MSYSplatform)
+#else
             else if (getegid() == buf.st_gid) {
                 return (2 * ((buf.st_mode & S_IWGRP) != 0));
             }
             else {
                 return (2 * ((buf.st_mode & S_IWOTH) != 0));
             }
+#endif
         }
     }
     else if (geteuid() == buf.st_uid) {
         return ((buf.st_mode & S_IWUSR) != 0);
     }
+#if defined(MSYSplatform)
+#else
     else if (getegid() == buf.st_gid) {
         return ((buf.st_mode & S_IWGRP) != 0);
     }
     else {
         return ((buf.st_mode & S_IWOTH) != 0);
     }
+#endif
 }
 
 
@@ -206,12 +212,15 @@
     else if (geteuid() == buf.st_uid) {
         return ((buf.st_mode & S_IREAD) != 0);
     }
+#if defined(MSYSplatform)
+#else
     else if (getegid() == buf.st_gid) {
         return ((buf.st_mode & S_IRGRP) != 0);
     }
     else {
         return ((buf.st_mode & S_IROTH) != 0);
     }
+#endif
 }
 
 
diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/src/lib/fnct_key.c.pamphlet axiom/src/lib/fnct_key.c.pamphlet
--- axiom-save/src/lib/fnct_key.c.pamphlet	Fri Oct 24 00:48:35 2003
+++ axiom/src/lib/fnct_key.c.pamphlet	Thu Oct 23 20:42:02 2003
@@ -44,9 +44,14 @@
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
 @
+\section{Windows}
+These functions are not implemented in Windows.
+
 <<*>>=
 <<license>>
 
+#if defined(MSYSplatform)
+#else
 #include "useproto.h"
 
 #include <unistd.h>
@@ -83,7 +88,7 @@
 static char *defaulteditor = "clefedit";
 char editorfilename[100];
 
-
+#endif
 
 /*
  * The following function environment variable clef editor. The command
@@ -97,6 +102,8 @@
 set_editor_key(void )
 #endif
 {
+#if defined(MSYSplatform)
+#else
     int pid;
 
     sprintf(editorfilename, "/tmp/clef%d", pid = getpid());
@@ -105,6 +112,7 @@
         (function_key[12]).type = SPECIAL;
         (function_key[12]).str = defaulteditor;
     }
+#endif
 }
 
 
@@ -121,6 +129,8 @@
     If found it gets the key bindings from within
     *****/
 {
+#if defined(MSYSplatform)
+#else
     char *HOME, path[1024], string[1024];
     int key;
     int fd;
@@ -187,6 +197,7 @@
      * Now set the editor function key
      */
     set_editor_key();
+#endif
 }
 
 
@@ -201,7 +212,8 @@
 get_key(int fd,char * ty)
 #endif
 {
-
+#if defined(MSYSplatform)
+#else
     /*
      * Determines the key number being mapped, and whether it is immediate
or
      * delay. It reurns the key value, and modifies the parameter type
@@ -221,6 +233,7 @@
         }
     }
     else
+#endif
         return 0;
 }
 
@@ -233,6 +246,9 @@
 get_str(int fd,char * string)
 #endif
 {
+#if defined(MSYSplatform)
+    return 0;
+#else
     /** Gets the key mapping being bound **/
     char c;
     int count = 0;
@@ -249,6 +265,7 @@
     }
     *trace = '\0';
     return count;
+#endif
 }
 
 void 
@@ -270,6 +287,8 @@
 handle_function_key(int key,int  chann)
 #endif
 {
+#if defined(MSYSplatform)
+#else
     /** this procedure simply adds the string specified by the function key
       to the buffer                                               ****/
     int count, fd;
@@ -391,7 +410,7 @@
         break;
     }
     return;
-
+#endif
 }
 @
 \eject


diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/src/lib/pixmap.c.pamphlet axiom/src/lib/pixmap.c.pamphlet
--- axiom-save/src/lib/pixmap.c.pamphlet	Fri Oct 24 00:48:35 2003
+++ axiom/src/lib/pixmap.c.pamphlet	Thu Oct 23 21:07:00 2003
@@ -44,28 +44,30 @@
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */
 @
+/section{Windows}
+The function pixmap are not available under Windows/MSYS.
+@
 <<*>>=
 <<license>>
-
 #include "useproto.h"
-
+#if defined(MSYSplatform)
+#else
 #include <X11/Xlib.h>
 #include <X11/Xutil.h>
 #include <X11/Xos.h>
-#include <stdlib.h>
-#include <stdio.h>
 #include <netinet/in.h>
-
-#define yes 1
-#define no  0
-
-
-
 #include "spadcolors.h"
 
 #include "pixmap.H1"
 #include "halloc.H1"
 #include "spadcolors.H1"
+#endif
+#include <stdlib.h>
+#include <stdio.h>
+
+#define yes 1
+#define no  0
+
 
 
 
@@ -303,9 +305,9 @@
 
 #else /*OLD*/
 
-
+#if defined(MSYSplatform)
+#else
 #include "xpm.h"
-
 int
 #ifdef _NO_PROTO
 read_pixmap_file(display, screen, filename, xi, width, height)
@@ -369,11 +371,11 @@
   xi = XGetImage(dsp, wid, x, y, width, height, AllPlanes, ZPixmap);
   if (xi==0) return ;
   status=XpmWriteFileFromImage(dsp,fn,xi,0,0);
-  
 }
 
 
 #endif
+#endif  
 

Here is the mingw.defs patch that is referred to above. 
 
diff -Naur -xint -x*.dvi -xgcl-2.6.1 -xCVS -xbin -xobj -xnoweb -xgcldir
axiom-save/zips/gcl-2.6.1.h.mingw.defs.patch
axiom/zips/gcl-2.6.1.h.mingw.defs.patch
--- axiom-save/zips/gcl-2.6.1.h.mingw.defs.patch	Wed Dec 31 19:00:00
1969
+++ axiom/zips/gcl-2.6.1.h.mingw.defs.patch	Fri Oct 24 00:11:42 2003
@@ -0,0 +1,12 @@
+--- mingw.defs	Thu Oct 23 23:21:39 2003
++++ mingw.defs-new	Thu Oct 23 23:26:46 2003
+@@ -5,7 +5,8 @@
+ #
+ 
+ SHELL        = sh
+-
++EXTRAS = ${OBJ}/${SYS}/lib/cfuns-c.o
++# ${OBJ}/${SYS}/lib/sockio-c.o
+ OFLAG	     = -O 
+ LIBS	    += -lwsock32
+ LIBC 	     =

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

\start
Date: Fri, 24 Oct 2003 10:55:07 +0200
From: Michel Lavaud
To: Bill Page
Subject: Re: [Gcl-devel] RE: GCL 2.6.1 on Windows XP

Hello Bill,

> > http://people.debian.org/~camm/gcl/stable-binary/gcl_2.6.1.min
> > gw32_japi_xdr_20030929.zip
> > 
> > Unzip it and run the install program. It installed and
> > runs under Windows XP for me with no problems (although
> > an earlier version did fail on the install unless you
> > installed it into a directory named c:/lang).
> > 
> 
> I have just tried this and I see that the problem with the
> install directory still exists. When the install scripts
> asks where you want to install GCL, tell it
> 
>   c:/lang/gcl261
> 
> instead of the default, then the install will complete
> normally.

Yes you are right, the script that creates gcl.bat during the installation=
 
seems to be broken? The only difference I saw between an installation in 
c:\lang\gcl261 and another directory is that the c:\lang\gcl261\bin 
directory contains 2 more files gcl.bat and gcl.pif. If for some reason 
specific to Axiom you need to use gcl from another directory than 
lang/gcl261, it seems that you can just move the whole directory 
c:\lang\gcl261 to your new directory, and add the following file gcl.bat 
in directory "NewDirectory\bin" (with the example directory  
C:\programs\gcl-2.6.1):

------------------- gcl.bat
@echo off
rem Define the main directory of gcl
set W$=c:\programs\gcl-2.6.1
rem set C_INCLUDE_PATH=%W$%\lib\gcl-2.6.1\h
path %W$%\mingw\bin;%PATH%
start %W$%\lib\gcl-2.6.1\unixport\saved_gcl.exe -dir %W$%/lib/gcl-
2.6.1/unixport/ -libdir %W$%/lib/gcl-2.6.1/ -eval "(setq si::*allow-
gzipped-file* t)" %1 %2 %3 %4 %5 %6 %7 %8 %9
------------------- End of gcl.bat

This works for me on Windows 98SE, I suppose it would run too under any 
version of Windows NT (4.0, 2000 or XP)

It think one can comment the line with C_INCLUDE_PATH, at least as long as=
 
gcl.bat just runs the executable for gcl. I don't think the env variable 
for gcc compiler is of any use to run the executable? Or is it for some 
reason I am unaware of ?.  Anyway, on Win98, gcl can be run without this 
var being defined.

\start
Date: 24 Oct 2003 07:30:30 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: GCL-2.5.2 build

Hi Tim!  Yes, this gcc-3.3 specific warning/default optimization
setting was addressed in 2.5.4 and later.  As you note, the old code
does not in fact appear to break with gcc-3.3, however.

Take care,

Tim Daly writes:

> Camm,
> 
> The version I'm porting to the various HP systems is GCL-2.5.2
> (mostly because I'm doing many things in parallel and 2.6.1
> is on a different thread of work). 
> 
> I get warnings (not errors) of the form:
> 
> cmpcall.c: In function `LnkTL124':
> cmpcall.c:1949: warning: dereferencing type-punned pointer will break strict-aliasing rules
> 
> The message is output hundreds of times during the build for many files.
> It does not seem to affect the result but I'm passing it along anyway.

\start
Date: Fri, 24 Oct 2003 07:28:38 -0400
From: Tim Daly
To: list
Subject: regression testing, macro table

*,

I previously broke the util.ht file. Somehow I clipped out the
stanza that walks into that subdirectory. That's been fixed.

I put up an early-release version of regression testing.
Basically it works as follows:

* the final build completes
* the input files are generated
* a Makefile is generated in int/input
* the Makefile is invoked which
   - runs the input files
   - saves the output

If you look at the Makefile (the source is in src/input/Makefile.pamphlet
under the <<regression tests>> chunk you can see that I've classified the
working/failing input files by type of failure. That way we have a larger
set of test cases for chasing a particular failure type.

"Failing" means that it causes a lisp break. "Working" means it doesn't.

Note that some of the "working" input files are still buggy for 2 reasons.
First, the names of the types or operators have changed so the input file
function fail to execute. Second, the input fails because it is supposed
to fail. That is, the input file is demonstrating a bug or intentionally
incorrect code. Failures can be found in the output by searching for
"Daly bug" messages The name is a holdover from scratchpad and was in
the NAG version. It is enabled by )set message test on. It exists so
I can automate detecting failures.

The regression testing is cheesy and limp but it is a start.
The Computer Algebra Test Suite (CATS) effort will eventually 
replace it.

\start
Date: Fri, 24 Oct 2003 07:43:30 -0400
From: Bill Page
To: Tim Daly
Subject: completion of algebra lattice

Tim,

I just posted an update to the Axiom CVS that completes
the algegra lattice. I added two new layers layer22 and
layer23 for the last remaining uncompiled modules. There
were also a few typos in module names etc. that I cleared
up. Finally I also updated the daase files now that our
lattice is complete.

So at long last the version of Axiom in the CVS has the
complete algebra. I tested it with some of the axiom
commands in the tutorial that previously failed. Everything
looks ok to me.

Let me know if there are any problems.

\start
Date: Fri, 24 Oct 2003 08:03:16 -0400
From: Tim Daly
To: Bill Page
Subject: Re: completion of algebra lattice

Excellent. I've downloaded it and I'll try it here.

I just added regression testing and now we can see if the input
files work with the new algebra. If you look in src/input/Makefile.pamphlet
for the <<regression tests>> chunk you can see the input files that break
with the new algebra. Adding the ${COMBF} variable to the all stanza
should test all of those input files that break because COMBF was missing.

\start
Date: Fri, 24 Oct 2003 08:32:10 -0400
From: Tim Daly
To: list, David Mentre
Subject: ports

David,

Axiom has been shown to build on:

SuSE Linux Ent Svr 8.0 on Intel   
ProLiant DL360 G2 2@1.4GHz

I'll make the tgz of the executable available soon.

\start
Date: Fri, 24 Oct 2003 13:00:30 -0400
From: Bill Page
To: Tim Daly
Subject: RE: completion of algebra lattice

Tim,

The new complete algebra lattice seems to run all of
the "regression tests" (including COMBF and the others)
without lisp failures. The only test that might have a
problem is

  lextripk (12)

which seems like it goes into an infinite loop (it is
still running after 15 minutes) when it calls
grobner$lextripack.

> Excellent. I've downloaded it and I'll try it here.
> 
> I just added regression testing and now we can see if the
> input files work with the new algebra. If you look in 
> src/input/Makefile.pamphlet for the <<regression tests>>
> chunk you can see the input files that break with the new
> algebra. Adding the ${COMBF} variable to the all stanza
> should test all of those input files that break because
> COMBF was missing.

\start
Date: Fri, 24 Oct 2003 19:14:32 +0200
From: David Mentre
To: Tim Daly
Subject: Re: GCL 2.6.1 on Windows XP
Cc: Camm Maguire, Bill Page

Hello Tim,

I had properly updated my CVS tree before doing the make.

Tim Daly writes:

> I believe that both you and David had a problem. 
> I probably uploaded a bad Makefile.pamphlet.

I think I have understood: there are both interp/Makefile and
interp/Makefile.pamphlet in the CVS, with the *same* date[1].

In the Makefile, INTERP.EXPOSED is present[2]. 
In the Makefile.pamphlet, INTERP.EXPOSED is gone.

As the date are the same, Makefile is not rebuild from
Makefile.pamphlet. Thus the wrong reference to INTERP.EXPOSED.

 => Erasing src/interp/Makefile solve the issue.


Conclusion: we should erase from CVS the following files:

lsp/ccl/src/axbase/Makefile
lsp/ccl/src/Makefile
lsp/ccl/src/boot/Makefile
lsp/ccl/src/caxbase/Makefile
lsp/ccl/src/cclbase/Makefile
lsp/ccl/src/cslbase/Makefile
lsp/ccl/src/scripts/Makefile
lsp/ccl/src/util/Makefile
lsp/ccl/Makefile
lsp/Makefile
src/algebra/Makefile
src/Makefile
src/boot/Makefile
src/doc/Makefile
src/etc/Makefile
src/include/Makefile
src/input/Makefile
src/interp/Makefile
src/lib/Makefile
src/scripts/Makefile
src/share/Makefile

(notice that I propose to keep the root Makefile*. We have already
discussed that before)

Yours,
d.

[1] At least in my clean CVS tree. I don't know if this behavior is due
    to CVS or due to my own use of CVS.

[2] See http://savannah.nongnu.org/cgi-bin/viewcvs/axiom/axiom/src/interp/Makefile?rev=1.3&content-type=text/vnd.viewcvs-markup

\start
Date: Fri, 24 Oct 2003 19:18:45 +0200
From: David Mentre
To: Tim Daly
Subject: Re: ports

Tim Daly writes:

> Could you update the "ports" webpage?

Done.

\start
Date: Fri, 24 Oct 2003 19:29:08 +0200
From: David Mentre
To: Bill Page
Subject: re: completion of algebra lattice

Hello Bill,

Bill Page writes:

> The new complete algebra lattice seems to run all of
> the "regression tests" (including COMBF and the others)
> without lisp failures. 

If you have time, you can close the corresponding bugs on savannah.

Otherwise, you can give me a list of bug that might be closed and I'll
double-check.

Yours,
d.

PS : Many thanks for updating the algebra. The path is now open to our
     first stable release.

\start
Date: Fri, 24 Oct 2003 13:09:20 -0400
From: Tim Daly
To: Bill Page
Subject: algebra completion

Bill, 

I did a checkout and build. My build blows up during the algebra compiles
at NODE1.spad. Does this compile for you?

\start
Date: Fri, 24 Oct 2003 13:09:59 -0400
From: Tim Daly
To: David Mentre
Subject: algebra completion

David,

I agree about removing the non-root Makefiles.
I'll do that tonight.

\start
Date: Fri, 24 Oct 2003 14:18:40 -0400
From: Bill Page
To: Tim Daly
Subject: RE: algebra completion

Tim,

That's odd. NODE1.o is in layer21. I did not
change anything in layers21 and below.

Yes, it compiled for me with no problem. I have
a file called NODE1.o in mnt/linux/algebra.

Usual questions: Did you start from zero?
What linux flavor?
What kind of "blows up"?

Bill.

> Bill, 
> 
> I did a checkout and build. My build blows up during
> the algebra compiles at NODE1.spad. Does this compile
> for you?

\start
Date: Fri, 24 Oct 2003 14:21:32 -0400
From: Bill Page
To: Tim Daly
Subject: RE: algebra completion

Tim,

On Friday, October 24, 2003 1:09 PM you wrote:
> 
> I did a checkout and build. My build blows up during
> the algebra compiles at NODE1.spad. Does this compile
> for you?

Maybe it's a daase problem? Can you try reverting to the
database files from the previous version?

\start
Date: Fri, 24 Oct 2003 21:44:44 +0200
From: David Mentre
To: list
Subject: Another failing build on EFUPXS: GCL 2.6.1 issue??

Hello,

Sorry to bother you once again. It appears that my build fails once
again on EFUPXS.spad (for latest Axiom CVS):

0 making /home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.spad from /home/david/pub/axiom-libre/axiom-powerpc/axiom/src/algebra/efupxs.spad.pamphlet
0 making /home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.NRLIB from /home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.spad

(AXIOM Sockets) The AXIOM server number is undefined.
[...]
   Loading 
      /home/david/pub/axiom-libre/axiom-powerpc/axiom/mnt/linux/algebra/ISTRING.o
      for domain IndexedString 
reloc for vs_overflow is overflowing
 
   >> System error:
   Cannot get relocated section contents


protected-symbol-warn called with (NIL)
(1) -> 0 making /home/david/pub/axiom-libre/axiom-powerpc/axiom/mnt/linux/algebra/EFUPXS.o from /home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.NRLIB
cp: cannot stat `/home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.NRLIB/code.o': No such file or directory
make[3]: *** [/home/david/pub/axiom-libre/axiom-powerpc/axiom/mnt/linux/algebra/EFUPXS.o] Error 1
make[3]: Leaving directory `/home/david/pub/axiom-libre/axiom-powerpc/axiom/src/algebra'
make[2]: *** [algebradir] Error 2


Any idea on what can going wrong? Is the message "reloc for vs_overflow
is overflowing" informs of an issue with gcl? I found such an error
message in lsp/gcl-2.6.1/o/sfaslbdf.c.

I'm building on Debian stable on PowerPC architecture.

\start
Date: 24 Oct 2003 18:20:41 -0400
From: Camm Maguire
To: David Mentre
Subject: Re: [Gcl-devel] Another failing build on EFUPXS: GCL 2.6.1 issue??

Greetings!

ppc relocs are 24bit by default, unless you compile with the
-mlong-calls (or some such), first supported on ppc in gcc-3.3.  The
configure script (at least on recent gcl, how recent I'm not sure),
should detect gcc-3.3 if present and add this option automatically.
Without it, loads on big images will lose.  Ran into this with the
acl2 book verifications, which are now known to work with -mlong-call.

Take care,

David Mentre writes:

> Hello,
> 
> Sorry to bother you once again. It appears that my build fails once
> again on EFUPXS.spad (for latest Axiom CVS):
> 
> 0 making /home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.spad from /home/david/pub/axiom-libre/axiom-powerpc/axiom/src/algebra/efupxs.spad.pamphlet
> 0 making /home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.NRLIB from /home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.spad
> 
> (AXIOM Sockets) The AXIOM server number is undefined.
> [...]
>    Loading 
>       /home/david/pub/axiom-libre/axiom-powerpc/axiom/mnt/linux/algebra/ISTRING.o
>       for domain IndexedString 
> reloc for vs_overflow is overflowing
>  
>    >> System error:
>    Cannot get relocated section contents
> 
> 
> protected-symbol-warn called with (NIL)
> (1) -> 0 making /home/david/pub/axiom-libre/axiom-powerpc/axiom/mnt/linux/algebra/EFUPXS.o from /home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.NRLIB
> cp: cannot stat `/home/david/pub/axiom-libre/axiom-powerpc/axiom/int/algebra/EFUPXS.NRLIB/code.o': No such file or directory
> make[3]: *** [/home/david/pub/axiom-libre/axiom-powerpc/axiom/mnt/linux/algebra/EFUPXS.o] Error 1
> make[3]: Leaving directory `/home/david/pub/axiom-libre/axiom-powerpc/axiom/src/algebra'
> make[2]: *** [algebradir] Error 2
> 
> 
> Any idea on what can going wrong? Is the message "reloc for vs_overflow
> is overflowing" informs of an issue with gcl? I found such an error
> message in lsp/gcl-2.6.1/o/sfaslbdf.c.
> 
> I'm building on Debian stable on PowerPC architecture.

\start
Date: Sat, 25 Oct 2003 09:04:47 +0200
From: David Mentre
To: Camm Maguire
Subject: Re: [Gcl-devel] Another failing build on EFUPXS: GCL 2.6.1 issue??

Camm Maguire writes:

> ppc relocs are 24bit by default, unless you compile with the
> -mlong-calls (or some such), first supported on ppc in gcc-3.3.
[...]
> Without it, loads on big images will lose.  Ran into this with the

Ouch! So if I read you correclty, you mean I can't compile Axiom on my
Debian stable/gcc 2.95.4 powerpc machine? 

A possible workaround: could I compile Axiom, statically linked, on a
powerpc machine with gcc-3.3 and then execute it on my powerpc debian
stable?

Another possible workaround: would it work with gcl-2.5.2 on my debian
stable (gcc 2.95.4)?


While I'm asking questions on gcl, do I need to recompile everything
from scratch if I switch gcl version used to compile Axiom (from
gcl-2.5.2 -> gcl-2.6.1)?

\start
Date: Sat, 25 Oct 2003 09:29:58 +0200
From: David Mentre
To: list
Subject: Which option to maximize architecture portability on gcl-2.6.1

Hello Camm,

I have yet another question on gcl-2.6.1. I noticed that my current
gcl-2.6.1 on my Celeron machine is using the -march=pentiumpro gcc
flag. 

In the eventuality where I would like to compile a static version of
Axiom portable on any usable x86 machine (pentium or greater), which
option should I give to gcl configure to have something like -march=i586
given to gcc?

In other words, even if I compile Axiom with gcl-2.6.1 on latest Athlon
or Pentium 4 machine, I would like to have a binary runnable on any x86
machine (except maybe i486 and i386).

\start
Date: Sat, 25 Oct 2003 10:57:39 -0400
From: Tim Daly
To: David Mentre
Subject: re: completion of algebra lattice
Cc: Bill Page

Bill,

I re-downloaded the CVS copy and did a build from scratch overnight.
It appears that the system won't build from CVS at the moment.
Try building from a clean CVS download and see if it works for you.
If not I think we need to back out the changes until we figure it out.

I was not able to complete the lattice because I ran into database problems.
The new databases don't seem to be able to rebuild the system. 
It looks like you tripped across the same bug. 

I first found the database problem when I tried to use a newly built system
complete the algebra. It turned out that the newly built system couldn't
compile the older code. I suspect there has been a change to the database
code and I'm looking into the problem.

\start
Date: 25 Oct 2003 11:22:05 -0400
From: Camm Maguire
To: David Mentre
Subject: Re: [Gcl-devel] Which option to maximize architecture portability on gcl-2.6.1

Greetings!  If memory serves, gcc doesn't (yet) emit ISA extension
instructions with any flag setting.  If this is the case, what you
have is fine.  To be safe, you can redefine the compiler::*cc*
variable as desired (e.g. just omit any march setting).

The stock Debian gcl does not have an march gcc flag setting.  If you
build gcl yourself, and have a CFLAGS environment variable set, and
march setting could be thus captured.

Take care,

David Mentre writes:

> Hello Camm,
> 
> I have yet another question on gcl-2.6.1. I noticed that my current
> gcl-2.6.1 on my Celeron machine is using the -march=pentiumpro gcc
> flag. 
> 
> In the eventuality where I would like to compile a static version of
> Axiom portable on any usable x86 machine (pentium or greater), which
> option should I give to gcl configure to have something like -march=i586
> given to gcc?
> 
> In other words, even if I compile Axiom with gcl-2.6.1 on latest Athlon
> or Pentium 4 machine, I would like to have a binary runnable on any x86
> machine (except maybe i486 and i386).

\start
Date: 25 Oct 2003 11:28:02 -0400
From: Camm Maguire
To: David Mentre
Subject: re: [Gcl-devel] Another failing build on EFUPXS: GCL 2.6.1 issue??

Greetings!

David Mentre writes:

> Camm Maguire writes:
> 
> > ppc relocs are 24bit by default, unless you compile with the
> > -mlong-calls (or some such), first supported on ppc in gcc-3.3.
> [...]
> > Without it, loads on big images will lose.  Ran into this with the
> 
> Ouch! So if I read you correclty, you mean I can't compile Axiom on my
> Debian stable/gcc 2.95.4 powerpc machine? 
> 

Most likely not.  On ppc, you'll be much happier with gcc-3.3.  You
can apt-get -q -b source it, 'apt pin' it (probably the easiest), or
set up an unstable debian chroot anvironment.

> A possible workaround: could I compile Axiom, statically linked, on a
> powerpc machine with gcc-3.3 and then execute it on my powerpc debian
> stable?
> 

This will work as long as you don't compile any further modules on
stable.  Make sure the compiler::*cc* variable has not hardcoded
gcc-3.3. 

> Another possible workaround: would it work with gcl-2.5.2 on my debian
> stable (gcc 2.95.4)?
> 

This is not a gcl issue, but a gcc one.  I.e. the problem exists with
all gcl on top of gcc < 3.3.

> 
> While I'm asking questions on gcl, do I need to recompile everything
> from scratch if I switch gcl version used to compile Axiom (from
> gcl-2.5.2 -> gcl-2.6.1)?
> 

Should not be necessary to recompile the axiom modules, but you will
need to ensure that all the intermediary images are build atop the new
gcl. 

BTW, you know that there is a pre-built Debian axiom package for ppc
(unstable)?  

\start
Date: 25 Oct 2003 11:31:47 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] RE: GCL 2.6.1 on Windows XP
Cc: Bill Page, Michel Lavaud

Greetings!  Mike, do you have a moment to upload a binary without the
path hard-coding? 

Take care,

Michel Lavaud writes:

> Hello Bill,
> 
> > > http://people.debian.org/~camm/gcl/stable-binary/gcl_2.6.1.min
> > > gw32_japi_xdr_20030929.zip
> > > 
> > > Unzip it and run the install program. It installed and
> > > runs under Windows XP for me with no problems (although
> > > an earlier version did fail on the install unless you
> > > installed it into a directory named c:/lang).
> > > 
> > 
> > I have just tried this and I see that the problem with the
> > install directory still exists. When the install scripts
> > asks where you want to install GCL, tell it
> > 
> >   c:/lang/gcl261
> > 
> > instead of the default, then the install will complete
> > normally.
> 
> Yes you are right, the script that creates gcl.bat during the installatio=
n 
> seems to be broken? The only difference I saw between an installation in=
 
> c:\lang\gcl261 and another directory is that the c:\lang\gcl261\bin 
> directory contains 2 more files gcl.bat and gcl.pif. If for some reason 
> specific to Axiom you need to use gcl from another directory than 
> lang/gcl261, it seems that you can just move the whole directory 
> c:\lang\gcl261 to your new directory, and add the following file gcl.bat=
 
> in directory "NewDirectory\bin" (with the example directory  
> C:\programs\gcl-2.6.1):
> 
> ------------------- gcl.bat
> @echo off
> rem Define the main directory of gcl
> set W$=c:\programs\gcl-2.6.1
> rem set C_INCLUDE_PATH=%W$%\lib\gcl-2.6.1\h
> path %W$%\mingw\bin;%PATH%
> start %W$%\lib\gcl-2.6.1\unixport\saved_gcl.exe -dir %W$%/lib/gcl-
> 2.6.1/unixport/ -libdir %W$%/lib/gcl-2.6.1/ -eval "(setq si::*allow-
> gzipped-file* t)" %1 %2 %3 %4 %5 %6 %7 %8 %9
> ------------------- End of gcl.bat
> 
> This works for me on Windows 98SE, I suppose it would run too under any 
> version of Windows NT (4.0, 2000 or XP)
> 
> It think one can comment the line with C_INCLUDE_PATH, at least as long a=
s 
> gcl.bat just runs the executable for gcl. I don't think the env variable=
 
> for gcc compiler is of any use to run the executable? Or is it for some 
> reason I am unaware of ?.  Anyway, on Win98, gcl can be run without this=
 
> var being defined.

\start
Date: 25 Oct 2003 12:37:45 -0400
From: Camm Maguire
To: David Mentre
Subject: re: GCL 2.6.1 on Windows XP
Cc: Bill Page

Greetings!  BTW, there are several other files I had to add manually
to the clean target of debian/rules in the Debian package to make sure
that a clean,build,clean cycle returns to the same point:

	rm -f lsp/Makefile.dvi src/algebra/Makefile.dvi src/input/Makefile.dvi obj/noweb/contrib/kostas/Makefile obj/noweb/src/c/notangle.o obj/noweb/src/c/getline.o obj/noweb/src/c/match.o obj/noweb/src/c/modules.o obj/noweb/src/c/modtrees.o obj/noweb/src/c/strsave.o obj/noweb/src/c/main.o obj/noweb/src/c/errors.o obj/noweb/src/c/columns.o obj/noweb/src/c/nt obj/noweb/src/c/markmain.o obj/noweb/src/c/markup.o obj/noweb/src/c/markup obj/noweb/src/c/mnt.o obj/noweb/src/c/mnt obj/noweb/src/c/finduses.o obj/noweb/src/c/recognize.o obj/noweb/src/c/finduses mnt/bin/lib/nt mnt/bin/lib/markup mnt/bin/lib/mnt mnt/bin/lib/finduses mnt/bin/Makefile.dvi  Makefile.dvi src/Makefile.dvi src/interp/Makefile.dvi src/doc/Makefile.dvi

There are also several scripts intalled by default under mnt/linux,
(several of which I'm guessing are an oversight at present), but
which, if shipped, need to be executable (for Debian policy at least:)

	cd debian/axiom && chmod -x ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/lib/nwmtime ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/tex/axiom.sty ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/axiom.sty ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/tail ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/htmltoc ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/Makefile ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/boxup ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/Makefile.pamphlet ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/head ./usr/lib/axiom-0.0.0cvs/mnt/linux/bin/showdvi ./usr/lib/axiom-0.0.0cvs/mnt/linux/algebra/topics.data ./usr/lib/axiom-0.0.0cvs/mnt/linux/doc/msgs/s2-us.msgs ./usr/lib/axiom-0.0.0cvs/mnt/linux/algebra/gloss.text


There also are (or were) CVS directories installed which had to be
removed by hand.

Very minor issues, so don't anyone spend too many brain cycles here!

David Mentre writes:

> Hello Tim,
> 
> I had properly updated my CVS tree before doing the make.
> 
> Tim Daly writes:
> 
> > I believe that both you and David had a problem. 
> > I probably uploaded a bad Makefile.pamphlet.
> 
> I think I have understood: there are both interp/Makefile and
> interp/Makefile.pamphlet in the CVS, with the *same* date[1].
> 
> In the Makefile, INTERP.EXPOSED is present[2]. 
> In the Makefile.pamphlet, INTERP.EXPOSED is gone.
> 
> As the date are the same, Makefile is not rebuild from
> Makefile.pamphlet. Thus the wrong reference to INTERP.EXPOSED.
> 
>  => Erasing src/interp/Makefile solve the issue.
> 
> 
> Conclusion: we should erase from CVS the following files:
> 
> lsp/ccl/src/axbase/Makefile
> lsp/ccl/src/Makefile
> lsp/ccl/src/boot/Makefile
> lsp/ccl/src/caxbase/Makefile
> lsp/ccl/src/cclbase/Makefile
> lsp/ccl/src/cslbase/Makefile
> lsp/ccl/src/scripts/Makefile
> lsp/ccl/src/util/Makefile
> lsp/ccl/Makefile
> lsp/Makefile
> src/algebra/Makefile
> src/Makefile
> src/boot/Makefile
> src/doc/Makefile
> src/etc/Makefile
> src/include/Makefile
> src/input/Makefile
> src/interp/Makefile
> src/lib/Makefile
> src/scripts/Makefile
> src/share/Makefile
> 
> (notice that I propose to keep the root Makefile*. We have already
> discussed that before)
> 
> Yours,
> d.
> 
> [1] At least in my clean CVS tree. I don't know if this behavior is due
>     to CVS or due to my own use of CVS.
> 
> [2] See http://savannah.nongnu.org/cgi-bin/viewcvs/axiom/axiom/src/interp/Makefile?rev=1.3&content-type=text/vnd.viewcvs-markup

\start
Date: Sat, 25 Oct 2003 12:42:04 -0400
From: Bill Page
To: Tim Daly
Subject: RE: completion of algebra lattice

Tim,

On Saturday, October 25, 2003 10:58 AM you wrote:
> 
> I re-downloaded the CVS copy and did a build from scratch 
> overnight. It appears that the system won't build from CVS at 
> the moment. Try building from a clean CVS download and see if 
> it works for you. If not I think we need to back out the 
> changes until we figure it out.

Ok, I am in the process of trying it again now on a different
machine. I built the whole algebra just fine on my RedHat 8.0
system with gcc 3.2-7, but using Juergen's databases files of
course.

> 
> I was not able to complete the lattice because I ran into 
> database problems. The new databases don't seem to be able to 
> rebuild the system. It looks like you tripped across the same
> bug. 

I did notice that the new database files that I built were
slightly different in size than Juergen's (some a little
bigger and some a little smaller). I wonder how Juergen built
those database files. Right now it seems that they are the
only ones that work ...

> 
> I first found the database problem when I tried to use a 
> newly built system complete the algebra. It turned out
> that the newly built system couldn't compile the older code.
> I suspect there has been a change to the database code and
> I'm looking into the problem.

But Juergen somehow managed to do it, right? Because the
ones that we started with (before I added Juergen's database
files to the CVS in September) also did not work. But I
think he claimed to have built the ones that do work using
that system. Or was there some other magic involved?

So I guess I am going to have to learn something about the
database files. As you look into this problem, if you feel
like discussing it, I'm all ears.

Anyway, I will let you know if I can build the new system
on my RedHat 9.0 system. (It's faster, it only takes about
3 hours to complete.) And if it fails like yours then I
will back out the CVS back to Juergen's database files.

\start
Date: Sat, 25 Oct 2003 19:09:39 +0200
From: Juergen Weiss
To: Bill Page
Subject: re: completion of algebra lattice

I think I build the database on cmu cl. Difference in
size is probably due to not including hypertex references
into the database files. That should not make any
difference to the current problems. Besides that, no
``magic'' was involved.

> Tim,
> 
> On Saturday, October 25, 2003 10:58 AM you wrote:
> > 
> > I re-downloaded the CVS copy and did a build from scratch 
> > overnight. It appears that the system won't build from CVS at 
> > the moment. Try building from a clean CVS download and see if 
> > it works for you. If not I think we need to back out the 
> > changes until we figure it out.
> 
> Ok, I am in the process of trying it again now on a different
> machine. I built the whole algebra just fine on my RedHat 8.0
> system with gcc 3.2-7, but using Juergen's databases files of
> course.
> 
> > 
> > I was not able to complete the lattice because I ran into 
> > database problems. The new databases don't seem to be able to 
> > rebuild the system. It looks like you tripped across the same
> > bug. 
> 
> I did notice that the new database files that I built were
> slightly different in size than Juergen's (some a little
> bigger and some a little smaller). I wonder how Juergen built
> those database files. Right now it seems that they are the
> only ones that work ...
> 
> > 
> > I first found the database problem when I tried to use a 
> > newly built system complete the algebra. It turned out
> > that the newly built system couldn't compile the older code.
> > I suspect there has been a change to the database code and
> > I'm looking into the problem.
> 
> But Juergen somehow managed to do it, right? Because the
> ones that we started with (before I added Juergen's database
> files to the CVS in September) also did not work. But I
> think he claimed to have built the ones that do work using
> that system. Or was there some other magic involved?
> 
> So I guess I am going to have to learn something about the
> database files. As you look into this problem, if you feel
> like discussing it, I'm all ears.
> 
> Anyway, I will let you know if I can build the new system
> on my RedHat 9.0 system. (It's faster, it only takes about
> 3 hours to complete.) And if it fails like yours then I
> will back out the CVS back to Juergen's database files.

\start
Date: Sat, 25 Oct 2003 14:25:17 -0400
From: Tim Daly
To: Camm Maguire
Subject: re: GCL 2.6.1 on Windows XP
Cc: Bill Page

Your list:

These are gone:

lsp/Makefile.dvi 
src/algebra/Makefile.dvi 
src/input/Makefile.dvi 
src/Makefile.dvi 
src/interp/Makefile.dvi 
src/doc/Makefile.dvi

These should never be in the "distribution" which should only contain 
files in the mnt directory. The obj and int directories can be deleted
at any time. They are only caches.

obj/noweb/contrib/kostas/Makefile 
obj/noweb/src/c/notangle.o 
obj/noweb/src/c/getline.o 
obj/noweb/src/c/match.o 
obj/noweb/src/c/modules.o 
obj/noweb/src/c/modtrees.o 
obj/noweb/src/c/strsave.o 
obj/noweb/src/c/main.o 
obj/noweb/src/c/errors.o 
obj/noweb/src/c/columns.o 
obj/noweb/src/c/nt 
obj/noweb/src/c/markmain.o 
obj/noweb/src/c/markup.o 
obj/noweb/src/c/markup 
obj/noweb/src/c/mnt.o 
obj/noweb/src/c/mnt 
obj/noweb/src/c/finduses.o 
obj/noweb/src/c/recognize.o 
obj/noweb/src/c/finduses 

These are used by noweb. In particular, the document command will
invoke nt and markup. 

mnt/bin/lib/nt 
mnt/bin/lib/markup 
mnt/bin/lib/mnt 
mnt/bin/lib/finduses 

I'll look into these. There shouldn't be Makefiles in mnt.

mnt/bin/Makefile.dvi 

This should remain. It is the primary documentation root and
needs to be available to users before the build. It is essentially
the top level "README" 

Makefile.dvi 

I'm confused. You siad: "need to be executable" but you wrote: "chmod -x"
which will remove the execution bit.

This part of noweb and is an internal command
./mnt/linux/bin/lib/nwmtime 

These are TeX macros not user commands and can't be executed.

./mnt/linux/bin/tex/axiom.sty 
./mnt/linux/bin/axiom.sty 

These are the components of the boxup command which works as follows:

boxup foo

rename foo to foo.org
concatenate head, foo, and tail (in that order) into foo.pamphlet,
run notangle to extract foo from foo.pamphlet,
diff foo and foo.org to ensure that 

./mnt/linux/bin/boxup 
./mnt/linux/bin/head
./mnt/linux/bin/tail 

These will go away:

./mnt/linux/bin/Makefile 
./mnt/linux/bin/Makefile.pamphlet 

These are Axiom internal data files, not scripts

./mnt/linux/algebra/topics.data 
./mnt/linux/doc/msgs/s2-us.msgs 
./mnt/linux/algebra/gloss.text


I have no idea what this does:
./mnt/linux/bin/htmltoc 

This was a feeble attempt at document support. Texmacs and ADVI
extensions will eventually do better.

./mnt/linux/bin/showdvi 

\start
Date: Sat, 25 Oct 2003 15:01:41 -0400
From: Bill Page
To: Juergen Weiss
Subject: RE: completion of algebra lattice

Juergen,

Just so that I am clear, could you please confirm again that you
did *not* create the database files using the GCL version of
Axiom?

For Axiom do you currently use GCL or do you use CMU CL?

Tim, is CMU CL an intended target lisp for Axiom? If so, then
perhaps we should also be actively using both lisps with Axiom -
especially if there are some things that CMU CL can do that
GCL can't.

I think I build the database on cmu cl. Difference in
size is probably due to not including hypertex references
into the database files. That should not make any
difference to the current problems. Besides that, no
``magic'' was involved.

\start
Date: Sat, 25 Oct 2003 15:49:56 -0400
From: Tim Daly
To: Bill Page
Subject: Re: completion of algebra lattice

Bill,

CMUCL is an intended target lisp for Axiom. Indeed, the previous
CVS at tenkan had the CMU files available.

If CMUCL can build correct databases and GCL can't then it indicates
that the problem is in the underlying common lisp. We can test if
this is true by generating a database from the same set of NRLIBs
using CMUCL and GCL and then comparing individual entries.

If the problem is not in the common lisp but is due to axiom code
then the databases should be broken in similar ways.

\start
Date: Sun, 26 Oct 2003 10:19:43 +1000
From: Mike Thomas
To: Camm Maguire
Subject: RE: GCL 2.6.1 on Windows XP
Cc: Bill Page, Michel Lavaud

Hi all.

| Greetings!  Mike, do you have a moment to upload a binary without the
| path hard-coding?

If I can't get it done tonight (Sunday, unlikely) then not until Friday a=
t
the very earliest I'm sorry as I'll be out of town and without a computer
for the coming week and away from computers most of today.

|
| Take care,
|
| Michel Lavaud writes:
|
| > Hello Bill,
| >
| > > > http://people.debian.org/~camm/gcl/stable-binary/gcl_2.6.1.min
| > > > gw32_japi_xdr_20030929.zip
| > > >
| > > > Unzip it and run the install program. It installed and
| > > > runs under Windows XP for me with no problems (although
| > > > an earlier version did fail on the install unless you
| > > > installed it into a directory named c:/lang).
| > > >
| > >
| > > I have just tried this and I see that the problem with the
| > > install directory still exists. When the install scripts
| > > asks where you want to install GCL, tell it
| > >
| > >   c:/lang/gcl261
| > >
| > > instead of the default, then the install will complete
| > > normally.
| >
| > Yes you are right, the script that creates gcl.bat during the
| installation
| > seems to be broken? The only difference I saw between an
| installation in
| > c:\lang\gcl261 and another directory is that the c:\lang\gcl261\bin
| > directory contains 2 more files gcl.bat and gcl.pif. If for some reas=
on
| > specific to Axiom you need to use gcl from another directory than
| > lang/gcl261, it seems that you can just move the whole directory
| > c:\lang\gcl261 to your new directory, and add the following
| file gcl.bat
| > in directory "NewDirectory\bin" (with the example directory
| > C:\programs\gcl-2.6.1):
| >
| > ------------------- gcl.bat
| > @echo off
| > rem Define the main directory of gcl
| > set W$=c:\programs\gcl-2.6.1
| > rem set C_INCLUDE_PATH=%W$%\lib\gcl-2.6.1\h
| > path %W$%\mingw\bin;%PATH%
| > start %W$%\lib\gcl-2.6.1\unixport\saved_gcl.exe -dir %W$%/lib/gcl-
| > 2.6.1/unixport/ -libdir %W$%/lib/gcl-2.6.1/ -eval "(setq si::*allow-
| > gzipped-file* t)" %1 %2 %3 %4 %5 %6 %7 %8 %9
| > ------------------- End of gcl.bat
| >
| > This works for me on Windows 98SE, I suppose it would run too under a=
ny
| > version of Windows NT (4.0, 2000 or XP)
| >
| > It think one can comment the line with C_INCLUDE_PATH, at least
| as long as
| > gcl.bat just runs the executable for gcl. I don't think the env
| variable
| > for gcc compiler is of any use to run the executable? Or is it for so=
me
| > reason I am unaware of ?.  Anyway, on Win98, gcl can be run
| without this
| > var being defined.
| >
| > Best wishes,

\start
Date: Sun, 26 Oct 2003 02:48:40 +0200
From: Juergen Weiss
To: Bill Page
Subject: RE: completion of algebra lattice

The database files that I posted on my website are
build with a CMU CL version. I got GCL working
on FreeBSD only lately. I compiled all the algebra
files on GCL Axiom with the CMU database and rebuild
a database on GCL. But I probably never tried to
use that database to compile all algebra files.
So I'm not sure if that would have been possible.

> Juergen,
> 
> Just so that I am clear, could you please confirm again that you
> did *not* create the database files using the GCL version of
> Axiom?
> 
> For Axiom do you currently use GCL or do you use CMU CL?
> 
> Tim, is CMU CL an intended target lisp for Axiom? If so, then
> perhaps we should also be actively using both lisps with Axiom -
> especially if there are some things that CMU CL can do that
> GCL can't.
> 
> 
> I think I build the database on cmu cl. Difference in
> size is probably due to not including hypertex references
> into the database files. That should not make any
> difference to the current problems. Besides that, no
> ``magic'' was involved.

\start
Date: Sat, 25 Oct 2003 21:24:22 -0400
From: Bill Page
To: Tim Daly
Subject: rebuilding the database

Tim,

I have a question about the proper procedure for
rebuilding the AXIOM database.

In the current src/algebra/Makefile.pamphlet there are
two stanza's with targe db: One is in some "old code"
chuck named <<original Makefile>> which I guess is no
longer used.

db: ${CENTER}
        @ echo rebuilding databases...
        @ cp -p ${SRC}/doc/gloss.text ${LIB}
        @ cp -p ${SRC}/doc/topics.data ${MID}
        @ echo rebuilding daase files
        @ (cd ${MID} ; \
           echo ')set out le 200' >/tmp/tmp.input ; \
           echo ')fin' >>/tmp/tmp.input ; \
           echo '(make-databases "" (QUOTE ("unix")))' >>/tmp/tmp.input
; \
           echo '(bye)' >>/tmp/tmp.input ; \
           cat /tmp/tmp.input | ${INTERPSYS} ; \
           rm -f /tmp/tmp.input )
        @ echo If all went well, go-ahead Mike and do a db-install as
well !

The other is the apparently new code which does get
executed

db:
        @ echo rebuilding databases...
        @ cp ${SRC}/doc/gloss.text ${MID}
        @ cp ${SRC}/doc/gloss.text ${OUT}
        @ cp ${SRC}/doc/topics.data ${MID}
        @ cp ${SRC}/doc/topics.data ${OUT}
        @ (cd ${MID} ; echo ')lisp (make-databases "" nil)' |
${INTERPSYS} )
        @ cp ${MID}/*.daase ${OUT}

--------

1) Are the differences in the make-databases options
  significant?

2) The new version of db: puts just the *.daase files
  into the mnt directory ${OUT}, but this is not (at least
  not usually, I think) where AXIOM looks for the databases
  files. I guess we are missing the install/promote steps
  in the new Makefile.

  When I tried to update the database yesterday, what I
  did was just to copy these .daase files from ${OUT} into
  src/share/algebra. Is that correct? I wondering if the
  database files now in the CVS are complete and self
  consistent.

3) The original makefile has the stanza

db-install:
#
#  Now move everything to int/lib/unix
#
        @ echo moving ${MID}/unix/compress.daase to ${CENTER}/
        @ mv ${MID}/unix/compress.daase ${CENTER}/
#
        @ echo moving ${MID}/unix/interp.daase to ${CENTER}/
        @ mv ${MID}/unix/interp.daase ${CENTER}/
#
        @ echo moving ${MID}/unix/browse.daase to ${CENTER}/
        @ mv ${MID}/unix/browse.daase ${CENTER}/
#
        @ echo moving ${MID}/unix/category.daase to ${CENTER}/
        @ mv ${MID}/unix/category.daase ${CENTER}/
#
        @ echo moving ${MID}/unix/operation.daase to ${CENTER}/
        @ mv ${MID}/unix/operation.daase ${CENTER}/
#
        @ echo moving ${MID}/unix/USERS.DAASE to ${CENTER}
        @ rm -rf ${CENTER}/USERS.DAASE
        @ mv ${MID}/unix/USERS.DAASE ${CENTER}
#
        @ echo moving ${MID}/unix/DEPENDENTS.DAASE to ${CENTER}
        @ mv ${MID}/unix/DEPENDENTS.DAASE ${CENTER}
#
        @ echo moving ${MID}/unix/libdb.text to ${CENTER}
        @ mv ${MID}/unix/libdb.text ${CENTER}
#
        @ echo moving ${MID}/unix/comdb.text to ${CENTER}
        @ mv ${MID}/unix/comdb.text ${CENTER}
#
        @ echo Now you need to promote the databases \(make
PART=dbpromote\)
        @ echo Then remake and promote the *.img files
#       @ echo rebuilding interpsys with the new database
#       @ touch ${OBJ}/${SYS}/interp/database.date
#       @ (cd ${SPD} ; ${MAKE} PART=interp)

----------

4) I notice that not only are the .daase files installed
but also the directories USERS.DAASE and DEPENDENTS.DAASE.
Since your new db: stanze did not copy these to ${OUT},
I did not copy them to share/algebra when. Are they needed?

5) Are any of the other non *.daase files needed? E.g.
the .text files?

6) There does not seem to be any "promote" stanza in
either the old or new make files but I notice that there
is a final step to re-build interpsys with the new
database. Is this necessary or just an optional check?

\start
Date: Sun, 26 Oct 2003 10:45:02 +0100
From: David Mentre
To: Camm Maguire
Subject: re: [Gcl-devel] Another failing build on EFUPXS: GCL 2.6.1 issue??

Camm Maguire writes:

> BTW, you know that there is a pre-built Debian axiom package for ppc
> (unstable)?  

Yes, I know. But I do not consider myself a debian developer. I'm much a
bare bone debian user.

\start
Date: Sun, 26 Oct 2003 10:54:04 +0100
From: David Mentre
To: Tim Daly
Subject: re: completion of algebra lattice
Cc: Bill Page

Hello Tim, Bill and Juergen,

Tim Daly writes:

> I re-downloaded the CVS copy and did a build from scratch overnight.
> It appears that the system won't build from CVS at the moment.

Just for the record, my build from scratch, latest CVS, also failed on
NODE1.

\start
Date: Sun, 26 Oct 2003 11:32:47 +0100
From: David Mentre
To: list
Subject: re: [Gcl-devel] Another failing build on EFUPXS: GCL 2.6.1 issue??

Tim,

Camm Maguire writes:

>> Ouch! So if I read you correclty, you mean I can't compile Axiom on my
>> Debian stable/gcc 2.95.4 powerpc machine? 
>> 
>
> Most likely not.  On ppc, you'll be much happier with gcc-3.3.  

I have updated web page explaining why Axiom won't build on Debian 3.0
(stable) on powerpc arch.

\start
Date: 26 Oct 2003 13:58:32 +0100
From: Wolfgang Zocher
To: list
Subject: Error with Axiom.CVS & gcl-2.6.1

Hi all,

when I tried to build axiom from scratch last night I got the errors listed
below. Is this kind of error symptomatic for the new release of gcl? Has
anyone tried to compile with gcl-2.7.x (CVS)? 

Here is the interesting part of the log-file:

   compiling local solveBernoulli : (Record(coef1: F,coefn: F,exponent: NonNegativeInteger),BasicOperator,Symbol,F) -> Union(F,failed)
   Semantic Errors:
      [1]  ElementaryFunctionODESolver is not a known type

   Warnings:
      [1] solve: not known that (OrderedSet) is of mode (CATEGORY package (SIGNATURE solve ((Union F failed) F F (BasicOperator) (Symbol))))
      [2] checkBernoulli: not known that (Ring) is of mode (CATEGORY package (SIGNATURE solve ((Union F failed) F F (BasicOperator) (Symbol))))

****** comp fails at level 4 with expression: ******
error in function solveBernoulli

(SEQ (LET |n1| (- 1 (|::| (|rec| |exponent|) (|Integer|))))
     (LET |deq|
       (+ (+ (|differentiate| |yx| |x|)
             (* (* |n1| (|rec| |coef1|)) |yx|))
          (* |n1| (|rec| |coefn|))))
     (LET |sol|
       (|::| | << | (|solve| |deq| |y| |x|) | >> |
             (|Record| (|:| |particular| F) (|:| |basis| (|List| F)))))
     (|exit| 1
             (/ (- (** |yx| |n1|) (|sol| |particular|))
                (|first| (|sol| |basis|)))))
****** level 4  ******
$x:= (solve deq y x)
$m:= $EmptyMode
$f:=
((((|deq| #) (|n1| #) (|exponent| #) (|coefn| #) ...)))

   >> Apparent user error:
   no modemap for solve with 3 arguments

protected-symbol-warn called with (NIL)
(1) -> 0 making /home/wolzoc/axiom-athlon/mnt/linux/algebra/NODE1.o from /home/wolzoc/axiom-athlon/int/algebra/NODE1.NRLIB
cp: Aufruf von stat fr /home/wolzoc/axiom-athlon/int/algebra/NODE1.NRLIB/code.o nicht mglich: Datei oder Verzeichnis nicht gefunden
make[3]: *** [/home/wolzoc/axiom-athlon/mnt/linux/algebra/NODE1.o] Fehler 1
make[3]: Leaving directory `/home/wolzoc/axiom-athlon/src/algebra'
make[2]: *** [algebradir] Fehler 2
make[2]: Leaving directory `/home/wolzoc/axiom-athlon/src'
make[1]: *** [srcdir] Fehler 2
make[1]: Leaving directory `/home/wolzoc/axiom-athlon'
make: *** [all] Fehler 2

\start
Date: Sun, 26 Oct 2003 13:41:03 +0100
From: David Mentre
To: Wolfgang Zocher
Subject: Re: Error with Axiom.CVS & gcl-2.6.1

Hello Wolfgang,

Wolfgang Zocher (Wolfgang Zocher) writes:

> when I tried to build axiom from scratch last night I got the errors listed
> below. Is this kind of error symptomatic for the new release of gcl? Has

No, it is not related to gcl.. It is more probably related to an issue
in Axiom internal database which describes Axiom knowledge on math
"modules".

> anyone tried to compile with gcl-2.7.x (CVS)? 

I don't think so.

[...]
> (1) -> 0 making /home/wolzoc/axiom-athlon/mnt/linux/algebra/NODE1.o from /hom

Both Tim, you and I failed on the same file. I have the same error
message as you.

I think the proper cause of failure is:
   compiling local solveBernoulli : (Record(coef1: F,coefn: F,exponent: NonNegativeInteger),BasicOperator,Symbol,F) -> Union(F,failed)
   Semantic Errors: 
      [1]  ElementaryFunctionODESolver is not a known type
 
   Warnings: 
      [1] solve: not known that (OrderedSet) is of mode (CATEGORY package (SIGNATURE solve ((Union F failed) F F (BasicOperator) (Symbol))))
      [2] checkBernoulli: not known that (Ring) is of mode (CATEGORY package (SIGNATURE solve ((Union F failed) F F (BasicOperator) (Symbol))))

\start
Date: Sun, 26 Oct 2003 09:02:30 -0500
From: Tim Daly
To: Wolfgang Zocher
Subject: Re: Error with Axiom.CVS & gcl-2.6.1

Wolfgang,

There is currently a problem with the CVS version.
We are actively working on it. If we don't solve it
shortly we will back out to the previous version.
I'll send you email once there is a buildable version in CVS.

\start
Date: Sun, 26 Oct 2003 16:28:46 -0500
From: Tim Daly
To: Bill Page
Subject: Re: cvs

re: commit. 

great. I'll download and test it.
In general I've learned not to mention to anyone that I've
changed CVS until I've uploaded, downloaded a brand-new copy,
compiled, and tested it. It is a long, painful cycle, no?

re: backout

I think the idea is that when you make a change it becomes 
foo.1.2 and if you want to get the previous version you
explicitly ask for 
cvs -r foo.1.1
I haven't done that explicitly but you're welcome to try it.
CVS maintains the old versions but I don't know of an explicit
command to "back out" a change. Usually you download a prior
version and then check it back in so it becomes foo.1.3

re: daase files

The daase files are random access files.
You get a number, seek into the file that number of bytes, and call read.

The format of the daase files is:

integer-offset-to-index
(sexpr) (sexpr) (sexpr) .... (sexpr)
(index)

The file is read by reading the integer offset,
seeking into the file that many bytes,
and reading the index. The index is a table
of lists of offset numbers (some of the offsets
are immediate data rather than numbers).

So, for instance, in browse.daase you can open the file in emacs,
read the first number (2135125) and then do:
C-u 2135125 C-f 
and you end up position 2135125 characters into the file which is
the start of the index list. If you know what the index list
entries mean then you can look up properties.

One of the subtle parts of some of the files is that there is a
compression algorithm I wrote to minimize the size of the daase
files. It could be the case that the compression algorithm has
a bug. In any case I'm going to write a program to compare two
daase versions. This involves reading the index, walking the index
entries to get the data, and comparing the results from the other file.
I've written a few checking routines of this type before. (see libcheck
in util.lisp.pamphlet which checks INTERP.EXPOSED (which I have to 
rewrite to use exposed.lsp)). I plan to add these checking routines
as part of the build process (they used to be there).

re: conflicts

I deleted some files per requests by David and Camm
and they've been uploaded again. Be sure to do
cvs update 
before you do a 
cvs commit

The "update" makes sure that you have resolved all of
the conflicts before adding your code.

I've forgotten this in the past but so far I've been the
only one making cvs commits. I expect that we'll all be
doing commits in the future so we have to be careful to
do cvs updates first.

Despite the unforseen gaffe I'm quite pleased that you 
went ahead and made independent changes. Provided we all
carefully check our work I'm hoping to see more of this.

\start
Date: 26 Oct 2003 17:33:48 -0500
From: Bill Page
To: Tim Daly
Subject: Re: cvs

Tim,

Thanks for the notes about the database files.

On Sun, 2003-10-26 at 16:28, you wrote

> re: conflicts
> 
> I deleted some files per requests by David and Camm
> and they've been uploaded again. Be sure to do
> cvs update before you do a cvs commit
> 
> The "update" makes sure that you have resolved all of
> the conflicts before adding your code.
> 

Ok, sorry. I did forget the update step. If I had done the
update would everything have authomatically been alright or
would I have had to manually delete my copy of the files
which you had separately deleted in order to avoid having
them re-added?

> I've forgotten this in the past but so far I've been the
> only one making cvs commits. I expect that we'll all be
> doing commits in the future so we have to be careful to
> do cvs updates first.
> 

Understood. I am amazed once again that the open software
movement has gotten as far as it has with CVS. But that's
dedication, I guess. But once one learns to cope with the
limitations of some complex tool, it is hard to give it up
even when something better and easier to use comes along...

> Despite the unforseen gaffe I'm quite pleased that you 
> went ahead and made independent changes. Provided we all
> carefully check our work I'm hoping to see more of this.
> 

You are absolutely right that I should have tested the
change to the database first (by re-compiling interpsys
again after changing the database files, obviously)
*before* uploading my changes to the CVS. Sorry.

The current interp/Makefile does not actually update
the database files. How do you plan to handle this in
the future? Would this normally be done as part of
every build? So does this always mean that we have to
build interpsys twice?

\start
Date: Sun, 26 Oct 2003 18:54:47 -0500
From: Tim Daly
To: Bill Page
Subject: Re: cvs

> Ok, sorry. I did forget the update step. If I had done the
> update would everything have authomatically been alright or
> would I have had to manually delete my copy of the files
> which you had separately deleted in order to avoid having
> them re-added?

It comes with practice which is why I first set up a local CVS
then the CVS on tenkan before I started using the main website.
On the first CVS I used remotely I uploaded my whole home directory
including my mail files. 

If I delete a file and you do the update then the cvs command will
delete your copy of the file when you do the update. In order to
avoid stepping on other peoples changes everyone must do a cvs update
before doing a commit. The cvs update will try to merge changes that
don't conflict but will complain about ones it can't. You need to
merge changes that cvs cannot before you check in the files.

> Understood. I am amazed once again that the open software
> movement has gotten as far as it has with CVS. But that's
> dedication, I guess. But once one learns to cope with the
> limitations of some complex tool, it is hard to give it up
> even when something better and easier to use comes along...

The linux kernel people have partially migrated to bitkeeper.
Bitkeeper is a much better idea and they let free software
projects use it for free. However it is the subject of endless
religious wars and we don't need the grief. There is also a
free version call subversions, I believe. Change control is
always a painful subject and I've never seen a system I liked.

Hosting Axiom on savannah makes CVS the required default so 
using other tools is a moot point.

If the number of developers gets large enough we'll have to
appoint a person as the "librarian" to centralize changes.
That person would be responible for applying and testing changes.

In the kernel there are many cvs trees although Linus's tree
is "the master" people like Alan Cox maintain their own tree.
You can check out the -ac version to get Alan's copy. Alan
maintains patches that either Linux won't accept, Alan thinks
aren't quite ready, or are specific to things Alan wants.

> You are absolutely right that I should have tested the
> change to the database first (by re-compiling interpsys
> again after changing the database files, obviously)
> *before* uploading my changes to the CVS. Sorry.

I follow this cycle:

1) I have a local tree where I make changes. There are currently 3 
   local trees with changes "in process" in parallel.
2) Once I'm happy with a local tree I do a cvs checkout of Axiom
   to a clean directory (call it directory A) and apply the changes 
   to that directory copy.
3) I do a build in the A directory.
4) I do a clean checkout of axiom into a B directory and diff -R A B
5) I copy the changed files to my "master" directory
   and do the cvs adds/deletes
6) I copy the master directory to a local directory C and do a build
   along with testing.
7) I cvs checkin the master
8) I cvs checkout the master to local directory D
9) I make directory D

It is a painfully long dance but I inserted the various steps 
because I make a lot of mistakes and each step catches some of
the errors. I still manage to shank one occasionally.
   

> The current interp/Makefile does not actually update
> the database files. How do you plan to handle this in
> the future? Would this normally be done as part of
> every build? So does this always mean that we have to
> build interpsys twice?

Yes, interpsys will eventually be built twice as part of the build.
During the second build there are a large number of function-calling
optimizations that get applied which considerably speed up the
execution.

The database files will only get rebuilt if they need to be.
Currently databases are rebuilt every time. This used to be
implemented in Scratchpad but seems to have disappeared.

\start
Date: Sun, 26 Oct 2003 20:06:11 -0500
From: Tim Daly
To: Wolfgang Zocher
Subject: Axiom build restored

Wolfgang,

The Axiom CVS has been restored to a version that builds properly.
Sorry for the problems.

\start
Date: Sun, 26 Oct 2003 22:42:36 -0500
From: Tim Daly
To: Bill Page
Subject: layer22

Bill,

I noticed in the last build that you not only removed the databases
but also your modifications to the src/algebra/Makefile.pamphlet.
I haven't finished testing yet but it appears that you've solved
most of the problems. A lot of the broken test cases listed in
src/input/Makefile.pamphlet under the <<regression tests>> chunk
seem to run with your changes.

I'll run some tests, probably tomorrow, with your layer22 changes
to see if they can be run out of mnt. If so we should probably 
restore at least the Makefile.pamphlet you made.

I'll let you know the results of the tests.

\start
Date: 27 Oct 2003 12:09:46 +0100
From: Wolfgang Zocher
To: Tim Daly
Subject: Re: Axiom build restored

Tim Daly writes:

Tim,

> The Axiom CVS has been restored to a version that builds properly.
> Sorry for the problems.

you really make me feel ashamed. You're doing a lot of great work with Axiom
while I'm only whining ... 

I wish I could help you - at the moment my knowledge about the details of the
Axiom system, its program structure etc. is too little to be ready for doing
something relevant unless I can help with tasks which don't require such
deeper knowledge ...

\start
Date: Mon, 27 Oct 2003 06:55:03 -0500
From: Tim Daly
To: Wolfgang Zocher
Subject: re: Axiom build restored

Wolfgang,

It is not my intention to make anyone feel ashamed. 

Building a running Axiom is a hard problem and involves many people
who are doing their work in the open where other people can watch.
Problems arise and we need people who are trying to use the system
to give us feedback when things don't work. To say that your effort
amounts to "I'm only whining" is to say that testing and bug reporting
is "only whining". Whining involves opinion; bug reporting involves
facts. You reported a fact that the system wouldn't build. That is
a valid contribution.

Bug reports are always welcome.

\start
Date: Mon, 27 Oct 2003 11:45:30 -0500
From: Tim Daly
To: Bill Page
Subject: Re: algebra completion

Bill,

I did a cvs update to get the latest version.
Then I did a cvs -r to get your previous src/algebra/Makefile.pamphlet.
I did a rebuild of the system with your Makefile.pamphlet.
I ran the broken test cases.
Your Makefile.pamphlet solves a couple dozen problems.
Tonight I'm going to restore your Makefile.pamphlet as well as
the newly working regression tests.

\start
Date: Mon, 27 Oct 2003 13:43:13 -0500
From: Bill Page
To: Tim Daly
Subject: RE: layer22

Tim

On Sunday, October 26, 2003 10:43 PM you wrote:
> 
> I noticed in the last build that you not only removed the
> databases but also your modifications to the
> src/algebra/Makefile.pamphlet.

If that is true then it certainly shows how much
I do not understand about CVS! It was not my
intention to remove the new algebra/Makefile.pamphlet
and I know for certain that it was *not* removed or
backed-out to the old version in the directory from
which I updated the CVS since I did a build of Axiom
right from that directory and ran the regression
tests.

Odd.

\start
Date: Mon, 27 Oct 2003 13:51:00 -0500
From: Bill Page
To: Tim Daly
Subject: RE: layer22

Tim,

I just checked the CVS using the Web interface on
Savannah

 
http://savannah.nongnu.org/cgi-bin/viewcvs/axiom/axiom/src/algebra/Makefile.
pamphlet

and it shows only the new version 1.3 of the algebra
Makefile.pamphlet that I uploaded (along with the
bad databases) last Friday morning. When you were
building Axiom you must have got the old one from
somewhere else. No?

No comprendo.

Cheers,
Bill Page.

On Monday, October 27, 2003 1:43 PM I wrote:
> 
> On Sunday, October 26, 2003 10:43 PM you wrote:
> > 
> > I noticed in the last build that you not only removed the
> > databases but also your modifications to the
> > src/algebra/Makefile.pamphlet.
> 
> If that is true then it certainly shows how much
> I do not understand about CVS!
> ...

\start
Date: Mon, 27 Oct 2003 19:58:10 +0100
From: David Mentre
To: Bill Page
Subject: On CVS (was: re: layer22)

Hello Bill,

Bill Page writes:

> and I know for certain that it was *not* removed or
> backed-out to the old version in the directory from
> which I updated the CVS since I did a build of Axiom
> right from that directory and ran the regression
> tests.

Your right. The src/algebra/Makefile.pamphlet currently in CVS is yours:
http://savannah.nongnu.org/cgi-bin/viewcvs/axiom/axiom/src/algebra/Makefile.pamphlet?graph=1.3

1.3 - 24-Oct-2003 12:33:11 - billpage1 - HEAD

Please notice that cvs tells you what it does. It is somewhat encoded
(e.g. in a cvs update) but the information is there.

\start
Date: Mon, 27 Oct 2003 20:01:12 +0100 (CET)
From: Ralf Hemmecke
To: list
Subject: axiom compilation problem (gcl)

Hello,

Some minutes ago, I downloaded the anonymous CVS module

cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom

There is now a default version 2.6.1 in Makefile.pamphlet which is
put into Makefile but not into Makefile.dvi.

The gcl versions 2.4.1 and 2.5 are not in the zips directory.

\start
Date: Mon, 27 Oct 2003 14:12:55 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: axiom compilation problem (gcl)

Ralf,

That is correct. Axiom is now built (by default)
using GCL 2.6.1. GCL versions 2.4.1 and 2.5 are
out of date. It is still possible (by a small
modification) to build with the previous version
of GCL which was 2.5.2.

When you say "not the Makefile.dvi" do you mean that
this documentation file is not up to date with these
changes? If so, then that should not affect the build
of Axiom and will be corrected as part of the build
process.

> 
> Hello,
> 
> Some minutes ago, I downloaded the anonymous CVS module
> 
> cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom
> 
> There is now a default version 2.6.1 in Makefile.pamphlet which is
> put into Makefile but not into Makefile.dvi.
> 
> The gcl versions 2.4.1 and 2.5 are not in the zips directory.

\start
Date: Mon, 27 Oct 2003 19:59:21 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: On statically linked Axiom (was: static lisp and rpms)

Camm,

When using the -enable-static option on configure under
RedHat Linux 8.0 and gcc 3.3.2 is it expected that the
gcl image be only about 180kbytes larger than without
the -enable-static option? Fram a 6 Mbyte image, this
seems like a surprizingly small change in size to me.

> Greetings!  OK, thanks for the report -- I've just committed a fix in
> cvs 2.6.1 and head.  The patch is in two parts, one loads weak symbols
> as well as undefined symbols into the bfd symbol table, and the other
> maps the 't' and 'nil stream descriptors properly in optimized
> references to read-char.  These will be in the next stable and
> unstable release on the temp site.
> ... 
> > 
> > On Monday, October 20, 2003 11:45 PM Tim wrote:
> > 
> > > 
> > > The statically linked GCL image has a problem:
> > > 
> > > make file foo.lisp:
> > > 
> > > (defun test (st) (read-char st))
> > > 
> > > at lisp prompt:
> > > 
> > > >(compile-file "foo.lisp")
> > > >(load "foo.o")
> > > 
> > 
> > I tried this under Windows with GCL 2.6.1 which is statically
> > linked without readline by default (I think?). It worked fine.
> > 
> > So it seems that moving to 2.6.1, building with the new
> > .\configure --enable-static option and eliminating readline
> > might correct your static linking problem.

\start
Date: Mon, 27 Oct 2003 23:21:28 -0500
From: Tim Daly
To: list
Subject: cvs

I've added new regression tests to the src/input/Makefile.pamphlet.
I've recreated Makefile.dvi

\start
Date: Tue, 28 Oct 2003 05:02:06 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: On statically linked Axiom (was: static lisp and rpms)

Camm,

Sorry, let me correct my report of the size of GCL
under a static build. The size difference that I
really see is

  7.275 Mb. (static) versus 5.930 Mb. (dynamic)

That's a difference of 1.345 Mb. - more reasonable?

Note also that the dynamic library version was build
using gcc 3.2.

The number that I reported previously was just the
different due to the change from gcc 3.2.1 to 3.3.2.

Bill Page.

> Camm,
> 
> When using the -enable-static option on configure under
> RedHat Linux 8.0 and gcc 3.3.2 is it expected that the
> gcl image be only about 180kbytes larger than without
> the -enable-static option? Fram a 6 Mbyte image, this
> seems like a surprizingly small change in size to me.

\start
Date: Tue, 28 Oct 2003 12:27:50 +0100
From: Juergen Weiss
To: David Mentre, Bill Page
Subject: RE: On CVS (was: re: layer22)

I had a look at the algebra Makefile, and it seems that
the domains/packages INTRVL, ODEEF and RSDCMPK are not
build. So without them, the database is incomplete and
it is not possible to recompile the system with the
incomplete database.

> Hello Bill,
> 
> Bill Page writes:
> 
> > and I know for certain that it was *not* removed or
> > backed-out to the old version in the directory from
> > which I updated the CVS since I did a build of Axiom
> > right from that directory and ran the regression
> > tests.
> 
> Your right. The src/algebra/Makefile.pamphlet currently in 
> CVS is yours:
> http://savannah.nongnu.org/cgi-bin/viewcvs/axiom/axiom/src/alg
ebra/Makefile.pamphlet?graph=1.3

1.3 - 24-Oct-2003 12:33:11 - billpage1 - HEAD

Please notice that cvs tells you what it does. It is somewhat encoded
(e.g. in a cvs update) but the information is there.

\start
Date: Tue, 28 Oct 2003 06:46:54 -0500
From: Bill Page
To: Weiss, Juergen
Subject: RE: On CVS (was: re: layer22)

Juergen,

Thank you very much for looking at this! You are right
that the three modules you mentioned are missing from
the layers defined in the current algebra/Makefile.
I have added them and am currently re-building a system
including these. Then I will try to repeat the build
with the resulting databases files.

> 
> I had a look at the algebra Makefile, and it seems that
> the domains/packages INTRVL, ODEEF and RSDCMPK are not
> build. So without them, the database is incomplete and
> it is not possible to recompile the system with the
> incomplete database.

\start
Date: Tue, 28 Oct 2003 07:47:13 -0500
From: Tim Daly
To: Bill Page
Subject: re: On statically linked Axiom (was: static lisp and rpms)
Cc: Camm Maguire

Bill,

If you create a linux-static chunk in the top-level Makefile.pamphlet
then you can create the static image by setting the Axiom varialble to:

export AXIOM=(yourpath)/axiom/mnt/linux-static

then we can try a static build of Axiom

\start
Date: Tue, 28 Oct 2003 09:26:39 -0500
From: Bill Page
To: Tim Daly
Subject: RE: On statically linked Axiom (was: static lisp and rpms)
Cc: Camm Maguire

Tim,

I have already completed a build with --enable-static.
However to get things to work I did two things: 

1) I replaced the gcl-2.6.1 tgz file in zips with the
more recent gcl-2.6.1-16 source from Camm's temporary
debian site. Since Camm had provided a patch in the
new version to handle readline in the static case.

2) I upgraded my gcc compiler to version 3.3.2 (the
newest version) since other emails also indicated that
there were possible problems with older versions of gcc.

It now seems to work. 

I was about to upload a binary to the files section for
others to try (since I only have RedHat Linux boxes here,
moving the static binary between them is not a real test),
but then Juergen pointed out that we still have three
missing algebra files, so I decided to include those files
before uploading the new static binary.

I will also proceed as you suggest and modify the
Makefile.pamphlet to include a linux-static chuck, however
I have to think about this a bit more since the change to
the GCL configuration option is done in the lsp/Makefile.
So I think this means that it will have to be controlled
by the GCLVERSION environment variable. E.g. maybe

  GCLVERSION=gcl-2.6.1-static

and then it will use that to pull the right chunk
out of the lsp/Makefile.pamphlet. Right?

Cheers,
Bill Page.

> Bill,
> 
> If you create a linux-static chunk in the top-level
> Makefile.pamphlet then you can create the static image by
> setting the Axiom varialble to:
> 
> export AXIOM=(yourpath)/axiom/mnt/linux-static
> 
> then we can try a static build of Axiom

\start
Date: Tue, 28 Oct 2003 09:13:46 -0500
From: Tim Daly
To: Bill Page
Subject: linux-static chunk
Cc: Camm Maguire

I'm sure you already know this but I'll write it down anyway.
The steps to take are:

A) CHANGES TO THE Makefile.pamphlet FILE:

*) copy the linux chunk and rename it to linux-static.
    This will set up almost all of the appropriate variables. The chunk
    that gets used is decided by the basename of the $AXIOM variable.
    So to select this new chunk you would make the AXIOM variable be:
  AXIOM=(yourpath)/axiom/mnt/linux-static
    This will create a Makefile.linux-static and invoke it.

*) modify the linux-static chunk to include a new make variable 
     Something like 
   STATIC=--enable-static

*) add this variable to the ENV variable
     This "passes" the variable down to the next level of Makefile
     which in this case is the lsp/Makefile. The reason this works
     is that you can generally set a shell variable on the same
     commandline as the call to make and the shell variables will
     be seen by the make. The change will look something like:
   ENV= ...... STATIC=${STATIC}

*) hardcode the GCLVERSION variable in the linux-static chunk
    GCLVERSION=gcl-2.6.1-static

*) add documentation to the new linux-static chunk to explain what
   you are doing and why. 

*) run the document command on the top level Makefile.pamphlet thus:
    SPAD=$AXIOM
    PATH=$AXIOM/bin:$PATH
    document Makefile     (don't add the .pamphlet)

B) CHANGES TO THE zips DIRECTORY

*) add the gcl-2.6.1-16.tgz to zips

*) copy the zips/gcl-2.6.1*.patch files to zips/gcl-2.6.1-16*.patch

*) cvs add gcl-2.6.1-16*

C) CHANGES TO THE lsp/Makefile.pamphlet FILE

*) modify the lsp/Makefile.pamphlet 
     so that the GCL configure line include ${STATIC}. Normally this
     will expand to the null string so it won't change the behavior
     of the normal build. When invoked from the Makefile.linux-static
     the STATIC variable will be defined and will expand to --enable-static.

*) document the change in the lsp/Makefile.pamphlet

D) CHANGES TO THE CHANGELOG FILE

*) add a comment to CHANGELOG

copy the whole pile, try a build, and when it works check it all in.

If you're really feeling ambitious you can go to www.testdrive.hp.com,
sign up for a password, and try it on several linux variants. I already
have a password so I'm likely to try it.

\start
Date: Tue, 28 Oct 2003 09:16:56 -0500
From: Tim Daly
To: Bill Page
Subject: linux-static chunk

In parallel I'll do a test build to see if gcl-2.6.1-16 works
properly. If so we can delete the gcl-2.6.1 image and move the
GCLVERSION variable to the -16 version.

Is gcl-2.6.1-16.tgz in the cvs?

\start
Date: Tue, 28 Oct 2003 09:58:28 -0500
From: Bill Page
To: Tim Daly
Subject: readline and axiom
Cc: Camm Maguire

Tim, Camm;

Am I confused over how readline is supposed to work
with GCL and Axiom?

Under the Windows version of GCL 2.6.1, I can enter
an expression like

  > (+ 1 1)

and then hit the up arrow key and make a change
say to

  > (+ 1 2)

and just hit enter to execute the edited line.

I have not been able to do the equivalent under Axiom.
When I press up arrow I get

  ^[0A

(^[ means "escape"?) which of course Axiom doesn't
understand.

And I have just tested the new GCL 2.6.1-16 built
with --enable-static and --enable-readline and I get
the same weird characters rather than the "readline"
behaviour that I expected.

Am I doing something wrong? Is there something that
has to be enabled in GCL as part of the startup?

\start
Date: Tue, 28 Oct 2003 09:25:04 -0500
From: Tim Daly
To: Bill Page
Subject: linux-static chunk
Cc: Joris van der Hoeven

Bill,

We use 2 "features" of noweb, the <<chunk>> mechanism and
the [[quoting]] mechanism. (btw, I'm about to patch the
annoying tmpnam message by rewriting that code).

We also have our own extension of noweb which uses code written by
David to do "booklets". Chunk names that begin with <<pamphlet:
are treated as a url and are included inline during the literate
programming pass. Note that we need to do this. The #include 
mechanism in TeX occurs AFTER the literate programming pass so 
you can't use it to include pamphlets since they would not be
expanded properly. The booklet code is in src/doc.

In general the longer term plan is to adopt the "protocol" style
of URLs (http:, ftp:, etc) to specify literate programming features.
One feature in the design pipeline is to have biblio references as:
<<reference: or <<spad:, etc.

\start
Date: Tue, 28 Oct 2003 09:28:58 -0500
From: Tim Daly
To: Bill Page
Subject: Axiom and readline

Bill,

There is a program called clef, which is part of Axiom, that handles 
this (as well as command completion for Axiom functions, etc). I'll
look at recovering it.

\start
Date: Tue, 28 Oct 2003 09:27:09 -0500
From: Tim Daly
To: Bill Page
Subject: linux-static chunk
Cc: Joris van der Hoeven

Bill,

Also of note is that the Red Flag Linux person has a deep
interest in literate programming. Should be fun to add languages
to the list of things to think about. There is no reason why the
research work has to be in english.

\start
Date: 28 Oct 2003 11:07:37 -0500
From: Camm Maguire
To: list
Subject: Re: Bug#217644: axiom: missing file: SIGNEF.o
Cc: 217644@bugs.debian.org, Martin Uecker, control@bugs.debian.org

forwarded 217644 list
thanks

Greetings everyone!  Another report of a missing file from a Debian
user -- is this linked with the COMBF.o issue?

Take care,

Martin Uecker writes:

> Package: axiom
> Version: 0.0.0cvs-7
> Severity: important
> 
> 
> This file seems critical for important functionality
> like integration:
> 
> (5) -> integrate(1/x,x)
>    Loading /usr/lib/axiom-0.0.0cvs/mnt/linux/algebra/SIGNEF.o for
>       package ElementaryFunctionSign
> 
>    >> System error:
>    Cannot open the file /usr/lib/axiom-0.0.0cvs/mnt/linux/algebra/SIGNEF.o.

\start
Date: Tue, 28 Oct 2003 17:13:04 +0100 (CET)
From: Ralf Hemmecke
To: list
Subject: axiom compilation succeded

Hello,

I have just succeded to compile axiom on

> uname -a
Linux dragonfly 2.2.20-idepci #1 Sat Apr 20 12:45:19 EST 2002
i686 unknown
(2.4GHz/1GB Debian Linux)

without any problem.

Congratulations to the developers!

I know that AXIOM is still in a very early state, but I would like to
add a few comments.

A good thing is that the compilation process works fine. After that
however, someone who wants to give a try on AXIOM, becomes certainly
rather frustrated. The reason is the missing documentation. OK, the
current stage is like that, but I think it is rather important, in
order to attract new people (users/developers/beta testers). I hope
the new axiom book is ready soon.

It would be a good idea to provide at least some sample file with a
collection of commands that are most commonly used in first year
undergraduate courses. Of course the book by Jenks & Sutor is a good
reference, but not everyone has it.

After I had finished the compilation, I looked for documentation. 
Unfortunately only the various Makefile.dvi files yields some
information, but there is one other file

mnt/linux/doc/DeveloperNotes.dvi

which, unfortunately is not a DVI file, but a LaTeX source. The
extension should be changed to avoid confusion. (OK, it is only for
the developers, so maybe it sould not be present in the anonymous
cvs.)

What about ADVI. It seems that it has not been built during make.
Is this intensional or simply will come later when more documentation 
files are available?

Wouldn't it be a good idea to rename the top-level README to 00README
so that it appears first in the directory listing? I would expect that
it guides me through the system, telling me which things are finished
and which are not. This would certainly prevent people (like me)
asking stupid questions about non-existing (or better
not-yet-existing) stuff.

Since I have done some development in Aldor, I am rather interested in
a connection of Aldor and Axiom. Unfortunately, the language is one
thing, the libraries on which to build one's own program are another.

Is it intended that Manuel Bronstein's libraries libaldor and
libalgebra and the axiom library converge? I guess, at the moment they
are incompatible. If I now build some program on libalgebra, is there
a chance (in a nearer future) that I can run this inside AXIOM without
modification. Is someone working on such a connection?

\start
Date: Tue, 28 Oct 2003 11:04:56 -0500
From: Tim Daly
To: Martin Uecker, Camm Maguire
Subject: SIGNEF.o

Martin,

The latest version in the CVS solves this problem but thanks for
the bug report.

Martin Uecker writes:

> Package: axiom
> Version: 0.0.0cvs-7
> Severity: important
> 
> 
> This file seems critical for important functionality
> like integration:
> 
> (5) -> integrate(1/x,x)
>    Loading /usr/lib/axiom-0.0.0cvs/mnt/linux/algebra/SIGNEF.o for
>       package ElementaryFunctionSign
> 
>    >> System error:
>    Cannot open the file /usr/lib/axiom-0.0.0cvs/mnt/linux/algebra/SIGNEF.o.

\start
Date: 28 Oct 2003 11:55:18 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: SIGNEF.o
Cc: Martin Uecker

Greetings!  Great!  I'll try another package release with the latest
stuff.

Take care,

Tim Daly writes:

> Martin,
> 
> The latest version in the CVS solves this problem but thanks for
> the bug report.
> 
> Martin Uecker writes:
> 
> > Package: axiom
> > Version: 0.0.0cvs-7
> > Severity: important
> > 
> > 
> > This file seems critical for important functionality
> > like integration:
> > 
> > (5) -> integrate(1/x,x)
> >    Loading /usr/lib/axiom-0.0.0cvs/mnt/linux/algebra/SIGNEF.o for
> >       package ElementaryFunctionSign
> > 
> >    >> System error:
> >    Cannot open the file /usr/lib/axiom-0.0.0cvs/mnt/linux/algebra/SIGNEF.o.

\start
Date: Tue, 28 Oct 2003 11:23:03 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: SIGNEF.o

Ralf,

> I have just succeded to compile axiom on
> 
> > uname -a
> Linux dragonfly 2.2.20-idepci #1 Sat Apr 20 12:45:19 EST 2002
> i686 unknown
> (2.4GHz/1GB Debian Linux)
> 
> without any problem.

Nice computer. Mail it to me :-)

> 
> Congratulations to the developers!

>From all of us, thanks. Join the party and become a developer.

> 
> I know that AXIOM is still in a very early state, but I would like to
> add a few comments.
> 
> A good thing is that the compilation process works fine. After that
> however, someone who wants to give a try on AXIOM, becomes certainly
> rather frustrated. The reason is the missing documentation. OK, the
> current stage is like that, but I think it is rather important, in
> order to attract new people (users/developers/beta testers). I hope
> the new axiom book is ready soon.

Slowly but surely the docs are coming. I have a near-religious belief
in documentation so you will eventually see it. 

> 
> It would be a good idea to provide at least some sample file with a
> collection of commands that are most commonly used in first year
> undergraduate courses. Of course the book by Jenks & Sutor is a good
> reference, but not everyone has it.

The mnt/linux/input subdirectory contains commands that work.
Eventually these will be in the mnt/linux/doc directory with
explanations of the associated mathematics.

> 
> After I had finished the compilation, I looked for documentation. 
> Unfortunately only the various Makefile.dvi files yields some
> information, but there is one other file
> 
> mnt/linux/doc/DeveloperNotes.dvi
> 
> which, unfortunately is not a DVI file, but a LaTeX source. 

(humpf. a bug. mumble, mutter, moan. i biffed another one.)
We'll get it fixed tonight. Sorry about that.

> which, unfortunately is not a DVI file, but a LaTeX source. The
> extension should be changed to avoid confusion. (OK, it is only for
> the developers, so maybe it sould not be present in the anonymous
> cvs.)
> 
> What about ADVI. It seems that it has not been built during make.
> Is this intensional or simply will come later when more documentation 
> files are available?

I have done several experiments with ADVI. David Mentre has expressed
interest in looking at further development and integration. ADVI, as
it stands now, is mostly of interest because it demonstrates the power
of the dvi file format. We can embed \special tags that allow us to 
include other pamphlets, include active graphics, include inline axiom
sessions, etc. In the long term this is very important. However we are
still recovering old functionality so there is very little time to 
expend on new work yet.

> 
> Wouldn't it be a good idea to rename the top-level README to 00README
> so that it appears first in the directory listing? I would expect that
> it guides me through the system, telling me which things are finished
> and which are not. This would certainly prevent people (like me)
> asking stupid questions about non-existing (or better
> not-yet-existing) stuff.

Umm, no. It appears that standard expectations are that we have a README
file (and a configure script). README exists to conform to that expectation.
The configure script is coming. I'll update the README later tonight.
I don't mind questions and don't consider them stupid. 

> Since I have done some development in Aldor, I am rather interested in
> a connection of Aldor and Axiom. Unfortunately, the language is one
> thing, the libraries on which to build one's own program are another.

Aldor libraries seem to have a rather small overlap with Axiom libraries.
There are 1100+ domains, packages, and categories in Axiom and, though
many have tried, there is no easy way to make them available in Aldor.
(The key problem is that you have to implement underlying lisp functionality
in Aldor and that is a huge amount of work). Aldor programs can be used
with Axiom.

> 
> Is it intended that Manuel Bronstein's libraries libaldor and
> libalgebra and the axiom library converge? I guess, at the moment they
> are incompatible. If I now build some program on libalgebra, is there
> a chance (in a nearer future) that I can run this inside AXIOM without
> modification. Is someone working on such a connection?

I doubt they'll converge. Some people want standalone code to implement
a particular algorithm and work in Aldor. Others want to write algorithms
in a general setting and work in Axiom. It is much easier to move an
Aldor program to Axiom than it is to move an Axiom program to Aldor. So
eventually I see Axiom containing algorithms originally written in Aldor
but not the reverse due to practical considerations mentioned above.
It's a minor point, really, as the algebra languages are the same.


\start
Date: 28 Oct 2003 12:03:18 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: readline and axiom

Greetings!

There is a small weakness in our current readline support which could
be addressed straightforwardly if/when I get a moment.  The way it is
now, the readline library must be initialized at runtime via the lisp
command:

(si::init-readline)

The gcl wrapper script should eval this for you automatically, but it
is likely that axiom users will have to escape to lisp and run this
command unless we get something more robust implemented.  On maxima,
this looks like

:lisp (si::init-readline)

In addition, our readline code will probe the running terminal, and
skip readline initialization if the controlling terminal is not
readline capable, e.g. an emacs shell buffer, and ilisp emacs
interface to gcl, etc.  Here is the existing code for this test:

	if (!isatty(0))
	   return;

	if ((cp=getenv("TERM")) && !strcmp(cp,"dumb"))
	   return;

Bill, you have access to linux too, no?  Would be nice if you could
report any readline functionality differences between the to ports, if
any. 

Take care,

Bill Page writes:

> Tim, Camm;
> 
> Am I confused over how readline is supposed to work
> with GCL and Axiom?
> 
> Under the Windows version of GCL 2.6.1, I can enter
> an expression like
> 
>   > (+ 1 1)
> 
> and then hit the up arrow key and make a change
> say to
> 
>   > (+ 1 2)
> 
> and just hit enter to execute the edited line.
> 
> I have not been able to do the equivalent under Axiom.
> When I press up arrow I get
> 
>   ^[0A
> 
> (^[ means "escape"?) which of course Axiom doesn't
> understand.
> 
> And I have just tested the new GCL 2.6.1-16 built
> with --enable-static and --enable-readline and I get
> the same weird characters rather than the "readline"
> behaviour that I expected.
> 
> Am I doing something wrong? Is there something that
> has to be enabled in GCL as part of the startup?

\start
Date: Tue, 28 Oct 2003 11:28:15 -0500
From: Tim Daly
To: Bill Page, Camm Maguire
Subject: readline

If you add the line:

)lisp (si::init-readline)

to your .axiom.input file it will get executed when Axiom starts.

\start
Date: Tue, 28 Oct 2003 18:27:52 +0100 (CET)
From: Ralf Hemmecke
To: Tim Daly
Subject: RE: SIGNEF.o

Hello,

> It is much easier to move an Aldor program to Axiom than it is to
> move an Axiom program to Aldor.

Yes, I know. I don't expect that Axiom (sub-) programs can be
extracted. What I am interested in is to use axiom as a front-end for
my program. 

Thus I will have add some functionality to my aldor domains (which
are, in fact, developed without any axiom domain). Is there someone
who has made some toy example available?

To make things easy, I want to build on as few axiom domains as
possible but still want my program run inside axiom. So, in fact, I'd
like to have the interpreter capabilities of axiom for my program.

Of course, I am willing to help to establish such a connection, but I
guess, there were already others who have made such connections
without using src/share/algebra/libaxiom.al.

How was libaxiom.al produced? Are there Aldor sources for it
somewhere. Maybe I can find out the necessary things myself and create
a sublibrary for my intended purpose.

\start
Date: Tue, 28 Oct 2003 12:29:31 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: readline and axiom

Camm,

On Tuesday, October 28, 2003 12:03 PM you wrote:

> ... readline library must be initialized at runtime via
> the lisp command:
> 
> (si::init-readline)
> 
> The gcl wrapper script should eval this for you automatically,
> but it is likely that axiom users will have to escape to lisp
> and run this command unless we get something more robust
> implemented.

Ok, that's clear. Can we still do something like pass an
-eval '(si::init-readline)' option to GCL when we startup
the Axiom image? And expect it to be executed before the
first prompt?

But Tim also suggests the use of .axiom.input. I guess
that would be ok if it was automatically installed.

> Bill, you have access to linux too, no?

Yes. In fact for the moment I am primarily working with
linux. (I can only take the frustrations of trying to
force Axiom to live with Windows for short periods...)

> Would be nice if you could report any readline functionality
> differences between the to ports, if any. 
> 

Well, I did observe that when I start GCL 2.6.1 on windows,
I don't have to do anything to start readline. So I guess
the (si::init-readline) got executed somehow but it is not
in the GCL.BAT startup file.

I'll let you know more once I actually see it work
under Linux.

\start
Date: Tue, 28 Oct 2003 12:03:10 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: libaldor

Ralf,

> Yes, I know. I don't expect that Axiom (sub-) programs can be
> extracted. What I am interested in is to use axiom as a front-end for
> my program.
> 
> Thus I will have add some functionality to my aldor domains (which
> are, in fact, developed without any axiom domain). Is there someone
> who has made some toy example available?

I don't know of any toy examples. There might be some documentation
in the NAG docs. I'll look tonight. If you're willing to email me 
your code I could look at it and suggest possible solutions.

> To make things easy, I want to build on as few axiom domains as
> possible but still want my program run inside axiom. So, in fact, I'd
> like to have the interpreter capabilities of axiom for my program.
> 
> Of course, I am willing to help to establish such a connection, but I
> guess, there were already others who have made such connections
> without using src/share/algebra/libaxiom.al.
> 
> How was libaxiom.al produced? Are there Aldor sources for it
> somewhere. Maybe I can find out the necessary things myself and create
> a sublibrary for my intended purpose.

I no longer remember exactly. But Aldor can generate .c files which
get compiled to .o files. I believe these are boxed up into a .a
library using ar. Aldor can also generate lisp files and these can
be used inside Axiom (which is just lisp). The algebra connection
is a fluffier subject and I'm going to have to do some behind-the-scenes
review about how that works exactly.

\start
Date: Tue, 28 Oct 2003 12:51:17 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: readline and axiom

Camm,

Is it usual for GCL to ouput a long stream of messages
following the

  (si::init-readline)

call? What I see when I start the --endable-static image
that was generated during the Axiom build after the
(si::init-readline) is

  starting address -T 0x86b04c0 Finished loading ... gcl_readline.o
  T
  "Gcl"
  1
  (":INTERN: ":STEP" .....

   etc. for about 200 lines of output or so

  ... "PUSH-OPTION-BINDING")

After which readline actually does behave as I had
hoped and allows me to edit.

Regards,
Bill Page.

On Tuesday, October 28, 2003 12:30 PM I wrote:
> 
> On Tuesday, October 28, 2003 12:03 PM you wrote:
> 
> > ... readline library must be initialized at runtime via
> > the lisp command:
> > 
> > (si::init-readline)
> > 
> ... 
> > Would be nice if you could report any readline functionality
> > differences between the to ports, if any. 
> > 
> 
> Well, I did observe that when I start GCL 2.6.1 on windows,
> I don't have to do anything to start readline. So I guess
> the (si::init-readline) got executed somehow but it is not
> in the GCL.BAT startup file.
> 
> I'll let you know more once I actually see it work
> under Linux.

\start
Date: Tue, 28 Oct 2003 18:58:19 +0100 (CET)
From: Ralf Hemmecke
To: Tim Daly
Subject: RE: libaldor

Dear Tim,

>> How was libaxiom.al produced?
 
> I no longer remember exactly. But Aldor can generate .c files which
> get compiled to .o files. I believe these are boxed up into a .a
> library using ar.

That is correct. My question was directed to the sources. There must
be some .as files somewhere which where used to produce libaxiom.a. 
>From them I could perhaps make a link and a corresponding description
available. At least I would like to have a look into it to see how
much work it would be.

> The algebra connection is a fluffier subject 

Since I don't need the axiom algebra, the connection to algebra
domains is not so important (at least not at the moment). Anyway, I
guess that connection from my private types to axiom algebra types is
just a matter of data conversion. I would do this when I see need for
it.

\start
Date: Tue, 28 Oct 2003 12:22:32 -0500
From: Tim Daly
To: Bill Page
Subject: clef

Bill,

Axiom's command-line editor (clef) has been recovered and works.  I'll
upload it tonight. Memory fails me and I haven't had time to look at
it deeply but I believe it can do things like function-name completion
in Axiom. As a side-effect the  mnt/linux/bin/axiom executable will
now become a shell script.

\start
Date: 28 Oct 2003 13:02:48 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: linux-static chunk

Greetings!

Tim Daly writes:

> In parallel I'll do a test build to see if gcl-2.6.1-16 works
> properly. If so we can delete the gcl-2.6.1 image and move the
> GCLVERSION variable to the -16 version.
> 

Great, please let me know if there are problems.

> Is gcl-2.6.1-16.tgz in the cvs?
> 

Yes.  In general, at least until ftp.gnu.org is again available, my
development procedure is to commit all changes either to the
Version_2_6_1 or HEAD CVS branch, then at some interval when an
important change is made, build and release the cvs tagged version as
a Debian package, which then automatically updates the temporary
website. 

\start
Date: 28 Oct 2003 13:00:09 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: linux-static chunk

Greetings!

Just a quick query and an observation --

Why would anyone want a static axiom?

Currently gcc warns about several c library functions used by gcl
which must be present in identical dynamic library form at runtime
even with the static image:

gcc -o raw_gcl  \
	-L.  -u __gmpn_toom3_mul_n -lgcl -static -lm  -lgmp /usr/lib/gcc-lib/i486-linux/3.3.2/../../../libbfd.a /usr/lib/gcc-lib/i486-linux/3.3.2/../../../libiberty.a -lreadline -lncurses -lc -lgclp
> /usr/lib/gcc-lib/i486-linux/3.3.2/../../../libreadline.a(complete.o)(.text+0x1c71): In function `rl_username_completion_function':
: warning: Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libgcl.a(unixfsys.o)(.text+0xc7): In function `coerce_to_filename':
: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libgcl.a(unixfsys.o)(.text+0x165): In function `coerce_to_filename':
: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc-lib/i486-linux/3.3.2/../../../libreadline.a(complete.o)(.text+0x1c62): In function `rl_username_completion_function':
: warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc-lib/i486-linux/3.3.2/../../../libreadline.a(complete.o)(.text+0x1d0d): In function `rl_username_completion_function':
: warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libgcl.a(nsocket.o)(.text+0x351): In function `fSgetpeername':
: warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
./libgcl.a(nsocket.o)(.text+0xa3f): In function `CreateSocketAddress':
: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

This would also seem to lessen any attractiveness in a static image.

Take care,


Tim Daly writes:

> I'm sure you already know this but I'll write it down anyway.
> The steps to take are:
> 
> A) CHANGES TO THE Makefile.pamphlet FILE:
> 
> *) copy the linux chunk and rename it to linux-static.
>     This will set up almost all of the appropriate variables. The chunk
>     that gets used is decided by the basename of the $AXIOM variable.
>     So to select this new chunk you would make the AXIOM variable be:
>   AXIOM=(yourpath)/axiom/mnt/linux-static
>     This will create a Makefile.linux-static and invoke it.
> 
> *) modify the linux-static chunk to include a new make variable 
>      Something like 
>    STATIC=--enable-static
> 
> *) add this variable to the ENV variable
>      This "passes" the variable down to the next level of Makefile
>      which in this case is the lsp/Makefile. The reason this works
>      is that you can generally set a shell variable on the same
>      commandline as the call to make and the shell variables will
>      be seen by the make. The change will look something like:
>    ENV= ...... STATIC=${STATIC}
> 
> *) hardcode the GCLVERSION variable in the linux-static chunk
>     GCLVERSION=gcl-2.6.1-static
> 
> *) add documentation to the new linux-static chunk to explain what
>    you are doing and why. 
> 
> *) run the document command on the top level Makefile.pamphlet thus:
>     SPAD=$AXIOM
>     PATH=$AXIOM/bin:$PATH
>     document Makefile     (don't add the .pamphlet)
> 
> B) CHANGES TO THE zips DIRECTORY
> 
> *) add the gcl-2.6.1-16.tgz to zips
> 
> *) copy the zips/gcl-2.6.1*.patch files to zips/gcl-2.6.1-16*.patch
> 
> *) cvs add gcl-2.6.1-16*
> 
> C) CHANGES TO THE lsp/Makefile.pamphlet FILE
> 
> *) modify the lsp/Makefile.pamphlet 
>      so that the GCL configure line include ${STATIC}. Normally this
>      will expand to the null string so it won't change the behavior
>      of the normal build. When invoked from the Makefile.linux-static
>      the STATIC variable will be defined and will expand to --enable-static.
> 
> *) document the change in the lsp/Makefile.pamphlet
> 
> D) CHANGES TO THE CHANGELOG FILE
> 
> *) add a comment to CHANGELOG
> 
> copy the whole pile, try a build, and when it works check it all in.
> 
> If you're really feeling ambitious you can go to www.testdrive.hp.com,
> sign up for a password, and try it on several linux variants. I already
> have a password so I'm likely to try it.

\start
Date: Tue, 28 Oct 2003 12:30:38 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: libaldor

Ralf,

Yes, there must be .as files somewhere corresponding to the libaldor
file. Unfortunately I don't believe these sources are available though
I may be wrong. Contact www.aldor.org and/or NAG for an authoritative 
answer.

Assuming you used libaldor it shouldn't be particularly hard to 
get it running in Axiom. Mostly I suspect it involves killing 
the semicolons :-)

\start
Date: Tue, 28 Oct 2003 12:34:20 -0500
From: Tim Daly
To: Camm Maguire
Subject: static axiom

Camm,

We have the usual struggle with dynamic libraries and their versions.
The idea was raised that if we could get Axiom build in a static
linked version we wouldn't have to deal with this issue.

glibc is likely to be installed on most machines but other libraries
appear not to be. Static linking may not solve all of the porting
issues but it might help.

\start
Date: Tue, 28 Oct 2003 13:15:00 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: linux-static chunk

Camm,

On Tuesday, October 28, 2003 1:00 PM you wrote:
> 
> Just a quick query and an observation --
> 
> Why would anyone want a static axiom?
> 
> Currently gcc warns about several c library functions used
> by gcl which must be present in identical dynamic library
> form at runtime even with the static image:
> 

Umm, well ...

The idea came originally (I think from Joris who says that
they produce a static version of TeXmacs for installation
on a wide range of linux machines, (i.e. no special library
dependencies to worry about).

But are you saying that this is *not* possible with GCL?

\start
Date: 28 Oct 2003 19:16:08 +0100
From: Juergen Weiss
To: list
Subject: Patch for algebra Makefile

With the following patch applied, I was able
to compile the algebra, generate a new
database and regenerate the algebra with the
new database. INTRVL and ODEEF should 
probably get compiled earlier. But at least
it works. 

Index: Makefile.pamphlet
===================================================================
RCS file: /cvsroot/axiom/axiom/src/algebra/Makefile.pamphlet,v
retrieving revision 1.3
diff -a -u -r1.3 Makefile.pamphlet
--- Makefile.pamphlet   24 Oct 2003 11:33:11 -0000      1.3
+++ Makefile.pamphlet   28 Oct 2003 18:09:07 -0000
@@ -1025,7 +1025,7 @@
 newpoint.spad.pamphlet (SUBSPACE)
 nregset.spad.pamphlet (NTSCAT)
 primelt.spad.pamphlet (FSPRMELT)
-regset.spad.pamphlet (REGSET RSETGCD)
+regset.spad.pamphlet (REGSET RSETGCD RSDCMPK)
 sregset.spad.pamphlet (SFRTCAT SRDCMPK SREGSET)
 sttf.spad.pamphlet (STTF)
 transsolve.spad.pamphlet (SOLVETRA)
@@ -1038,7 +1038,7 @@
   ${OUT}/FSPRMELT.o ${OUT}/INBFF.o    \
   ${OUT}/LODO.o     ${OUT}/LODO1.o    ${OUT}/LODO2.o    \
   ${OUT}/NTSCAT.o   ${OUT}/REGSET.o   \
-  ${OUT}/RGCHAIN.o  ${OUT}/RSETGCD.o  \
+  ${OUT}/RGCHAIN.o  ${OUT}/RSETGCD.o  ${OUT}/RSDCMPK.o \
   ${OUT}/SFRTCAT.o  ${OUT}/SIGNEF.o   ${OUT}/SNTSCAT.o  \
   ${OUT}/SOLVETRA.o ${OUT}/SRDCMPK.o  ${OUT}/SREGSET.o  ${OUT}/STTF.o     \
   ${OUT}/SUBSPACE.o ${OUT}/ZDSOLVE.o
@@ -1062,7 +1062,7 @@
 LAYER23=\
   ${OUT}/CPIMA.o    ${OUT}/IRURPK.o   ${OUT}/LAZM3PK.o  ${OUT}/LEXTRIPK.o \
   ${OUT}/NORMPK.o   ${OUT}/QCMPACK.o    ${OUT}/RURPK.o    ${OUT}/SFRGCD.o   \
-  ${OUT}/SFQCMPK.o  
+  ${OUT}/SFQCMPK.o  ${OUT}/INTRVL.o ${OUT}/ODEEF.o
 @
 \subsection{Order}
 The final order of the layers is determined here.


\start
Date: Tue, 28 Oct 2003 12:41:08 -0500
From: Tim Daly
To: David Mentre
Subject: Re: clef
Cc: Bill Page

David,

Ok. The executable will be mnt/linux/bin/AXIOMsys and
mnt/linux/bin/axiom will be a shell script again.

\start
Date: Tue, 28 Oct 2003 19:17:03 +0100
From: David Mentre
To: Tim Daly
Subject: Re: clef
Cc: Bill Page

Tim Daly writes:

> As a side-effect the mnt/linux/bin/axiom executable will now become a
> shell script.

Speaking of side-effects and TeXmacs interface, could you rename the
Axiom binary AXIOMsys or whatever the name was with NAG axiom? And in
general, could you follow the same naming convention that for the NAG
version?

It would allow Bill to provide only one tm_axiom TeXmacs/Axiom that
would support both the free Axiom and NAG one.

\start
Date: 28 Oct 2003 13:27:23 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: [Gcl-devel] RE: On statically linked Axiom	(was: static lisp and rpms)
Cc: Vadim V. Zhytnikov

Greetings!

Bill Page writes:

> Tim,
> 
> I have already completed a build with --enable-static.
> However to get things to work I did two things: 
> 
> 1) I replaced the gcl-2.6.1 tgz file in zips with the
> more recent gcl-2.6.1-16 source from Camm's temporary
> debian site. Since Camm had provided a patch in the
> new version to handle readline in the static case.
> 

Just a clarifification here -- my patch was to address certain
undefined symbols.  The readline/static issue I was referring to
before has not yet been to my knowledge definitively tested or
resolved.  I'm cc'ing the gcl developer who first reported this
problem.  

Take care,

> 2) I upgraded my gcc compiler to version 3.3.2 (the
> newest version) since other emails also indicated that
> there were possible problems with older versions of gcc.
> 
> It now seems to work. 
> 
> I was about to upload a binary to the files section for
> others to try (since I only have RedHat Linux boxes here,
> moving the static binary between them is not a real test),
> but then Juergen pointed out that we still have three
> missing algebra files, so I decided to include those files
> before uploading the new static binary.
> 
> I will also proceed as you suggest and modify the
> Makefile.pamphlet to include a linux-static chuck, however
> I have to think about this a bit more since the change to
> the GCL configuration option is done in the lsp/Makefile.
> So I think this means that it will have to be controlled
> by the GCLVERSION environment variable. E.g. maybe
> 
>   GCLVERSION=gcl-2.6.1-static
> 
> and then it will use that to pull the right chunk
> out of the lsp/Makefile.pamphlet. Right?
> 
> > 
> > Bill,
> > 
> > If you create a linux-static chunk in the top-level
> > Makefile.pamphlet then you can create the static image by
> > setting the Axiom varialble to:
> > 
> > export AXIOM=(yourpath)/axiom/mnt/linux-static
> > 
> > then we can try a static build of Axiom

\start
Date: Tue, 28 Oct 2003 13:37:52 -0500
From: William Sit
To: Tim Daly
Subject: Foreign language port
Cc: Bill Page, Joris van der Hoeven

Tim Daly wrote (linux-static chunk):
> 
> Bill,
> 
> Also of note is that the Red Flag Linux person has a deep
> interest in literate programming. Should be fun to add languages
> to the list of things to think about. There is no reason why the
> research work has to be in english.
> 
> Tim
Tim:

I think you have misunderstood my message (relevant portion quoted
below). Dr.  Nobuki Takayama (from Japan, Kobe University), I presume
is the person you refer to, is not involved as far as I know with the
Red Flag Linux project (which is Chinese).

According to the quoted reply from Nobuki, he is also interested in
(Texmacs?)  interface.

William
---
William Sit wrote to Tim:

> I returned to the States yesterday. I was fortunate that one of the
> scheduled speakers did not show up and so I took the slot to present
> Axiom, to a crowd of over 50 and I got a few enthusiastic
> response. Specifically, Prof. Nobuki Takayama, one of the two
> invited speakers who is not only a great mathematician on
> hypergeometric and special functions, but a very experienced
> programmer. You can easily look up his web page from google. He has
> been working for 10 years or more on KAN/SML and recently proposed
> and implemented a digital formula document format where annotations,
> references, proofs, etc are embedded (sort of like your literate
> programming, but using OpenMath, OpenML and XML). He is interested
> in the Axiom project and asked a lot of questions on who are
> currently involved.  I gave him a list of the recent developers
> (David, Camm, etc) and tell him to contact you. However, it may be
> better if you contact him first. His email address is: Nobuki
> Takayama. He also asked about the licensing
> and which lisp. I told him what I thought (modified BSD and GCL) and
> said you will be the one to give authentic answers. If you are
> writing him, please include the savannah site and how to download
> Axiom (I ran out of CD at the conference).  I also obtained
> (downloaded) a copy of Red Flag Linux server version 4.0. I burnt a
> CD and will give to you when I have the chance (possibly today). I
> have just installed the basic on a virtual machine. You probably
> won't be able to because it is in Chinese.  Red Flag linux is
> apparently the product of some company and the people at MMRC (the
> unit that sponsored the conference and my contacts) were all using
> Windows and do not seem to have enough people-power or interest in
> Red Flag linux (or perhaps even linux). I gave two copies of the CD
> to them. I think we (I?) have to contact the company, but I may have
> to learn how to input Chinese first (not an easy project)!  I think
> the Japanese can contribute more than the Chinese, at least for now.


Dear Prof. Tim Daly;
Thank you very much for your mail, which will help us to work on
writing an external interface for axiom.
Best Regards,  Nobuki

\start
Date: Tue, 28 Oct 2003 14:42:22 -0500
From: Bill Page
To: Juergen Weiss
Subject: RE: Patch for algebra Makefile

Juergen,

That is very good to hear.

I made a patch that was almost identical to yours below.
But things have not been kind to me. I am now using gcc
3.3.2 and the GCL .configure option --enable-static.

Earlier I was able to complete a compilation of all the
algebra except the three files that you mentioned in
your email using --enable-static. In spite of the missing
files, the static built version was able to run all of
the regression tests.

But when I made my patch to add the three files in almost
the same way that you have (except I did put INTRVL.o
in layer12 which seemed to be what Tim had planned),
unfortunately after a 6 hour compilation, the build
failed with an error when it tried to build the databases!
I get

    >> Sytem error:
    build error

  protected-symbol-warn called with (NIL)
  cp: cannot stat '/home/bpage/axiom-new/int/algebra/*.daase

There were no other errors reported.

So the apparently the make-databases failed. But oddly
I find if I manually copy the src/share/algebra/*.daase
databases into mnt/linus/algebra I do get what appears to
be a fully functional Axiom system.

Hmmm... I do not know the cause of this failure. There
now seem too many variables. :( However I expect it has
something to do with the --enable-static option.

Oh and BTW Tim and Camm, issuing )lisp (si::init-readline)
does make readline work. Aslo it only replied Value=T to me
and not all that other stuff I reported earlier.

> With the following patch applied, I was able
> to compile the algebra, generate a new
> database and regenerate the algebra with the
> new database. INTRVL and ODEEF should 
> probably get compiled earlier. But at least
> it works. 

\start
Date: 28 Oct 2003 15:19:26 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: readline and axiom

Greetings!

Bill Page writes:

> Camm,
> 
> Is it usual for GCL to ouput a long stream of messages
> following the
> 
>   (si::init-readline)
> 
> call? What I see when I start the --endable-static image
> that was generated during the Axiom build after the
> (si::init-readline) is
> 
>   starting address -T 0x86b04c0 Finished loading ... gcl_readline.o
>   T
>   "Gcl"
>   1
>   (":INTERN: ":STEP" .....
> 
>    etc. for about 200 lines of output or so
> 
>   ... "PUSH-OPTION-BINDING")
> 

This is normal for the current readline implementation.  The symbols
are those in the current package which could be available from
command-line completion.  We could silence this I imagine.

I'd be most interested if you find any instability (e.g. segfaults) in
a static readline build.

Take care,

> After which readline actually does behave as I had
> hoped and allows me to edit.
> 
> Regards,
> Bill Page.
> 
> On Tuesday, October 28, 2003 12:30 PM I wrote:
> > 
> > On Tuesday, October 28, 2003 12:03 PM you wrote:
> > 
> > > ... readline library must be initialized at runtime via
> > > the lisp command:
> > > 
> > > (si::init-readline)
> > > 
> > ... 
> > > Would be nice if you could report any readline functionality
> > > differences between the to ports, if any. 
> > > 
> > 
> > Well, I did observe that when I start GCL 2.6.1 on windows,
> > I don't have to do anything to start readline. So I guess
> > the (si::init-readline) got executed somehow but it is not
> > in the GCL.BAT startup file.
> > 
> > I'll let you know more once I actually see it work
> > under Linux.

\start
Date: Tue, 28 Oct 2003 15:26:23 -0500
From: Bill Page
To: Tim Daly
Subject: RE: readline and axiom
Cc: Camm Maguire

Tim,

A quick note:

  axiom -eval '(si::init-readline)'

(where the binary 'axiom' is the same as interpsys)
works just fine and readline works as expected right
from the first prompt. So I guess in the future
axiom could be a shell script that runs AXIOMsys (alias
interpsys) with the eval.

Now if readline is work, I am not sure what will happen
if we also implement Axiom's clef, but then clef is bsd
... maybe we don't need readline at all?

Thanks.

\start
Date: 28 Oct 2003 15:42:21 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: libaldor

Greetings!  Another minor issue reported by a Debian user (Igor Khavkine):

6 making /fix/g/camm/axiom/axiom-0.0.0cvs/mnt/linux/doc/DeveloperNotes.dvi from /fix/g/camm/axiom/axiom-0.0.0cvs/src/doc/DeveloperNotes.pamphlet

This does not produce a dvi file.

Also, the installation is missing the files referrred to by the
)summary and )copyright commands.

\start
Date: Tue, 28 Oct 2003 15:49:15 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: libaldor

I'll fix the summary, copyright issues tonight. -- Tim

\start
Date: 28 Oct 2003 21:56:35 +0100
From: Juergen Weiss
To: list
Subject: manexp

seems that the following definition for 
manexp gives resonable results on common lisp


#+(or :cmu :akcl)
(defun manexp (u)
  (multiple-value-bind (f e s) (decode-float u)
                       (list (* s f) e)))


\start
Date: Tue, 28 Oct 2003 16:05:05 -0500
From: Tim Daly
To: Juergen Weiss
Subject: Re: manexp

Juergen,

Where did you find a definition of manexp?
I can't even figure out what the function might mean from the name.

\start
Date: Tue, 28 Oct 2003 23:03:13 +0100 (CET)
From: Bertfried Fauser
To: list
Subject: compilation (SuSE 8.0)

Hi,

I tried to download axiom from the cvs and to compile it on a SuSE 8.0. I
get alsmost immediately and error since the noweb.zip files are not found.
Since I had deleted the whole ./axiom folder, I guess that I have
downloaded the very recent statut of teh cvs. Do I need to install noweg
(and what more manually or should it be comming with axiom)?

\start
Date: Tue, 28 Oct 2003 16:25:35 -0500
From: Tim Daly
To: Bertfried Fauser
Subject: Re: compilation (SuSE 8.0)

Bertfried,

The noweb file is zips/noweb-2.10a.tgz. It is automatically unpacked
into place and patches are applied. If this file isn't in your zips
directory then your cvs co failed. I downloaded a clean version of
this file so it is certainly in the cvs.

One other symptom that causes an early failure is an incorrect setting
of the AXIOM variable. It should be:

AXIOM=(yourpath)/axiom/mnt/linux

Let me know if this helps.

\start
Date: 28 Oct 2003 16:04:20 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: GCL 2.6.1 on Windows XP
Cc: Bill Page

Hi Tim!

Tim Daly writes:

> Your list:
> 
> These are gone:
> 
> lsp/Makefile.dvi 
> src/algebra/Makefile.dvi 
> src/input/Makefile.dvi 
> src/Makefile.dvi 
> src/interp/Makefile.dvi 
> src/doc/Makefile.dvi
> 

Thanks!

> These should never be in the "distribution" which should only contain 
> files in the mnt directory. The obj and int directories can be deleted
> at any time. They are only caches.
> 
> obj/noweb/contrib/kostas/Makefile 
> obj/noweb/src/c/notangle.o 
> obj/noweb/src/c/getline.o 
> obj/noweb/src/c/match.o 
> obj/noweb/src/c/modules.o 
> obj/noweb/src/c/modtrees.o 
> obj/noweb/src/c/strsave.o 
> obj/noweb/src/c/main.o 
> obj/noweb/src/c/errors.o 
> obj/noweb/src/c/columns.o 
> obj/noweb/src/c/nt 
> obj/noweb/src/c/markmain.o 
> obj/noweb/src/c/markup.o 
> obj/noweb/src/c/markup 
> obj/noweb/src/c/mnt.o 
> obj/noweb/src/c/mnt 
> obj/noweb/src/c/finduses.o 
> obj/noweb/src/c/recognize.o 
> obj/noweb/src/c/finduses 
> 

OK, I guess the point was that the clean target of the Makefile does
not remove these files, at least at the time of my earlier message.

> These are used by noweb. In particular, the document command will
> invoke nt and markup. 
> 
> mnt/bin/lib/nt 
> mnt/bin/lib/markup 
> mnt/bin/lib/mnt 
> mnt/bin/lib/finduses 
> 

Again, I think these are generated by the build, and can/should be
removed by 'clean'.

> I'll look into these. There shouldn't be Makefiles in mnt.
> 
> mnt/bin/Makefile.dvi 
> 

Thanks.

> This should remain. It is the primary documentation root and
> needs to be available to users before the build. It is essentially
> the top level "README" 
> 
> Makefile.dvi 
> 

As a suggestion, could you provide this in .tex format instead?  At
least for Debian packages, changes in binary files like .dvi files
cannot be represented in a diff, so everytime this file changes, if I
leave it in the package, I have to increment the "upstream" package
number and install the *whole* original source tree tarball as a
separate version in the Debian archives.  I.e., multiple axiom
tarballs installed in their entirety perhaps diffing only in this
file. 

BTW, do you have a suggestion for the "upstream" axiom version number
used in the Debian package?  Right now I'm using 0.0.0cvs.


> I'm confused. You siad: "need to be executable" but you wrote: "chmod -x"
> which will remove the execution bit.
> 

My bad -- Debian policy is that all files installed with executable
permissions should be elf or scripts.  These files are neither, and so
I am as you note removing the x permission.  Perhaps you could also in
the CVS?

> This part of noweb and is an internal command
> ./mnt/linux/bin/lib/nwmtime 
> 

executable?

> These are TeX macros not user commands and can't be executed.
> 
> ./mnt/linux/bin/tex/axiom.sty 
> ./mnt/linux/bin/axiom.sty 
> 
> These are the components of the boxup command which works as follows:
> 
> boxup foo
> 
> rename foo to foo.org
> concatenate head, foo, and tail (in that order) into foo.pamphlet,
> run notangle to extract foo from foo.pamphlet,
> diff foo and foo.org to ensure that 
> 
> ./mnt/linux/bin/boxup 
> ./mnt/linux/bin/head
> ./mnt/linux/bin/tail 
> 

OK, these sound like executables too.

> These will go away:
> 
> ./mnt/linux/bin/Makefile 
> ./mnt/linux/bin/Makefile.pamphlet 
> 

OK

> These are Axiom internal data files, not scripts
> 
> ./mnt/linux/algebra/topics.data 
> ./mnt/linux/doc/msgs/s2-us.msgs 
> ./mnt/linux/algebra/gloss.text
> 

OK, so perhaps a chmod -x in CVS?

> 
> I have no idea what this does:
> ./mnt/linux/bin/htmltoc 
> 

OK, but sounds like an executable.

> This was a feeble attempt at document support. Texmacs and ADVI
> extensions will eventually do better.
> 
> ./mnt/linux/bin/showdvi 
> 

OK, sounds like an executable.

\start
Date: Tue, 28 Oct 2003 16:27:57 -0500
From: Bill Page
To: Camm Maguire
Subject: re: GCL 2.6.1 on Windows XP

On Tuesday, October 28, 2003 4:04 PM
Camm Maguire Camm Maguire wrote:
> Tim Daly wrote:
> > 
> > These are the components of the boxup command which
> > works as follows:
> > 
> > boxup foo
> > 
> > rename foo to foo.org
> > concatenate head, foo, and tail (in that order) into foo.pamphlet,
> > run notangle to extract foo from foo.pamphlet,
> > diff foo and foo.org to ensure that 
> > 
> > ./mnt/linux/bin/boxup 
> > ./mnt/linux/bin/head
> > ./mnt/linux/bin/tail 
> > 
> 
> OK, these sound like executables too.
>

As far as I can tell Tim, these little scripts were only
useful to you during the intial conversion of .spad to
.spad.pamphlet. They can be deleted, no? Especially,
because we are going to reference mnt/linux/bin in $PATH,
I don't think you should use names like head and tail
which conflict with standard unix filters.

\start
Date: Tue, 28 Oct 2003 22:15:19 +0100
From: Juergen Weiss
To: Tim Daly
Subject: RE: manexp

Mantissa and Exponent. Arthur Norman pointed me
to the definition in CSL (arith06.c) in terms of
the C function frexp.

> Juergen,
> 
> Where did you find a definition of manexp?
> I can't even figure out what the function might mean from the name.

\start
Date: Tue, 28 Oct 2003 17:20:17 -0500
From: Tim Daly
To: Camm Maguire
Subject: re: GCL 2.6.1 on Windows XP

Camm,

The clean target of the Makefile eventually removes all of int and obj.
Individual clean stanzas in Makefiles need not care. I eventually plan
to allow individual directories to be built (the so-called PART function).
It used to be the case that you could say make PART=doc and it would only
build the doc directory and any required parts (e.g. noweb). It is too
early to introduce that ability but as I continue to introduce new parts
of Axiom we will need it. At that time I'll make sure the "clean" works.

> As a suggestion, could you provide this in .tex format instead?  At
> least for Debian packages, changes in binary files like .dvi files
> cannot be represented in a diff, so everytime this file changes, if I
> leave it in the package, I have to increment the "upstream" package
> number and install the *whole* original source tree tarball as a
> separate version in the Debian archives.  I.e., multiple axiom
> tarballs installed in their entirety perhaps diffing only in this
> file. 

Ummm, maybe. I plan to update the README file tonight. I'll consider
splitting out the non-Makefile related stuff into the README and 
then have the .dvi file autoconstructed. I'll see what I can do.

> BTW, do you have a suggestion for the "upstream" axiom version number
> used in the Debian package?  Right now I'm using 0.0.0cvs.

I'm unhappy with the version 3.1.4.1.5.9.2.6.5 kind of numbering scheme
as it is completely content-free. I much prefer a date-based format such
as YYYYMMDDxxx where xxx is an incrementing number for events on the same
day. If Debian wants dotted-decimal format I suppose we could use
2003.10.28 or some such. If that still isn't ok then feel free to invent
one.

I'm torn about removing the boxup commands. They provide a standard
head and tail to functions and catch bad pamphlet files. I guess I'll
leave them there for now.

I'll chmod -x these:

> These are Axiom internal data files, not scripts
> 
> ./mnt/linux/algebra/topics.data 
> ./mnt/linux/doc/msgs/s2-us.msgs 
> ./mnt/linux/algebra/gloss.text

\start
Date: Tue, 28 Oct 2003 17:22:43 -0500
From: Tim Daly
To: Bill Page
Subject: re: GCL 2.6.1 on Windows XP
Cc: Camm Maguire

Bill,

The boxup command is still quite useful as it provides a standard header
and trailer for files and checks for bad pamphlet files. I'm still using
it (used it today for clef) so I'll keep it hanging around for now.
The head and tail files are just text. I'll rename them.

\start
Date: Tue, 28 Oct 2003 17:34:39 -0500
From: Bill Page
To: Tim Daly
Subject: RE: manexp

Tim,

manexp is defined in domain DFLOAT (sf.spad.pamphlet)
as

  manexp:% -> Record(MANTISSA:Integer,EXPONENT:Integer)

except for some special cases it is given in terms of

  MANEXP(x)$Lisp

which is unfortunately apparently not to be found in
the common lisp specs?

Hence Juergen's definition

  (defun manexp (u)
  (multiple-value-bind (f e s) (decode-float u)
                       (list (* s f) e)))

But where should it go? And why doesn't the Axiom
build complain about it's absence?

> Juergen,
> 
> Where did you find a definition of manexp?
> I can't even figure out what the function might mean from the name.

\start
Date: 28 Oct 2003 23:45:31 +0100
From: Juergen Weiss
To: list
Subject: acot function

The missing arcus cotangens function

;; stolen from csl
#+(or :cmu :akcl)
(defun acot (a)
  (if (>= a 0.0)
      (if (> a 1.0)
          (atan (/ 1.0 a))
        (- (/ pi 2.0) (atan a)))
    (if (< a -1.0)
        (- pi (atan (/ -1.0 a)))
      (+ (/ pi 2.0) (atan (- a))))))


\start
Date: Tue, 28 Oct 2003 17:26:19 -0500
From: Tim Daly
To: Juergen Weiss
Subject: Re: manexp

Juergen,

I've added the MANEXP definition and am testing it now.
Thanks.

\start
Date: Tue, 28 Oct 2003 17:37:48 -0500
From: Tim Daly
To: Bill Page
Subject: Re: manexp

Bill,

It has been inserted into vmlisp.lisp.pamphlet.
This is lisp so missing functions are never noted unless you try to 
execute them. I'm building a test image now and I'll run the test cases
against it.

\start
Date: 29 Oct 2003 00:06:54 +0100
From: Juergen Weiss
To: list
Subject: get-current-directory

another missing function

#+:cmu
(defun get-current-directory ()
  (namestring (extensions::default-directory)))

#+:akcl
(defun get-current-directory ()
  (namestring (truename "")))

\start
Date: Tue, 28 Oct 2003 20:38:29 -0500
From: Bill Page
To: "'Camm Maguire'" <Camm Maguire>
Subject: RE: On statically linked Axiom

Camm, et al.

Well I guess I was too optimistic about building
Axiom with GCL --enable-static. After a day of
running the cpu around the whole build cycle
several times and in several different ways, I am
still not (quite) able to complete a build of Axiom
using the .configure --enable-static option. I am
working with gcc 3.3.2 on Linux 8.0 and GCL-2.6.1-16.

In fact, the Axiom build proceeds to very near
completion. Having added three missing files to
the build since my last successful attempt, the
Axiom build now stalls during the make-databases
stage - the very last stage before finishing normally.
This seems quite odd to me since at the time the
build goes into an infinite loop, it is just loading
NRLIB/code - not compiling. I tried doubling the
vssize and maxpage parameters but that seemed to
have no effect.

It turns out that I *can* manually canel and override
this last step and simply copy the old databases files
into the new run-time and all seems to work well and the
resulting Axiom system even runs all of it's regression
tests in the same way as the non-static build (though
it is still not be able to re-build it's own databases).

I am now certain that the problem is related to the
--enable-static option since I am able to repeatably
remove this option and have the build complete entirely
normally. Whether I then update the databases to the
newly built ones or not, as soon as I return to
--enable-static, a re-build of Axiom will again fail
at the same point (loading BBTREE.NRLIB/code).

So I am about to give on this for now. But I do have
one or two final quesitions:

1) Do you think that it would it be worthwhile to
attempt this using the unstable development branch
version GCL 2.7.1? Are there changes in 2.7.1 that
might have subtle effects on a static GCL?

2) What about the choice of versions of gcc? Was
my approach to upgrade to the most recent gcc 3.3.2
a good decision or is there an earlier gcc version
that might be happier building static binaries? Are
there libraries besides the ones in gcc that should
also be upgraded?

3) And this more to the Axiom developers: Do you
think there would be any point in my uploading the
binary part of the static build even though the database
build did not complete normally? The possible advantage
(maybe) would be that we might have a chance to see
if this approach of a static build will provide a
single binary that could be run on a larger number of
linux platforms.

\start
Date: Tue, 28 Oct 2003 21:25:40 -0500
From: Tim Daly
To: Bill Page
Subject: Re: On statically linked Axiom
Cc: Camm Maguire

Bill,

You've had a painful day I see. 

I can think of no reason why the build should hang loading files.

If you put the static image somewhere I can reach I'll try
it on the hp testdrive machines. 

\start
Date: Tue, 28 Oct 2003 22:10:51 -0500
From: Bill Page
To: Tim Daly
Subject: RE: On statically linked Axiom
Cc: Camm Maguire

Tim,

Well, I've had worse ... <grin> Actually it seemed
like quite a productive day as far as Axiom goes.

Thanks for the offer to test drive the static
version. I am very curious about it.

I have uploaded it to the files section at

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

see

  Axiom_Run

> You've had a painful day I see. 
> 
> I can think of no reason why the build should hang loading
> files.
> 
> If you put the static image somewhere I can reach I'll try
> it on the hp testdrive machines. 

\start
Date: Tue, 28 Oct 2003 22:43:49 -0500
From: Tim Daly
To: list
Subject: changes

*,

manexp, acot, and get-current-directory lisp functions added (Juergen)
mnt/linux/doc/DeveloperNotes.dvi is now a dvi file (Camm)
head and tail are now boxhead, boxtail (Bill)
the startup msgs are cleaner (me)
summary, copyright exist and work (Camm, David)
more input tests run (me)
rename r2.*.input.pamphlet to r2*.input.pamphlet (me)
expanded README (Camm)
removed Makefile.dvi (Camm)
added RSDCMPK, INTRVL, ODEEF (Juergen, David)
added Clef (Bill)
expanded DeveloperNotes (me)

clef still needs to be enabled. To do that I have to change
axiom to a shell script and that isn't done yet.

A couple of the input files are still failing. Check 
src/input/Makefile.pamphlet and look for VALUESTACK.

Virtually all of the MANEXP failures are now errors of the form:
Error: (7) is not of type NUMBER
which leads me to believe that the MANEXP definition is somewhat amiss.

The GET-CURRENT-DIRECTORY bug has been solved.
The ACOT bug has been solved but now COT is undefined.

ODEEF's test file ode.input fails


I'll check these changes in soon. I want to rebuild from scratch
once more to make sure they work. Paranoia, yaknow?

\start
Date: Wed, 29 Oct 2003 10:46:26 +0100
From: Juergen Weiss
To: list
Subject: RE: changes

Sorry, my fault. I did not have any testcases from
axiom. MANEXP should return a cons, not a list.
So please exchange list with cons.

> *,
> 
> manexp, acot, and get-current-directory lisp functions added (Juergen)
> mnt/linux/doc/DeveloperNotes.dvi is now a dvi file (Camm)
> head and tail are now boxhead, boxtail (Bill)
> the startup msgs are cleaner (me)
> summary, copyright exist and work (Camm, David)
> more input tests run (me)
> rename r2.*.input.pamphlet to r2*.input.pamphlet (me)
> expanded README (Camm)
> removed Makefile.dvi (Camm)
> added RSDCMPK, INTRVL, ODEEF (Juergen, David)
> added Clef (Bill)
> expanded DeveloperNotes (me)
> 
> clef still needs to be enabled. To do that I have to change
> axiom to a shell script and that isn't done yet.
> 
> A couple of the input files are still failing. Check 
> src/input/Makefile.pamphlet and look for VALUESTACK.
> 
> Virtually all of the MANEXP failures are now errors of the form:
> Error: (7) is not of type NUMBER
> which leads me to believe that the MANEXP definition is 
> somewhat amiss.
> 
> The GET-CURRENT-DIRECTORY bug has been solved.
> The ACOT bug has been solved but now COT is undefined.
> 
> ODEEF's test file ode.input fails
> 
> 
> I'll check these changes in soon. I want to rebuild from scratch
> once more to make sure they work. Paranoia, yaknow?

\start
Date: Wed, 29 Oct 2003 07:35:39 -0500
From: Tim Daly
To: Juergen Weiss
Subject: Re: changes

Juergen,

The "is not a NUMBER" tests all succeed with your new fix. Thanks.
COT and ASEC are undefined.

\start
Date: Wed, 29 Oct 2003 07:29:17 -0500
From: Tim Daly
To: Juergen Weiss
Subject: Re: changes

no problem. i'm rerunning the tests now.

any chance you can find a definition for COT?

\start
Date: 29 Oct 2003 07:43:25 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: [Gcl-devel] RE: On statically linked Axiom

Greetings!

Well, while I can't imagine anything in the loader which would
infinite loop, this is the only place in the gcl code relevant to the
experience you report below (sfaslbfd.c).

Neither 2.7.0 nor other gcc version is likely to help.  The debugging
steps are to run a 'nm' on the object file failing to load, an nm on
the image failing to do the loading, and to make sure no unknown
symbol was written into the .o.  Then run in gdb, with the build
having the --enable-debug flag set, and step through the loop in
fasload where the bfd_relocate_section_contents call is made to see
what's happening.

>From what you report, I'd expect a simple fix to present itself
readily, like the recent patch from -15 to -16.  As to my earlier
comment regarding the gcc linker warnings in writing raw_gcl, I
believe these refer to a few C library routines used by gcl which do
the equivalent of a dlopen anyway -- I imagine they are rarely used,
and we could in principle disable them if needed (for extra safety)
when the --enable-static option is selected. So in principle there
should be nothing which would absolutely stand in the way of a static
build if/when desired. 

If this is important to axiom, please let me know, and I'll try to
debug the build myself.

Take care,

Bill Page writes:

> Camm, et al.
> 
> Well I guess I was too optimistic about building
> Axiom with GCL --enable-static. After a day of
> running the cpu around the whole build cycle
> several times and in several different ways, I am
> still not (quite) able to complete a build of Axiom
> using the .configure --enable-static option. I am
> working with gcc 3.3.2 on Linux 8.0 and GCL-2.6.1-16.
> 
> In fact, the Axiom build proceeds to very near
> completion. Having added three missing files to
> the build since my last successful attempt, the
> Axiom build now stalls during the make-databases
> stage - the very last stage before finishing normally.
> This seems quite odd to me since at the time the
> build goes into an infinite loop, it is just loading
> NRLIB/code - not compiling. I tried doubling the
> vssize and maxpage parameters but that seemed to
> have no effect.
> 
> It turns out that I *can* manually canel and override
> this last step and simply copy the old databases files
> into the new run-time and all seems to work well and the
> resulting Axiom system even runs all of it's regression
> tests in the same way as the non-static build (though
> it is still not be able to re-build it's own databases).
> 
> I am now certain that the problem is related to the
> --enable-static option since I am able to repeatably
> remove this option and have the build complete entirely
> normally. Whether I then update the databases to the
> newly built ones or not, as soon as I return to
> --enable-static, a re-build of Axiom will again fail
> at the same point (loading BBTREE.NRLIB/code).
> 
> So I am about to give on this for now. But I do have
> one or two final quesitions:
> 
> 1) Do you think that it would it be worthwhile to
> attempt this using the unstable development branch
> version GCL 2.7.1? Are there changes in 2.7.1 that
> might have subtle effects on a static GCL?
> 
> 2) What about the choice of versions of gcc? Was
> my approach to upgrade to the most recent gcc 3.3.2
> a good decision or is there an earlier gcc version
> that might be happier building static binaries? Are
> there libraries besides the ones in gcc that should
> also be upgraded?
> 
> 3) And this more to the Axiom developers: Do you
> think there would be any point in my uploading the
> binary part of the static build even though the database
> build did not complete normally? The possible advantage
> (maybe) would be that we might have a chance to see
> if this approach of a static build will provide a
> single binary that could be run on a larger number of
> linux platforms.

\start
Date: 29 Oct 2003 14:35:25 +0100
From: Juergen Weiss
To: list
Subject: cot and asec

Here the lisp version of the C versions in csl
One problem: the formula may work for real arguments
only.


;; stolen from csl
#+(or :cmu :akcl)
(defun cot (a)
  (if (or (> a 1000.0) (< a -1000.0))
      (/ (cos a) (sin a))
    (/ 1.0 (tan a))))

;; stolen from csl
#+(or :cmu :akcl)
(defun asec (a)
  (if (and (a > -1.0) (a < 1.0))
      0.0
    (acos (/ 1.0 a))))

Date: Wed, 29 Oct 2003 14:28:24 +0000
From: Mike Dewar
To: Ralf Hemmecke
Subject: RE: libaldor

On Tue, Oct 28, 2003 at 06:58:19PM +0100, Ralf Hemmecke
wrote:
> >> How was libaxiom.al produced?
>  
> > I no longer remember exactly. But Aldor can generate .c files which
> > get compiled to .o files. I believe these are boxed up into a .a
> > library using ar.
> 
> That is correct. My question was directed to the sources. There must
> be some .as files somewhere which where used to produce libaxiom.a. 
> >From them I could perhaps make a link and a corresponding description
> available. At least I would like to have a look into it to see how
> much work it would be.
libaxiom.al is a "mock" library to allow you to compile Aldor code which
will run inside Axiom.  It contains equivalent definitions of all the
Axiom types which IIRC are created by first making Axiom generate ".ax"
files for each Axiom constructor, then converting those to ".ao" files
using Aldor, then making them into a library using "ar".  The ".ax"
files contain Lisp representations of the signatures of the
constructor's exports.  All the code for doing this was in the src/as
directory I sent to Tim when we open-sourced Axiom.

> > The algebra connection is a fluffier subject 
> 
> Since I don't need the axiom algebra, the connection to algebra
> domains is not so important (at least not at the moment). Anyway, I
> guess that connection from my private types to axiom algebra types is
> just a matter of data conversion. I would do this when I see need for
> it.
If you want to run your code inside Axiom then you just need to compile
against libaldor and )lib it.

We did some experiments with running Aldor code in a "clean" Axiom
interpreter (i.e. one with no algebra and no databases).  This didn't
really work because the interpreter code is riddled with assumptions
about the existence of particular constructors and operations.  It could
probably be made to work with a bit of effort however.

\start
Date: Wed, 29 Oct 2003 11:26:56 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: libaldor sources
Cc: Mike Dewar

It appears that I have the sources... somewhere.
I'll look for them tonight.
I haven't explored the Aldor connection yet.

\start
Date: Wed, 29 Oct 2003 19:01:59 +0100
From: David Mentre
To: Bertfried Fauser
Subject: Re: compilation (SuSE 8.0)

Hello Bertfried,

Bertfried Fauser writes:

> I tried to download axiom from the cvs and to compile it on a SuSE 8.0. I
> get alsmost immediately and error since the noweb.zip files are not found.

What is the content of your AXIOM environment variable?

\start
Date: Wed, 29 Oct 2003 13:16:18 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: [Gcl-devel] RE: On statically linked Axiom

Camm,

Thanks for the describing the debugging approach.
I do not (yet) feel familiar enough with these tools
to do what you suggest. As time permits, I may be able
to attempt this. I am not really sure how important this
is to the Axiom project as such, unless it should turn
out that static builds really can be run on a large
number of platforms without re-building... I consider
the current attempt as simply an experiment. Perhaps
Tim can comment further.

Anyway, last night I ran yet another clean re-build with
up to date Axiom sources and the --enable-static option
on GCL. As before, it ran all the way through until the
final make-databases step, but then after doing the
autoloads I got the following messages:

  ...
  Loading /home/bpage/axiom-new/mnt/linux/autoload/br-saturn.

Unrecoverable error: mark botch.
make [3]: *** [db] Error 134
make [3]: Leaving directory '/home/bpage/axiom-new/src/algebra'

...

Now a quick search of the Axiom and GCL source reveals that
the error message 'mark botch' comes from either

  o/gbc.c

or

  o/sgbc.c

in GCL. I presume that this is telling me something about
a garbage collection error?

I guess that this might explain why this error message is
different than the behaviour I saw yesterday but occurs at
roughly the same point in the Axiom build.

The only thing that I did different in this most recent
build was to remove the --enable-vssize --enable-maxpage
and --enable-statsysfd from the .configure. In fact the
configure statement is just

  ./configure --enable-static

So far as I can tell, the other options specified in the
current Axiom lsp/Makefile.pamphlet are either unnecessary
or defaults. I would expect a more explicit message from
GCL if we reached any of these limits or had a conflicting
choice of options. But I am rather unclear about this, so
of course let me know if I am wrong ...

So, were too from here? I feel even less certain about
debugging GCL garbage collection then I do about hunting
for undefined symbols. <grin>

> Greetings!
> 
> Well, while I can't imagine anything in the loader which
> would infinite loop, this is the only place in the gcl code
> relevant to the experience you report below (sfaslbfd.c).
> 
> Neither 2.7.0 nor other gcc version is likely to help.  The
> debugging steps are to run a 'nm' on the object file failing to
> load, an nm on the image failing to do the loading, and to make
> sure no unknown symbol was written into the .o.  Then run in
> gdb, with the build having the --enable-debug flag set, and
> step through the loop in fasload where the
> bfd_relocate_section_contents call is made to see
> what's happening.
> 
> From what you report, I'd expect a simple fix to present itself
> readily, like the recent patch from -15 to -16.  As to my earlier
> comment regarding the gcc linker warnings in writing raw_gcl,
> I believe these refer to a few C library routines used by gcl
> which do the equivalent of a dlopen anyway -- I imagine they are
> rarely used, and we could in principle disable them if needed
> (for extra safety) when the --enable-static option is selected.
> So in principle there should be nothing which would absolutely
> stand in the way of a static build if/when desired. 
> 
> If this is important to axiom, please let me know, and I'll
> try to debug the build myself.

\start
Date: Wed, 29 Oct 2003 13:20:50 -0500
From: Bill Page
To: David Mentre
Subject: RE: compilation (SuSE 8.0)

David, Tim;

I find this use of the AXIOM environment variable
awkward and confusing. Wouldn't it be better simply
to provide SYS as part of the make command and have
make set up the required environment? E.g.

  make linux

> Hello Bertfried,
> 
> Bertfried Fauser writes:
> 
> > I tried to download axiom from the cvs and to compile it
> > on a SuSE 8.0. I get alsmost immediately and error since
> > the noweb.zip files are not found.
> 
> What is the content of your AXIOM environment variable?

\start
Date: Wed, 29 Oct 2003 13:17:15 -0500
From: Tim Daly
To: Bill Page
Subject: Mark Botch

Bill,

Try:

make SPD=`pwd` SYS=linux

\start
Date: Wed, 29 Oct 2003 13:14:47 -0500
From: Tim Daly
To: Bill Page
Subject: Mark Botch

Bill,

Guffaw. I owe you. One of my old areas of expertise is memory
management and I spent quite a while talking to Bill Schelter
about akcl garbage collection. One of the phases of garbage
collection is called the "mark" phase where you mark all of
the "live" objects (then you collect the dead objects and
reclaim memory). The error message is "mark botch". I got it
so often that I adopted the pseudonym of "Mark Botch" when
writing to Bill.

Clearly the garbage collector is unhappy. I'll look at the
code and see if I can figure out why.

\start
Date: Wed, 29 Oct 2003 14:40:07 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Mark Botch

Tim,

Yes, I like that better. But it will not correctly
set the AXIOM environment variable, will it? Later
on in the build it seems to me that it will fail (or
doing something unpredictable) if AXIOM is not set
correctly.

Bill Page.

> Bill,
> 
> Try:
> 
> make SPD=`pwd` SYS=linux

\start
Date: Wed, 29 Oct 2003 14:40:43 -0500
From: Tim Daly
To: Bill Page
Subject: Mark Botch

Bill,

The latest CVS has "make install" but it is not complete.
I can't decide how to put the Axiom shell script on your PATH.
If the "make install" knows the install location and the SYS type
we can modify the Axiom script to automatically set the AXIOM 
variable. 

I have to figure out how other systems handle this problem.

\start
Date: Wed, 29 Oct 2003 15:39:23 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Mark Botch

Tim,

I think

  make install

usually installs to a directory that is already
in (or expected to be in) the user's path. E.g.
/usr/local/bin ... etc. This directory is specified
during the ./configure or defaulted. Thus the
install often requires root priveleges.

In many packages it is possible for a user to run
the built application without an install, but of
course then the user must expect to modify their
path manually or at least cd to the appropriate
bin directory first. E.g.

  cd axiom/mnt/linux/bin
  axiom

So I guess the best thing would be to have the
build initially set

  export AXIOM=${SPAD}/mnt/${SYS}

and also copy it into the mnt/linux/bin/axiom script
so that the user could run without installing.

Then during

  make install

the entire mnt/linux/bin directory could be copied
to the final target install directory and the 'axiom'
script could be updated with the correct location
and stored in the target directory.

At least I think that's how it usually goes ...

> Bill,
> 
> The latest CVS has "make install" but it is not complete.
> I can't decide how to put the Axiom shell script on your PATH.
> If the "make install" knows the install location and the SYS type
> we can modify the Axiom script to automatically set the AXIOM 
> variable. 
> 
> I have to figure out how other systems handle this problem.

\start
Date: 29 Oct 2003 17:44:17 -0500
From: Camm Maguire
To: Tim Daly
Subject: Recent Debian package release

Greetings!  Just released another Debian package of the latest CVS,
and ran into a problem which will affect ia64, mips, and alpha, all of
which built axiom until recently.  These platforms relocate/load
objects using dlopen (pending a bfd enabling patch possible in
principle), and the build has hit the limit of the maximum number of
open files (1024).  Is there any intermediate image which could be
built with the objects preloaded which would minimize the number of
load attempts made later in the build?

This is perhaps the chief weakness of the dlopen relocation option vis
a vis the bfd or custom relocation option.

Take care,

Tim Daly writes:

> Bill,
> 
> Guffaw. I owe you. One of my old areas of expertise is memory
> management and I spent quite a while talking to Bill Schelter
> about akcl garbage collection. One of the phases of garbage
> collection is called the "mark" phase where you mark all of
> the "live" objects (then you collect the dead objects and
> reclaim memory). The error message is "mark botch". I got it
> so often that I adopted the pseudonym of "Mark Botch" when
> writing to Bill.
> 
> Clearly the garbage collector is unhappy. I'll look at the
> code and see if I can figure out why.

\start
Date: 29 Oct 2003 20:24:25 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Mark Botch
Cc: Bill Page

:-)

(wondering what neat pseudonym still left for me to claim...)

Just a quick note to state that a significant gbc leak was plugged
some months ago due to a report by an acl2 user, which involved the
interaction of contiguous page garbage collection and SGC toggling.
Object modules are loaded into contiguous pages.  Wondering if there
is any significant size difference with --enable-static.  Wondering
also if axiom uses sgc.  Only time I've ever seen a mark botch is when
heap memory somehow gets allocated past heap_end and into either the
hole or the relocatable block section.  It may be useful to recall
that GCL memory is organized into non-relocatable pages of various
types below heap_end, then a hole of size holesize, then a relocatable
block section up to core_end, which can be extended up to maxpages.

I must say I haven't seen anything like this in ages -- the gbc has
been extremely stable since I've worked on gcl save for the one leak
mentioned above.  Of course I'd be most appreciative of any uncovering
of a bug in this area.

Take care,


Tim Daly writes:

> Bill,
> 
> Guffaw. I owe you. One of my old areas of expertise is memory
> management and I spent quite a while talking to Bill Schelter
> about akcl garbage collection. One of the phases of garbage
> collection is called the "mark" phase where you mark all of
> the "live" objects (then you collect the dead objects and
> reclaim memory). The error message is "mark botch". I got it
> so often that I adopted the pseudonym of "Mark Botch" when
> writing to Bill.
> 
> Clearly the garbage collector is unhappy. I'll look at the
> code and see if I can figure out why.

\start
Date: Thu, 30 Oct 2003 08:50:43 +0100 (CET)
From: Bertfried Fauser
To: list
Subject: Re: compilation (SuSE 8.0)

On Tue, 28 Oct 2003, Tim Daly wrote:

Hi,

sorry for my compiling ignorance, but I just wished to have a newly build
axiom, perhaps I should use the compiled version, however...

> The noweb file is zips/noweb-2.10a.tgz.

This file is in place and loos OK

> One other symptom that causes an early failure is an incorrect setting
> of the AXIOM variable. It should be:
>
> AXIOM=(yourpath)/axiom/mnt/linux

I have set this variable

Compilation fails nevetheless....

13 making noweb
tar: /home/axiomgnu/new/zips/noweb-2.10a.tgz: Cannot open: No such file or
directory
tar: Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error exit delayed from previous errors
/bin/sh: cd: /home/axiomgnu/new/obj/noweb/src: No such file or directory
/bin/sh: ./awkname: No such file or directory
/bin/sh: cd: /home/axiomgnu/new/obj/noweb/src/c: No such file or directory
cp: cannot stat `/home/axiomgnu/new/zips/noweb.modules.c.patch': No such
file or directory

I dound in the makefile under taget 13 that it is looked for ${ZIPS}, at
the beginning of the makefile ${ZIPS} is set to ZIPS=${SPD}/zips, but
${SPD} is set to /home/axiom/new, which fails on my machine....

After setting this to ~/axiom/new/new, it unpacks the noweb...tgz but the
compilation fails with another error, which might also be a path
problem....

13 making noweb
/bin/sh: cd:
/Net/clifford/CliDiskInt/Users/fauser/axiom/new/new/obj/noweb: No such
file or directory
/bin/sh: cd:
/Net/clifford/CliDiskInt/Users/fauser/axiom/new/new/obj/noweb/src: No such
file or directory
/bin/sh: ./awkname: No such file or directory
/bin/sh: cd:
/Net/clifford/CliDiskInt/Users/fauser/axiom/new/new/obj/noweb/src/c: No
such file or directory
can't find file to patch at input line 3
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|--- modules.c  Wed Mar 28 13:49:22 2001
|+++ modules.c.tpd      Mon Nov 18 22:26:35 2002
--------------------------
File to patch:

> Let me know if this helps.

regretful to say NO

\start
Date: Thu, 30 Oct 2003 07:04:21 -0500
From: Tim Daly
To: Bertfried Fauser
Subject: Re: compilation (SuSE 8.0)

Bertfried,

It appears that your version of Axiom came from axiom.tenkan.org.
You probably have a variable called CVSROOT defined somewhere
that tells you where to get Axiom. Try typing:

echo $CVSROOT

If you any answer at all then you need to unset this variable:

unset CVSROOT

You also need to find where the variable gets set. Look in your .bashrc file.

The CVS for Axiom is now on savannah. The following steps should work:

1) move to your home directory:

   cd /Net/clifford/CliDiskInt/Users/fauser

2) get rid of the old axiom code:

rm -rf axiom

3) log in to savannah. When it prompts you for a password just hit enter:

cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom login

4) get the latest version:

cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom

5) cd to the new directory:

cd axiom

6) set the AXIOM variable:

export AXIOM=/Net/clifford/CliDiskInt/Users/fauser/axiom/mnt/linux

7) start the build:

make

Try this. Save the console. If it fails send me the console.

\start
Date: Thu, 30 Oct 2003 20:47:09 +0100
From: David Mentre
To: list
Subject: Build fails on mnt/linux/lib/summary due to missing mnt/linux/lib/ directory

Hello,

I tried to build latest CVS from Axiom on a previous build, just by
updating required files.

The build failed when making mnt/linux/lib/summary because the
mnt/linux/lib/ directory was not made.

Making the above directory solves the issue.

I suppose that this directory was made in a previous step, not done
because I updated on modified files from the CVS. I don't consider this
a bug, my email is just for information (and if other people fall on
this issue :).

Yours,
d.

PS: Another warning during the build:

6 making /home/david/pub/axiom-libre/axiom-i386/axiom/mnt/linux/doc/DeveloperNotes.dvi from /home/david/pub/axiom-libre/axiom-i386/axiom/src/doc/DeveloperNotes.pamphlet
The root module <<*>> was not defined.

\start
Date: Thu, 30 Oct 2003 20:56:15 +0100
From: David Mentre
To: Tim Daly
Subject: Re: compilation (SuSE 8.0)

Bertfied,

Tim Daly writes:

>    cd /Net/clifford/CliDiskInt/Users/fauser

you should also notice that Axiom has currently a bug that prevents it
to build from a directory with upper characters in the directory path.

Patches to solve this issue have been floating around but I don't know
if they have been integrated in current CVS tree. You have been warned!
;-) 

Go
od luck and let us know of any issue,
Yours,

\start
Date: Thu, 30 Oct 2003 16:31:37 -0500
From: Tim Daly
To: David Mentre
Subject: Re: compilation (SuSE 8.0)

David,

That isn't Bertfried's current problem but it would have shown up later.
Good catch. I'll move the fix up higher on the todo list.

\start
Date: 30 Oct 2003 22:17:51 -0500
From: Camm Maguire
To: Bill Page
Subject: RE: On statically linked Axiom

Greetings!  can someone please save me a bit of time and tell me how I
can run the database rebuilding step by hand (i.e. outside the
Makefile) -- the path setup and file locations (or absences) are
eluding me.

\start
Date: Thu, 30 Oct 2003 22:28:50 -0500
From: Tim Daly
To: Camm Maguire
Subject: make-databases
Cc: Bill Page

Camm,

First, move to where the .NRLIB files are.
The databases are built using the *.NRLIB/info files.

  cd int/algebra

Then start interpsys and give it the lisp command:

  )lisp (make-databases "" nil) | (yourpath)/obj/bin/interpsys

I'm still pondering your "split" request for database file loads.

\start
Date: Thu, 30 Oct 2003 22:43:41 -0500
From: Tim Daly
To: Camm Maguire
Subject: make-databases
Cc: Bill Page

Camm,

First, move to where the .NRLIB files are.
The databases are built using the *.NRLIB/info files.

  cd int/algebra

Then start interpsys and give it the lisp command:

  )lisp (make-databases "" nil) | (yourpath)/obj/bin/interpsys

I'm still pondering your "split" request for database file loads.

In more detail: 

The make-databases function walks across the NRLIB/info files 
extracting information for documentation (e.g. the browse.daase)
or other uses. So, in the case of browse.daase, it extracts
documentation strings, compresses them (see src/interp/daase.lisp),
and writes them out into a random access file format. 

The random access file format has 3 parts: 

an initial pair, 
a sequence of s-expressions, 
a list of lists. 

The list of lists is the index. To look something up in one of these
files you read the first number (N), seek N bytes into the file, and
do a (read). Read will return the list of lists.  For each domain
there is a list. 

Each list consists of indexes into the file (any non-negative number)
or immediate data (a symbol, a string, or a negative number). If the
list item is a number (M) you start from the top of the file, seek M
bytes into the file and call (uncompress (read)).

I'm sure there are more details I missed but the src/interp/daase.lisp
has the actual code.

The split request is going to be a challenge. I think I need to figure
out how to dynamically add one file to the databases. Once I can do
this I can split the database build into any convenient step size.

\start
Date: Fri, 31 Oct 2003 06:45:15 -0500
From: Tim Daly
To: list
Subject: changelog

*,

The bsdsignal.c and openpty.c functions have been modified for clef (me)
clef has now exists and is used by default (Bill)
axiom is now a shell script (*)
AXIOMsys is the name of the axiom image file (*)
several unused files were deleted (me)
configure exists, works, and is documented (*)
make install exists, works, and is documented (*)
The axiom socket message is gone (me)
mnt/linux/lib is created before it is used (David)
COT and ASEC are defined (Juergen)

So basically you now do:

./configure
make
make install

\start
Date: 31 Oct 2003 10:51:25 -0500
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] make-databases
Cc: Bill Page

Greetings!

Tim Daly writes:

> Camm,
> 
> First, move to where the .NRLIB files are.
> The databases are built using the *.NRLIB/info files.
> 
>   cd int/algebra
> 
> Then start interpsys and give it the lisp command:
> 
>   )lisp (make-databases "" nil) | (yourpath)/obj/bin/interpsys
> 
> I'm still pondering your "split" request for database file loads.
> 

Thanks, Tim.  Please feel free to say it is too difficult if that is
the case.  It is likely the shortest route to axiom on mips(el),
alpha, ia64, and hppa, but in principle we should build a bfd backend
for those targets at some point, and this may provide incentive :-).
The latter is a large task, and I likely will not have time for it
until 2004, but should be doable, though ugly.  The following page
describes the state of bfd relocation pretty well:

http://www.ugcs.caltech.edu/info/insight/bfdint_6.html

Apparently these newer target machines are using the 'new linker'
mechanism which bypasses the bfd_get_relocated_section_contents
strategy we're using entirely.  Instead, they provide a 'backend'
specific 'relocate_section' function, an example call of which can be
found in the elflink.h file in the binutils/bfd subdir of the gcl
source tree.  While in principle such a call might work across the
board, it appears to use quite a few auxiliary structures which
require building before the call.  Energetic volunteers appreciated!
Perhaps if anyone feels motivated, they could fork the sfaslbfd.c file
into sfaslbfd_new.c, and rewrite the section relocation calls using
bfd's 'new' linker strategy.  (While I'm sure he is too busy, we do
have such a bfd-knowledgeable person on the gcl team, right Aurelian?
:-)).

Take care,

> In more detail: 
> 
> The make-databases function walks across the NRLIB/info files 
> extracting information for documentation (e.g. the browse.daase)
> or other uses. So, in the case of browse.daase, it extracts
> documentation strings, compresses them (see src/interp/daase.lisp),
> and writes them out into a random access file format. 
> 
> The random access file format has 3 parts: 
> 
> an initial pair, 
> a sequence of s-expressions, 
> a list of lists. 
> 
> The list of lists is the index. To look something up in one of these
> files you read the first number (N), seek N bytes into the file, and
> do a (read). Read will return the list of lists.  For each domain
> there is a list. 
> 
> Each list consists of indexes into the file (any non-negative number)
> or immediate data (a symbol, a string, or a negative number). If the
> list item is a number (M) you start from the top of the file, seek M
> bytes into the file and call (uncompress (read)).
> 
> I'm sure there are more details I missed but the src/interp/daase.lisp
> has the actual code.
> 
> The split request is going to be a challenge. I think I need to figure
> out how to dynamically add one file to the databases. Once I can do
> this I can split the database build into any convenient step size.

\start
Date: Fri, 31 Oct 2003 11:08:10 -0500
From: Tim Daly
To: Camm Maguire
Subject: make-databases

Camm,

The databases do not contain system-specific code. 
It would be possible to skip the make-database code for particular
platforms and just untar a copy into the mnt directory.

If you have the right switches to run gcl on the alpha I'd be
most interested. I have access to a dozen or so alpha machines
on the HP Testdrive website. If I could build GCL there I could
probably build Axiom there.

We're also trying to get Axiom on a Zaurus 5600. Do you know if
GCL runs there? It's an Intel X-scale processor running Lineo Linux.

\start
Date: 31 Oct 2003 12:19:44 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: [Gcl-devel] make-databases

Greetings!

Tim Daly writes:

> Camm,
> 
> The databases do not contain system-specific code. 
> It would be possible to skip the make-database code for particular
> platforms and just untar a copy into the mnt directory.
> 

i.e. cp src/share/algebra/*daase mnt/linux/algebra/ ?  Can I do this
at the start of the build?

> If you have the right switches to run gcl on the alpha I'd be
> most interested. I have access to a dozen or so alpha machines
> on the HP Testdrive website. If I could build GCL there I could
> probably build Axiom there.
> 

Axiom does build on Debian alpha, at least.  --disable-statsysbfd
--enable-dlopen are needed.  You will also need to build a few of the
intermediary images with the calls to (compiler::link...  I posted a
while ago.  These work everywhere, but are required on dlopen systems,
as unexec will not dump dlopen'ed loaded modules.  I can repost the
details if needed.

> We're also trying to get Axiom on a Zaurus 5600. Do you know if
> GCL runs there? It's an Intel X-scale processor running Lineo Linux.
> 

I thought the Zaurus was an ARM processor?  If so, gcl is fully
supported there without dlopen.  Config should start at least with
--enable-machine=arm-linux if not autodetected.  Don't know what
positive.

If you want to avoid any of the gcl builds, you can grab a .deb off of
the temporary dist site and unpack on any linux box (with compatible
shared libs installed, do a ldd unixport/saved_gcl to confirm).

\start
Date: Fri, 31 Oct 2003 18:36:21 +0100
From: David Mentre
To: Camm Maguire
Subject: re: [Gcl-devel] make-databases

Hello,

Camm Maguire writes:

> I thought the Zaurus was an ARM processor?  If so, gcl is fully
> supported there without dlopen.

XScale is ARM architecture (with few additions). Intel loves rename
things it touches. :)

\start
Date: Fri, 31 Oct 2003 12:00:47 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel] make-databases

Yes, if you 
  mkdir mnt/linux/algebra
  cp src/share/algebra/*daase
the databases won't get rebuilt. However, the databases will be old
NAG databases. What you really want to do is copy the databases from 
another recent build, tar them up, copy them over, and untar them
into mnt/linux/algebra.

The Zaurus 5500 is arm, the 5600 is X-scale.

Could you point me at a site with the .deb file?
Is a .deb file a tgz file? How do I unpack one?
I'm not a debian user. Is there a faq someplace?

\start
Date: 31 Oct 2003 13:06:34 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: [Gcl-devel] make-databases

Greetings!

Tim Daly writes:

> Yes, if you 
>   mkdir mnt/linux/algebra
>   cp src/share/algebra/*daase
> the databases won't get rebuilt. However, the databases will be old
> NAG databases. What you really want to do is copy the databases from 
> another recent build, tar them up, copy them over, and untar them
> into mnt/linux/algebra.
> 

Thanks!  Will try this in a new package ...

> The Zaurus 5500 is arm, the 5600 is X-scale.
> 
> Could you point me at a site with the .deb file?
> Is a .deb file a tgz file? How do I unpack one?
> I'm not a debian user. Is there a faq someplace?
> 

http://people.debian.org/~camm/gcl

There is a file there called HOWTO-UNPACK-DEBS, but in short, .deb as
an ar format.  ar x ....deb gives a data.tar.gz, which can be unpacked
with gzip and tar.

\start
Date: Fri, 31 Oct 2003 21:50:58 +0100
From: David Mentre
To: Bill Page
Subject: Line breaking and small font

While testing your tm_axiom (1.0.2), I noticed that if I use a small
font in TeXmacs (Format->Size->Small) the line breaking is done too
early. In other words, the Axiom/TeXmacs interface seems to not take
into account the page size and font size parameters. Any idea to solve
that?

PS: You have probably noticed that I re-submited to texmacs-dev your
    tm_axiom against latest TeXmacs (1.0.2.4), taking into account axiom
    renaming (AXIOMsys).

\start
Date: Fri, 31 Oct 2003 15:54:47 -0500
From: Bill Page
To: list
Subject: RE: [Texmacs-dev] Patch for axiom plugin: line-breaking algorithm & support of both NAG and free Axiom

David,

Can you upload this new version to the files section
at Savannah? Maybe as version 1.0.3 or such?

Also, if you do upload it to the files section, let me
know if you have any problem with access restrictions.
A couple of days ago I had trouble trying to add the
static build tar.gz file to a directory that you had
previously set up. I thought at first that it might be
a space problem so I tried to remove one of the older
binary files. But Savannah did not let me do it. I
ended up just creating another directory and everything
uploaded properly. I am not sure whether I did something
wrong or not.

Do you think we should make a place for this in the
Axiom CVS or will the TeXmacs people take this on?

There was also another modification recently providing
a command line option to tm_axiom which specified either
one or two prompts. With this change to AXIOMsys, that
option should not longer be necessary, right?

I think the question of line-breaking: tm_axiom vs. TeXmacs
is still an active issue. And there are some bugs in the
line-break code in this new version of tm_axiom. Should we
track these bugs as part of the Axiom project?

> Here is a patch against TeXmacs 1.0.2.4 axiom plugin that
> includes:
> 
>  - support of both free and NAG versions of Axiom (only tested
>    on the free Axiom, I have not access to the NAG version)
> 
>  - inclusion of a line-breaking algorithm
> 
>  - modification on prompt handling to interact correctly with
>    Axiom
> 
> Please notice that this patch will work only with releases of 
> Axiom starting from current CVS tree. Older Axiom (like those 
> found precompiled on Axiom web site) won't work.
> 
> Most of the work of this patch comes from Bill Page.
> 
> Let me know of any issue with this patch.

\start
Date: Fri, 31 Oct 2003 16:17:35 -0500
From: Bill Page
To: David Mentre
Subject: RE: Line breaking and small font

David,

At the present time the line-break code in tm_axiom
makes assumptions about the font size (and type) and
has a single parameter which specifies a maximum line
length (now set at 4500, I think, which means 4.5 inches).
When you change the font size used by TeXmacs to render
the mathematics, tm_axiom does not know this. It might
be possible to pass a command-line parameter to tm_axiom
to set line length and font-scaling etc. I guess these
numbers could be extracted from TeXmacs by the init-axiom.scm
script but exactly how to do this is beyond my level of
knowledge of TeXmacs at this time.

I think this complication supports the idea promoted by
Joris that we should leave line-breaking to TeXmacs itself.
But to do this, we might then be forced to make improvements
to TeXmacs LaTeX conversion routines. That makes me think:

"Well, ok maybe, but Axiom is already a pretty big thing to
take on, adding TeXmacs to the top of that makes it seem like
too big a task for me right now ..."

Still, I do think TeXmacs has a great potential to achieve
not only an excellent display of Axiom's mathematics within a
full mathematical document preparation system, but also can go
a long way towards providing the kind of literate programming
tools that Tim has argued is important to Axiom's future. The
extensions necessary to TeXmacs to make it handle the noweb-style
pamphlet files and to provide a "tangle" operation to extract
code etc. are (in principle) quite straight forward.

So I am still of two minds about this. But I am definitely
leaning toward the idea of suggesting that Axiom adopt TeXmacs
as it's primary user interface. In which case, investing the
time necessary to help adapt TeXmacs for this purpose might
be justified.

> Hello Bill,
> 
> While testing your tm_axiom (1.0.2), I noticed that if I use 
> a small font in TeXmacs (Format->Size->Small) the line 
> breaking is done too early. In other words, the Axiom/TeXmacs 
> interface seems to not take into account the page size and 
> font size parameters. Any idea to solve that?
> 
> Yours,
> david
> 
> PS: You have probably noticed that I re-submited to texmacs-dev
> your tm_axiom against latest TeXmacs (1.0.2.4), taking into 
> account axiom renaming (AXIOMsys).
> -- 
> David Mentre -- http://www.nongnu.org/axiom/
> 

\start
Date: Fri, 31 Oct 2003 22:43:56 +0100
From: David Mentre
To: Bill Page
Subject: RE: [Texmacs-dev] Patch for axiom plugin: line-breaking algorithm & support of both NAG and free Axiom

Hello Bill,

Bill Page writes:

> Can you upload this new version to the files section
> at Savannah? Maybe as version 1.0.3 or such?

I tried but...

> Also, if you do upload it to the files section, let me
> know if you have any problem with access restrictions.

...as you, savannah did not let me upload the files. I wonder if the
directory owner on savannah is not the guy who has done the last
successful upload.

I'll send you the files by email, so you could give it a try. 

> Do you think we should make a place for this in the
> Axiom CVS or will the TeXmacs people take this on?

I think it would be better to let TeXmacs people to integrate it. But if
they don't do it, we will add this work to our CVS.

> There was also another modification recently providing
> a command line option to tm_axiom which specified either
> one or two prompts. With this change to AXIOMsys, that
> option should not longer be necessary, right?

I think so. At least in my version, AXIOMsys is called directly. And as
it was mentioned on the list, it should work with NAG's version.

> I think the question of line-breaking: tm_axiom vs. TeXmacs
> is still an active issue. And there are some bugs in the
> line-break code in this new version of tm_axiom. Should we
> track these bugs as part of the Axiom project?

As we have wrote and we maintain this software, we should fix bugs
ourself, as time permits.



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