\start
Date: Tue, 8 Apr 2003 10:35:06 -0400
From: Tim Daly
To: Don Peterson
Subject:  Re: Axiom web pages

Don,

Yes, it's true that there is no code at the savannah website.
Currently the pre-release version of the code exists in a private
CVS only accessed by developers. About 80% of the algebra compiles
and runs. At the present time I'm working on finding and fixing 
compiler bugs that prevent the remaining algebra from compiling.
Progress is slow, mostly because I have to build up the facilities
to do debugging and due to the complexity of the compiler, but progress
is being made. Let me know if you need anything else.

An executive summary:

Axiom is a general purpose computer algebra system. Axiom is a
strongly-typed, theory-based system that uses modern algebra structure
as it's model for development. It handles a wide range of mathematics,
supports a wide range of data structures, has excellent graphics,
links for numeric libraries and a programming language. The algebra
knowledge of the system is expressed in it's own language which can be
easily extended by the user. The algebra language leads to concise,
efficient, correct algorithms. Axiom was originally developed at IBM
Research over a 23 year period. It was later sold to the Numerical
Algorithms Group where it became a commercial product.  In October,
2001 Axiom was withdrawn from the market. In September, 2002 it was
released as open source under the BSD license. Work is in progress to
make it freely available.

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

 "Don Peterson"

Tim:

I got your email address from http://savannah.nongnu.org/users/axiom/.

I was interested in learning something about Axiom (I'm downloading
different free computer algebra systems and trying to learn something
about them), so I went to the web page 
http://savannah.nongnu.org/projects/axiom/.  However, clicking on the
Filelist link produces an essentially empty page, as does clicking on 
the link to access the download area directly.

It would be great if there was an "executive summary" type document
about Axiom that described it, its benefits, and usage model.  I'd
be happy to write a rough draft to such a document if I could get my
hands on the system/code.

Don Peterson

\start
Date: Tue, 8 Apr 2003 14:33:32 -0400
From: Tim Daly
To: Don Peterson
Subject:  Re: Axiom web pages

Axiom is several layers of languages.

The underlying Lisp, the whole graphics package and the numeric
library communication programs are all in C (not C++). I haven't
even started looking at the graphics portion of the system nor
has anyone else. If you're interested then sign up as a developer
and I'll ask the sysadmin to give you read/write access to the CVS.
It's all volunteer and it's all a free-time activity so if you've
got the time we've got the problems.

Tim

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

I had seen a couple of positive comments about Axiom, so I was
interested in trying it out.  I've played with Maxima and Yacas.
I also used Mathematica a bit when I worked at HP (I retired last
summer).

I'd be happy to help with this building and debugging, but it would
have to be C or C++ or somesuch.  Maxima is written in Lisp and Yacas
is C++ (but essentially a Lisp implementation) and I wouldn't have
the time to learn Lisp right now (although I'd like to someday).

donp

\start
Date: Tue, 15 Apr 2003 18:01:58 +0200
From: Michel Lavaud
To: list
Subject:  CD-ROM Rosetta for Windows available for download

Hello,

Version 1.0a of the CD-ROM Rosetta for Windows (free Computer Algebra 
Systems) is available for downloading as an iso image, bz2-compressed, at 

ftp://ftp.univ-orleans.fr/pub/tex/PC/AsTeX/rosetta

The CAS on the CD-ROM are Gnu-Calc, CoCoA, Gap, Giac, Jacal, Macaulay, 
Maxima, MuPAD Studio, Pari, Singular and Yacas. As for the Linux version 
by Tim Daly, everything is run directly from the CD-ROM, just a few 
configuration files are written to the hard disk.

Detailed instructions for getting/burning a CD-ROM are available at

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/rosetta/html/urse7.htm

The user's guide is available at 

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/rosetta/html/urose.htm

Right now, the guide is only in French, translation into English is not 
yet available.

\start
Date: Wed, 23 Apr 2003 22:41:25 -0400
From: Tim Daly
To: Tim Daly Jr.
Subject:  Re: Axiom CVS

Tim,

Please set Dylan up with a read/write account to the Axiom CVS on Tenkan.

Tim

> I'm a mathematician at Harvard, constantly annoyed by the lack of free
> CAS systems.  I'm interested in playing with Axiom, and with helping
> getting it to compile.  May I get access to the developer CVS?

> Peace,
>	Dylan

\start
Date: Thu, 24 Apr 2003 18:04:31 +0200
From: Michel Lavaud
To: list
Subject:   Doc in English available for CD Rosetta for Windows (free CAS)

Hello,

The Installation and User's Guide of the CD-ROM Rosetta for Windows (free 
Computer Algebra Systems) is available in English at the addresses:

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/rosetta/html/urose.htm

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/rosetta/htmla/urose.htm

in html form (multi-files and mono-file), and in pdf form at:

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/rosetta/src/urosej.pdf

The CAS on the CD-ROM Rosetta are Gnu-Calc, CoCoA, Gap, Giac, Jacal, 
Macaulay, Maxima (5.5 and 5.9.0), MuPAD Studio, Pari, Singular and Yacas.

French versions of the manual are available at

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/rosetta/html/urose.htm

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/rosetta/htmla/urose.htm

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/rosetta/src/urosej.pdf

Version 1.0b of the CD-ROM Rosetta will be available to-morrow for 
downloading as an iso image, bz2-compressed, at

ftp://ftp.univ-orleans.fr/pub/tex/PC/AsTeX/rosetta

Detailed instructions for getting/burning a CD-ROM are available in 
English at

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/en/rosetta/html/urse7.htm

and in French at:

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/rosetta/html/urse7.htm

\start
Date: Thu, 24 Apr 2003 19:25:17 +0200
From: Michel Lavaud
To: Tim Daly
Subject: Re:  Re: Axiom CVS

Hello,

> Please set Dylan up with a read/write account to the Axiom CVS on Tenkan.
> 
> Tim
> 
> > I'm a mathematician at Harvard, constantly annoyed by the lack of free
> > CAS systems.  I'm interested in playing with Axiom, and with helping
> > getting it to compile.  May I get access to the developer CVS?
> 
> > Peace,
> >	Dylan

Is there some preliminary version already running under Windows, and some 
doc, to prepare CD number 2 of Rosetta for Windows ? Have you an estimate 
of the volume in Mb of the doc + exe? 50 Mb ? More?

Is there somebody working on a version for Mac OSX ?

\start
Date: Thu, 24 Apr 2003 13:32:22 -0400
From: Tim Daly
To: Michel Lavaud
Subject: Re: Axiom CVS

Michel,

Glad to see the changes in Rosetta. Good job. I'll download the image
in work next week. I have access to a Windows machine there.

I've recently collected the latest versions of systems for another
Rosetta CD release. It probably won't be available until summer, however,
due to lack of available free time. Work on it continues (at a glacial
pace).

Re: Axiom

There isn't a preliminary image on Mac OSX although I don't see why 
it would be a problem. If GCC and GCL run on Mac OSX it should compile
and run. I have access to a Mac OSX in work but I'm heads-down chasing
compiler bugs and can't even think about porting it yet. Bill Page
has done some work on Windows.

\start
Date: Fri, 25 Apr 2003 00:49:18 -0400
From: Tim Daly
To: Dylan Thurston
Subject:  Re: new/src/boot/Makefile.pamphlet

Dylan

> In my initial attempts to understand the compilation system, I found a
> minor problem: lines 165-168 of new/src/boot/Makefile.pamphlet read:
> 
> ----
> Integers start with a digit (0-9) and are followed by any number
> of digits.  The syntax for floating point numbers is
> <.I | I. | I.I> <E|e> <+ | - | empty> I where I is an integer.
> ----
> 
> which turns into goobledy-gook when TeXed, particularly the '<' and
> '>' signs.  How should I fix things like this?  Should I make a patch
> and send it to you, or should I check it into CVS directly?

Send me the patches directly. The CVS tree is rather static as I'm
working locally. This will change once the system compiles and I can
move the working sources to savannah. But for now, just send me the patch.

> 
> (I'm still getting oriented, so I won't be able to help much with
> substantive matters for a little bit.)

Not to worry, Axiom is a huge system with many layers and it takes
a while to figure things out and build up a good working environment.
I lost a lot of my tools once the project left IBM and I'm slowly
rebuilding them as I work.

> 
> The other thing that was annoying me was the hard-coding of the SPD
> path in the top-level makefile.

Ah, well, something seems to have changed in Make since it was last
used. I used to be able to take a shell variable (AXIOM) and do things
like: 

SPD=`basename $AXIOM`

and it would get executed. That fails now and I need to figure out the
new magic to make that work. Unfortunately my two attempts both failed
and I resorted to hard-coding them. It really annoys me also. In theory
you should just have to set the AXIOM shell variable and the Makefile
figures out all the subtree information, including the kind of system
to build. It used to be the case that setting the AXIOM variable to:

AXIOM=/spad/mnt/sun

would build a sun system. And

AXIOM=/spad/mnt/linux

would build a linux system. I can't figure out how to parse out the
basename at Make time. Seems trivial but ....

>                                    Also, why do you patch the noweb
> makefile to point to /tmp/null rather than /dev/null?  And have you
> submitted your patch to noweb to Norman Ramsey?  It seems like a very
> reasonable patch...

I have corresponded with Norman on several occasions. I've made some
changes to noweb that Norman feels should be done with gawk filters.
I'm a much better C programmer than a gawk programmer (in fact, I
never use awk or gawk) so I made changes in the C code. Since these
changes are not of interest to others (well, maybe the /dev/null)
and I haven't taken the time to learn gawk there is no common ground
to give back the changes. This really isn't Norman's problem, it's me.

It'll get worse in the future as I want the pamphlet files to have
more functionality. In the fullness of time I want pamphlet files to
be the publication standard for an Axiom Journal. A pamphlet file
should be able to be "dropped" onto a running Axiom. Axiom should
read the bibligraphy and recursively parse and load the referenced
pamphlets. (This way a referee could actually run the algorithm that
supports a research paper which now gets lost in a library).

Another design goal is that pamphlets form portions of larger works
(booklets). Booklets slice the pamphlets in various ways. So, for
instance, there can be a booklet of all the matrix domains in the
system (a horizontal slice) explaining all of the matrix operations
the system knows. Alternatively you can include the matrix pamphlet
into a booklet on digital filters where you explain digital filtering
concepts from the top level commands all the way down to the bits
(a vertical slice). 

The noweb chunks need some small syntactic changes (basically a URL
style syntax). These will not be of interest to Norman either so I
don't expect to have the patches included into noweb.

> 
> At some point, it will be necessary to change the Makefile to allow
> the option of using the versions of GCL, CMUCL, noweb, etc. that are
> already installed on the system.

You'll notice that the top level Makefile does nothing but build a
system-specific Makefile before proceeding. Changing the variables
in the top-level Makefile will change which system-specific Makefile
gets built. All of the system-specific information is customized at
that point. Ideally the AXIOM variable names the kind of system you
want to build and this automatically selects the system-specific 
version. It used to work this way and I was able to build on 12
different systems by simply 

 1) cross-mount NFS file systems to cover the src and int subdirectories
    For example, if I were going to build a Sun system I'd NFS mount
    src and int (these are read-only during the SECOND build) directories
    from the master machine
 2) set the AXIOM=/spad/mnt/Sun
 3) cd /spad
 4) make

I could build sparcs, powerpcs, intels, and symbolics (lisp-machine)
versions under solaris, linux, pc-dos with djgpp, aix, etc. I hope
to be able to do that again. This is why there are 5 different "major"
subtrees (src, int, obj, mnt, lsp).

It used to work and eventually it will all work again.

\start
Date: Fri, 25 Apr 2003 02:46:25 -0400
From: Tim Daly
To: Dylan Thurston
Subject:  Re: new/src/boot/Makefile.pamphlet

re: the patch. thanks.

> > I have corresponded with Norman on several occasions. I've made some
> > changes to noweb that Norman feels should be done with gawk filters.
> > I'm a much better C programmer than a gawk programmer (in fact, I
> > never use awk or gawk) so I made changes in the C code. Since these
> > changes are not of interest to others (well, maybe the /dev/null)
> > and I haven't taken the time to learn gawk there is no common ground
> > to give back the changes. This really isn't Norman's problem, it's me.
> 
> There was one patch to modules.nw (in noweb.modules.nw.patch) that
> looked very much as if it belonged upstream.

noweb appears to digest the file into some syntactic form which can be
processed by filters. i haven't taken the time to understand the intermediate
file format nor the way to reparse them. Norman made the point that the
patch you're looking at can be done in a much cleaner way. I fully agree
but either way it became a patch and I was focused on getting it to run.
Thus, rather than climb the learning curve I stomped the offending code.
mea culpa. I plan to revisit this whole issue in the future. I'm trying
to get a system that will run all of the algebra (which is the heart of
Axiom) and get it so others can at least use it to write new algebra.
At that point I have the free time to rehack the rest of the code. In
the current state no one can fully run the algebra and time passes...

> 
> > It'll get worse in the future as I want the pamphlet files to have
> > more functionality. In the fullness of time I want pamphlet files to
> > be the publication standard for an Axiom Journal. ...
> 
> Yes, I was just browsing the old list archives.  Quite a grand vision
> you have.

Axiom's been around 30 years and it has the potential to be around a lot
longer; provided we solve some fundamental software issues like making it
maintainable, documenting it so the algorithms can be modified, etc. I
plan to spend the next 5 years leading the project and building the
supporting code and social structures. If it isn't at least mildly 
self-sustaining at that point I guess I will have failed. I just hate
to see such unbelievably good research go to waste. 

I spent last year while I was waiting for code release pondering the
reasons that make a large software project like Axiom fail. Most of
the "grand vision" ideas come from that question. After 33 years of
programming I'm tired of watching systems vaporize. Surely we can 
do better. If mathematical software can't span the generations, what
software can? So, in a sense, this is a research project on software
as much as it is a research project in mathematics. Since my day job
at City College is a joint venture of the math dept and comp sci it
fits my interests.

> 
> I thought the TeXmacs authors had a reasonable point, that there's no
> need to remained tied to noweb if it ends up being too limiting.
> OTOH, it's a trivially simple format to parse, so there's no harm
> using it now.

I tried various systems and had a discussion with Joris about Texmacs.
I eventually want Texmacs to be the common front-end of Axiom. But
noweb is clearly the best path for the short term. I've tried to use
noweb on various other projects, the latest being a huge music theory
program in Java. It is unclear if literate programming adds value for
such things as there is very little "theory" in the actual programming
and any decent programmer is better of "reading the source code". 
However, "reading the source code" isn't going to get you far with
Axiom's algebra so literate programming really shines for Axiom.

> 
> So all I want right now is to use the versions of gcl, noweb, and
> cmucl that were already installed on my Debian GNU/Linux system, and
> which are more recent than the versions you included.  Is there some
> simple change to do that?

Um, no. noweb could be made to work if you put the patched version
onto your system. GCL could work if you use the version I ship. 
Just any version won't do. The key problem (assuming you try to
use a newer version of common lisp) is that common lisp has changed
since NAG took over the code and they didn't keep up with the new
common lisp language. So, for example, Axiom assumes that
  (in-package 'foo)
will do a make-package if foo does not exist. That was true in the
original steele version of common lisp but the new standard requires
the make-package to occur first. I have the latest common lisp (GCL 2.5)
and have been sending Camm fixes, changes, and general harassing
email. Axiom will certainly run on the latest common lisp standard
as I feel it is important to keep up to date. However, first I want
to get it running on the common lisp where it used to run (AKCL aka GCL).
NAG used a "different" common lisp called CCL (which has the advantage
that it is byte-coded and platform independent). However, they made
non-common-lisp changes to the source code so it ran better on CCL
and I have to find and rewrite these (unfortunately I didn't keep the
original sources or I could diff them). So, no, unless you use exactly
the versions (including patches) I can't guarantee the build will
succeed.

On the other hand, being a "certified developer" you're welcome to 
try a different common lisp and make it work there. CMUCl and GCL 2.5
are certainly on the "todo" list and it would be most helpful if you
succeeded.

\start
Date: Fri, 25 Apr 2003 10:21:33 -0400
From: Bill Page
To: Michel Lavaud
Subject:  RE: Axiom for Windows

Michel,

Unfortunately it is premature. At this point all I can
say is that I now feel like I am ready to "get serious".
I have experimented (successfully) with getting CCL running
under Windows using MinGW/Msys. CCL is one of the lisp that
was previously used for Axiom on the Windows platform. I
have also successfully compiled and run the newest version
of GCL (2.5) under Windows.

I also did some earlier experiments using Cygwin, but the
GCL developers have moved to MinGW as the primary platform
for Windows because it produces "native" code (does not
depend on any non-Windows supplied libraries). The advantage
of Cygwin however is that it does provide an X11 graphics
environment which might be important in future gui development
for Axiom. But I have other ideas about this based on my
experience with TexMacs - an open source graphical mathematical
text editor designed to interface with computer algebra
systems.

The current alpha version of Axiom that a have from Tim only
compiles using an earlier version of GCL (2.4) under Linux.
And that version currently has a bug which prevents all but
very simple algebra. Tim is working to correct this. Also it
does not currently completely compile with CCL. Because I have
not tried very hard, so far I have succeeded in compiling
only small parts of the Axiom code under CCL and GCL 2.5 in
the Windows environment.

The original code as supplied by NAG was claimed by them
to compile completely under an older version of linux (6.2?)
And that it should also have been possible to compile it
using CCL under Windows with the Microsoft C compiler. I
haven't yet taken the time to verify this. One reason is
that the procedures to do this are not at all well documented.
The other reason is that Tim's priorities are focused on
improving the documentation for the whole system by using
the combined source code+documentation techniques promoted
by Knuth in his WEB methodology (as extended and simplified
in a tool called noweb). But if you are adventuresome and
anxious to get started, you might want to try to play with
the original code. If so, you should ask Tim (nicely) if
he pass it on to you since I don't think it is still in
his cvs.

Tim, a while back I understood that you were in the process
of converting what you have to work with GCL 2.5 under linux.
How is that going? I recall that you found a problem with
some missing functionality in the first release of 2.5 (same
problem under the Windows version) that was later corrected
by the GCL developer. Can you now get to the same stage
with 2.5 that you were at with 2.4? If so, maybe I should
refresh the stuff I am working with from your most recent
source.

> Subject: Axiom for Windows
> 
> 
> Helo Bill,
> 
> Did you succeed to get a working version of Windows? Have you 
> written some 
> comments for compilation, so that it would be worth to ask 
> for an access 
> to CVS and try, or is it premature? 
> 
> Best wishes,
> 
> 

\start
Date: Fri, 25 Apr 2003 10:47:01 -0400
From: Bill Page
To: list
Subject:  FW: Mail System Error - Returned Mail

------=_NextPart_000_0009_01C30B18.02702350
	charset="US-ASCII"

Tim,

(Sorry to send this to the developer email list, but I am
not sure how else to get this to you.)

Is there something wrong with your ISP? I am using a well
recognized and widely used ISP in Canada called Sympatico
that is run by ma' Bell, but your ISP is apparently refusing
email from them as "untrusted"? I did not used to have any
problem with your email address. Or am I
miss interpreting the response of your ISP?

Cheers,
Bill Page.

------=_NextPart_000_0004_01C30B18.026DB250

Michel,

Unfortunately it is premature. At this point all I can
say is that I now feel like I am ready to "get serious".
I have experimented (successfully) with getting CCL running
under Windows using MinGW/Msys. CCL is one of the lisp that
was previously used for Axiom on the Windows platform. I
have also successfully compiled and run the newest version
of GCL (2.5) under Windows.

I also did some earlier experiments using Cygwin, but the
GCL developers have moved to MinGW as the primary platform
for Windows because it produces "native" code (does not
depend on any non-Windows supplied libraries). The advantage
of Cygwin however is that it does provide an X11 graphics
environment which might be important in future gui development
for Axiom. But I have other ideas about this based on my
experience with TexMacs - an open source graphical mathematical
text editor designed to interface with computer algebra
systems.

The current alpha version of Axiom that a have from Tim only
compiles using an earlier version of GCL (2.4) under Linux.
And that version currently has a bug which prevents all but
very simple algebra. Tim is working to correct this. Also it
does not currently completely compile with CCL. Because I have
not tried very hard, so far I have succeeded in compiling
only small parts of the Axiom code under CCL and GCL 2.5 in
the Windows environment.

The original code as supplied by NAG was claimed by them
to compile completely under an older version of linux (6.2?)
And that it should also have been possible to compile it
using CCL under Windows with the Microsoft C compiler. I
haven't yet taken the time to verify this. One reason is
that the procedures to do this are not at all well documented.
The other reason is that Tim's priorities are focused on
improving the documentation for the whole system by using
the combined source code+documentation techniques promoted
by Knuth in his WEB methodology (as extended and simplified
in a tool called noweb). But if you are adventuresome and
anxious to get started, you might want to try to play with
the original code. If so, you should ask Tim (nicely) if
he pass it on to you since I don't think it is still in
his cvs.

Tim, a while back I understood that you were in the process
of converting what you have to work with GCL 2.5 under linux.
How is that going? I recall that you found a problem with
some missing functionality in the first release of 2.5 (same
problem under the Windows version) that was later corrected
by the GCL developer. Can you now get to the same stage
with 2.5 that you were at with 2.4? If so, maybe I should
refresh the stuff I am working with from your most recent
source.

Cheers,
Bill Page.

> Helo Bill,
> 
> Did you succeed to get a working version of Windows? Have you 
> written some 
> comments for compilation, so that it would be worth to ask 
> for an access 
> to CVS and try, or is it premature? 

\start
Date: Fri, 25 Apr 2003 14:40:51 -0400
From: Tim Daly
To: Bill Page
Subject: RE: Axiom for Windows
cc: Michel Lavaud

Bill


> Tim, a while back I understood that you were in the process
> of converting what you have to work with GCL 2.5 under linux.
> How is that going? I recall that you found a problem with
> some missing functionality in the first release of 2.5 (same
> problem under the Windows version) that was later corrected
> by the GCL developer. Can you now get to the same stage
> with 2.5 that you were at with 2.4? If so, maybe I should
> refresh the stuff I am working with from your most recent
> source.

I'm not working on 2.5 at the moment. The issue is that the in-package
change requires changes to the sources and I'm trying to get the world
to work with minimal source changes. Once that is working and stable
I'll look at 2.5. I have sent changes to Camm in the past and he has
made corrections so when we get to 2.5 I'm sure the process will go
smoothly. The old definition of common lisp and the new definition are
fairly close. Since I wrote or rewrote most of the common lisp code
and I code using a very simple subset I'm not anticipating a lot of work
to change to 2.5. However, it's not at the top of the todo list yet.
You're welcome to give it a try and I'm willing to accept patches.

> The other reason is that Tim's priorities are focused on
> improving the documentation for the whole system by using
> the combined source code+documentation techniques promoted
> by Knuth in his WEB methodology (as extended and simplified
> in a tool called noweb). But if you are adventuresome and
> anxious to get started, you might want to try to play with
> the original code. If so, you should ask Tim (nicely) if
> he pass it on to you since I don't think it is still in
> his cvs.

Actually, if you look in int/interp, int/boot, int/algebra, (e.g
the int subdirectory) you will find the original sources. The first
step in the documentation goal was to take the original code, wrap
it in noweb, tangle the noweb form and get the original code back
(in the int directory). Anywhere that doesn't happen can be considered
a bug (well, modulo the fact that I've been experiementing with future
changes. but these should be confined to a few files and should not
change the semantics of the code). You could just mapcar the tangle
function over a list of the .pamphlet files and get the original 
sources back.

\start
Date: Fri, 25 Apr 2003 14:46:54 -0400
From: Tim Daly
To: Bill Page
Subject: FW: Mail System Error - Returned Mail

Bill,

About the bounced email....

> (Sorry to send this to the developer email list, but I am
> not sure how else to get this to you.)
> 
> Is there something wrong with your ISP? I am using a well
> recognized and widely used ISP in Canada called Sympatico
> that is run by ma' Bell, but your ISP is apparently refusing
> email from them as "untrusted"? I did not used to have any
> problem with your email address. Or am I
> miss interpreting the response of your ISP?

I'm connected to the world thru Earthlink and Earthlink, being a
large ISP, occasionally gets blacklisted and even blackholed due
to the fact that spammers compromise nodes on their network. I
ran into this with the original Axiom site. France was bouncing
emails and I couldn't get them to stop so I had to buy a domain
on a non-earthlink net in order to talk to the french.

I'll see if I can set up a mail id on tenkan that you can use to
contact me. Alternatively it might be possible to get mail thru
the savannah site. I'll let you know.

I did get this email directly even though you got a bounced message.
You can also contact me thru my work id.

\start
Date: Sat, 26 Apr 2003 10:44:38 -0400
From: Dylan Thurston
To: list
Subject:  Compiling

I've successfully gotten the compiler to run, and, after some poking,
found that obj/linux/bin/interpsys would give me a prompt at which I
could do some computations.  But, as warned, the compilation is very
incomplete.  I played around to try to see, e.g., why FFIELDC from
ffcat.spad.pamphlet was not being compiled, and got to the point of
getting a 'Value stack overflow', which is now an error I could try to
address.  (Could it just be that some gcl limits are set too low?)

One thing that seemed clear to me is that there must be automated
tools for doing this; also, it doesn't seem that this is a very
efficient use of make, since there are about 24 lines per individual
category in the Makefile, and many different places that need to be
changed when you want to, say, add a new file.

Peace,
	Dylan

\start
Date: 26 Apr 2003 17:29:47 +0200
From: David Mentre
To: list
Subject:  Re: GCL version
cc: Bill Page

Hello tim,

A long time ago, you told me:

Tim Daly writes:

> As to the "non visibility of BOOTTRAN package in the compilation
> enviroment" it should be possible to create a lisp image that
> includes BOOTTRAN by doing this in a lisp image:
> 
> (make-package "BOOTTRAN")
> (system-savesystem "lisp")
> 
> I'll experiment with it tonight and get back to you on it.

I've you made any progress on this issue?

\start
Date: Sat, 26 Apr 2003 12:24:46 -0400
From: Tim Daly
To: Dylan Thurston
Subject: Re:  Compiling

Dylan,

> I've successfully gotten the compiler to run, and, after some poking,
> found that obj/linux/bin/interpsys would give me a prompt at which I
> could do some computations.  But, as warned, the compilation is very
> incomplete.  I played around to try to see, e.g., why FFIELDC from
> ffcat.spad.pamphlet was not being compiled, and got to the point of
> getting a 'Value stack overflow', which is now an error I could try to
> address.  (Could it just be that some gcl limits are set too low?)

Ah, would that it were so simple... This is the primary bug that I'm
tracing. The compiler will load definitions of domains and categories
from previously compiled files in order to build the new domain or
category. You can see some of the dependency relationships in the
src/alebra/Makefile comments where I've been documenting them as I
discover them. They basically form a graph which is the source of 
the problem. I've been flattening the graph into a lattice by eliminating
cycles. There appears to be a cycle involving RING which I've been
unable to unwind. The stack overflow occurs because RING involves RING.
My usual attack on this problem is to compile the intermediate lisp code
(Axiom's compiler generates common lisp) rather than compile the Axiom
source. You can see this by looking at the bottom layer of the lattice.
(Each of the stanza's for the bottom layer target the ${MID} file rather
than the ${OUT} file.) For some obscure reason this won't work with RING.
The reason isn't obvious to me yet, thus the delay. It's not all wasted
time as I'm beginning to document how the compiler works. The compiler
was written in a coffee-induced fever and is comment-free.

An algebra rewrite is in order so that the algebra is built as a lattice.
But that won't happen for a long while.

> 
> One thing that seemed clear to me is that there must be automated
> tools for doing this; also, it doesn't seem that this is a very
> efficient use of make, since there are about 24 lines per individual
> category in the Makefile, and many different places that need to be
> changed when you want to, say, add a new file.

Well, I considered using either a common-lisp package or ANT but since
I'd already written most of it before I continued on my path.

Adding a file basically involves cloning the lines of a similar file.

Makefiles ONLY build files in the directory where the Makefile lives.
There is a Makefile for every directory in the source subtree.

Each Makefile MUST ensure that all of the preconditions for building
every subdirectory are satisfied then it walks each subdirectory calling
make in each subdirectory. Thus a leaf Makefile can assume that all of
its preconditions exist (e.g. output directories exist, other files in
other directories have been made, etc). Each non-leaf Makefile can
assume that it's preconditions exist and must only deal with files
either in its own directory or its subdirectories.

The reason the Makefiles are so verbose is that Make is unable to to
automatically handle dependencies if the files are not in the same
directory. The underlying assumption of make is that you build your
code in the directory containing the source code.

Axiom was designed to run on many different platforms and we wanted a
common source tree. In particular, it used to take one to three days of
compiling to build for a particular system (back in the day of 33Mhz).
One observation is that a large portion of the work could be cached and
shared in a read-only manner across many systems  so the "int" directory 
was born. Another observation was that there were system-specific files
that needed to be built (such as .o files) which would not be part of
the customer final image so "obj" was born. "mnt" contains only customer
shipped files. (NAG actually damaged this model by introducing "share"
but I'll fix that eventually).  "lsp" was born because I ported Axiom 
so it ran on about a dozen common lisps though some were never shipped 
because of license issues but we had private copies for test purposes.

Make is really an old tool that is unable to handle the underlying idea
that it needs to compare timestamps of files in different directories.
In order to overcome that lack (Make was all we had) the scheme was to
impose a "pull-flow" model on the stanzas. Each file is compiled because
it is required my MNT, usually from a file compiled in a platform
specific way into OBJ:

${MNT}/foo: ${OBJ}/foo

Now the OBJ file usually comes from an intermediate, cached source file:

${OBJ}/foo: ${INT}/foo

and the intermediate file was built from the source:

${INT}/foo: ${SRC}/foo

So changing a source file causes:

${SRC}/foo -> ${INT}/foo -> ${OBJ}/foo -> ${MNT}/foo

so the makefile stanzas tend to come in groups of 4 per file. 
Many times you'll find that there are less than 4 stanza's per file.

To build for a new system you need only NFS mount the SRC and INT
directories, type make and you get:

              ${INT}/foo -> ${OBJ}/foo -> ${MNT}/foo

Even a source change will only cascade a small ripple (usually) across
all the systems since only a small number of INT, OBJ, and MNT files
will have to change which is the whole point of make. And the source
change will only be done once per multiple systems, cached in INT.

(By the way, you'll notice that the Makefiles actually reference
${IN}, ${MID}, and ${OUT} instead of ${SRC}, ${INT}, ${OBJ} and ${MNT}
as there are various "IN" and "OUT" directories for different types
of files. ${IN}, etc, are constructed at the top of each Makefile.)

If make supported the notion of cross-directory timestamps the makefiles
would be less verbose. You'll note, however, that the stanzas, while
seemingly repeated copies, yet there is a lot of "special" knowledge built
in to customize the dependencies. Almost all of the customization is
there to ensure that the minimum of work is done to build the system.

I eventually reduced the 3 day builds to about 1 hour and they could
all run in parallel because SRC and INT were read-only after the first
build occurs, a factor of 48 (3*24) speedup.

Given the speed of systems these days, given the fact that users will
not be doing parallel, NFS mounted builds, given the fact that read-only
sources are not necessary for individual systems, etc. a lot of the 
assumptions that went into designing the Makefiles are invalid. 
Nevertheless, Axiom is STILL a large system and building it in a 
a simplistic manner on my 1Ghz machine STILL takes a long time whereas
the Makefiles reduce this to seconds, it probably is worthwhile rethinking
the design but "throwing it all away and doing it by brute force" is 
still a lose. 

In the cleverest of implementations the user should just be able to
NFS mount the CVS directories, type make and get a working Axiom
without ever copying the sources. In such a world you could rebuild
Axiom from savannah each time the user runs it so their image
reflects the very latest changes. No more downloads, no more tar.gz
files, etc. Axiom's makefiles could support this. Now THAT would be novel.

\start
Date: Sat, 26 Apr 2003 12:29:35 -0400
From: Tim Daly
To: David Mentre
Subject: Re:  Re: GCL version
cc: Bill Page

> A long time ago, you told me:
> 
> Tim Daly writes:
> 
> > As to the "non visibility of BOOTTRAN package in the compilation
> > enviroment" it should be possible to create a lisp image that
> > includes BOOTTRAN by doing this in a lisp image:
> > 
> > (make-package "BOOTTRAN")
> > (system-savesystem "lisp")
> > 
> > I'll experiment with it tonight and get back to you on it.
> 
> I've you made any progress on this issue?
> 

An embarassingly long time ago.... mea culpa.

Acually the question was raised before the current debugging cycle
(which has eaten all my free time). The issue is related to getting
Axiom to run on GCL 2.5 (or any current common lisp that requires
make-package before in-package). Making the packages and saving
them into a lisp image is a kludge that would be interesting for a
hand experiment. It would allow you to try to build a system, get
around the in-package bug and move on to the next bug/issue. 

Unfortunately, until I fix the algebra I have no time to look at GCL 2.5

\start
Date: 26 Apr 2003 12:30:02 -0400
From: Camm Maguire
To: David Mentre
Subject:  

Greetings!  I'm away from easy access to my email until 6/1, so
correspondence will be somewhat spotty.  When I get back, I'd like to
be able to help with gcl/axiom issues if regular work will allow.  

I've built an axiom cvs with the latest gcl a few months ago, and
basically the only changes required were of the sort you list.  GCL is
in the process of moving from the old lisp standard to the new ANSI
standard.  Right now, in-package is in between -- it does require a
make-package or defpackage before use, but right now it still is not a
macro, and does evaluate quoted arguments.  Don't rely on this in the
future, as it will change.  The right thing to do long term is as Paul
states -- write a bunch of defpackage calls in a separate file, and
load at the appropriate time.  If you would like to see an example,
look at the packages.lisp files in the pcl and clcs directories of the
gcl source.  

If you want something dirtier which might work more quickly, you can

1) fire up gcl, do all your make-package/defpackage calls, and
   (si::save-system "new-gcl-image").  Then build axiom as normal with
   the new gcl image

2) fire up gcl, redefine in-package to call make-package first
   (checking of course that it hasn't already been run), then
   save the image as above, and build as normal with the new image.

I would *not* recommend doing either of these in the long term.  But
to experiment and flush out any other possible issues, this should
work.

> Hello,
> 
> [ Sorry if I'm out of topic for this list. Please redirect me to correct
>   list if needed. ]
> 
> I'm interested in ported a software (Axiom) from gcl-2.4.4 to latest gcl
> 2.5.2.
> 
> One issue I am fighting is that some (in-package ...) statements are
> working on gcl-2.4.4 and not gcl-2.5.2.
> 
> According to Tim Daily (of Axiom fame), this issue is related to the
> fact that "Common Lisp definition has changed since Axiom was
> written. In particular, use-package used to create the package if it did
> not exist and now it does not." (quoting tim [1]).
> 
> The advice from tim[2] is to change each (in-package ...) in
> "(make-package ...) (in-package ...)".
> 
> Is it the right fix for gcl-2.5.2?
> 
> In an attempt to apply this fix, I observed a strange behaviour (to me
> ;-) that I could not explain[3] :
> 
> "
> If I do:
> -- --
> gcl> (compile-file "/path-to/boothdr.lisp" :output-file "/tmp/boothdr.o")
> -- --
> it fails on (in-package ...) S-expr.
> 
> However, if I do:
> -- --
> gcl> (make-package 'BOOTTRAN)
> gcl> (PROVIDE 'BOOTTRAN)
> gcl> (compile-file "/path-to/boothdr.lisp" :output-file "/tmp/boothdr.o")
> -- --
> it works!
> "
> 
> Moreover, as I'm new to common lisp, is anybody on this list knows a
> good reference/pointer where I could dig and try to understand all those
> package considerations?
> 
> Many thanks in advance for any help,
> Best regards,
> d.
> 
> [1] http://mail.nongnu.org/archive/html/axiom-developer/2003-03/msg00001.html
> [2] http://mail.nongnu.org/archive/html/axiom-developer/2003-03/msg00004.html
> [3] http://mail.nongnu.org/archive/html/axiom-developer/2003-03/msg00002.html
> -- 

\start
Date: 26 Apr 2003 18:36:42 +0200
From: David Mentre
To: list
Subject: Re: GCL version
cc: Bill Page

Tim Daly writes:

> Unfortunately, until I fix the algebra I have no time to look at GCL
> 2.5

Ok, no problem. I have some answers on this (in-package) issue on the
gcl-devel mailing-list so I'll try to dig into it, but do not count on
it.

\start
Date: 26 Apr 2003 18:45:11 +0200
From: David Mentre
To: list
Subject: Re:  Compiling

Tim Daly writes:

> The reason the Makefiles are so verbose is that Make is unable to to
> automatically handle dependencies if the files are not in the same
> directory. The underlying assumption of make is that you build your
> code in the directory containing the source code.

I think this is plain wrong. :)

*Multiple* Makefiles are unable to handle multiple directories, but a
*unique* Makefile handles multiple directories quite well.

You just need to prefix your targets and sources with the correct
relative path.


For example:

dir1/target1: dir1/src1.lsp dir1/src2.c dir2/src3.lsp

dir2/src3.lsp: dir2/src3.pamphlet


The only issue with this approach is the relative verbosity of the
resulting Makefile. But using some makefile variables should help.


On that subject, you should consider to have a look at:
"Recursive Make Considered Harmful "
http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html

\start
Date: Sat, 26 Apr 2003 16:13:05 -0400
From: Bill Page
To: David Mentre
Subject: RE:  Compiling

On Saturday, April 26, 2003 12:45 PM David Mentre

> ... 
> On that subject, you should consider to have a look at: 
> "Recursive Make Considered Harmful " 
> http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html
> 

Thank you David. I found the article very educational.

It seems to me that Peter Miller's observations apply
quite directly to the current Axiom makefile structure.
Perhaps the process of constructing a single make file
for Axiom would help to identify the dependency cycles
with which Tim is currently struggling. In a complete
makefile such dependencies ought to generate error
message even before the build process begins. Right?

\start
Date: 27 Apr 2003 00:03:13 +0200
From: Juergen Weiss
To: David Mentre
Subject: Re:  Compiling

for examples with GNU make you may write:

OUT=somedir
IN=otherdir
LISP=lsp

DEPLISP= util.lisp sys-pkg.lisp  .....

$(addprefix ${OUT}/, $(DEPLISP:.lisp=.${LISP})): ${OUT}/%.${LISP}: ${IN}/%.lisp
        ln -s $< $@


By the way, I think the RING category does not compile on
gcl because the value stack is too small. On cmu lisp,
RING compiles without problems.

David Mentre  writes:

> I think this is plain wrong. :)
> 
> *Multiple* Makefiles are unable to handle multiple directories, but a
> *unique* Makefile handles multiple directories quite well.
> 
> You just need to prefix your targets and sources with the correct
> relative path.
> 
> 
> For example:
> 
> dir1/target1: dir1/src1.lsp dir1/src2.c dir2/src3.lsp
> 
> dir2/src3.lsp: dir2/src3.pamphlet
> 
> 
> The only issue with this approach is the relative verbosity of the
> resulting Makefile. But using some makefile variables should help.
> 
> 
> On that subject, you should consider to have a look at:
> "Recursive Make Considered Harmful "
> http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html
> 

\start
Date: 27 Apr 2003 01:16:52 +0200
From: Juergen Weiss
To: list
Subject:  axiom on cmu cl

Hi,

I'm trying to get axiom to run on cmu cl. My main interest is
with the algebra system. The system is running with the old
parser only.  I eliminated a few files ;-). So my system
consists of the following files:

apply.x86f      daase.x86f      ggreater.x86f   info.x86f       nrunopt.x86f    simpbool.x86f
bits.x86f       database.x86f   hash.x86f       interop.x86f    nruntime.x86f   slam.x86f
bootfuns.lisp   debug.x86f      hashcode.x86f   iterator.x86f   package.x86f    spad.x86f
bootlex.lisp    def.lisp        i-analy.x86f    lisplib.x86f    parse.lisp      spaderror.x86f
bootlex.x86f    def.x86f        i-code.x86f     macros.x86f     parse.x86f      sys-pkg.lisp
br-data.x86f    define.x86f     i-coerce.x86f   makeint.lisp    parsing.lisp    template.x86f
br-util.x86f    fnewmeta.lisp   i-coerfn.x86f   match.x86f      parsing.x86f    termrw.x86f
buildom.x86f    fnewmeta.x86f   i-eval.x86f     metalex.lisp    patches.x86f    trace.x86f
c-doc.x86f      foam_l.x86f     i-funsel.x86f   metalex.x86f    pathname.x86f   union.x86f
c-util.lisp     format.x86f     i-hist.x86f     metameta.lisp   postpar.lisp    util.lisp
c-util.x86f     functor.x86f    i-intern.x86f   metameta.x86f   postpar.x86f    util.x86f
category.x86f   g-boot.lisp     i-map.x86f      modemap.x86f    preparse.lisp   vmlisp.x86f
cattable.x86f   g-boot.x86f     i-output.x86f   msgdb.x86f      preparse.x86f   xrun.x86f
clam.x86f       g-cndata.x86f   i-resolv.x86f   newaux.lisp     property.lisp   xruncomp.x86f
clammed.x86f    g-error.x86f    i-spec1.x86f    newfort.x86f    rulesets.x86f
comp.x86f       g-opt.x86f      i-spec2.x86f    nlib.x86f       setq.lisp
compat.x86f     g-timer.x86f    i-syscmd.x86f   nruncomp.x86f   setvars.x86f
compiler.x86f   g-util.lisp     i-toplev.x86f   nrunfast.x86f   setvart.lisp
compress.x86f   g-util.x86f     i-util.x86f     nrungo.x86f     showimp.x86f


Here some output from my effort:

[root@zdvnetz] > $SPAD/bin/interpsys
CMU Common Lisp 18d, running on zdvnetz.zdv.Uni-Mainz.DE
Send questions to cmucl-help@cons.org. and bug reports to cmucl-imp@cons.org.
Loaded subsystems:
    Python 1.0, target Intel x86
    CLOS based on PCL version:  September 16 92 PCL (f)
Warning:  Old-style IN-PACKAGE.
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
 
(1) -> )read "intaf.input"

;)cl all
   All user variables and function definitions have been cleared.
;x**2 / sqrt(a + b*x**3)

              2
             x
   (1)  -----------
         +--------+
         |   3
        \|b x  + a
                                                     Type: Expression Integer

;integrate(%,x)


Warning: This variable is undefined:
  |#1|
          +--------+
          |   3
        2\|b x  + a
   (2)  ------------
             3b

Warning: This variable is undefined:
  |#1|
                                          Type: Union(Expression Integer,...)



Using the old parser seems to break a few things, which I have
not figured out how to fix yet. There is a problem with macro
definitions: I am not able to compile several algebra modules
together.

Why are there two almost identical parsers at all? I like the
table driven one (as used in macsyma and reduce).

\start
Date: Mon, 28 Apr 2003 06:32:45 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re:  axiom on cmu cl

Sorry for the delay in reply. I was away in the real world. 

Awesome that you got it to compile. I'll look very carefully at what
you did. I tried expanding every possible value of GCL's memory 
control and it had no obvious effect. Perhaps I made a mistake and
I'll repeat the experiment. If that fixes the problem then it is a 
major breakthru.

I wonder if you could do me a favor. The way Axiom works with algebra
is that, during compile, it loads and calls the domain constructor.
This lives in a file called RING.NRLIB/code.lsp. The domain constructor
calls another function which is computed once and cached. It looks like:


(|/VERSIONCHECK| 2) 

(SETQ |Ring;AL| (QUOTE NIL)) 

(DEFUN |Ring| NIL 
 (LET (#:G121144) 
  (COND 
   (|Ring;AL|) 
   (T 
    (SETQ |Ring;AL| (|Ring;|)))))) 

(DEFUN |Ring;| NIL 
 (PROG (#1=#:G121142) 
  (RETURN 
   (PROG1 
    (LETT #1# 
     (|Join| 
        (|Rng|) 
        (|Monoid|)
        (|LeftModule| (QUOTE |$|))
        (|mkCategory| 
          (QUOTE |domain|)
          (QUOTE (((|characteristic| ((|NonNegativeInteger|))) T)
                  ((|coerce| (|$| (|Integer|))) T)))
          (QUOTE ((|unitsKnown| T)))
          (QUOTE ((|Integer|) (|NonNegativeInteger|))) NIL))
       |Ring|)
    (SETELT #1# 0 (QUOTE (|Ring|))))))) 

(MAKEPROP (QUOTE |Ring|) (QUOTE NILADIC) T) 

Could you trace the function |Ring|, run the following compile,
and send me the console?

)co coerce
)lisp (trace '|Ring|)
)co xpoly )con XPR

\start
Date: Mon, 28 Apr 2003 20:22:23 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re:  axiom on cmu cl

I probably sent you the tape you were using. Do you happen to still have
the original sources around? Is it possible to tar them up and put them
somewhere I can reach? My original sources are gone, IBM no longer has
any, and NAG has them on exabyte tapes but no longer has an exabyte tape
drive. 

It would be most useful to be able to diff the current sources with the
originals. It would speed up the debugging considerably. NAG rewrote
some of the inner routines in CCL specific ways and I've been unwinding
those changes.

As to the layers of parsers, compilers, redundant code, etc...

Yes, it all needs cleanup and rethinking. The Aldor compiler was originally
supposed to be in common lisp and was intended to replace the parsers and
compilers in the system. A decision was made to make it external and write
it in C instead.

There are many layers of cruft. The original code was a "chrybdis"
printing system from the 1960s and parts of it still survive. If you're
an ex-maclisp, vm/360 lisp or vm/370 lisp speaker you'll see idioms from
those languages also. There will eventually be a field called software
archeology and Axiom will be its major treasure trove.

Several times while working on the code I rewrote sections to make it
much cleaner but there were limits on what I was allowed to do. Those
limits no longer exist so the time has come to clean it up.

The first step, however, is to get it to run as most of the users don't
care how it works, only that it does work.

The second step is to document what's there and understand it better.
It is very easy to break the system if you modify the lisp without
understanding so the effort to document it is important.

Step three is to understand how it should work, write a literate document
that explains it and contains new code to replace the old functionality.

The plan is to take what I consider the best algebra system and make it
the best it can be.

\start
Date: Tue, 29 Apr 2003 12:04:10 +0200
From: Michel Lavaud
To: Bill Page
Subject:  RE: Axiom for Windows

Hello Bill,

Thanks for your answer and explanations.

> I also did some earlier experiments using Cygwin, but the
> GCL developers have moved to MinGW as the primary platform
> for Windows because it produces "native" code (does not
> depend on any non-Windows supplied libraries). The advantage
> of Cygwin however is that it does provide an X11 graphics
> environment which might be important in future gui development
> for Axiom. But I have other ideas about this based on my
> experience with TexMacs - an open source graphical mathematical
> text editor designed to interface with computer algebra
> systems.

I had bad experience some time ago with X11 server of cygwin when using 
Lyx : I couldn't type accented letters of French, and sometimes the X11 
window vanished without any notice. I suppose these problems have been 
solved but I didn't try yet.

I think that Texmacs is interesting for education, but for research I 
prefer to have total control on the input in the usual way, by entering 
formulas linearly in Emacs/Xemacs and including the result, eventually 
compiled by TeX as an image (as is done by imaxima.el for example). I have=
 
no confidence on 2D interfaces : I remember a demonstration of Scientific 
Word (Texmacs can be viewed as a free clone of SW) that gave two 
completely different results from two inputs that appeared identical on 
screen, and differed only by a few keystrokes (I don't know which ones, 
because the man who did the demonstration switched hastily to something 
else...)

So both would be desirable, in my opinion: mingw+(X)emacs for research, 
cygwin+X11+Texmacs for training and education. 

\start
Date: Tue, 29 Apr 2003 10:11:10 -0400
From: Tim Daly
To: Tim Daly Jr., Arthur Norman
Subject:  Axiom CVS access

Tim,

Please set up CVS read/write access for Arthur Norman.

\start
Date: 29 Apr 2003 09:52:48 -0400
From: Camm Maguire
To: list
Subject: Re:  axiom on cmu cl

Greetings!  [ Just a reminder, I'm still away on sabbatical until 6/1,
so correspondence will be somewhat spotty. ]

I just noticed how cmucl handled the in-package issue:

CMU Common Lisp 18d, running on zdvnetz.zdv.Uni-Mainz.DE
Send questions to cmucl-help@cons.org. and bug reports to cmucl-imp@cons.org.
Loaded subsystems:
    Python 1.0, target Intel x86
    CLOS based on PCL version:  September 16 92 PCL (f)
Warning:  Old-style IN-PACKAGE.
-----------------------------------------------------------------------------

It would be rather easy to implement this type of behavior in GCL, at
least for your development work locally, and perhaps enabled by an
environment variable so as to still pass Paul's ansi-cl tests.  I'm
only bringing this up as there were quite a few bug fixes in addition
to the ansi-cl changes in 2.4 -> 2.5.2.  2.4 should be basically
unchanged from Dr. Schelter's (high quality) work with only a few
minimal fixes.  If axiom ever worked on 2.4, it should still, but in
general, I think 2.5.2 is significantly more robust.  I'd be
interested to see if you still get the stack overflow with the newer
version.  Please let me know if you would like to try a simple patch
to package.d along these lines in 2.5.2.

Also, if you could please post a simple (as possible) set of steps
showing the bug, I'd be happy to look at it here under a debugger.

Tim Daly writes:

> Sorry for the delay in reply. I was away in the real world. 
> 
> Awesome that you got it to compile. I'll look very carefully at what
> you did. I tried expanding every possible value of GCL's memory 
> control and it had no obvious effect. Perhaps I made a mistake and
> I'll repeat the experiment. If that fixes the problem then it is a 
> major breakthru.
> 
> I wonder if you could do me a favor. The way Axiom works with algebra
> is that, during compile, it loads and calls the domain constructor.
> This lives in a file called RING.NRLIB/code.lsp. The domain constructor
> calls another function which is computed once and cached. It looks like:
> 
> 
> (|/VERSIONCHECK| 2) 
> 
> (SETQ |Ring;AL| (QUOTE NIL)) 
> 
> (DEFUN |Ring| NIL 
>  (LET (#:G121144) 
>   (COND 
>    (|Ring;AL|) 
>    (T 
>     (SETQ |Ring;AL| (|Ring;|)))))) 
> 
> (DEFUN |Ring;| NIL 
>  (PROG (#1=#:G121142) 
>   (RETURN 
>    (PROG1 
>     (LETT #1# 
>      (|Join| 
>         (|Rng|) 
>         (|Monoid|)
>         (|LeftModule| (QUOTE |$|))
>         (|mkCategory| 
>           (QUOTE |domain|)
>           (QUOTE (((|characteristic| ((|NonNegativeInteger|))) T)
>                   ((|coerce| (|$| (|Integer|))) T)))
>           (QUOTE ((|unitsKnown| T)))
>           (QUOTE ((|Integer|) (|NonNegativeInteger|))) NIL))
>        |Ring|)
>     (SETELT #1# 0 (QUOTE (|Ring|))))))) 
> 
> (MAKEPROP (QUOTE |Ring|) (QUOTE NILADIC) T) 
> 
> Could you trace the function |Ring|, run the following compile,
> and send me the console?
> 
> )co coerce
> )lisp (trace '|Ring|)
> )co xpoly )con XPR
> 

\start
Date: Tue, 29 Apr 2003 12:35:07 -0400
From: Dylan Thurston
To: Camm Maguire
Subject: Re:  axiom on cmu cl

On Tue, Apr 29, 2003 at 09:52:48AM -0400, Camm Maguire wrote:
> Greetings!  [ Just a reminder, I'm still away on sabbatical until 6/1,
> so correspondence will be somewhat spotty. ]
> 
> I just noticed how cmucl handled the in-package issue:
> ...
> It would be rather easy to implement this type of behavior in GCL, at
> least for your development work locally, ...

This sounds very easy for you; I for one would be interested in this
patch, so that I can work on more interesting issues.

\start
Date: Tue, 29 Apr 2003 18:02:22 -0400
From: Tim Daly
To: Juergen Weiss
Subject:  done

Juergen,

I have the files. Thanks much. This will greatly speed the debugging.
The RT version isn't even of academic interest :-)

Did you build your cmucl system from the CVS version of the sources 
or from your version?

\start
Date: Wed, 30 Apr 2003 15:03:54 -0400
From: Tim Daly
To: list
Subject:  bounced mail

It appears that there is a problem sending email to me at
my normal address of Tim Daly cause of some random
spam-filtering at an ISP. Several developers have complained
that they are getting bounces.

Since it is important that I don't miss Axiom messages I've
set up a mailing address that I will monitor. You can copy
either or both of these addresses.





