\start
Date: Tue, 1 Jul 2003 10:06:07 +0100
From: Mike Dewar
To: Jason White
Subject: Re: subscribing to axiom-developer, user interface issues.

Oops, I think this is because Axiom isn't being built with the OpenMath
libraries from INRIA.  I took this out when passing the sources to Tim
because of licensing issues - there is a general free license but we
have access to the libraries under a different arrangement.  You can
download the libraries at http://www.openmath.org/software/OMCv1.4a.tgz
if you're interested, but you'll need to look at the appropriate part of
CCL (src/cslbase/openmath.c which Tim has) to work out what the Lisp API
should look like.

Mike.

On Thu, Jun 26, 2003 at 11:28:39AM +1000, Jason White wrote:
> Mike Dewar writes:
>  > On Wed, Jun 25, 2003 at 07:53:47PM +1000, Jason White wrote:
>  > > While on the subject of output formats, as a longer-term goal, MathML
>  > > would probably be a useful addition.
>  > I agree.  Actually we started including OpenMath (which in a way is a
>  > superset of MathML) and were planning to include MathML once it
>  > stabilised.
>  > 
>  > G82328 (2) -> OMwrite sin(x)
> 
> Interesting. Upon issuing this command under Tim's test release I get:
> 
> (1) -> OMwrite sin(x)
>  
>    >> System error:
>    OM-STRINGTOSTRINGPTR is invalid as a function.
> 
> protected-symbol-warn called with (NIL)
> 
> Another item for the bug list?

\start
Date: Tue, 1 Jul 2003 15:13:22 -0400
From: Tim Daly
To: Mike Dewar
Subject: OM libraries

Mike,

Thanks for the OM pointer. I've downloaded the file. I'll read the
api code you suggested and figure out how to fit this into the
build. I'll be at the Libre Software meeting in Metz next week.
If you're going we should arrange to do dinner or something.

\start
Date: Mon, 14 Jul 2003 12:29:01 -0400
From: Tim Daly
To: oscas@acm.org
Subject: CATS (Computer Algebra Test Suite)

We just concluded the Libre Software Meeting in Metz.

One of the results of the meeting was an agreement to pool some of
our resources in the area of Computer Algebra systems. CA systems
have tasks that are not central to the computer algebra problem itself
such as graphics, help browsers, etc. They also need test suites.

We came to the conclusion that it is both possible and useful to
develop a test suite that can be used in common. This effort begins
now and is known as CATS, the computer algebra test suite.

I'm looking at system-independent ways of organizing the information,
similar to the GAMS effort at NIST which organizes mathematical library
code. Unfortunately that effort seems oriented toward numerical libraries.

Ideally this test suite would be adopted by all of the systems listed
in the Rosetta.tex document. I'll be contacting the various groups to
enlist their input.

If you have any comments, suggestions, or (free) sources of tests
please contact me.

\start
Date: Mon, 14 Jul 2003 12:41:16 -0400
From: Tim Daly
To: Michael Wester
Subject: CATS (Computer Algebra Test Suite)

Michael,

I sent you email last year to obtain permission to use your 
tables of system commands. It has since grown a bit to become
Rosetta.tex, a list of commands across more systems. Many of
the open source systems have been added.

We just concluded the Libre Software Meeting in Metz.

One of the results of the meeting was an agreement to pool some of
our resources in the area of Computer Algebra systems. CA systems
have tasks that are not central to the computer algebra problem itself
such as graphics, help browsers, etc. They also need test suites.

We came to the conclusion that it is both possible and useful to
develop a test suite that can be used in common. This effort begins
now and is known as CATS, the computer algebra test suite.

I'm looking at system-independent ways of organizing the information,
similar to the GAMS effort at NIST which organizes mathematical library
code. Unfortunately that effort seems oriented toward numerical libraries.

Ideally this test suite would be adopted by all of the systems listed
in the Rosetta.tex document. I'll be contacting the various groups to
enlist their input.

Since you've long been an active voice in this area I'd like to know
if you can give some feedback about this effort. Do you know of a 
classification scheme that we could readily adopt? Do you know of
freely useable examples? Do you have any suggestions regarding this
effort?

\start
Date: Mon, 14 Jul 2003 13:42:37 -0400
From: Tim Daly
To: Richard Fateman
Subject: CATS (Computer Algebra Test Suite)

Another item of note is that, unlike Wester's work, this effort is
intended to be an internal test suite. Each test will have some
discussion of the solution with some mathematical explanation and the
expected answer(s).  The intention is that each system lead developer
will code their own variation of the problem for their particular
system. A lot of the examples are expected to be "corner" cases.
This differs significantly from Wester's work (although he has quite
a range of useful examples) where he tried to rate the systems.

If a system gives an answer which differs from the expected answer
but can be shown to be correct or equivalent they can update the
test suite document. (The suite will eventually be stored in CVS
so it can be updated).

\start
Date: 14 Jul 2003 15:39:07 -0400
From: Camm Maguire
To: Richard Stallman
Subject: Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL	compliance with GNU GPL
Cc: David Turner, Sam Steingold

Greetings, and thank you so much for this helpful reply!

Richard Stallman writes, re: Readline:

> The situation with GCL is not analogous to the previous
> situation with CLISP.  At the time, CLISP was non-free.
> 
> So you don't have a problem.

OK, so I take it that technically this means that, in Sam Steingold's
approximate earlier words, that GCL has special permission to use
readline under the LGPL.  Thanks!

If this is correctly understood, we might need to know how to indicate
this on the website and/or in the COPYING files so that this issue
isn't raised again.

I'm also assuming that, now that we know this option is available,
that it is also the most desirable, including most importantly from
the 'strategic' perspective of the FSF.  To my understanding, placing
software under the GPL is 'to be strategically preferred' when it
provides a clear technical advantage over analogous software in the
closed source world.  As GCL's advantages in this respect are arguably
still somewhat tenuous, it would appear that the LGPL is the way to go
here. 

I'm including the three other options considered earlier before we
knew of this possibility below for easy reference.  If my assumptions
are incorrect and any interested parties feel that one of the choices
below is preferable to keeping readline and the LGPL for GCL as is,
please let me know.  Otherwise I'll consider this issue closed, and
place the note granting permission above on the website and in the
COPYING files in some manner to clarify the legitimacy of GCL's LGPL
license.  

Camm Maguire writes:

> Greetings, and thanks for your reply!
> 
> David Turner writes:
> 
> > On Mon, 2003-06-30 at 21:47, Camm Maguire wrote:
> > 
> > > It appears we have several options:
> > > 
> > > 1) remove or replace readline in GCL and keep the LGPL
> > > 2) make use of the clause you cite below for a multiple license
> > >         strategy depending on whether readline is linked in.
> > > 3) make GCL GPL and add a note in the COPYING file allowing
> > >         proprietary images built with proprietary standard common lisp
> > >         code. 
> > > 
> > > My first question is concerning the difference in practice between the
> > > LGPL and the GPL with the clause as in 3).  Aren't they completely
> > > equivalent?  It would not appear that option 3) would pose a
> > > significant obstacle to anyone.
> > 
> > I'm not sure I fully understand clause 3.  Note that the LGPL's section
> > 6 does impose some restrictions on software that links to the library.
> > 
> 
> As for clause 3), this refers to the paragraph GPL'ed CLISP uses to
> allow proprietary images built with the compiler, as suggested by Sam
> Steingold:
> 
> =============================================================================
> As for the users who want to build proprietary software with GCL, you
> can add a clause to GCL's COPYING file, similar to the one in the CLISP
> distribution:
> <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/clisp/clisp/COPYRIGHT?rev=HEAD>.
> 
>   This copyright does *not* cover user programs that run in CLISP and
>   third-party packages not part of CLISP, if they only reference external
>   symbols in CLISP's public packages (namely the packages COMMON-LISP,
>   COMMON-LISP-USER, KEYWORD, EXT), i.e. if they don't rely on CLISP
>   internals and would as well run in any other Common Lisp implementation.
>   Such user programs are not covered by the term "derived work" used in
>   the GNU GPL. Neither is their compiled code, i.e. the result of compiling
>   them by use of the function COMPILE-FILE. We refer to such user programs
>   as "independent work".
> 
>   You may copy and distribute memory image files generated by the
>   function SAVEINITMEM, if it was generated only from CLISP and independent
>   work, and provided that you accompany them, in the sense of section 3
>   of the GNU GPL, with the source code of CLISP - precisely the same CLISP
>   version that was used to build the memory image -, the source or compiled
>   code of the user programs needed to rebuild the memory image (source
>   code for all the parts that are not independent work, see above), and
>   a precise description how to rebuild the memory image from these.
> =============================================================================
> 
> Could you please elaborate on the restrictions implied by LGPL section
> 6 to which you refer?
> 
> 
> > > That having been said, I feel that, as long as the right to compile
> > > proprietary programs is safeguarded, the decision ought to be a
> > > strategic one made primarily by the FSF.  The code has copyright
> > > comments throughout listing primarily Dr. Schelter as the copyright
> > > holder, through a few other individuals are also named.  As the
> > > primary author is deceased, it would make sense to take some steps
> > > toward a transfer of the copyright to the FSF if this is at all
> > > possible.  I don't know if anyone else can be guaranteed to be around
> > > long enough to fulfill this role otherwise.
> > 
> > You would have to talk to RMS about FSF accepting copyright assignment,
> > and Dr. Schelter's heirs or assignees about assigning.
> 
> Unfortunately, there is very little chance I will have time for this,
> so the current situation regarding copyright assignment is likely to
> remain unchanged unless someone else volunteers.
> 
> > -Dave Turner
> > GPL Compliance Engineer
> > Support my work: http://svcs.affero.net/rm.php?r=novalis&p=FSF

\start
Date: Mon, 14 Jul 2003 16:33:28 -0400
From: Tim Daly
To: James Amundson
Subject: CATS (Computer Algebra Test Suite)

Jim,

Where can I find the current maxima test cases?

\start
Date: Mon, 14 Jul 2003 23:37:16 +0200
From: Ayal Pinkus
To: list
Subject: Some thoughts on CATS

Hi all,
I think CATS is a great initiative! However, I would at least like to 
try
to get the tests in a form where all systems could read the same tests
somehow. So here are some thoughts/proposals.

1) would it be an idea to have the test in LISP syntax? I think all
      systems have a way of reading LISP expressions, and if they
      don't, it is (or should be) easy to write a parser for LISP code.
      The nice thing about LISP syntax is that it is unambiguous and
      easy to parse (and actually, all systems are implemented in LISP
      in some form, apart from Giac).
2) tests are typically of the form "When you evaluate A you should
      get B as a result". It thus compares "(EVAL A)" with "B". However,
      we could give hints, tell the system what it is comparing. We could
      have tests like

	(VERIFY-POLY-EQUAL
	  (* (+ X 1) (+ X 1) )
	  (+ (* X X) (* 2 X) 1))

so that we will accept that ordering of the polynomial terms is not 
important, or

	(VERIFY-NUMERIC-EQUAL
	  (+ 1.1 2.2)
	  3.3)

allowing the system to compare two floats taking precision into account.
Each system will want to define these tests, VERIFY-*-EQUAL as macros
that map the operation to some functions defined in the system.

3) There should be some way to specify some system-specific 
declarations.
      Axiom is a clear example, in that it needs to know the types of 
objects. But
      other systems might for instance require some 'assume'. Systems
      are then free to skip declarations meant for other systems. I 
don't know what
      that would look like in Axiom, but hopefully that is possible?

What do you think? Is it too ambitious to try to share the code amongst 
systems?

\start
Date: Mon, 14 Jul 2003 23:55:25 +0200
From: Ayal Pinkus
To: list
Subject: Re: Some thoughts on CATS

>
> 	(VERIFY-POLY-EQUAL
> 	  (* (+ X 1) (+ X 1) )
> 	  (+ (* X X) (* 2 X) 1))
>

Ehm, that should of course be

	(VERIFY-POLY-EQUAL
	  (EXPAND  (* (+ X 1) (+ X 1) ) )
	  (+ (* X X) (* 2 X) 1))

And in the case where numeric calculations are performed we might
want to specify the number of digits precision as a third argument.

\start
Date: Mon, 14 Jul 2003 17:59:01 -0400
From: Tim Daly
To: Ayal Pinkus
Subject: Some thoughts on CATS

Ayal,

My attack on the problem involves literate programming, which should
come as no surprise. Each test case involves a tex explanation of the
mathematics of the problem and the expected result. This is followed
by code chunks for each system. Developers of the different systems
will have to write the specific test code to implement the test.  The
developer has the option to skip or include any test and have any code
executed for their specific system.

There is no common method shared by any two systems which verifies
results.  Axiom, for instance, won't accept lisp expressions as an
input form as there is no general conversion mechanism (though there
probably should be) from s-expressions to internal data structures and
back. Defining VERIFY-EQUAL functions for the Axiom domains would be
a large development effort.

Yacas can, as I see from your examples, not only runs the extracted
code but can wrap the test in a verification function. Other systems
don't have such a verification function and the expected results will
have to be verified in a different manner. In Axiom we simply diff the
resulting output files and check for changes.

Tests for yacas can be extracted by writing:

    notangle -Ryacas CATS.pamphlet

Documentation for the tests is available by writing:

    noweave CATS.pamphlet

I'm going to work up a first draft example this week so people have
something specific to complain about. I hope to post it by next week.

\start
Date: Tue, 15 Jul 2003 04:36:16 -0400
From: Tim Daly
To: oscas@acm.org
Subject: CATS (Computer Algebra Test Suite)

Excellent. I'll look at what has been done so far at this site and
consider what we can do with the two project efforts. Thanks for the
pointer.

> Am Montag, 14. Juli 2003 18:29 Tim Daly wrote:
> > One of the results of the meeting was an agreement to pool some of
> > our resources in the area of Computer Algebra systems. CA systems
> > have tasks that are not central to the computer algebra problem itself
> > such as graphics, help browsers, etc. They also need test suites. ...
> 
> We started such a project some years ago, but there was no much response yet. 
> Please have a look at http://www.symbolicdata.org. The CVS is located on the 
> UMS medicis server and you can easily join the project (with read/write 
> access) if you have an account there and belong to the group 'polydata'. The 
> main philosophy is -- at least in the current stage -- that of Open Source: 
> collect data that _you_ use in _your_ projects and put them on the Web. Agree 
> with other _interested_ people on common questions. Hence using and managing 
> these data requires some programming efforts and experience, that interested 
> people are usually familiar with. 
> 
> We developed some Perl tools that support the management of data (read 
> sd-files and create hashes, manipulate content etc.). Please consult the Web 
> documentation for more information. 
> 
> I think it is desirable to evaluate these efforts for CATS (and -- may be -- 
> even to make CATS on top of SymbolicData). 
> 
> Please note that I will be out of office for about 2 months starting next 
> week.
> 
> -- 
> Best regards, Hans-Gert Graebe

\start
Date: Tue, 15 Jul 2003 07:02:03 -0400
From: Richard Stallman
To: Camm Maguire
Subject: Re:  GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

    OK, so I take it that technically this means that, in Sam Steingold's
    approximate earlier words, that GCL has special permission to use
    readline under the LGPL.  Thanks!

We seem to be having a misunderstanding.  I did not say that.  You
can't "use readline under the LGPL".  Readline is released under the
GPL, and only the GPL.

The LGPL is compatible with the GPL.  GCL can be released under the
LGPL, and used without Readline under the LGPL.

When you combine GCL and Readline, the license that applies to the
combination is the GPL.

\start
Date: 15 Jul 2003 08:58:55 -0400
From: Camm Maguire
To: Richard Stallman
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

Greetings!  Please accept my apologies for misunderstanding your
earlier note.  I suppose its showing by this point that I'm not a
lawyer :-).

OK, allow me to try to revise my earlier email here.  I take it that
the most desirable licensing option for GCL now is what I had earlier
referred to as option 2), as you state below, licensing GCL under the
LGPL when not configured to link against readline, and under the GPL
otherwise.  I'm not sure what this imples for lisp code built using
GCL, but as the option of the original LGPL without readline is there
for the authors of such programs to use as before, it would still
appear that this option is workable.  Let us assume most
conservatively that third party lisp programs built using GCL linking
against readline must then also be distributed under the GPL.  I'm
assuming this is analogous to the situation with CLISP, i.e. the
clause allowing proprietary common lisp images making use of only a
certain interface only applies when clisp is not configured to use
readline, in which latter case the image must be distributed under the
GPL.  If this is true, then our scheme would be somewhat more friendly
to proprietary images than clisp, as without readline we replace
clisp's 'GPL + complicated standard interface clause' with LGPL.

The task then remains of how to clearly indicate this situation in the
relevant COPYING files and on the website.

Comments and corrections most welcome.

Richard Stallman writes:

>     OK, so I take it that technically this means that, in Sam Steingold's
>     approximate earlier words, that GCL has special permission to use
>     readline under the LGPL.  Thanks!
> 
> We seem to be having a misunderstanding.  I did not say that.  You
> can't "use readline under the LGPL".  Readline is released under the
> GPL, and only the GPL.
> 
> The LGPL is compatible with the GPL.  GCL can be released under the
> LGPL, and used without Readline under the LGPL.
> 
> When you combine GCL and Readline, the license that applies to the
> combination is the GPL.

\start
Date: Wed, 16 Jul 2003 15:20:23 +0200
From: David Mentre
To: list
Subject: A patch to define SPD and SYS

Hell Tim the bus driver, ;-)

Here is a small patch to main Makefile that defines SPD and SYS from
respectively pwd and $AXIOM. I hope it is the behavior you intendeed.

--- axiom-cvs-2003-06-25/new/new/Makefile.pamphlet	Sat Jul 12 18:43:08 2003
+++ axiom-cvs-2003-06-25-dm/new/new/Makefile.pamphlet	Wed Jul 16 15:10:29 2003
@@ -670,10 +670,16 @@
 file lookup is in conditional lisp code so other lisps will not 
 see the file load. The collectfn.lsp code is used by GCL to generate
 the ``.fn'' files which are used to optimize function calling.
+
+When defining the environment, the [[SPD]] variable is defined as the
+current directory. [[SYS]] is taken as the last non-directory part of
+environment variable [[$AXIOM]] (e.g. if [[$AXIOM=/(a-path)/mnt/linux]]
+then [[SYS=linux]]). It is \emph{mandatory} that [[$AXIOM]] does
+\emph{not} contain any trailing slash, because of [[notdir]] behaviour.
 <<environment>>=
 
-SPD=/home/axiomgnu/new
-SYS=linux
+SPD=$(shell pwd)
+SYS=$(notdir $(AXIOM))
 SPAD=${SPD}/mnt/${SYS}
 LSP=${SPD}/lsp
 <<GCLVERSION>>

\start
Date: Wed, 16 Jul 2003 09:01:30 -0400
From: Tim Daly
To: David Mentre
Subject: shell variables

David,

That patch works correctly.
Thanks.

(btw, in Metz it appears that "TIM" is somehow associated
with the bus company which I found amusing).

Tim

\start
Date: Wed, 16 Jul 2003 16:26:37 +0200
From: David Mentre
To: list
Subject: Patch for build steps and FAQ

Hi Tim,

Another patch for the Build steps and the FAQ:

 * for build steps, say to set AXIOM variable
 * delete item number in faq item titles, the subsection number takes
   care of that
 * added two new items (things I had to do to make Axiom build)
 * I have given the debian counterpart for needed software

Best regards,
d.

--- axiom-cvs-2003-06-25/new/new/Makefile.pamphlet	Sat Jul 12 18:43:08 2003
+++ axiom-cvs-2003-06-25-dm/new/new/Makefile.pamphlet	Wed Jul 16 16:24:34 2003
@@ -439,13 +439,14 @@
 \section{Steps in the build process}
 The sequence of steps necessary to build a clean Axiom is simply:
 \begin{verbatim}
+  export AXIOM=(path-to-your-axiom-directory)/mnt/linux
   make
 \end{verbatim}
 
 If this fails check the next section for possible problems and their
 fixes.
 \section{FAQ: Things that can go wrong}
-\subsection{(1) The SPAD variable is hard coded}
+\subsection{The SPAD variable is hard coded}
 You can put the source code anywhere. The default SPAD variable
 can be changed on the initial {\bf make} command line thus:
 \begin{verbatim}
@@ -455,19 +456,19 @@
 \end{verbatim}
 which will override the default value.
 
-\subsection{(2) Xlib.h is not found}
+\subsection{Xlib.h is not found}
 You need to have Xlib.h to build the graphics. If you are building
 on a RedHat 8 system you need to install the following RPM:
 \begin{verbatim}
-
   rpm -i XFree86-devel-4.2.0-72.i386.rpm
-
 \end{verbatim}
 A copy of this rpm (for RedHat 8) can be found in the zips directory.
 Note that if you have a different version of Linux you may need a
 different file.
 
-\subsection{(3) noweb.sty is not found}
+On Debian GNU/Linux, the package 'xlibs-dev' is needed.
+
+\subsection{noweb.sty is not found}
 The build of noweb creates 3 files in the mnt/\${SYS}/bin
 directory: notangle, noweave, and tex/noweb.sty. The build
 of the src/scripts directory copies the document command
@@ -479,7 +480,7 @@
    make start
 \end{verbatim}
 
-\subsection{(4) make hangs}
+\subsection{make hangs}
 A pamphlet file was modified and has a syntax error.
 The {\bf document} command has its output redirected
 to a file in the obj/\$\{SYS\}/tmp directory called trace.
@@ -492,7 +493,7 @@
 which will override the redirection and allow the latex
 output to go to the console.
 
-\subsection{(5) noweb needs to be rebuilt}
+\subsection{noweb needs to be rebuilt}
 The first time noweb is built a dummy file called {\bf noweb}
 is written into the top level directory. If this file is
 removed noweb will be rebuilt. The following sequence should work:
@@ -501,7 +502,7 @@
   make noweb
 \end{verbatim}
 
-\subsection{6) lisp needs to be rebuilt}
+\subsection{lisp needs to be rebuilt}
 The first time lisp is built a dummy file called {\bf gcldir}
 is written into the top level directory. If this file is
 removed lisp will be rebuilt. The following sequence should work:
@@ -510,7 +511,7 @@
   make 
 \end{verbatim}
 
-\subsection{(7) The interpreter is badly broken}
+\subsection{The interpreter is badly broken}
 If you look in src/interp/Makefile.pamphlet you'll see a
 stanza that is marked debugsys. You can add {\bf \$\{DEBUGSYS\}} to the
 {\bf all} stanza, make the system and run debugsys. This is a copy
@@ -522,7 +523,7 @@
 can play the game at this level send axiom-developer a note and we'll
 inscribe your name on a log and throw it on the fire.)
 
-\subsection{(8) The wrong version of GCL was used}
+\subsection{The wrong version of GCL was used}
 If you are building a version of Axiom on GCL there are two tested
 versions. The first is GCL-2.4.1 which is an version 1 Common Lisp.
 GCL-2.5 is a version 2 Common Lisp. There is a shell variable 
@@ -530,6 +531,25 @@
 Be sure it is set to either gcl-2.4.1, gcl-2.5 or gcl-2.5.2
 as these are the only known-good versions of gcl for Axiom.
 
+\subsection{The \texttt{-j} option of make does not work}
+
+Looking through makefiles, you'll notice that some dependencies between
+different parts of the system (for example, between layers in algebra)
+are not reflected by dependencies in Makefile. This implies that the
+\texttt{-j} option of make will not work and should not be used when
+building Axiom. This behavior is intended: once the algebra is built,
+nearly everything can be rebuilt independently of layers or
+dependencies. We could consider allowing \texttt{-j} use in the future,
+but this is not considered at the moment.
+
+\subsection{GCL does not build on my system: libbfd.a and bfd.h are
+  missing} 
+
+We are using option \texttt{--enable-statsysbfd} when building GCL (see
+lsp/Makefile) so libbfd.a and bfd.h files are necessary on your system.
+
+On Debian GNU/Linux, the needed package is 'binutils-dev'.
+
 \section{General Makefile Structure}
 
 Makefiles are responsible for four things. First, they have to set up

\start
Date: Wed, 16 Jul 2003 10:10:49 -0400
From: Tim Daly
To: David Mentre
Subject: shell variables

David,

The patches to the Makefile.pamphlet were applied.
I had already written a section on make -j so I kept my version.

\start
Date: Wed, 16 Jul 2003 17:08:27 +0200
From: David Mentre
To: Tim Daly
Subject: Re: shell variables

Tim Daly writes:

> I had already written a section on make -j so I kept my version.

Sure, thanks.

\start
Date: Wed, 16 Jul 2003 18:12:33 +0200
From: David Mentre
To: list
Subject: Setting noweb mode in Emacs to edit pamphlet files

Hello,

Thanks to a Hubert Canon on fr.comp.applications.emacs, I have put the
following code in my .emacs. It allows to have a properly configured
noweb-mode when editing pamphlet files. The minor mode is set
accordingly to the type of file (C, lisp, makefile).


;; To have noweb mode automatically
(setq auto-mode-alist
      (append '(("\\.pamphlet$"  . noweb-mode)
                ) auto-mode-alist))

                          ; many thanks to Hubert Canon for this code
(add-hook 'noweb-mode-hook 'my-noweb-set-mode-code)
(defun my-noweb-set-mode-code ()
  (let* ((filename (file-name-nondirectory buffer-file-name))
	 (mode (cond ((string-match "^Makefile" filename) 'makefile-mode)
		     ((string-match "\\.lisp\\.pamphlet" filename) 'lisp-mode)
		     ((string-match "\\.lsp\\.pamphlet" filename) 'lisp-mode)
		     ((string-match "\\.clisp\\.pamphlet" filename) 'lisp-mode)
		     ((string-match "\\.c\\.pamphlet" filename) 'c-mode)
		     ((string-match "\\.h\\.pamphlet" filename) 'c-mode)
		     (t 'fundamental-mode))))
    (noweb-set-code-mode mode)))


;; To avoid converting tabulations into spaces using AUC TeX mode
(setq TeX-auto-untabify nil)

\start
Date: Thu, 17 Jul 2003 09:42:12 +1000
From: Mike Thomas
To: Camm Maguire, Richard Stallman
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

Hi all.

| The task then remains of how to clearly indicate this situation in the
| relevant COPYING files and on the website.
|
|
| Comments and corrections most welcome.

Other (not necessarily all other) relevant items include the optional use of
the BFD library (GPL as I understand it) for linking and extracts from the
Emacs source tree for saving and loading executable images (also GPL).

BFD can be handled, in the terms that Richard seems to be proposing, by
optionally using the old GCL custom relocation code (GCL is then licenced as
LGPL) or using BFD linking (GCL licenced as GPL).  It may also be that BFD
could be linked as a dynamic library, but I personally feel that this leads
to legal and/or ethical grey areas, not to mention dependence on whatever
BFD library version happens to be sitting on any given system, which I don't
like from a software engineering design viewpoint.

With respect to the Emacs code extracts, I can't see any alternative to GCL
being licenced as GPL without getting a waiver or authorisation to use LGPL
from the copyright holders.

\start
Date: Thu, 17 Jul 2003 09:08:25 -0500
From: James Amundson
To: list
Subject: Re: CATS (Computer Algebra Test Suite)

Tim,

The maxima tests are all in the tests subdirectory of the maxima module,
which you can obtain as a tarball or as a cvs checkout from
maxima.sf.net. The tests are all in files with names like "rtest10.mac".
The format is

input1;
expected_output1$
input2;
expected_output2$

etc. Please ask if you have questions.

--Jim

On Mon, 2003-07-14 at 15:33, Tim Daly wrote:
> Jim,
> 
> Where can I find the current maxima test cases?
> 

\start
Date: 17 Jul 2003 16:48:06 -0400
From: Camm Maguire
To: list
Subject: Re: current bug

Greetings!  I just looked at this again, and have come to the
conclusion that the issue is the limit on the C stack size.  After
increasing the value stack size to taste in stacks.h, one must (at
least) also redefine MAX_STACK_SIZE in the .h file upward from its
default value of (1<<23) /* 8Mb */.  I'm trying a compile now with
double the value.  One may also have to adjust other stack limits -- I
hope to report soon.  I did verify though in gdb that the segfault in
executing the command below occurred on attempting to push the stack
pointer %esp past the 8Mb boundary, 0xbf800000.

Take care,

Tim Daly writes:

> If you have the ability to do 1+1 in an axiom interpreter
> built from the current sources then you can also try tracking
> the same bug i'm chasing at the moment. It should be the case
> that if you try to compile the XPR domain from xpoly.spad thus:
> 
> )co xpoly.spad )con XPR
> 
> you will see a value stack overflow. 
> 
> The nature of the problem is that there is a line of the form:
> 
> if R has Field
>  then ...
> 
> where, in general, Field could be replaced by other categories.
> Algebra code that contains "if R has" conditionals will not compile.
> 
> This causes an infinite loop in the compiler apparently related
> to RING.
> 
> You now have all of the basic information I have. If we can solve
> this problem it is likely that we can get the rest of the algebra
> to compile and we will have a running system.

\start
Date: Thu, 17 Jul 2003 19:55:11 -0400
From: Richard Stallman
To: Mike Thomas
Subject: Re: GCL compliance with GNU GPL
Cc: Camm Maguire, David Turner, Sam Steingold

    BFD can be handled, in the terms that Richard seems to be proposing, by
    optionally using the old GCL custom relocation code (GCL is then licenced as
    LGPL) or using BFD linking (GCL licenced as GPL).  It may also be that BFD
    could be linked as a dynamic library,

Using dynamic linking wouldn't change the consequences.

    With respect to the Emacs code extracts, I can't see any alternative to GCL
    being licenced as GPL without getting a waiver or authorisation to use LGPL
    from the copyright holders.

What are these Emacs extracts, and how big are they total?

\start
Date: Fri, 18 Jul 2003 11:13:46 +1000
From: Mike Thomas
To: Richard Stallman
Subject: Re: GCL compliance with GNU GPL
Cc: Camm Maguire, David Turner, Sam Steingold

Hi everyone.

| What are these Emacs extracts, and how big are they total?

In broad terms:

$ fgrep -i "is part of GNU emacs" o/*
grep: o/CVS: Invalid request code
o/firstfile.c:This file is part of GNU Emacs.
o/lastfile.c:This file is part of GNU Emacs.
o/ntheap.h:This file is part of GNU Emacs.
grep: o/save: Invalid request code
o/unexaix.c:This file is part of GNU Emacs.
o/unexdyld.c:This file is part of GNU Emacs.
o/unexec-19.29.c:This file is part of GNU Emacs.
o/unexec.c:This file is part of GNU Emacs.
o/unexmips.c:This file is part of GNU Emacs.
o/unexnt.c:This file is part of GNU Emacs.
o/unexnt.c:This file is part of GNU Emacs.
o/unexsgi.c:This file is part of GNU Emacs.

$ ls -l o/*file.c o/ntheap.h o/unex*
-rw-r--r--    1 miketh   Administ     1237 Jul 31  2002 o/firstfile.c
-rw-r--r--    1 miketh   Administ     1954 Jul 31  2002 o/lastfile.c
-rw-r--r--    1 miketh   Administ     1494 Feb 17 11:57 o/mingfile.c
-rw-r--r--    1 miketh   Administ     3906 Dec  7  1999 o/ntheap.h
-rw-r--r--    1 miketh   Administ    25320 Feb  1  2002 o/unexaix.c
-rw-r--r--    1 miketh   Administ    36213 Jul 18 07:09 o/unexdyld.c
-rw-r--r--    1 miketh   Administ    33765 Jul 20  2002 o/unexec-19.29.c
-rw-r--r--    1 miketh   Administ    33770 Nov  1  2002 o/unexec.c
-rw-r--r--    1 miketh   Administ    41710 Feb 17 11:57 o/unexelf.c
-rw-r--r--    1 miketh   Administ    31815 Dec  7  1999 o/unexelfsgi.c
-rw-r--r--    1 miketh   Administ     9374 Dec  7  1999 o/unexhp9k800.c
-rw-r--r--    1 miketh   Administ    27283 Jul 20  2002 o/unexlin.c
-rw-r--r--    1 miketh   Administ    10157 Feb 11 10:52 o/unexmips.c
-rw-r--r--    1 miketh   Administ    33573 Jul 11 16:06 o/unexnt.c
-rw-r--r--    1 miketh   Administ    32686 Dec  7  1999 o/unexsgi.c

We are also looking at integrating the latest unexw32.c and support files
from GNU Emacs.

I personally hope that we can retain LGPL licencing for GNU Common Lisp, but
not at the expense of trampling on the rights of the various contributors to
the GPL licenced code.

\start
Date: 17 Jul 2003 23:07:32 -0400
From: Camm Maguire
To: list
Subject: Re: current bug

Greetings!  Just a followup -- this appeared to work!  gcl will build
axiom cvs with this setting at least until the message:

make[3]: Leaving directory `/fix/s/camm/axiom/axiom1/new/new/src/algebra'
make[2]: *** No rule to make target `/fix/s/camm/axiom/axiom1/new/new/src/input/Makefile.pamphlet', needed by `/fix/s/camm/axiom/axiom1/new/new/src/input/Makefile'.  Stop.
make[2]: Leaving directory `/fix/s/camm/axiom/axiom1/new/new/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/fix/s/camm/axiom/axiom1/new/new'
make: *** [all] Error 2

Take care,

Camm Maguire writes:

> Greetings!  I just looked at this again, and have come to the
> conclusion that the issue is the limit on the C stack size.  After
> increasing the value stack size to taste in stacks.h, one must (at
> least) also redefine MAX_STACK_SIZE in the .h file upward from its
> default value of (1<<23) /* 8Mb */.  I'm trying a compile now with
> double the value.  One may also have to adjust other stack limits -- I
> hope to report soon.  I did verify though in gdb that the segfault in
> executing the command below occurred on attempting to push the stack
> pointer %esp past the 8Mb boundary, 0xbf800000.
> 
> Take care,
> 
> Tim Daly writes:
> 
> > If you have the ability to do 1+1 in an axiom interpreter
> > built from the current sources then you can also try tracking
> > the same bug i'm chasing at the moment. It should be the case
> > that if you try to compile the XPR domain from xpoly.spad thus:
> > 
> > )co xpoly.spad )con XPR
> > 
> > you will see a value stack overflow. 
> > 
> > The nature of the problem is that there is a line of the form:
> > 
> > if R has Field
> >  then ...
> > 
> > where, in general, Field could be replaced by other categories.
> > Algebra code that contains "if R has" conditionals will not compile.
> > 
> > This causes an infinite loop in the compiler apparently related
> > to RING.
> > 
> > You now have all of the basic information I have. If we can solve
> > this problem it is likely that we can get the rest of the algebra
> > to compile and we will have a running system.

\start
Date: Thu, 17 Jul 2003 23:12:18 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: current bug

Camm, 

Don't tease me. What settings? Send me a patch.

\start
Date: 17 Jul 2003 23:21:21 -0400
From: Camm Maguire <Camm Maguire>
To: Richard Stallman
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

Greetings!  The BFD library linking is a recent addition, and could be
removed if necessary, though it would force us back to
dlopen/non-permanent object loading on all but two of the 6 platforms
which we thus support at present.  If need be I suppose we could
expand on the custom reloc code already in the tree. Richard
is of course right here that static or dynamic linking is not
relevant.

The unexec routines from emacs were definitely in place when GCL was
maintained by Dr. Schelter.  Surely the license issues must have been
worked out at that time?  To my understanding, the only function
needed from emacs is unexec -- the files listed my Mike are those
needed to support this function on several architectures.

How much of an issue is it really if we just place GCL under the GPL?
Do we know of anyone who would be inconvenienced by this?

Take care,

Richard Stallman Richard Stallman writes:

>     BFD can be handled, in the terms that Richard seems to be proposing, by
>     optionally using the old GCL custom relocation code (GCL is then licenced as
>     LGPL) or using BFD linking (GCL licenced as GPL).  It may also be that BFD
>     could be linked as a dynamic library,
> 
> Using dynamic linking wouldn't change the consequences.
> 
>     With respect to the Emacs code extracts, I can't see any alternative to GCL
>     being licenced as GPL without getting a waiver or authorisation to use LGPL
>     from the copyright holders.
> 
> What are these Emacs extracts, and how big are they total?

\start
Date: Fri, 18 Jul 2003 14:35:32 +1000
From: Mike Thomas
To: Camm Maguire, Richard Stallman
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

Hi Camm.

| Greetings!  The BFD library linking is a recent addition, and could be
| removed if necessary, though it would force us back to
| dlopen/non-permanent object loading on all but two of the 6 platforms
| which we thus support at present.

That would be a shame, I think.

My understanding is that we would only need to dump BFD linking in cases
where a particular GNU Common Lisp binary distribution was to be licenced
under LGPL.

Such a binary would presumably give the author of new third-party software
developed with that GCL binary the option of not releasing the source code
to their new software.

So for example, a developer might build a GCL with custom relocation rather
than BFD, no readline and assuming that the Emacs code is subject to a
waiver, that particular build of GCL could be licenced under LGPL.  That
person could then write a spreadsheet with that LGPL GCL and sell it without
making the source code to that spreadsheet available.

By my understanding, such an example was OK within the scope of historical
GCL releases before references to BFD and readline (and possibly Emacs
unexec) entered the source tree.

If not, then I see no advantage in licencing GNU Common Lisp under LGPL and
it would save us all a lot of trouble just to go with full GPL.


| If need be I suppose we could
| expand on the custom reloc code already in the tree. Richard
| is of course right here that static or dynamic linking is not
| relevant.

I had been under the impression that a dispute existed over the issue of
dynamic linking at one time and I never found out what the outcome was,
which is why I used the phrase "grey area".  From an ethical point of view I
agree, incidentally, with yourself and Richard and on that basis I would
hope that the point of view of the courts would be so constrained.


| The unexec routines from emacs were definitely in place when GCL was
| maintained by Dr. Schelter.  Surely the license issues must have been
| worked out at that time?

My understanding also, but I felt that while we were sorting licencing out
it would be appropriate to ensure that an overall view be formed - I had
forgotten in previous discussions that these other relevant licencing
factors existed.  I am also concerned that the unexec stuff might have crept
in, historically speaking, without sufficient consideration.  I don't know
the timeline or facts of these matters myself, but I would like to know.


| To my understanding, the only function
| needed from emacs is unexec -- the files listed my Mike are those
| needed to support this function on several architectures.
|
| How much of an issue is it really if we just place GCL under the GPL?
| Do we know of anyone who would be inconvenienced by this?

As far as I know, only potential users of GCL who might one day like to
protect their software ventures by means of source code secrecy; an issue
which goes to the heart of the existence of the FSF.  It seems also,
however, that there is a moral imperative at play in terms of the intentions
of Bill Schelter who preserved the LGPL status of GCL while keeping it
alive.

In the end, I bow to the decision of yourself and the relevant FSF experts
as I am sure that you will all proceed on the merits of the project in terms
of it's potential for doing some good in this world.

\start
Date: 18 Jul 2003 09:30:08 -0400
From: Camm Maguire
To: list
Subject: Re: current bug

Greetings!

--- /fix/s/camm/gcl/o/main.c	Thu Feb 13 17:31:27 2003
+++ main.c	Thu Jul 17 16:30:18 2003
@@ -235,7 +235,7 @@
 
 #ifdef BSD
 #ifndef MAX_STACK_SIZE
-#define MAX_STACK_SIZE (1<<23) /* 8Mb */
+#define MAX_STACK_SIZE (1<<24) /* 16Mb */
 #endif
 #ifdef RLIMIT_STACK
 	getrlimit(RLIMIT_STACK, &rl);


Or just define this constant in your patch against the .h

Take care, and please let me know how it goes.  I want to make sure
the upcoming 2.5.4 build axiom without problems.


Tim Daly writes:

> Camm, 
> 
> Don't tease me. What settings? Send me a patch.
> 

\start
Date: Fri, 18 Jul 2003 15:44:03 +0200
From: David Mentre
To: Camm Maguire
Subject: Re: current bug

Hello Camm,

Camm Maguire <Camm Maguire> writes:

> Greetings!  Just a followup -- this appeared to work!  gcl will build
> axiom cvs with this setting at least until the message:
>
> make[3]: Leaving directory `/fix/s/camm/axiom/axiom1/new/new/src/algebra'
> make[2]: *** No rule to make target `/fix/s/camm/axiom/axiom1/new/new/src/input/Makefile.pamphlet', needed by `/fix/s/camm/axiom/axiom1/new/new/src/input/Makefile'.  Stop.

You should update your axiom from CVS with -d option. The input
directory was created recently.

\start
Date: Fri, 18 Jul 2003 15:47:33 +0200
From: David Mentre
To: Camm Maguire
Subject: Re: current bug

Hello Cam,

Camm Maguire <Camm Maguire> writes:

> Greetings!  I just looked at this again, and have come to the
> conclusion that the issue is the limit on the C stack size.  After
> increasing the value stack size to taste in stacks.h, one must (at
> least) also redefine MAX_STACK_SIZE in the .h file upward from its
> default value of (1<<23) /* 8Mb */.  I'm trying a compile now with
> double the value.  One may also have to adjust other stack limits 

Looking at your gcl 2.5.2 sources, I found only one occurence of
MAX_STACK_SIZE in o/main.c. However this definition is between an #ifdef
BSD. Are you sure that this value of MAX_STACK_SIZE is used under Linux?

Which value have you put to build your axiom? (1<<24) /* 16Mb */ ?

\start
Date: Fri, 18 Jul 2003 18:13:01 +0200
From: David Mentre
To: Camm Maguire
Subject: Re: current bug

Hi Camm,

I've just seen your email giving the right value tu use.

However...

David Mentre writes:

> Looking at your gcl 2.5.2 sources, I found only one occurence of
> MAX_STACK_SIZE in o/main.c. However this definition is between an #ifdef
> BSD. Are you sure that this value of MAX_STACK_SIZE is used under Linux?

...the #ifdef BSD still puzzle me.

\start
Date: 18 Jul 2003 13:27:19 -0400
From: Camm Maguire
To: Juergen Weiss
Subject: Re: Error when converting to a set

Greetings!  Does this issue persist?  If so, can it be boiled down to
a simple lisp example?

Take care,

"Juergen Weiss" writes:

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

\start
Date: Fri, 18 Jul 2003 13:47:09 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Error when converting to a set

Yes, the issue still exists. I know that it fails due to a length
computation somewhere in the Charybdis subsystem (Axiom's printing).
I have not yet found the offending bit of lisp code but I'll retry
the example after this new build completes and see if I can isolate it.

I've applied your stack patch and will also test it after this build completes.

> Greetings!  Does this issue persist?  If so, can it be boiled down to
> a simple lisp example?
> 
> Take care,
> 
> "Juergen Weiss" writes:
> 
> > The last command in coercels.input converts the result
> > to a set. With gcl, the result contains duplicate 
> > elements. Problem does not occur with cmu cl.

\start
Date: 18 Jul 2003 14:01:02 -0400
From: Camm Maguire
To: David Mentre
Subject: Re: current bug

The BSD macro is defined in the linux.h or in the subincludes.  BSD is
versus ATT, and linux is closer to BSD for these purposes.

Take care,

David Mentre writes:

> Hi Camm,
> 
> I've just seen your email giving the right value tu use.
> 
> However...
> 
> David MENTRE writes:
> 
> > Looking at your gcl 2.5.2 sources, I found only one occurence of
> > MAX_STACK_SIZE in o/main.c. However this definition is between an #ifdef
> > BSD. Are you sure that this value of MAX_STACK_SIZE is used under Linux?
> 
> ...the #ifdef BSD still puzzle me.

\start
Date: Fri, 18 Jul 2003 14:13:56 -0400
From: Tim Daly
To: list
Subject: list bug

REALLY curious behavior:

[999]
    [999]                                  Type: List PositiveInteger

[1000]
    [100]                                  Type: List PositiveInteger

[1001]
    [1001]                                 Type: List PositiveInteger

So the failure is data dependent. Sigh.
Does this failure occur on the CMUCL version also?

\start
Date: Fri, 18 Jul 2003 14:15:09 -0400
From: Tim Daly
To: list
Subject: list bug

The compile of 
   )co xpoly )con XPR
still fails with a value stack overflow.

\start
Date: Fri, 18 Jul 2003 14:31:15 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Error when converting to a set

As far as I know, yes. I'm chasing it now.

> Thanks.  Please let me know.  To my knowledge this is the only
> remaining axiom build issue which has been shown to vary with the
> underlying lisp, correct?  I just checked, and we have no known bugs
> in our ansi-test suite relating to the set functions, other than the
> type of error reported.  You may have found something new, or it may
> be an ordering issue as you've implied earlier.

\start
Date: 18 Jul 2003 14:27:50 -0400
From: Camm Maguire
To: list
Subject: Re: Error when converting to a set

Greetings!

Tim Daly writes:

> Yes, the issue still exists. I know that it fails due to a length
> computation somewhere in the Charybdis subsystem (Axiom's printing).
> I have not yet found the offending bit of lisp code but I'll retry
> the example after this new build completes and see if I can isolate it.
> 

Thanks.  Please let me know.  To my knowledge this is the only
remaining axiom build issue which has been shown to vary with the
underlying lisp, correct?  I just checked, and we have no known bugs
in our ansi-test suite relating to the set functions, other than the
type of error reported.  You may have found something new, or it may
be an ordering issue as you've implied earlier.

Take care,

> I've applied your stack patch and will also test it after this build completes.
> 
> > Greetings!  Does this issue persist?  If so, can it be boiled down to
> > a simple lisp example?
> > 
> > Take care,
> > 
> > "Juergen Weiss" writes:
> > 
> > > The last command in coercels.input converts the result
> > > to a set. With gcl, the result contains duplicate 
> > > elements. Problem does not occur with cmu cl.

\start
Date: Fri, 18 Jul 2003 14:47:11 -0400
From: Bill Page
To: list
Subject: RE: list bug

Tim,

I am sorry, but could you please explain what you find
"curious" about the results shown in your email?

Thanks.

Bill Page.

> 
> 
> REALLY curious behavior:
> 
> [999]
>     [999]                                  Type: List PositiveInteger
> 
> [1000]
>     [100]                                  Type: List PositiveInteger
> 
> [1001]
>     [1001]                                 Type: List PositiveInteger
> 
> So the failure is data dependent. Sigh.
> Does this failure occur on the CMUCL version also?

\start
Date: Fri, 18 Jul 2003 15:01:08 -0400
From: Tim Daly
To: Bill Page
Subject: Re: list bug

Bill,

The result is very data dependent. 
[1]       ==> [1]
[10]      ==> [10]
[100]     ==> [100]
[1000]    ==> [100]
[10000]   ==> [10000]
[100000]  ==> [100000]
[1000000] ==> [100000]

If you replace the 1 by a 9 in the above example they all work.

\start
Date: Fri, 18 Jul 2003 15:05:16 -0400
From: Bill Page
To: list
Subject: RE: list bug

Oh, I see. It is because [1000] displays as [100]. But this
was explained a few weeks ago by Juergen Weiss as a rounding
error in log10. Wasn't it? See

  http://mail.gnu.org/archive/html/axiom-developer/2003-06/msg00050.html

> 
> Tim,
> 
> I am sorry, but could you please explain what you find 
> "curious" about the results shown in your email?
> 
> Thanks.
> 
> Bill Page.
> 
> > 
> > REALLY curious behavior:
> > 
> > [999]
> >     [999]                                  Type: List 
> PositiveInteger
> > 
> > [1000]
> >     [100]                                  Type: List 
> PositiveInteger
> > 
> > [1001]
> >     [1001]                                 Type: List 
> PositiveInteger
> > 
> > So the failure is data dependent. Sigh.
> > Does this failure occur on the CMUCL version also?

\start
Date: Fri, 18 Jul 2003 15:52:19 -0400
From: Richard Stallman
To: Mike Thomas
Subject: Re: GCL compliance with GNU GPL
Cc: Camm Maguire, David Turner, Sam Steingold

firstfile and lastfile are trivial.  I don't think ntheap comes from
Emacs--at least I can't find it in Emacs.  Maybe it was in an older
version of Emacs.  Can you show it to me?

As for the unexec files, they are far from trivial, and I don't
see a reason to make them available for non-free software.
So I think you need to tell people that those files can only
be used in GPL-covered programs.

\start
Date: Fri, 18 Jul 2003 15:52:29 -0400
From: Richard Stallman
To: Camm Maguire
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

    How much of an issue is it really if we just place GCL under the GPL?
    Do we know of anyone who would be inconvenienced by this?

I think it would be good if GCL were under the GPL.  And the LGPL
permits changing the license to the GPL, so anyone can do that, so we
can do that.  However, if the bulk of the code was written by people
who wanted that code to be under the LGPL, there is a sense in which
it would be bad to go against their wishes.

We could say, "Some of the files are under the LGPL, and some under
the GPL.  If you want to use the combination, you must follow the
terms of the GPL."  This way, we could avoid changing the license
on code written by others.

\start
Date: 18 Jul 2003 15:27:59 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

Greetings!  Thanks as always for your input, Mike!  Please see my
other mail on some of the helpful thoughts you raise below.  Perhaps
we could next hear what the FSF would like to do?

Take care,

"Mike Thomas" writes:

> Hi Camm.
> 
> | Greetings!  The BFD library linking is a recent addition, and could be
> | removed if necessary, though it would force us back to
> | dlopen/non-permanent object loading on all but two of the 6 platforms
> | which we thus support at present.
> 
> That would be a shame, I think.
> 
> My understanding is that we would only need to dump BFD linking in cases
> where a particular GNU Common Lisp binary distribution was to be licenced
> under LGPL.
> 
> Such a binary would presumably give the author of new third-party software
> developed with that GCL binary the option of not releasing the source code
> to their new software.
> 
> So for example, a developer might build a GCL with custom relocation rather
> than BFD, no readline and assuming that the Emacs code is subject to a
> waiver, that particular build of GCL could be licenced under LGPL.  That
> person could then write a spreadsheet with that LGPL GCL and sell it without
> making the source code to that spreadsheet available.
> 
> By my understanding, such an example was OK within the scope of historical
> GCL releases before references to BFD and readline (and possibly Emacs
> unexec) entered the source tree.
> 
> If not, then I see no advantage in licencing GNU Common Lisp under LGPL and
> it would save us all a lot of trouble just to go with full GPL.
> 
> 
> | If need be I suppose we could
> | expand on the custom reloc code already in the tree. Richard
> | is of course right here that static or dynamic linking is not
> | relevant.
> 
> I had been under the impression that a dispute existed over the issue of
> dynamic linking at one time and I never found out what the outcome was,
> which is why I used the phrase "grey area".  From an ethical point of view I
> agree, incidentally, with yourself and Richard and on that basis I would
> hope that the point of view of the courts would be so constrained.
> 
> 
> | The unexec routines from emacs were definitely in place when GCL was
> | maintained by Dr. Schelter.  Surely the license issues must have been
> | worked out at that time?
> 
> My understanding also, but I felt that while we were sorting licencing out
> it would be appropriate to ensure that an overall view be formed - I had
> forgotten in previous discussions that these other relevant licencing
> factors existed.  I am also concerned that the unexec stuff might have crept
> in, historically speaking, without sufficient consideration.  I don't know
> the timeline or facts of these matters myself, but I would like to know.
> 
> 
> | To my understanding, the only function
> | needed from emacs is unexec -- the files listed my Mike are those
> | needed to support this function on several architectures.
> |
> | How much of an issue is it really if we just place GCL under the GPL?
> | Do we know of anyone who would be inconvenienced by this?
> 
> As far as I know, only potential users of GCL who might one day like to
> protect their software ventures by means of source code secrecy; an issue
> which goes to the heart of the existence of the FSF.  It seems also,
> however, that there is a moral imperative at play in terms of the intentions
> of Bill Schelter who preserved the LGPL status of GCL while keeping it
> alive.
> 
> In the end, I bow to the decision of yourself and the relevant FSF experts
> as I am sure that you will all proceed on the merits of the project in terms
> of it's potential for doing some good in this world.

\start
Date: Fri, 18 Jul 2003 17:13:34 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: list bug

Camm,

Bill Page pointed me to an email (which I either never received or
it never hit my long-term memory) from Juergen Weiss that found the
root of the display problem. The LOG10 function in GCL returns 
rounded values that are used in the output length computation
(src/interp/i-output.boot.pamphlet, line 843).

The GCL results are:
log10(100) ==> 2.0
log10(1000) ==> 2.9999999999999996

we take the floor of the results as the length of the number
giving (floor (log10 1000)) => 2 rather than 3. Patching the
generated boot.clisp code and reloading it fixes the problem.
For now I'll add a fudge factor into the boot code.

Many thanks to Juergen and Bill.

\start
Date: Fri, 18 Jul 2003 15:18:30 -0400
From: Tim Daly
To: Bill Page
Subject: Re: list bug

Ah. I never got that piece of email. Very interesting.
(my ISP is playing with SPAM filters and eats real email. very frustrating).
I'll check into it further. Many thanks.

> Oh, I see. It is because [1000] displays as [100]. But this
> was explained a few weeks ago by Juergen Weiss as a rounding
> error in log10. Wasn't it? See
> 
>   http://mail.gnu.org/archive/html/axiom-developer/2003-06/msg00050.html

\start
Date: 18 Jul 2003 15:18:03 -0400
From: Camm Maguire
To: Stavros Macrakis
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

Greetings, and thanks for your input! 

I agree that the LGPL would be better, and I think the FSF agrees too
for this application.  The problem appears to be in weighing this
against our need/desire to use readline, bfd, unexec in making GCL a
better product.  In any case, were we to go GPL, I think at the
minimum we would want to use a proprietary code allowing clause along
the lines of clisp.  I'm still not terribly clear on what the
difference is between such a setup and the LGPL.

The goal, here, IMHO, is to make GCL as beneficial to the most number
of people, users and developers, as possible, and of course to advance
the cause of free software lisp.  What that means in practice is again
dependent on an assessment of the current state of the free software
lisp world.  What stands out to me in making this assessment are
chiefly two things, 1) there are a number of high quality alternatives
to GCL available, and 2) there is a comparative dearth of free
programs being written in lisp, and/or a particular comparative
historical bias toward proprietary software in the lisp community.

Point 1) would certainly indicate that the LGPL is better for GCL in a
sense, but if that means that we have to reinvent every wheel with our
limited resources from scratch, then GCL won't measure up to the
competition in any case.  Personally, I think the best chance for long
term GCL survival, and even for the increased usage of lisp in free
software, is to capitalize on GCL's relationship with gcc, and to make
it function optionally as an official common lisp front end to
gcc. This bears on point 2), as thinking of GCL as primarily a lisp
*compiler*, the analogy with gcc would appear to clearly indicate that
one should be able to produce programs with it with the license of the
author's choosing.  gcc appears to be able to do this being licensed
under the GPL.  Perhaps this is a signpost for us.

In any case, I feel we need to hear what the FSF would like to do --
GCL is after all the official common lisp of the FSF.  It appears we
have, as before stated, two broad options (corrections welcome):

1) LGPL when not using readline/bfd.  Depends on permission to use
   unexec from emacs.
2) GPL with clisp and/or gcc text along use as a compiler of
   proprietary programs.

"Stavros Macrakis" writes:

> > How much of an issue is it really if we just place GCL under 
> > the GPL? Do we know of anyone who would be inconvenienced by this?
> 
> Camm,
> 
> Personally, I think LGPL is a better license.  It means I can write
> something and be sure it doesn't get hijacked into a commercial product,
> but doesn't prevent others from building proprietary things that depend
> on it.
> 
> Obviously, FSF disagrees.  The GPL is intended to build a brick wall
> between proprietary and GPL software.  I prefer peaceful cooperation and
> coexistence.
> 
> I find it especially annoying that the GPL prevents you from building
> something *on top of* GCL.  That is, not only would a GCL with a fancier
> GUI-building system be contaminated, but even (as in the previous
> example) a spreadsheet built on top of GCL would be.

\start
Date: Fri, 18 Jul 2003 17:54:14 -0400
From: Dylan Thurston
To: list
Subject: Re: list bug

On Fri, Jul 18, 2003 at 05:13:34PM -0400, Tim Daly wrote:
> Camm,
> 
> Bill Page pointed me to an email (which I either never received or
> it never hit my long-term memory) from Juergen Weiss that found the
> root of the display problem. The LOG10 function in GCL returns 
> rounded values that are used in the output length computation
> (src/interp/i-output.boot.pamphlet, line 843).
> 
> The GCL results are:
> log10(100) ==> 2.0
> log10(1000) ==> 2.9999999999999996
> 
> we take the floor of the results as the length of the number
> giving (floor (log10 1000)) => 2 rather than 3. Patching the
> generated boot.clisp code and reloading it fixes the problem.
> For now I'll add a fudge factor into the boot code.

I do hope you will fix this correctly.  It is very wrong to be using a
floating point log to display integers.

\start
Date: 18 Jul 2003 17:46:38 -0400
From: Camm Maguire
To: list
Subject: Re: list bug

Greetings!  Could someone please instruct me where to insert a
debugging '(format t "hello~%") statement which would enumerate the
number of recursive calls, and then tell me what the correct number
should be on a working system?  I can keep expanding the stacks, but
I'm not sure if the problem is they're being too small, or another
termination error.  

\start
Date: Fri, 18 Jul 2003 18:54:02 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: list bug

Camm,

btw, your CC list is wrong. You reference gcl-deve@gnu.org not
gcl-devel@gnu.org

> Greetings!  Could someone please instruct me where to insert a
> debugging '(format t "hello~%") statement which would enumerate the
> number of recursive calls, and then tell me what the correct number
> should be on a working system?  I can keep expanding the stacks, but
> I'm not sure if the problem is they're being too small, or another
> termination error.  

Madness lies in that direction :-)

DEBUGGING HINTS:

If you wish you can look at the clisp (boot translation), lisp (hand
written lisp) or lsp (compiler output) files, modify them, and reload
them. All of the translated code is translated to common lisp and the
common lisp lies in int/algebra and its subdirectories. Essentially
you can consider the compiler/interpreter sources to live in this
subdirectory.

You can drop into lisp by typing:
)fin
and return to the Axiom prompt by typing:
(restart)

You can issue any lisp command (e.g. call the function foo) thus:
)lisp (foo)

RECURSION ISSUE:

Axiom creates arrays of functions and does a dynamic lookup using a
macro called SPADCALL. (Look at the .lsp files in the subdirectories
under int/algebra) To see this macro expanded you can start up
Axiom and type:

)lisp (macroexpand '(spadcall a b))

Each algebra file has its own private vector and there is no central
place where recursion occurs. You can see this call-vector by doing:

1
)lisp (setq *print-array* t)
)lisp (setq *print-circle* t)
)lisp (hget |$ConstructorCache| '|Integer|)

The Axiom compiler hard-codes indexes into the call vector using the
spadcall macro.

INFINITE LOOP ISSUE:

The infinite loop happens during compilation.  I've been looking at
the compiler code trying to understand why it cannot properly walk the
inheritance chain. The infinite loop only happens if the domain you
are compiling has code of the form:

if R has X

where R is the current domain and X is a category somewhere in the
inheritance chain. In the case I've been chasing:

)co xpoly )con XPR

the chain gets walked until the category Ring is found at which point
it continues to find Ring. This leads me to believe that one of the
set functions is not quite right as the compiler keeps adding the
inherited files to be processed into a set for later analysis. I have
found only one case, so far, that changes the set definitions from
CCL (the NAG version) to GCL. 

If
(setq a '(a))
(setq b '(a b c))

(set-difference b a)

CCL ==> (b c)
GCL ==> (c b)

Both definitions are correct but the change in order changes the
way that Axiom walks the inheritance tree. Ideally Axiom's compiler
should not be sensitive to this. However, I think it is and yet I
have not yet found the sensitive code (if it exists) or proven that
it is not.

\start
Date: Fri, 18 Jul 2003 18:56:15 -0400
From: Tim Daly
To: Dylan Thurston
Subject: list bug, log10

> > we take the floor of the results as the length of the number
> > giving (floor (log10 1000)) => 2 rather than 3. Patching the
> > generated boot.clisp code and reloading it fixes the problem.
> > For now I'll add a fudge factor into the boot code.
> 
> I do hope you will fix this correctly.  It is very wrong to be using a
> floating point log to display integers.
> 

It is purely an optimization line in the code for integers.
Rather than convert the integers to strings and count the string
length we use the log10 of the integer.

\start
Date: Fri, 18 Jul 2003 22:19:11 -0400
From: Stavros Macrakis
To: Richard Stallman, Mike Thomas
Subject: Re: GCL compliance with GNU GPL
Cc: Camm Maguire, David Turner, Sam Steingold

> As for the unexec files, they are far from trivial, and I 
> don't see a reason to make them available for non-free 
> software. So I think you need to tell people that those files 
> can only be used in GPL-covered programs.

Perhaps alternatives to unexec which do not encumber applications with 
GPL terms are available.  Would Xemacs's pdumper work for GCL?  I wonder
if the Xemacs people would consider licensing pdumper, their alternative
to unexec
(http://www.xemacs.org/Releases/Public-21.2/projects/pdump.html) under
LGPL or other less restrictive license.

\start
Date: 18 Jul 2003 23:44:40 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] Re: list bug

Greetings!  Just thought I'd mention quickly how I'm debugging this
thus far.

The issue appears to be in knownInfo in info.clisp, which is called
recursively.  If one copies info.clisp into
mnt/linux/autoload/info.lsp, and moves the info.o in that directory
out of the way, then one can reproduce the same error with the
interpreted code and debugging messages to taste.  Here is what I see
so far:

=============================================================================
knownInfo called with (|has| R (|Field|))
knownInfo called with T
calling 9 with T   ((|RetractableTo| E) T 42)
knownInfo called with T
foo is NIL, (|Field|) ((|RetractableTo| E))
calling 9 with T   ((|FreeModuleCat| R E) T 41)
knownInfo called with T
foo is NIL, (|Field|) ((|FreeModuleCat| R E))
calling 9 with T   ((|XAlgebra| R) T 40)
knownInfo called with T
foo is NIL, (|Field|) ((|XAlgebra| R))
calling 9 with T   ((|XAlgebra| R) T NIL)
knownInfo called with T
foo is NIL, (|Field|) ((|XAlgebra| R))
calling 9 with (|has| R (|CommutativeRing|))   ((|Algebra| R) (|has| R (|CommutativeRing|)) 39)
knownInfo called with (|has| R (|CommutativeRing|))
knownInfo called with T
calling 9 with T   ((|RetractableTo| E) T 42)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|RetractableTo| E))
calling 9 with T   ((|FreeModuleCat| R E) T 41)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|FreeModuleCat| R E))
calling 9 with T   ((|XAlgebra| R) T 40)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with T   ((|XAlgebra| R) T NIL)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with (|has| R (|CommutativeRing|))   ((|Algebra| R) (|has| R (|CommutativeRing|)) 39)
knownInfo called with (|has| R (|CommutativeRing|))
knownInfo called with T
calling 9 with T   ((|RetractableTo| E) T 42)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|RetractableTo| E))
calling 9 with T   ((|FreeModuleCat| R E) T 41)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|FreeModuleCat| R E))
calling 9 with T   ((|XAlgebra| R) T 40)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with T   ((|XAlgebra| R) T NIL)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with (|has| R (|CommutativeRing|))   ((|Algebra| R) (|has| R (|CommutativeRing|)) 39)
knownInfo called with (|has| R (|CommutativeRing|))
knownInfo called with T
calling 9 with T   ((|RetractableTo| E) T 42)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|RetractableTo| E))
calling 9 with T   ((|FreeModuleCat| R E) T 41)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|FreeModuleCat| R E))
calling 9 with T   ((|XAlgebra| R) T 40)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with T   ((|XAlgebra| R) T NIL)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with (|has| R (|CommutativeRing|))   ((|Algebra| R) (|has| R (|CommutativeRing|)) 39)
knownInfo called with (|has| R (|CommutativeRing|))
knownInfo called with T
calling 9 with T   ((|RetractableTo| E) T 42)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|RetractableTo| E))
calling 9 with T   ((|FreeModuleCat| R E) T 41)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|FreeModuleCat| R E))
calling 9 with T   ((|XAlgebra| R) T 40)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with T   ((|XAlgebra| R) T NIL)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with (|has| R (|CommutativeRing|))   ((|Algebra| R) (|has| R (|CommutativeRing|)) 39)
knownInfo called with (|has| R (|CommutativeRing|))
knownInfo called with T
calling 9 with T   ((|RetractableTo| E) T 42)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|RetractableTo| E))
calling 9 with T   ((|FreeModuleCat| R E) T 41)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|FreeModuleCat| R E))
calling 9 with T   ((|XAlgebra| R) T 40)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with T   ((|XAlgebra| R) T NIL)
knownInfo called with T
foo is NIL, (|CommutativeRing|) ((|XAlgebra| R))
calling 9 with (|has| R (|CommutativeRing|))   ((|Algebra| R) (|has| R (|CommutativeRing|)) 39)
knownInfo called with (|has| R (|CommutativeRing|))
knownInfo called with T
calling 9 with T   ((|RetractableTo| E) T 42)
...
=============================================================================

(DEFUN |knownInfo| (|pred|) (format t "knownInfo called with ~S~%"
|pred|) (PROG (|attr| |x| |cat| |a| |vmode| |l| |LETTMP#1| |vv|
|catlist| |u| |ISTMP#1| |name| |ISTMP#2| |op| |ISTMP#3| |sig| |v|
|ww|) (RETURN (SEQ (COND ((BOOT-EQUAL |pred| (QUOTE T)) (QUOTE T))
((|member| |pred| (|get| (QUOTE |$Information|) (QUOTE |special|)
|$e|)) (QUOTE T)) ((AND (PAIRP |pred|) (EQ (QCAR |pred|) (QUOTE OR))
(PROGN (SPADLET |l| (QCDR |pred|)) (QUOTE T))) (PROG (#0=#:G4026)
(SPADLET #0# NIL) (RETURN (DO ((#1=#:G4032 NIL #0#) (#2=#:G4033 |l|
(CDR #2#)) (|u| NIL)) ((OR #1# (ATOM #2#) (PROGN (SETQ |u| (CAR #2#))
NIL)) #0#) (SEQ (EXIT (SETQ #0# (OR #0# (progn (format t "calling 1
with ~S~%" |u|) (|knownInfo| |u|)))))))))) ((AND (PAIRP |pred|) (EQ
(QCAR |pred|) (QUOTE AND)) (PROGN (SPADLET |l| (QCDR |pred|)) (QUOTE
T))) (PROG (#3=#:G4040) (SPADLET #3# (QUOTE T)) (RETURN (DO
((#4=#:G4046 NIL (NULL #3#)) (#5=#:G4047 |l| (CDR #5#)) (|u| NIL))
((OR #4# (ATOM #5#) (PROGN (SETQ |u| (CAR #5#)) NIL)) #3#) (SEQ (EXIT
(SETQ #3# (AND #3# (progn (format t "calling 2 with ~S~%" |u|)
(|knownInfo| |u|)))))))))) ((AND (PAIRP |pred|) (EQ (QCAR |pred|)
(QUOTE |or|)) (PROGN (SPADLET |l| (QCDR |pred|)) (QUOTE T))) (PROG
(#6=#:G4054) (SPADLET #6# NIL) (RETURN (DO ((#7=#:G4060 NIL #6#)
(#8=#:G4061 |l| (CDR #8#)) (|u| NIL)) ((OR #7# (ATOM #8#) (PROGN (SETQ
|u| (CAR #8#)) NIL)) #6#) (SEQ (EXIT (SETQ #6# (OR #6# (progn (format
t "calling 3 wqith ~S~%" |u|) (|knownInfo| |u|)))))))))) ((AND (PAIRP
|pred|) (EQ (QCAR |pred|) (QUOTE |and|)) (PROGN (SPADLET |l| (QCDR
|pred|)) (QUOTE T))) (PROG (#9=#:G4068) (SPADLET #9# (QUOTE T))
(RETURN (DO ((#10=#:G4074 NIL (NULL #9#)) (#11=#:G4075 |l| (CDR #11#))
(|u| NIL)) ((OR #10# (ATOM #11#) (PROGN (SETQ |u| (CAR #11#)) NIL))
#9#) (SEQ (EXIT (SETQ #9# (AND #9# (progn (format t "calling 4 with
~S~%" |u|) (|knownInfo| |u|)))))))))) ((AND (PAIRP |pred|) (EQ (QCAR
|pred|) (QUOTE ATTRIBUTE)) (PROGN (SPADLET |ISTMP#1| (QCDR |pred|))
(AND (PAIRP |ISTMP#1|) (PROGN (SPADLET |name| (QCAR |ISTMP#1|))
(SPADLET |ISTMP#2| (QCDR |ISTMP#1|)) (AND (PAIRP |ISTMP#2|) (EQ (QCDR
|ISTMP#2|) NIL) (PROGN (SPADLET |attr| (QCAR |ISTMP#2|)) (QUOTE
T))))))) (SPADLET |v| (|compForMode| |name| |$EmptyMode| |$e|)) (COND
((NULL |v|) (|stackSemanticError| (CONS (QUOTE |can't find category of
|) (CONS |name| NIL)) NIL)) ((QUOTE T) (SPADLET |LETTMP#1|
(|compMakeCategoryObject| (CADR |v|) |$e|)) (SPADLET |vv| (CAR
|LETTMP#1|)) (COND ((NULL |vv|) (|stackSemanticError| (CONS (QUOTE
|can't make category of |) (CONS |name| NIL)) NIL)) ((|member| |attr|
(ELT |vv| 2)) (QUOTE T)) ((SPADLET |x| (|assoc| |attr| (ELT |vv| 2)))
(progn (format t "calling 5 with ~S~%" (cadr |x|)) (|knownInfo| (CADR
|x|)))) ((QUOTE T) NIL))))) ((AND (PAIRP |pred|) (EQ (QCAR |pred|)
(QUOTE |has|)) (PROGN (SPADLET |ISTMP#1| (QCDR |pred|)) (AND (PAIRP
|ISTMP#1|) (PROGN (SPADLET |name| (QCAR |ISTMP#1|)) (SPADLET |ISTMP#2|
(QCDR |ISTMP#1|)) (AND (PAIRP |ISTMP#2|) (EQ (QCDR |ISTMP#2|) NIL)
(PROGN (SPADLET |cat| (QCAR |ISTMP#2|)) (QUOTE T))))))) (COND ((AND
(PAIRP |cat|) (EQ (QCAR |cat|) (QUOTE ATTRIBUTE)) (PROGN (SPADLET |a|
(QCDR |cat|)) (QUOTE T))) (progn (format t "calling 6 with ~S~%" (CONS
(QUOTE ATTRIBUTE) (CONS |name| |a|))) (|knownInfo| (CONS (QUOTE
ATTRIBUTE) (CONS |name| |a|))))) ((AND (PAIRP |cat|) (EQ (QCAR |cat|)
(QUOTE SIGNATURE)) (PROGN (SPADLET |a| (QCDR |cat|)) (QUOTE T)))
(progn (format t "calling 7 with ~S~%" (CONS (QUOTE SIGNATURE) (CONS
|name| |a|))) (|knownInfo| (CONS (QUOTE SIGNATURE) (CONS |name|
|a|))))) ((AND (PAIRP |name|) (EQ (QCAR |name|) (QUOTE |Union|))) NIL)
((QUOTE T) (SPADLET |v| (|compForMode| |name| |$EmptyMode| |$e|))
(COND ((NULL |v|) (|stackSemanticError| (CONS (QUOTE |can't find
category of |) (CONS |name| NIL)) NIL)) ((QUOTE T) (SPADLET |vmode|
(CADR |v|)) (COND ((BOOT-EQUAL |cat| |vmode|) (QUOTE T)) ((AND (PAIRP
|vmode|) (EQ (QCAR |vmode|) (QUOTE |Join|)) (PROGN (SPADLET |l| (QCDR
|vmode|)) (QUOTE T)) (|member| |cat| |l|)) (QUOTE T)) ((QUOTE T)
(SPADLET |LETTMP#1| (|compMakeCategoryObject| |vmode| |$e|)) (SPADLET
|vv| (CAR |LETTMP#1|)) (SPADLET |catlist| (ELT |vv| 4)) (COND ((NULL
|vv|) (|stackSemanticError| (CONS (QUOTE |can't make category of |)
(CONS |name| NIL)) NIL)) ((|member| |cat| (CAR |catlist|)) (QUOTE T))
((AND (SPADLET |u| (|assoc| |cat| (CADR |catlist|))) (progn (format t
"calling 8 with ~S~%" (cadr |u|)) (|knownInfo| (CADR |u|)))) (QUOTE
T)) ((PROG (#12=#:G4082) (SPADLET #12# NIL) (RETURN (DO ((#13=#:G4089
NIL #12#) (#14=#:G4090 (CADR |catlist|) (CDR #14#)) (|u| NIL)) ((OR
#13# (ATOM #14#) (PROGN (SETQ |u| (CAR #14#)) NIL)) #12#) (SEQ (EXIT
(COND ((progn (format t "calling 9 with ~S ~S~%" (cadr |u|) |u|)
(|knownInfo| (CADR |u|))) (SETQ #12# (OR #12# (let ((foo (|AncestorP|
|cat| (LIST (CAR |u|))))) (format t "foo is ~S, ~S ~S~%" foo |cat|
(list (car |u|))) foo) ))))))))) (QUOTE T)) ((QUOTE T) NIL)))))))))
((AND (PAIRP |pred|) (EQ (QCAR |pred|) (QUOTE SIGNATURE)) (PROGN
(SPADLET |ISTMP#1| (QCDR |pred|)) (AND (PAIRP |ISTMP#1|) (PROGN
(SPADLET |name| (QCAR |ISTMP#1|)) (SPADLET |ISTMP#2| (QCDR |ISTMP#1|))
(AND (PAIRP |ISTMP#2|) (PROGN (SPADLET |op| (QCAR |ISTMP#2|)) (SPADLET
|ISTMP#3| (QCDR |ISTMP#2|)) (AND (PAIRP |ISTMP#3|) (PROGN (SPADLET
|sig| (QCAR |ISTMP#3|)) (QUOTE T))))))))) (SPADLET |v| (|get| |op|
(QUOTE |modemap|) |$e|)) (DO ((#15=#:G4102 |v| (CDR #15#)) (|w| NIL))
((OR (ATOM #15#) (PROGN (SETQ |w| (CAR #15#)) NIL)) NIL) (SEQ (EXIT
(PROGN (SPADLET |ww| (CDAR |w|)) (SEQ (COND ((AND (BOOT-EQUAL (LENGTH
|ww|) (LENGTH |sig|)) (|SourceLevelSubsume| |ww| |sig|)) (COND
((BOOT-EQUAL (CAADR |w|) (QUOTE T)) (EXIT (RETURN (QUOTE
T))))))))))))) ((QUOTE T) NIL))))))
=============================================================================

Take care,

Tim Daly writes:

> Camm,
> 
> btw, your CC list is wrong. You reference gcl-deve@gnu.org not
> gcl-devel@gnu.org
> 
> > Greetings!  Could someone please instruct me where to insert a
> > debugging '(format t "hello~%") statement which would enumerate the
> > number of recursive calls, and then tell me what the correct number
> > should be on a working system?  I can keep expanding the stacks, but
> > I'm not sure if the problem is they're being too small, or another
> > termination error.  
> 
> Madness lies in that direction :-)
> 
> DEBUGGING HINTS:
> 
> If you wish you can look at the clisp (boot translation), lisp (hand
> written lisp) or lsp (compiler output) files, modify them, and reload
> them. All of the translated code is translated to common lisp and the
> common lisp lies in int/algebra and its subdirectories. Essentially
> you can consider the compiler/interpreter sources to live in this
> subdirectory.
> 
> You can drop into lisp by typing:
> )fin
> and return to the Axiom prompt by typing:
> (restart)
> 
> You can issue any lisp command (e.g. call the function foo) thus:
> )lisp (foo)
> 
> RECURSION ISSUE:
> 
> Axiom creates arrays of functions and does a dynamic lookup using a
> macro called SPADCALL. (Look at the .lsp files in the subdirectories
> under int/algebra) To see this macro expanded you can start up
> Axiom and type:
> 
> )lisp (macroexpand '(spadcall a b))
> 
> Each algebra file has its own private vector and there is no central
> place where recursion occurs. You can see this call-vector by doing:
> 
> 1
> )lisp (setq *print-array* t)
> )lisp (setq *print-circle* t)
> )lisp (hget |$ConstructorCache| '|Integer|)
> 
> The Axiom compiler hard-codes indexes into the call vector using the
> spadcall macro.
> 
> INFINITE LOOP ISSUE:
> 
> The infinite loop happens during compilation.  I've been looking at
> the compiler code trying to understand why it cannot properly walk the
> inheritance chain. The infinite loop only happens if the domain you
> are compiling has code of the form:
> 
> if R has X
> 
> where R is the current domain and X is a category somewhere in the
> inheritance chain. In the case I've been chasing:
> 
> )co xpoly )con XPR
> 
> the chain gets walked until the category Ring is found at which point
> it continues to find Ring. This leads me to believe that one of the
> set functions is not quite right as the compiler keeps adding the
> inherited files to be processed into a set for later analysis. I have
> found only one case, so far, that changes the set definitions from
> CCL (the NAG version) to GCL. 
> 
> If
> (setq a '(a))
> (setq b '(a b c))
> 
> (set-difference b a)
> 
> CCL ==> (b c)
> GCL ==> (c b)
> 
> Both definitions are correct but the change in order changes the
> way that Axiom walks the inheritance tree. Ideally Axiom's compiler
> should not be sensitive to this. However, I think it is and yet I
> have not yet found the sensitive code (if it exists) or proven that
> it is not.

\start
Date: Sat, 19 Jul 2003 09:40:17 -0400
From: Tim Daly
To: Camm Maguire
Subject: hascategory bug

Indeed, this bug is the reason that debugsys exists.
The debugsys image is built with non-compiled lisp
code so I can examine and step every function.
I forgot to mention it in my note yesterday.

\start
Date: 19 Jul 2003 21:01:05 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] hascategory bug

Greetings, and thanks for this!  I wonder if you could save me a bit
of time and detail how I can get this debugsys image built?  I've
edited debugsys.lisp.pamphlet, but to no avail.

Separately, is there a problem with the compilation of macros.lisp for
you?  If so, I've made a small improvement to the compiler which
removes the difficulty I was seeing.  The change should go in in any
case.  I can't be sure at this point however if there is a genuine
difficulty or if my problem resulted from some local changes I've been
making to my tree.  In any case I can supply a patch if needed.

Also, I see this warning repeatedly:

   Loading /fix/s/camm/axiom/axiom1/new/new/mnt/linux/autoload/package.
   Loading /fix/s/camm/axiom/axiom1/new/new/mnt/linux/autoload/htcheck.
Warning: macro table not found
   Loading /fix/s/camm/axiom/axiom1/new/new/mnt/linux/autoload/xruncomp.


as well as

Loading /fix/s/camm/axiom/axiom1/new/new/int/interp/vmlisp.lisp
Warning: EXIT is being redefined.
Finished loading /fix/s/camm/axiom/axiom1/new/new/int/interp/vmlisp.lisp

End of Pass 1.  
Warning: mkEnumerationFunList has a duplicate definition in this file
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /fix/s/camm/axiom/axiom1/new/new/obj/linux/interp/buildom.o.

End of Pass 1.  
Warning: PSETCAT-;exactQuo has a duplicate definition in this file
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling PSETCAT-.o.


Could these be related?

More later,

Tim Daly writes:

> Indeed, this bug is the reason that debugsys exists.
> The debugsys image is built with non-compiled lisp
> code so I can examine and step every function.
> I forgot to mention it in my note yesterday.

\start
Date: Sat, 19 Jul 2003 21:49:34 -0400
From: Tim Daly
To: Camm Maguire
Subject: hascategory bug

Debugsys is supposed to be built as a side-effect of the original make.
Since I'm the only one who has used it so far I haven't seen any 
problems but now I see that it has hard-coded pathnames. You need to
change the pathnames to "/fix/s/camm/axiom/axiom1/new/new/..." and
I need to change the lisp code to call a function which returns the
current pathname. Debugsys.lisp.pamphlet contains the captured commands 
that build an Axiom system. 

I'm unaware of any problems with macros.lisp. The axiom build
loads the macros into the system before compiles happen.

I'll check for the macro table warning but I don't recall ever seeing it.
I'll have to rebuild the system so I'll get back to you after I check
the rebuild.

The "EXIT is being redefined" message has been fixed by your patch
which removed EXIT from the common lisp. I have applied the patch
here but have not yet uploaded the patch.

There are a couple of duplicate function definitions and I have it
on my list of things to fix. I have to compare the definition and
uses of the functions to see how they might have changed and which
definition might be correct.

\start
Date: Sat, 19 Jul 2003 23:24:50 -0400
From: Tim Daly
To: Camm Maguire
Subject: hascategory bug

I rebuilt the system from scratch and ran all of the test cases.
The string "macro table" occurs nowhere.

\start
Date: Sun, 20 Jul 2003 12:20:17 +0200
From: David Mentre
To: Tim Daly
Subject: Re: hascategory bug
Cc: Camm Maguire

Tim Daly writes:

> I rebuilt the system from scratch and ran all of the test cases.
> The string "macro table" occurs nowhere.

On my compilation log archive, this string was occuring on Axiom CVS
2003-05-07 but not on latest Axiom CVS 2003-06-25.

So I think, Camm, that you should update your axiom tree (don't forget
the -d option to get the input/ directory like me I has done ;).

Best regards,
d.

PS : BTW, I can't never reach you through your email address
Camm Maguire. My emails are rejected with error:
<Camm Maguire>: Name service error for enhanced.com: Host not found, try
    again
Reporting-MTA: dns; wanadoo.fr

\start
Date: Sun, 20 Jul 2003 06:43:06 -0400
From: Tim Daly
To: David Mentre
Subject: savannah
Cc: Camm Maguire

I see the time has come to concentrate on getting savannah set up. 

\start
Date: Sun, 20 Jul 2003 07:22:30 -0400
From: Tim Daly
To: list
Subject: booklet function

I need a simple C program to do the following:

booklet [-v] bookletfile pamphletfile

The booklet function is basically a recursive macro-expander.

The booklet function takes as input the name of a booklet file and the
name of a pamphlet file. 

The bookletfile is any file that contains special strings of the form:
<<file:filename>>
which we will call a booklet URL. 

The booklet function replaces the whole booklet URL including the
surrounding << and >> symbols by the contents of filename.

The replaced text should be exact with no extra leading or trailing
characters so that x<<file:filename1>><<file:filename2>>y where filename1
contains a single byte 'a' and filename2 contains a single byte 'b'
should result in the inline string 'xaby'.

The replaced text is recursively searched for any instance of a
booklet URL and these are replaced inline.

The resulting text is output to the pamphletfile.

The -v flag is optional. If supplied the booklet function write the
replacement actions to standard output thus:
in (filename1) replacing <<file:filename2>> with text from (filename2)
where (filename1) is the file containing the booklet URL and
filename2 is the parsed filename from the booklet URL. This will
allow the user to trace where replacements are specified and where
the replacement came from.

If the file is not found the booklet function should fail with a clear
diagnostic traceback that outputs the containing file, the failing
booklet URL, and a recursive traceback. This should allow the user to
easily find the path of embeds that led to the failing line. The
failing booklet program should return a -1 to the shell.

Note that the filename in the booklet URL can contain a relative or
absolute pathname and will have to follow system-specific naming
conventions (forward-slash for unix, backslash for windows).

At this time only the file: protocol specifier is needed.

It should be a design criteria that the file: portion of the booklet URL
be considered one of a set of cases for a "protocol specifier" which will
be further specified in the future as needed (likely containing such
things as "http:", "pamphlet:", etc). 

It should be a design criteria that each protocol specifier has it's own
associated parser as the syntax of the booklet URL may vary based on the
protocol specifier. Thus,
<<file:filename>> parses the 'filename' portion as a path and file spec.
<<http:web>> parses the 'web' portion as any valid URL

Note that the booklet program should be developed as a literate program
and be contained in a single pamphlet file that does not use booklet URLs.
This is required so that the booklet function does not depend on itself.

(Axiom will build on multiple platforms and portions of the system will
be specified in booklet files. We need this program to be standalone
as it will be built very early in the process (even before the common
lisp). This will allow portions of the system to be written as booklet
files. The protocol specifiers will be used later to fetch pamphlet
files mentioned in the reference section of a pamphlet. Since we have
not used this feature yet there is no reason to implement anything. 
However, as we expect to use this feature in the future it is important
that the booklet function be (a) flexible enough to add other protocol
specifiers and (b) documented as a pamphlet file so others can change it.)

If this is unclear please ask questions.

\start
Date: Sun, 20 Jul 2003 14:43:49 +0200
From: David Mentre
To: list
Subject: Re: savannah
Cc: Camm Maguire

Tim Daly writes:

> I see the time has come to concentrate on getting savannah set up. 

Have you fixed the remaining bug?

\start
Date: Sun, 20 Jul 2003 10:59:43 -0400
From: Tim Daly
To: David Mentre
Subject: Re: savannah
Cc: Camm Maguire

nope. but it will be found eventually. 

\start
Date: 20 Jul 2003 12:36:58 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] hascategory bug

Greetings!  I just did a clean checkout, and I still get the 'macro
table not found' error.  Do you perhaps have an uncommitted change in
your tree?

Tim Daly writes:

> I rebuilt the system from scratch and ran all of the test cases.
> The string "macro table" occurs nowhere.

\start
Date: Sun, 20 Jul 2003 12:42:17 -0400
From: Tim Daly
To: Camm Maguire
Subject: macro table msg

Several uncommitted changes but nothing that should cause the effect
you are seeing. I'm not even sure what the message means. Is it being
issued by the common lisp? I am using gcl-2.5.2 for the build. Which
version are you build upon?

\start
Date: 20 Jul 2003 13:03:25 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] Re: list bug

Greetings!  

Have you considered something like:

(first (multiple-value-list (round (log 1000 10))))

3

?

Is this relevant to the 'duplicate member in set' bug we were
discussing earlier?  I'm referring to that reported by Juergen in:

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

Juergen Weiss

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

I still don't see where this is, but I'm still running a new build on
a fresh checkout to look for it.  To my understanding, this bug and
the hasCategory bug are the only two which appear to vary with the
underlying lisp.  And as you suspect a 'set' function in the latter as
well, they may be the same issue.  Just as a data point, I tried
loading a set-difference which reverses the order of the output to
test your hypothesis in interpsys before attempting to compile xpoly.
The compile still fails.  

BTW, please excuse my earlier hasty exuberance.  I knew something here
was recursive, and I knew axiom had to extend the stacks anyway to
some large value, so I just assumed the sequence would terminate if
there was enough room, and reported the source of the stack limitation
in my earlier email.  It does now appear to be an infinite loop.  And
while I need to verify, the infinite loop appears to lie completely
within recursively called knownInfo, being passed some erroneously
repetitive input.

I still would greatly appreciate the correct output from my earlier
posted modified knownInfo on a working system.  Also, this has
obviously worked with some gcl in the past.  Any details on the last
known working gcl setup?

Tim Daly writes:

> Camm,
> 
> Bill Page pointed me to an email (which I either never received or
> it never hit my long-term memory) from Juergen Weiss that found the
> root of the display problem. The LOG10 function in GCL returns 
> rounded values that are used in the output length computation
> (src/interp/i-output.boot.pamphlet, line 843).
> 
> The GCL results are:
> log10(100) ==> 2.0
> log10(1000) ==> 2.9999999999999996
> 
> we take the floor of the results as the length of the number
> giving (floor (log10 1000)) => 2 rather than 3. Patching the
> generated boot.clisp code and reloading it fixes the problem.
> For now I'll add a fudge factor into the boot code.
> 
> Many thanks to Juergen and Bill.

\start
Date: 20 Jul 2003 14:31:56 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] macro table msg

Greetings!

Tim Daly writes:

> Several uncommitted changes but nothing that should cause the effect
> you are seeing. I'm not even sure what the message means. Is it being
> issued by the common lisp? I am using gcl-2.5.2 for the build. Which

Yes, from /fix/s/camm/axiom/axiom1/new/new:

;buildHtMacroTable() ==
;  $htMacroTable := MAKE_-HASHTABLE 'UEQUAL
;  fn := CONCAT(getEnv '"AXIOM", '"/../../share/doc/hypertex/pages/util.ht")
;  if PROBE_-FILE(fn) then
;    instream := MAKE_-INSTREAM fn
;    while not EOFP instream repeat
;      line := READLINE instream
;      getHtMacroItem line is [string,:numOfArgs] =>
;        HPUT($htMacroTable,string,numOfArgs)
;    for [s,:n] in $primitiveHtCommands repeat HPUT($htMacroTable,s,n)
;  else
;    sayBrightly '"Warning: macro table not found"
;  $htMacroTable

(DEFUN |buildHtMacroTable| NIL (PROG (|fn| |instream| |line| |ISTMP#1| |string| |numOfArgs| |s| |n|) (RETURN (SEQ (PROGN (SPADLET |$htMacroTable| (MAKE-HASHTABLE (QUOTE UEQUAL))) (SPADLET |fn| (CONCAT (|getEnv| (MAKESTRING "AXIOM")) (MAKESTRING "/../../share/doc/hypertex/pages/util.ht"))) (COND ((PROBE-FILE |fn|) (SPADLET |instream| (MAKE-INSTREAM |fn|)) (DO NIL ((NULL (NULL (EOFP |instream|))) NIL) (SEQ (EXIT (PROGN (SPADLET |line| (READLINE |instream|)) (COND ((PROGN (SPADLET |ISTMP#1| (|getHtMacroItem| |line|)) (AND (PAIRP |ISTMP#1|) (PROGN (SPADLET |string| (QCAR |ISTMP#1|)) (SPADLET |numOfArgs| (QCDR |ISTMP#1|)) (QUOTE T)))) (HPUT |$htMacroTable| |string| |numOfArgs|))))))) (DO ((#0=#:G3615 |$primitiveHtCommands| (CDR #0#)) (#1=#:G3592 NIL)) ((OR (ATOM #0#) (PROGN (SETQ #1# (CAR #0#)) NIL) (PROGN (PROGN (SPADLET |s| (CAR #1#)) (SPADLET |n| (CDR #1#)) #1#) NIL)) NIL) (SEQ (EXIT (HPUT |$htMacroTable| |s| |n|))))) ((QUOTE T) (|sayBrightly| (MAKESTRING "Warning: macro table not found")))) |$htMacroTable|))))) 


> version are you build upon?
> 

2.5.2.

\start
Date: Sun, 20 Jul 2003 14:54:18 -0400
From: Tim Daly
To: list
Subject: Re: [Gcl-devel] macro table msg

Camm,

Clearly my mistake. My grep seems to have missed that.

>From reading the function it appears that there are a few possible cases:
(1) If $AXIOM is wrong
  If you follow $AXIOM/../../share/doc/hypertex/pages do you find util.ht?
(2)
  If the CVS is wrong. I checked my copy of the CVS and it includes the util.ht
  file. Perchance the upload failed (it has in the past). I'm in the 
  process of building a cleaned-up version of the system to upload to CVS
  on Savannah. This will take a while to complete and the import takes about
  5 hours (I'm on a modem) so even that will take a long time.
(3) 
  If your copy of the CVS is broken. Do you have a copy of the file? If not
  I've appended one here. Store it in 
  $AXIOM/../../share/doc/hypertex/pages/util.ht
  Potentially you need to add the -d option to CVS to get the 
  share/doc... subdirectory.
(4) 
  If you have an uppercase name in the path. Axiom tends to string-downcase
  pathnames because of the DOS port years ago. This is on the list of
  things to change. Until then you can't use an uppercase character in 
  paths.
(5)
  If you have a symbolic link in the path. Some pathname functions (maybe
  truename) will resolve a different path if there is a symbolic link
  in the given path. I can't construct a case at the moment but I've
  seen it happen.

You could modify the defun code and print the value of the |fn| variable
after the assignment. That will give us a clue about what getenv returned
and concat built. I can't reproduce the problem here.

\start
Date: Sun, 20 Jul 2003 15:07:28 -0400
From: Tim Daly
To: Camm Maguire
Subject: util.ht

% Copyright The Numerical Algorithms Group Limited 1992-1994.
% Certain derivative-work portions Copyright (C) 1988 by Leslie Lamport.
% All rights reserved

% ----------------------------------------------------------------------
% This file contains macros for the Axiom HyperDoc hypertext facility.
% Most of the macros for the system are here though there may be some in
% individual .ht files that are of a local nature.
% ----------------------------------------------------------------------

% ----------------------------------------------------------------------
% 1. Names of software and facilities.
% ----------------------------------------------------------------------

\newcommand{\Browse}{Browse}
\newcommand{\Language}{AXIOM}
\newcommand{\SpadName}{\Language}
\newcommand{\LangName}{\Language}
\newcommand{\HyperName}{HyperDoc}
\newcommand{\axiomxl}{AXIOM-XL}
\newcommand{\anatural}{AXIOM-XL}
\newcommand{\Clef}{Clef}
\newcommand{\Lisp}{Common LISP}
\newcommand{\naglib}{NAG Foundation Library}


% ----------------------------------------------------------------------
% 2. Special pages used by HyperDoc.
% ----------------------------------------------------------------------

\newcommand{\GoBackToWork}{\vspace{2}\newline{Click on \  \UpButton{} \  to go back to what you were doing.}}

\begin{page}{SpadNotConnectedPage}{Not Connected to AXIOM}
\beginscroll
\HyperName{} isn't connected to \Language{}, therefore cannot execute
the button you pressed.
%
\GoBackToWork{}
\endscroll
\end{page}

\begin{page}{ProtectedQuitPage}{Do You Really Want to Exit?}
\beginscroll
{Click again on \  \ExitButton{QuitPage} \  to terminate \HyperName{}.}
\vspace{1}\newline
\centerline{OR}
\GoBackToWork{}
\endscroll
\autobuttons
\end{page}

\begin{page}{UnknownPage}{Missing Page}
\beginscroll
\pp
The page you requested was not found in the \HyperName{} database.
\GoBackToWork{}
\endscroll
\end{page}

\begin{page}{ErrorPage}{Something is Wrong}
\beginscroll
{For some reason the page you tried to link to cannot be formatted.}
\GoBackToWork{}
\endscroll
\autobuttons
\end{page}

\begin{page}{Unlinked}{Sorry!}
\beginscroll
{This link is not implemented yet.}
\GoBackToWork{}
\endscroll
\autobuttons
\end{page}

% ----------------------------------------------------------------------
% 3. Special hooks to Unix.
% ----------------------------------------------------------------------

% All unix commands should be done as macros defined here so we don't
% have to go hunting when moving between Unix versions.

\newcommand{\newspadclient}[1]{xterm -n "#1" -e \$SPAD/bin/clef \$SPAD/bin/server/spadclient}
\newcommand{\searchwindow}[2]{\unixwindow{#1}{\$SPAD/lib/htsearch "#2"}}
\newcommand{\unixwindow}[2]{\unixlink{#1}{#2}}
\newcommand{\menuunixlink}[2]{\item\unixlink{\menuitemstyle{#1}}{#2}}
\newcommand{\menuunixcommand}[2]{\item\unixcommand{\menuitemstyle{#1}}{#2}}
\newcommand{\menuunixwindow}[2]{\item\unixwindow{\menuitemstyle{#1}}{#2}}

% ----------------------------------------------------------------------
% 4. HyperDoc menu macros.
% ----------------------------------------------------------------------

% Example:
%
% \beginmenu
% \menulink{Thing One}{PageOne} la da di da da ...
% \menulink{Thin Two}{PageTwo}  do da day ...
% \item \ACmdMacro{\menuitemstyle{Thing Three}} la di da ...
% \endmenu

% The menu environment

\newcommand{\beginmenu}          {\beginitems[\MenuDotBitmap]}
\newcommand{\endmenu}            {\enditems}

% This is the usual format for a menu item.

\newcommand{\menuitemstyle}[1]   {{\MenuDotBitmap}#1}

% Often-used menu item forms

%   These two simply do links
\newcommand{\menudownlink}[2]    {\item\downlink{\menuitemstyle{#1}}{#2}}
\newcommand{\menulink}[2]        {\menudownlink{#1}{#2}}

%   This will cause lower level links to have a HOME button
\newcommand{\menumemolink}[2]    {\item\memolink{\menuitemstyle{#1}}{#2}}

%   This opens a new window for the linked page.
\newcommand{\menuwindowlink}[2]    {\item\windowlink{\menuitemstyle{#1}}{#2}}

%   These execute lisp commands in various flavors
\newcommand{\menulispcommand}[2] {\item\lispcommand{\menuitemstyle{#1}}{#2}}
\newcommand{\menulispdownlink}[2]{\item\lispdownlink{\menuitemstyle{#1}}{#2}}
\newcommand{\menulispmemolink}[2]{\item\lispmemolink{\menuitemstyle{#1}}{#2}}
\newcommand{\menulispwindowlink}[2]{\item\lispwindowlink{\menuitemstyle{#1}}{#2}}

%   This executes a unix command
\newcommand{\menuunixcmd}[2]     {\item\unixcommand{\menuitemstyle{#1}}{#2}}
\newcommand{\searchresultentry}[3]{\tab{3}\item#3\tab{8}\downlink{\menuitemstyle{#1}}{#2}\newline}
\newcommand{\newsearchresultentry}[3]{\tab{3}\item#1\tab{8}\downlink{\menuitemstyle{#2}}{#3}\newline}

% ----------------------------------------------------------------------
% 5. Bitmaps and bitmap manipulation macros.
% ----------------------------------------------------------------------

\newcommand{\htbmdir}{\env{AXIOM}/../../share/doc/hypertex/bitmaps}
\newcommand{\htbmfile}[1]{\htbmdir /#1.bitmap}
\newcommand{\htbitmap}[1]{\inputbitmap{\htbmfile{#1}}}
\newcommand{\ControlBitmap}[1]{\controlbitmap{\htbmfile{#1}}}

% next group of bitmaps frequently appear in the titlebar
\newcommand{\ContinueBitmap} {\ControlBitmap{Continue}}
\newcommand{\DoItBitmap}     {\ControlBitmap{DoIt}}
\newcommand{\ExitBitmap}     {\ControlBitmap{exit3d}}
\newcommand{\HelpBitmap}     {\ControlBitmap{help3d}}
\newcommand{\ReturnBitmap}   {\ControlBitmap{home3d}}
\newcommand{\NoopBitmap}       {\ControlBitmap{noop3d}}
\newcommand{\UpBitmap}       {\ControlBitmap{up3d}}

\newcommand{\MenuDotBitmap}{\htbitmap{menudot}}

% Including control panel pixmaps for help pages:

\newcommand{\helpbit}[1]{\centerline{\inputpixmap{\env{AXIOM}/../../share/doc/hypertex/pixmaps/{#1}}}}

% ----------------------------------------------------------------------
% 6. HyperDoc button objects.
% ----------------------------------------------------------------------

\newcommand{\ContinueButton}[1]{\downlink{Click here}{#1} to continue.}
\newcommand{\ExitButton}[1]{\memolink{\ExitBitmap}{#1}}
\newcommand{\HelpButton}[1]{\memolink{\HelpBitmap}{#1}}
\newcommand{\StdHelpButton}{\HelpButton{ugHyperPage}}
\newcommand{\StdExitButton}{\ExitButton{ProtectedQuitPage}}
\newcommand{\UpButton}{\upbutton{\UpBitmap}{UpPage}}
\newcommand{\ReturnButton}{\returnbutton{\ReturnBitmap}{ReturnPage}}
\newcommand{\on}[1]{{\inputbox[1]{#1}{\htbmfile{pick}}
             {\htbmfile{unpick}}}}
\newcommand{\off}[1]{{\inputbox[0]{#1}{\htbmfile{pick}}
             {\htbmfile{unpick}}}}

% ----------------------------------------------------------------------
% 6. Standard HyperDoc button configurations.
% ----------------------------------------------------------------------

\newcommand{\autobutt}[1]{\helppage{#1}}
\newcommand{\autobuttons}{}
\newcommand{\exitbuttons}{}

\newcommand{\autobuttLayout}[1]{\centerline{#1}}}
\newcommand{\autobuttMaker}[1]{\autobuttLayout{\HelpButton{#1}}}
\newcommand{\riddlebuttons}[1]{\autobuttLayout{\link{\HelpBitmap}{#1}}}

% Macro for downward compatibility (?).

\newcommand{\simplebox}[2]{\inputbox[#1]{#2}{\htbitmap{Xbox}}{\htbitmap{Xopenbox}}}

% ----------------------------------------------------------------------
% 7. HyperDoc graphics macros.
% ----------------------------------------------------------------------

% Including viewport bitmaps within \HyperName pages:

\newcommand{\viewport}[1]{\inputimage{{#1}.VIEW/image}}
\newcommand{\axiomViewport}[1]{\inputimage{\env{AXIOM}/../../share/doc/viewports/{#1}.VIEW/image}}
\newcommand{\spadviewport}[1]{\axiomViewport{#1}}

% Creating a real live viewport:

\newcommand{\viewportbutton}[2]{\unixcommand{#1}{viewAlone #2}}
\newcommand{\axiomViewportbutton}[2]{\unixcommand{#1}{viewAlone \$AXIOM/../../share/doc/viewports/{#2}}}
\newcommand{\spadviewportbutton}[2]{\axiomViewportbutton{#1}{#2}}

% Making active viewport buttons:

\newcommand{\viewportasbutton}[1]{\unixcommand{\inputimage{{#1}.VIEW/image}}{viewAlone {#1}}}
\newcommand{\axiomViewportasbutton}[1]{\unixcommand{\inputimage{\env{AXIOM}/../../share/doc/viewports/{#1}.VIEW/image}}{viewAlone \$AXIOM/../../share/doc/viewports/{#1}}}
\newcommand{\spadviewportasbutton}[1]{\axiomViewportasbutton{#1}}

% ----------------------------------------------------------------------
% 8. TeX and LaTeX compatibility macros.
% ----------------------------------------------------------------------

%% Begin macros that are needed because HD uses the wrong names

\newcommand{\center}[1]{\centerline{#1}}
\newcommand{\box}[1]{\fbox{#1}}

%% End   macros that are needed because HD uses the wrong names

\newcommand{\LARGE}{}
\newcommand{\LaTeX}{LaTeX}
\newcommand{\Large}{}
\newcommand{\TeX}{TeX}
\newcommand{\allowbreak}{}
\newcommand{\aleph}{\inputbitmap{\htbmdir{}/aleph.bitmap}}
\newcommand{\alpha}{\inputbitmap{\htbmdir{}/alpha.bitmap}}
\newcommand{\angle}{\inputbitmap{\htbmdir{}/angle.bitmap}}
\newcommand{\backslash}{\inputbitmap{\htbmdir{}/backslash.bitmap}}
\newcommand{\beta}{\inputbitmap{\htbmdir{}/beta.bitmap}}
\newcommand{\bigbreak}{\newline\newline}
\newcommand{\bot}{\inputbitmap{\htbmdir{}/bot.bitmap}}
\newcommand{\bullet}{\inputbitmap{\htbmdir{}/bullet.bitmap}}
\newcommand{\caption}[1]{\newline\centerline{#1}\newline}
\newcommand{\chi}{\inputbitmap{\htbmdir{}/chi.bitmap}}
\newcommand{\cite}[1]{bibliography entry for {\it #1}}
\newcommand{\cleardoublepage}{}
\newcommand{\coprod}{\inputbitmap{\htbmdir{}/coprod.bitmap}}
\newcommand{\del}{\inputbitmap{\htbmdir{}/del.bitmap}}
\newcommand{\delta}{\inputbitmap{\htbmdir{}/delta.bitmap}}
\newcommand{\Delta}{\inputbitmap{\htbmdir{}/Delta.bitmap}}
\newcommand{\div}{\inputbitmap{\htbmdir{}/div.bitmap}}
\newcommand{\dot}{\inputbitmap{\htbmdir{}/dot.bitmap}}
\newcommand{\ell}{\inputbitmap{\htbmdir{}/ell.bitmap}}
\newcommand{\emptyset}{\inputbitmap{\htbmdir{}/emptyset.bitmap}}
\newcommand{\epsilon}{\inputbitmap{\htbmdir{}/epsilon.bitmap}}
\newcommand{\epsffile}{}
\newcommand{\eta}{\inputbitmap{\htbmdir{}/eta.bitmap}}
\newcommand{\exists}{\inputbitmap{\htbmdir{}/exists.bitmap}}
\newcommand{\forall}{\inputbitmap{\htbmdir{}/forall.bitmap}}
\newcommand{\footnote}[1]{ {(#1)}}
\newcommand{\frenchspacing}{}
\newcommand{\gamma}{\inputbitmap{\htbmdir{}/gamma.bitmap}}
\newcommand{\Gamma}{\inputbitmap{\htbmdir{}/Gamma.bitmap}}
\newcommand{\hbar}{\inputbitmap{\htbmdir{}/hbar.bitmap}}
\newcommand{\hbox}[1]{{#1}}
\newcommand{\hfill}{}
\newcommand{\hfil}{}
\newcommand{\huge}{}
\newcommand{\Im}{\inputbitmap{\htbmdir{}/Im.bitmap}}
\newcommand{\imath}{\inputbitmap{\htbmdir{}/imath.bitmap}}
\newcommand{\infty}{\inputbitmap{\htbmdir{}/infty.bitmap}}
\newcommand{\int}{\inputbitmap{\htbmdir{}/int.bitmap}}
\newcommand{\iota}{\inputbitmap{\htbmdir{}/iota.bitmap}}
\newcommand{\index}[1]{}
\newcommand{\jmath}{\inputbitmap{\htbmdir{}/jmath.bitmap}}
\newcommand{\kappa}{\inputbitmap{\htbmdir{}/kappa.bitmap}}
\newcommand{\label}[1]{}
\newcommand{\lambda}{\inputbitmap{\htbmdir{}/lambda.bitmap}}
\newcommand{\Lambda}{\inputbitmap{\htbmdir{}/Lambda.bitmap}}
\newcommand{\large}{}
\newcommand{\ldots}{...}
\newcommand{\le}{<=}
\newcommand{\marginpar}[1]{}
\newcommand{\mu}{\inputbitmap{\htbmdir{}/mu.bitmap}}
\newcommand{\neg}{\inputbitmap{\htbmdir{}/neg.bitmap}}
\newcommand{\newpage}{}
\newcommand{\noindent}{\indent{0}}
\newcommand{\nonfrenchspacing}{}
\newcommand{\nabla}{\inputbitmap{\htbmdir{}/nabla.bitmap}}
\newcommand{\nu}{\inputbitmap{\htbmdir{}/nu.bitmap}}
\newcommand{\omega}{\inputbitmap{\htbmdir{}/omega.bitmap}}
\newcommand{\Omega}{\inputbitmap{\htbmdir{}/Omega.bitmap}}
\newcommand{\pageref}[1]{???}
\newcommand{\parallel}{\inputbitmap{\htbmdir{}/parallel.bitmap}}
\newcommand{\partial}{\inputbitmap{\htbmdir{}/partial.bitmap}}
\newcommand{\phi}{\inputbitmap{\htbmdir{}/phi.bitmap}}
\newcommand{\Phi}{\inputbitmap{\htbmdir{}/Phi.bitmap}}
\newcommand{\pi}{\inputbitmap{\htbmdir{}/pi.bitmap}}
\newcommand{\Pi}{\inputbitmap{\htbmdir{}/Pi.bitmap}}
\newcommand{\prime}{\inputbitmap{\htbmdir{}/prime.bitmap}}
\newcommand{\prod}{\inputbitmap{\htbmdir{}/prod.bitmap}}
\newcommand{\protect}{}
\newcommand{\psi}{\inputbitmap{\htbmdir{}/psi.bitmap}}
\newcommand{\Psi}{\inputbitmap{\htbmdir{}/Psi.bitmap}}
\newcommand{\quad}{\inputbitmap{\htbmdir{}/quad.bitmap}}
\newcommand{\Re}{\inputbitmap{\htbmdir{}/Re.bitmap}}
\newcommand{\rho}{\inputbitmap{\htbmdir{}/rho.bitmap}}
\newcommand{\sc}{\rm}
\newcommand{\sf}{\bf}
\newcommand{\sigma}{\inputbitmap{\htbmdir{}/sigma.bitmap}}
\newcommand{\Sigma}{\inputbitmap{\htbmdir{}/Sigma.bitmap}}
\newcommand{\small}{}
\newcommand{\sum}{\inputbitmap{\htbmdir{}/sum.bitmap}}
\newcommand{\surd}{\inputbitmap{\htbmdir{}/surd.bitmap}}
\newcommand{\tau}{\inputbitmap{\htbmdir{}/tau.bitmap}}
\newcommand{\theta}{\inputbitmap{\htbmdir{}/theta.bitmap}}
\newcommand{\Theta}{\inputbitmap{\htbmdir{}/Theta.bitmap}}
\newcommand{\times}{\inputbitmap{\htbmdir{}/times.bitmap}}
\newcommand{\top}{\inputbitmap{\htbmdir{}/top.bitmap}}
\newcommand{\triangle}{\inputbitmap{\htbmdir{}/triangle.bitmap}}
\newcommand{\upsilon}{\inputbitmap{\htbmdir{}/upsilon.bitmap}}
\newcommand{\Upsilon}{\inputbitmap{\htbmdir{}/Upsilon.bitmap}}
\newcommand{\vbox}[1]{{#1}}
\newcommand{\wp}{\inputbitmap{\htbmdir{}/wp.bitmap}}
\newcommand{\xi}{\inputbitmap{\htbmdir{}/xi.bitmap}}
\newcommand{\Xi}{\inputbitmap{\htbmdir{}/Xi.bitmap}}
\newcommand{\zeta}{\inputbitmap{\htbmdir{}/zeta.bitmap}}
\newcommand{\bs}{\\}

% ----------------------------------------------------------------------
% 9. Book and .ht page macros.
% ----------------------------------------------------------------------

\newcommand{\beginImportant}{\horizontalline}
\newcommand{\endImportant}{\horizontalline}
%
% following handles things like "i-th" but uses "-th"
\newcommand{\eth}[1]{{#1}-th}}
%
\newcommand{\texnewline}{}
\newcommand{\texbreak}{}
\newcommand{\Gallery}{{AXIOM Images}}
\newcommand{\exptypeindex}[1]{}
\newcommand{\gotoevenpage}{}
\newcommand{\ignore}[1]{}
\newcommand{\ind}{\newline\tab{3}}
\newcommand{\labelSpace}[1]{}
\newcommand{\mathOrSpad}[1]{{\spad{#1}}}
\newcommand{\menuspadref}[2]{\menudownlink{#1}{#2Page}}
\newcommand{\menuxmpref}[1]{\menudownlink{`#1'}{#1XmpPage}}
\newcommand{\noOutputXtc}[2]{\xtc{#1}{#2}}  % comment and then \spadcommand or spadsrc
\newcommand{\not=}{\inputbitmap{\htbmdir{}/not=.bitmap}}
\newcommand{\notequal}{\inputbitmap{\htbmdir{}/notequal.bitmap}}
\newcommand{\nullXtc}[2]{\xtc{#1}{#2}}      % comment and then \spadcommand or spadsrc
\newcommand{\nullspadcommand}[1]{\spadcommand}
\newcommand{\pp}{\newline}              % Use this instead of \par for now.
\newcommand{\psXtc}[3]{\xtc{#1}{#2}}        % comment and then \spadcommand or spadsrc
\newcommand{\ref}[1]{(see the graph)}
\newcommand{\showBlurb}[1]{Issue the system command \spadcmd{)show #1} to display the full list of operations defined by \spadtype{#1}.}
\newcommand{\smath}[1]{\mathOrSpad{#1}}
\newcommand{\spadFileExt}{.spad}
\newcommand{\spadkey}[1]{}
\newcommand{\spadref} [1]{{\it #1}}
\newcommand{\spadsig}[2]{\spadtype{#1} {\tt ->} \spadtype{#2}}
\newcommand{\axiomSig}[2]{\axiomType{#1} {\tt ->} \axiomType{#2}}
\newcommand{\subscriptIt}[2]{{\it {#1}\_{#2}}}
\newcommand{\subscriptText}[2]{{\it {#1}\_{\it #2}}}
\newcommand{\subsubsection}[1]{\newline\indent{0}{\bf #1}\newline\newline}
\newcommand{\syscmdindex}[1]{}              % system command index macro
\newcommand{\threedim}{three-dimensional}
\newcommand{\twodim}{two-dimensional}
\newcommand{\unind}{\newline}
\newcommand{\void}{the unique value of \spadtype{Void}}
\newcommand{\xdefault}[1]{The default value is {\tt "#1"}.}
\newcommand{\xmpLine}[2]{{\tt #1}\newline}   % have to improve someday
\newcommand{\xmpref}[1]{\downlink{`#1'}{#1XmpPage}}
\newcommand{\xtc}[2]{#1 #2}                 % comment and then \spadcommand or spadsrc

% glossary terms
\newcommand{\axiomGloss}[1]{\lispdownlink{#1}{(|htGloss| '|#1|)}}
\newcommand{\axiomGlossSee}[2]{\lispdownlink{#1}{(|htGloss| '|#2|)}}
\newcommand{\spadgloss}[1]{\axiomGloss{#1}}
\newcommand{\spadglossSee}[2]{\axiomGlossSee{#1}{#2}}

% use this for syntax punctuation: \axiomSyntax{::}
\newcommand{\axiomSyntax}[1]{``{\tt #1}''}
\newcommand{\spadSyntax}[1]{\axiomSyntax{#1}}

% constructors
\newcommand{\axiomType}[1]{\lispdownlink{#1}{(|spadType| '|#1|)}}
\newcommand{\spadtype}[1]{\axiomType{#1}}
\newcommand{\nonLibAxiomType}[1]{{\it #1}}       % things that browse can't handle
\newcommand{\pspadtype}[1]{\nonLibAxiomType{#1}}

\newcommand{\axiom}   [1]{{\tt #1}}              % note font
\newcommand{\spad}    [1]{\axiom{#1}}
\newcommand{\spadvar} [1]{\axiom{#1}}            % exists in ++ comments; to be removed
\newcommand{\s}       [1]{\axiom{#1}}

\newcommand{\httex}[2]{#1}
\newcommand{\texht}[2]{#2}

% Function names:
%
% The X versions below are used because AXIOM function names that end
% in ``!'' cause problems for makeindex for had-copy.
%
% Example: \spadfunFromX{reverse}{List} prints as   reverse!
%
% In the "From" versions, the first arg is function name, second is constructor
% where exported.
%
% Use the "op" flavors of "-", "+", "*" etc, otherwise the "fun" flavors

\newcommand{\userfun} [1]{{\bf #1}}              % example, non-library function names

\newcommand{\fakeAxiomFun}[1]{{\bf #1}}          % not really a library function
\newcommand{\pspadfun} [1]{\fakeAxiomFun{#1}}

\newcommand{\axiomFun} [1]{\lispdownlink{#1}{(|oPage| '|#1|)}}
\newcommand{\spadfun} [1]{\axiomFun{#1}}
\newcommand{\axiomFunX}[1]{\axiomFun{#1!}}
\newcommand{\spadfunX}[1]{\axiomFun{#1!}}

\newcommand{\axiomFunFrom}[2]{\lispdownlink{#1}{(|oPageFrom| '|#1| '|#2|)}}
\newcommand{\spadfunFrom}[2]{\axiomFunFrom{#1}{#2}}
\newcommand{\axiomFunFromX}[2]{\axiomFunFrom{#1!}{#2}}
\newcommand{\spadfunFromX}[2]{\axiomFunFrom{#1!}{#2}}

\newcommand{\axiomOp} [1]{\lispdownlink{#1}{(|oPage| '|#1|)}}
\newcommand{\spadop}  [1]{\axiomOp{#1}}
\newcommand{\axiomOpX}[1]{\axiomOp{#1!}}

\newcommand{\axiomOpFrom}[2]{\lispdownlink{#1}{(|oPageFrom| '|#1| '|#2|)}}
\newcommand{\spadopFrom} [2]{\axiomOpFrom{#1}{#2}}
\newcommand{\axiomOpFromX}[2] {\axiomOpFrom{#1!}{#2}}
\newcommand{\spadopFromX}[2] {\axiomOpFrom{#1!}{#2}}

% redundant defns for system commands
\newcommand{\syscom}[1]{\lispdownlink{)#1}{(|syscomPage| '|#1|)}}
%
\newcommand{\spadsyscom}[1]{{\tt #1}}
\newcommand{\spadcmd}[1]{\spadsyscom{#1}}
\newcommand{\spadsys}[1]{\spadsyscom{#1}}


% Following macros should be phased out in favor of ones above:

\newcommand{\gloss}[1]{\axiomGloss{#1}}
\newcommand{\spadglos}[1]{\axiomGloss{#1}}
\newcommand{\glossSee}[2]{\axiomGlossSee{#1}{#2}}

% ----------------------------------------------------------------------
% 10. Browse macros.
% ----------------------------------------------------------------------

\newcommand{\undocumented}[0]{is not documented yet}
\newcommand{\aliascon}[2]{\lispdownlink{#1}{(|conPage| '|#2|)}}
\newcommand{\aliasdom}[2]{\lispdownlink{#1}{(|conPage| '|#2|)}}
\newcommand{\andexample}[1]{\indent{5}\spadcommand{#1}\indent{0}\newline}
\newcommand{\blankline}{\vspace{1}\newline }
\newcommand{\con}[1]{\lispdownlink{#1}{(|conPage| '|#1|)}}

\newcommand{\conf}[2]{\lispdownlink{#1}{(|conPage| '{#2})}}
% generalizes "con" to allow arbitrary title and form

\newcommand{\ops}[3]{\lisplink{#1}{(|conOpPage| #2 '{#3})}}
% does lisplink to operation page of a constructor or form
% #1 is constructor name or form, without fences, e.g. "Matrix(Integer)"
% #2 is page number, extracted from $curPage (see fromHeading/dbOpsForm)
% #3 is constructor name or form, with fences, e.g. "(|Matrix| (|Integer|))"

\newcommand{\dlink}[2]{\downlink{#2}{#1}}
\newcommand{\dom}[1]{\lispdownlink{#1}{(|conPage| '|#1|)}}
\newcommand{\example}[1]{\newline\indent{5}\spadcommand{#1}\indent{0}\newline}
\newcommand{\lisp}[2]{\lispdownlink{#2}{#1}}
\newcommand{\spadatt} [1]{{\it #1}}
\newcommand{\indented}[2]{\indentrel{#1}\newline #2\indentrel{-#1}\newline}
\newcommand{\keyword}[1]{\lispdownlink{#1}{(|htsn| '|#1|)}}
\newcommand{\op}[1]{\lispdownlink{#1}{(|htsn| '|#1|)}}
\newcommand{\spadignore}[1]{#1}

% ----------------------------------------------------------------------
% 11. Support for output and graph paste-ins.
% ----------------------------------------------------------------------

\newcommand{\axiomcommand}[1]{\spadcommand{#1}}
\newcommand{\axiomgraph}[1]{\spadgraph{#1}}

\newcommand{\pastecommand}[1]{\spadpaste{#1}}
\newcommand{\pastegraph}[1]{\graphpaste{#1}}

\newcommand{\showpaste}{\htbitmap{sdown3d}}
\newcommand{\hidepaste}{\htbitmap{sup3d}}
\newcommand{\spadpaste}[1]{
  \newline
  \begin{paste}{\pagename Empty \examplenumber}{\pagename Patch \examplenumber}
  \pastebutton{\pagename Empty \examplenumber}{\showpaste}
  \tab{5}\spadcommand{#1}
  \end{paste}
}

\newcommand{\graphpaste}[1]{
  \newline
  \begin{paste}{\pagename Empty \examplenumber}{\pagename Patch \examplenumber}
  \pastebutton{\pagename Empty \examplenumber}{\showpaste}
  \tab{5}\spadgraph{#1}
  \end{paste}
}

% ----------------------------------------------------------------------
% 12. Hook for including a local menu item on the rootpage.
% ----------------------------------------------------------------------

\newcommand{\localinfo}{}

\start
Date: Sun, 20 Jul 2003 21:01:18 +0200
From: Juergen Weiss
To: Camm Maguire
Subject: RE: [Gcl-devel] Re: list bug

Hi,

the inaccuracy in log is independent of the other problems.
I do not know how accurate the calculation of the width
of objects must be calculated to get reasonably placed
output. Is it better to overestimate the space needed?
If the output routines require exact width calculations,
one should consider to calculate the exact print width.
Besides, is the calculation of a logarithm really less
expensive than the exact integer calculation for a 
fixnum (bignums are handled differently)? Even if it is,
does it matter?

> Greetings!  
> 
> Have you considered something like:
> 
> (first (multiple-value-list (round (log 1000 10))))
> 
> 3
> 
> ?
> 
> Is this relevant to the 'duplicate member in set' bug we were
> discussing earlier?  I'm referring to that reported by Juergen in:
> 

\start
Date: Sun, 20 Jul 2003 15:13:26 -0400
From: Tim Daly
To: Camm Maguire
Subject: util.ht

The i-output.boot.pamphlet file has been modified to change the test slightly.
We add a simple fudge-factor as a temporary measure until log10 computes
correct values. The code was: 
    u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR LOG10 u
and is now:
    u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR ((LOG10 u) + 0.0000001)

The attached diff:

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

--- i-output.boot.pamphlet	Sun Jul 20 15:10:37 2003
+++ i-output.boot.pamphlet.tpd	Sun Jul 20 15:12:16 2003
@@ -9,6 +9,26 @@
 \eject
 \tableofcontents
 \eject
+\section{GCL_log10_bug}
+In some versions of GCL the LOG10 function returns improperly rounded values.
+The symptom is:
+\begin{verbatim}
+(24) -> [1000]
+   (24)  [100]
+\end{verbatim}
+The common lisp failure can be shown with:
+\begin{verbatim}
+(25) -> )lisp (log10 1000)
+Value = 2.9999999999999996
+\end{verbatim}
+This previous boot code was:
+\begin{verbatim}
+    u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR LOG10 u
+\end{verbatim}
+and should be restored when the GCL bug is fixed.
+<<GCL_log10_bug>>=
+    u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR ((LOG10 u) + 0.0000001)
+@ 
 <<*>>=
 -- See LICENSE.AXIOM for Copyright
 
@@ -840,7 +860,7 @@
       negative := 0
     -- Try and be fairly exact for smallish integers:
     u = 0 => 1
-    u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR LOG10 u
+<<GCL_log10_bug>>
     -- Rough guess: integer-length returns log2 rounded up, so divide it by
     -- roughly log2(10). This should return an over-estimate, but for objects
     -- this big does it matter?

\start
Date: Sun, 20 Jul 2003 15:19:28 -0400
From: Tim Daly
To: Juergen Weiss
Subject: list bug
Cc: Camm Maguire

Juergen,

Yes, the GCL log10 bug is independent of the other bugs.
I'm certain that i-output could use better algorithms to
compute the length of numbers but the change would have
to be carefully applied as an incorrect length causes
ALL output to change. For example, undercounting the 
length leads to the behavior:

[1000] ==> [100]

but overcounting the length changes printing of many 
things including result numbers and polynomials thus:

 (8 )  4 x + 1

whereas the current result is

 (8)  4x + 1

The i-output code is very, very old, likely from the late 60s.

\start
Date: Sun, 20 Jul 2003 15:20:59 -0400
From: Tim Daly
To: list
Subject: ISSAC 2003 in Philadelphia

Hello *,

Is anyone on this list attending ISSAC 2003?
I'll be there.

\start
Date: Sun, 20 Jul 2003 16:01:50 -0400
From: Bill Page
To: list
Subject: RE: [Gcl-devel] hascategory bug

Tim, Cam,

Two weeks ago I built Axiom on RedHat 8.0 from the tenkan CVS.
After changing the hard coded paths, I also compiled debugsys
and did not receive any errors regarding macros.lisp. I am
able to replace interpsys with debugsys and things work fine
(except a little more verbose and a lot slower). The increased
output of the compiler lets you see more clearly where the
stack overflow begins. I played a little bit more, adding some
of the missing depencencies in the makefile.pamphlet but since
I still don't know enough about how things work and very little
about debugging in lisp, I have given it up for now.

Tim, your recent message containing a few hints on how to use
debugsys will probably help a lot, so I may give it a fresh start
when I get back to my test setup tomorrow evening.

Bill Page.

> Debugsys is supposed to be built as a side-effect of the 
> original make. Since I'm the only one who has used it so far 
> I haven't seen any 
> problems but now I see that it has hard-coded pathnames. You 
> need to change the pathnames to 
> "/fix/s/camm/axiom/axiom1/new/new/..." and I need to change 
> the lisp code to call a function which returns the current 
> pathname. Debugsys.lisp.pamphlet contains the captured commands 
> that build an Axiom system. 
> 
> I'm unaware of any problems with macros.lisp. The axiom build 
> loads the macros into the system before compiles happen.
> 
> I'll check for the macro table warning but I don't recall 
> ever seeing it. I'll have to rebuild the system so I'll get 
> back to you after I check the rebuild.
> 
> The "EXIT is being redefined" message has been fixed by your 
> patch which removed EXIT from the common lisp. I have applied 
> the patch here but have not yet uploaded the patch.
> 
> There are a couple of duplicate function definitions and I 
> have it on my list of things to fix. I have to compare the 
> definition and uses of the functions to see how they might 
> have changed and which definition might be correct.

\start
Date: Sun, 20 Jul 2003 23:22:48 +0200
From: David Mentre
To: Tim Daly
Subject: Re: booklet function

Hello Tim,

Tim Daly writes:

> I need a simple C program to do the following:
>
> booklet [-v] bookletfile pamphletfile
>
> The booklet function is basically a recursive macro-expander.

You'll find your booklet program at:
  http://www.linux-france.org/~dmentre/code/axiom/booklet-0.1.tar.gz

Several notes:

 - you need noweb tools on your path to compile it. Just type 'make'

 - for convenience, the above tar file contains both compiled booklet
   and booklet.dvi

 - this is probably not my most beautiful C program :)

 - the literate part is quite weak. I'll expand on it later if the
   program suits your need.

 - there is no licence on the program (neither copyright). You can put
   it under Axiom licence.

 - error control on filename path is non-existent

Let me know if you find bugs or if I have misinterpreted your
requirements.

\start
Date: Sun, 20 Jul 2003 17:27:14 -0400
From: Tim Daly
To: David Mentre
Subject: Re: booklet function

already? I'm impressed!

\start
Date: Sun, 20 Jul 2003 19:05:51 -0400
From: Richard Stallman
To: Camm Maguire
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold, Stavros Macrakis

    I agree that the LGPL would be better, and I think the FSF agrees too
    for this application.

I wouldn't be sad to see GCL under the GPL.

GCL has had its current license for a long time.  Is there any
indication that this license has led proprietary software developers
to contribute substantially to GCL, or even led them to use it in
large numbers?

      In any case, were we to go GPL, I think at the
    minimum we would want to use a proprietary code allowing clause along
    the lines of clisp.

That would not work--it would encounter the same problem as using the
LGPL encounters: namely, that the various libraries and copied code
don't have such an exception.

\start
Date: Mon, 21 Jul 2003 10:21:04 +1000
From: Mike Thomas
To: Richard Stallman
Subject: Re: GCL compliance with GNU GPL
Cc: Camm Maguire, David Turner, Sam Steingold

Hi Richard.

| firstfile and lastfile are trivial.  I don't think ntheap comes from
| Emacs--at least I can't find it in Emacs.  Maybe it was in an older
| version of Emacs.  Can you show it to me?

See below my name - it makes it into GCL as a #include in "unexnt.h".

| As for the unexec files, they are far from trivial, and I don't
| see a reason to make them available for non-free software.
| So I think you need to tell people that those files can only
| be used in GPL-covered programs.

OK, thanks.


/* Heap management routines (including unexec) for GNU Emacs on Windows NT.
   Copyright (C) 1994 Free Software Foundation, Inc.

This file is part of GNU Emacs.

GNU Emacs is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.

GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Emacs; see the file COPYING.  If not, write to
the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.

   Geoff Voelker (voelker@cs.washington.edu)			     7-29-94
*/

#ifndef NTHEAP_H_
#define NTHEAP_H_

#include <windows.h>

/*
 * Heap related stuff.
 */
#define get_reserved_heap_size()	reserved_heap_size
#define get_committed_heap_size()	(get_data_end () - get_data_start ())
#define get_heap_start()		get_data_start ()
#define get_heap_end()			get_data_end ()
#define get_page_size()			sysinfo_cache.dwPageSize
#define get_allocation_unit()		sysinfo_cache.dwAllocationGranularity
#define get_processor_type()		sysinfo_cache.dwProcessorType
#define get_nt_major_version()  	nt_major_version
#define get_nt_minor_version()  	nt_minor_version

extern unsigned char *get_data_start();
extern unsigned char *get_data_end();
extern unsigned long  data_region_size;
extern unsigned long  reserved_heap_size;
extern SYSTEM_INFO    sysinfo_cache;
extern int    	      nt_major_version;
extern int    	      nt_minor_version;

/* To prevent zero-initialized variables from being placed into the bss
   section, use non-zero values to represent an uninitialized state.  */
#define UNINIT_PTR ((void *) 0xF0A0F0A0)
#define UNINIT_LONG (0xF0A0F0A0L)

enum {
  OS_WIN95 = 1,
  OS_NT
};

extern int os_subtype;

/* Emulation of Unix sbrk().  */
extern void *sbrk (unsigned long size);

/* Recreate the heap created during dumping.  */
extern void recreate_heap (char *executable_path);

/* Round the heap to this size.  */
extern void round_heap (unsigned long size);

/* Load in the dumped .bss section.  */
extern void read_in_bss (char *name);

/* Map in the dumped heap.  */
extern void map_in_heap (char *name);

/* Cache system info, e.g., the NT page size.  */
extern void cache_system_info (void);

/* Round ADDRESS up to be aligned with ALIGN.  */
extern unsigned char *round_to_next (unsigned char *address,
				     unsigned long align);

/* ----------------------------------------------------------------- */
/* Useful routines for manipulating memory-mapped files. */

typedef struct file_data {
    char          *name;
    unsigned long  size;
    HANDLE         file;
    HANDLE         file_mapping;
    unsigned char *file_base;
} file_data;

#define OFFSET_TO_RVA(var,section) \
	  (section->VirtualAddress + ((DWORD)(var) - section->PointerToRawData))

#define RVA_TO_OFFSET(var,section) \
	  (section->PointerToRawData + ((DWORD)(var) - section->VirtualAddress))

#define RVA_TO_PTR(var,section,filedata) \
	  ((void *)(RVA_TO_OFFSET(var,section) + (filedata).file_base))

int open_input_file (file_data *p_file, char *name);
int open_output_file (file_data *p_file, char *name, unsigned long size);
void close_file_data (file_data *p_file);

unsigned long get_section_size (PIMAGE_SECTION_HEADER p_section);

/* Return pointer to section header for named section. */
IMAGE_SECTION_HEADER * find_section (char * name, IMAGE_NT_HEADERS *
nt_header);

/* Return pointer to section header for section containing the given
   relative virtual address. */
IMAGE_SECTION_HEADER * rva_to_section (DWORD rva, IMAGE_NT_HEADERS *
nt_header);

#endif /* NTHEAP_H_ */

\start
Date: Sun, 20 Jul 2003 17:44:34 -0700
From: Richard Fateman
To: Richard Stallman
Subject: GCL used commercially?
Cc: Camm Maguire, David Turner, Sam Steingold

I think that the Macsyma company used Austin-Kyoto-Common-Lisp
(which I believe is related to GCL) for its unix-sun/hp/.... version.
I do not know if they are still in a position to distribute
it, but I understand that there are still sales being made of
Macsyma for Windows by Kalman Reti.  Kalman may have more
information.

I don't know if this relates to the current license
discussion.

Richard Stallman wrote:
>     I agree that the LGPL would be better, and I think the FSF agrees too
>     for this application.
> 
> I wouldn't be sad to see GCL under the GPL.
> 
> GCL has had its current license for a long time.  Is there any
> indication that this license has led proprietary software developers
> to contribute substantially to GCL, or even led them to use it in
> large numbers?
> 
>       In any case, were we to go GPL, I think at the
>     minimum we would want to use a proprietary code allowing clause along
>     the lines of clisp.
> 
> That would not work--it would encounter the same problem as using the
> LGPL encounters: namely, that the various libraries and copied code
> don't have such an exception.

\start
Date: Mon, 21 Jul 2003 15:40:01 -0400
From: Richard Stallman
To: Mike Thomas
Subject: Re: GCL compliance with GNU GPL
Cc: Camm Maguire, David Turner, Sam Steingold

That file ntheap.h appears no longer to be in Emacs, though the code
might still be present somewhere else--I don't know.  In any case it
is pretty small, and we might as well relicense it if that's
convenient for anyone.

However, the larger GPL-covered programs are the real issue.

\start
Date: Mon, 21 Jul 2003 13:03:17 -0700
From: Richard Fateman
To: Richard Stallman
Subject: Re: GCL used commercially?
Cc: David Turner, Sam Steingold

Richard Stallman wrote:
 > RJF wrote
>     I think that the Macsyma company used Austin-Kyoto-Common-Lisp
>     (which I believe is related to GCL) for its unix-sun/hp/.... version.
> 
>RMS wrote:

> GCL is the same program as was formerly called AKCL.  The developers
> agreed to make it a GNU package.
> 
> I believe Macsyma is released under the GPL now, so there would
> be no difficulty running it on GCL even if GCL were GPL'd.

The open-source version of Macsyma "Maxima", a descendent of the
1982 or so version that I forced Joel Moses and Mike Dertouzos to
release to the department of energy,  is GPL licensed thanks to
the efforts of the late Bill Schelter.

The commercial version, which was enhanced by Symbolics and then
"Macsyma Inc" for about 20 years, is not public.  The Macsyma INc
people supported and enhanced AKCL.  I do not know if their
changes to AKCL were made public, but I suspect not. Certainly
their changes to Macsyma are not public.

\start
Date: 21 Jul 2003 17:34:54 -0400
From: Camm Maguire
To: Richard Stallman
Subject: Re: GCL compliance with GNU GPL
Cc: David Turner, Sam Steingold

Greetings, and thanks as always for your attention to these matters!
(It is, IMHO, largely the reason we are here in the first place :-)). 

Richard Stallman Richard Stallman writes:

>     I agree that the LGPL would be better, and I think the FSF agrees too
>     for this application.
> 
> I wouldn't be sad to see GCL under the GPL.
> 
> GCL has had its current license for a long time.  Is there any
> indication that this license has led proprietary software developers
> to contribute substantially to GCL, or even led them to use it in
> large numbers?
> 
>       In any case, were we to go GPL, I think at the
>     minimum we would want to use a proprietary code allowing clause along
>     the lines of clisp.
> 
> That would not work--it would encounter the same problem as using the
> LGPL encounters: namely, that the various libraries and copied code
> don't have such an exception.
> 
> _______________________________________________

1) I'm not concerned with proprietary software vendors.  I wouldn't
   expect much help from them for GCL in any case.

2) I am concerned with free software authors who might insist for some
   reason on a BSD-like license.  Specifically axiom.  There is a more
   ansi-compliant, less portable, faster, BSD-like lisp system with
   which GCL must compete -- CMUCL.

3) I feel that any 'predominant' free compiler for a given language
   will likely not restrict the license of code merely compiled with
   it.

4) I feel that any 'predominant' free compiler for a given language
   will also be predominant among free software authors.

5) I feel that the 'predominant' compiler for a given language will
   likely be of the highest quality, due to its large mindshare.

5) I feel that the existence of a 'predominant' high quality free
   compiler for a given language encourages its use in the production
   of free software.

6) Its obviously not right to use emacs' unexec under the LGPL without
   special permission.  I'm confused as to how this situation arose.
   I find some unexec files in the May 10 1994 release of gcl-1.0.
   Did Dr. Schelter ever discuss this with you or any other emacs
   developers? 

7) From what I know now, and if you are still persuaded that it would
   be best not to license unexec to GCL under the LGPL, then it would
   appear the following is the best course:

        a) license the current GCL under the GPL
        b) ask the xemacs people if pdumper could be used as an
           LGPL'ed replacement for unexec.  
        c) If b) is yes, then make a --enable-lgpl configure option
           which would eliminate readline and bfd and use pdumper in
           place of unexec.
        d) If b) is no, consider modifying unexec to not dump itself
           into any saved image (if possible -- this might be
           achievable by simply placing the unexec file before
           firstfile.o in the link).  Some --enable-proprietary-images
           switch would then install this feature as well as eliminate
           readline and bfd.  GCL itself would be GPL (like gcc), but
           produced images would not have readline, bfd, nor unexec
           (and therefore could not run si::save-system), and
           therefore could be licensed as the author wished.

8) Comments/corrections most welcome.  If 7) is adopted as our plan,
   then I will need volunteers to help with steps b), c) and d).  All
   those who want a LGPL GCL please step forward now :-)!  In any
   case, it looks like *current* 2.5.4 should be released under the
   GPL, if Richard's opinion as to the best course remains unchanged.

\start
Date: Mon, 21 Jul 2003 15:40:03 -0400
From: Richard Stallman
To: Richard Fateman
Subject: Re: GCL used commercially?
Cc: Camm Maguire, Stavros Macrakis, David Turner, Sam Steingold

    I think that the Macsyma company used Austin-Kyoto-Common-Lisp
    (which I believe is related to GCL) for its unix-sun/hp/.... version.

GCL is the same program as was formerly called AKCL.  The developers
agreed to make it a GNU package.

I believe Macsyma is released under the GPL now, so there would
be no difficulty running it on GCL even if GCL were GPL'd.

\start
Date: 21 Jul 2003 20:16:47 -0400
From: Camm Maguire
To: Juergen Weiss
Subject: Re: source access

Greetings!

"Juergen Weiss" writes:

> Unfortunately it seems, that there are two problems. The
> first one is insufficient value stack size for Axiom
> (the rs6000 port of gcl had a higher limit for quite a while).

I can't find any settings for the r6000.  Might you know where to
look? 

> I think sometimes the function |Join| is called with
> quite a few arguments. Setting the value to the value
> used for rs6000 should fix that problem. For the second 

Don't see what this has to do with the stack.  But there are limits to
64 arguments in places inside GCL.  Overflows trigger reported
errors.  Do you feel this could be an issue?

> one I posted an example on 06/10. There is an infinite
> recursion. Reason is unclear. Could be different sharing
> of cells in cmu and gcl in destructive calls, that is a
> coding error in Axiom. Change of semantics of a lisp
> function. Or the gcl compiler has generated some bad code
> (I already found a compiler error in cmu cl at another 
> place).

So far, I know that compForMode on first input (|CommutativeRing|)
gives a vmode of (|Ring|), and compMakeCategoryObject on (|Ring|)
returns a 'catlist' containing (|has| R (CommutativeRing|)).  Might
you know if either of these might be in error?  (One of them certainly
should be at least, I think.) (See knownInfo in info.clisp).

> > Greetings!
> > 
> > "Juergen Weiss" writes:
> > 
> > > The current problem lies with gcl. With cmucl I was able to
> > > compile all the algebra files and get a working algebra
> > > system.
> > > 
> > > So there is nothing in principle and practice against generating
> > > an axiom system with a simple call to make. There is a
> > > problem with the gcl system which must be fixed. As far I can
> > > see from the discussion in this list, it seems to be related
> > > to the number of arguments in a function call or something similar. 
> > > Akcl had to be customized even 10 years ago to run axiom. I think,
> > > I did that once for akcl on sparc sunos 4.1. But I fear I cannot
> > > remember the details. This problem is triggered by the axiom
> > 
> > OK, please forgive, as I only intermittently follow this list.  It was
> > my understanding that this 'value stack overflow' problem had been
> > resolved, but apparently I've misread some earlier email on the
> > subject.  It would be most helpful to me if someone could summarize in
> > as much detail as possible what is known about this issue.   Can one
> > provide a small example in lisp which triggers this overflow?  I take
> > it that there is some termination problem in a recursive function
> > call?  How its this related to the number of arguments in a call?
> > I've reproduced the ')co xpoly.spad' example, and have verified that
> > the value stack will terminate at some 44k deep if one expands the
> > default value stack size, but then there is a segfault.  Haven't yet
> > looked much deeper, but I'd like to time permitting.  I'd also like to
> > know what a proper stack should look like in a correctly functioning
> > setup. 
> > 
> > BTW, here is the patch submitted a while ago for the elt error message
> > bug, if you would like it:
> > 
> > Index: o/error.c
> > ===================================================================
> > RCS file: /cvsroot/gcl/gcl/o/error.c,v
> > retrieving revision 1.15
> > retrieving revision 1.16
> > diff -u -r1.15 -r1.16
> > --- o/error.c	27 Feb 2003 15:50:59 -0000	1.15
> > +++ o/error.c	10 Jun 2003 13:28:11 -0000	1.16
> > @@ -120,7 +120,7 @@
> >  
> >  
> >  
> > -static object
> > +object
> >  Icall_error_handler(object error_name,object 
> > error_format_string,int nfmt_args,...)
> >  { object b[20];
> >    b[0]= error_name;
> > Index: o/sequence.d
> > ===================================================================
> > RCS file: /cvsroot/gcl/gcl/o/sequence.d,v
> > retrieving revision 1.3
> > retrieving revision 1.4
> > diff -u -r1.3 -r1.4
> > --- o/sequence.d	15 Oct 2002 19:32:01 -0000	1.3
> > +++ o/sequence.d	10 Jun 2003 13:28:11 -0000	1.4
> > @@ -123,7 +123,9 @@
> >  E:
> >  	vs_push(make_fixnum(index));
> >  	/* FIXME message should indicate out of range */
> > -	FEwrong_type_argument(sLpositive_fixnum,vs_head);
> > +	Icall_error_handler(sKwrong_type_argument,
> > +		     make_simple_string("The index, ~S, is too large."),
> > +		     1,vs_head);
> >  	return(Cnil);
> >  }
> >  
> > Index: h/protoize.h
> > ===================================================================
> > RCS file: /cvsroot/gcl/gcl/h/protoize.h,v
> > retrieving revision 1.26
> > retrieving revision 1.27
> > diff -u -r1.26 -r1.27
> > --- h/protoize.h	1 Mar 2003 22:37:37 -0000	1.26
> > +++ h/protoize.h	10 Jun 2003 13:28:11 -0000	1.27
> > @@ -1737,6 +1737,9 @@
> >  object
> >  cplus(object,object);
> >  
> > +object
> > +Icall_error_handler(object,object,int,...);
> > +
> >  #if defined (__MINGW32__)
> >  int bcmp ( const void *s1, const void *s2, size_t n );
> >  void bcopy ( const void *s1, void *s2, size_t n );

\start
Date: Mon, 21 Jul 2003 20:31:36 -0400
From: Tim Daly
To: David Mentre
Subject: booklet function

I've made some modifications to your program so that it outputs
chunk tags that do not contain protocol specifiers. Thus

<<asdf>>

is output unchanged but

<<file:asdf>>

is replaced inline. I've also added some additional documentation.
Other than that the program works great.

I've been trying to include test code from the original files.
I needed the program because you can't use TeX's include function
with noweb. If you try:

<<chunk>>=
\include{asdf}
@

it fails because the \include is quoted. If you try:

\include{asdf}

where the file asdf contains the <<chunk>> it fails because
notangle and noweave process the file before TeX so the
chunk is never seen.

The booklet function preprocesses the file and expands the
protocol specifier before either notangle or tex is run. 
Thus it is now possible to keep all of your test cases in
files in subdirectories arranged by subject and then expand
them into the documents and test cases.

Eventually booklet will expand to handle other protocols.

\start
Date: Tue, 22 Jul 2003 11:17:18 +0200
From: Juergen Weiss
To: Camm Maguire
Subject: RE: source access

Hi,


> Greetings!
> 
> "Juergen Weiss" writes:
> 
> > Unfortunately it seems, that there are two problems. The
> > first one is insufficient value stack size for Axiom
> > (the rs6000 port of gcl had a higher limit for quite a while).
> 
> I can't find any settings for the r6000.  Might you know where to
> look? 

rios.h or rios-aix3.h

> > I think sometimes the function |Join| is called with
> > quite a few arguments. Setting the value to the value
> > used for rs6000 should fix that problem. For the second 
> 
> Don't see what this has to do with the stack.  But there are limits to
> 64 arguments in places inside GCL.  Overflows trigger reported
> errors.  Do you feel this could be an issue?

Probably not, at least the problems we see now is caused by
infinite recursion, not by stacks which are too small. I think
there was a problem with the number of arguments to a function,
at least in compiled code. There was a comment in the axiom
code at some place. But sorry, I do not remember the details.
 
> > one I posted an example on 06/10. There is an infinite
> > recursion. Reason is unclear. Could be different sharing
> > of cells in cmu and gcl in destructive calls, that is a
> > coding error in Axiom. Change of semantics of a lisp
> > function. Or the gcl compiler has generated some bad code
> > (I already found a compiler error in cmu cl at another 
> > place).
> 
> So far, I know that compForMode on first input (|CommutativeRing|)
> gives a vmode of (|Ring|), and compMakeCategoryObject on (|Ring|)
> returns a 'catlist' containing (|has| R (CommutativeRing|)).  Might
> you know if either of these might be in error?  (One of them certainly
> should be at least, I think.) (See knownInfo in info.clisp).

I have to look at this.

\start
Date: Tue, 22 Jul 2003 08:59:49 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: source access
Cc: Camm Maguire

GCL won't handle a large number of arguments to a compiled function.
There is a file called "nocompil.lisp" which contains Join. Join is
called with a large number of arguments and so it is not compiled.

\start
Date: Tue, 22 Jul 2003 09:25:21 -0400
From: Page, Bill
To: Mike Thomas
Subject: RE: [Gcl-devel] 2.5.4

Mike,

Thank you for your effort on this. I am quite impressed by
the energy of the people that support MinGW and Msys. I
think what they are doing is very important to the other
"half" of the computing community, who for a variety of
reasons still mostly live in the "Wonderful World of Windows".

> Hi Bill.
> 
> Further to this I have passed a package on to Earnie, so 
> let's wait and see
> what happens.
> 
> 
> | Mike,
> |
> | Where does the Windows version look for the XDR/rpc libraries
> | and/or header files? Do you have a recommended MinGW/msys
> | configuration?
> |
> | Since you are most active on the MinGW forum as well, are you
> | planning (or have you already) contacted Earnie Boyd about
> | the ONC rpc libraries? (see messages below).
> |
> | BTW, with your help I did manage also to build a Windows
> | version of GCL 2.5.2 with XDR support for Axiom testing using
> | the ONC library. Thanks. But I have not tested it much yet.
> |
> |
> | > Hi Camm.
> | >
> | > | If we have another week before you release 2.5.4 we should
> | > also add XDR
> | > | detection to configure and I will also fold some changes back in
> | > | to support
> | > | building an ANSI binary installer for Windows.
> | >
> | > Each of these is now complete although the XDR library/header
> | > configuration for Unix platforms is untested.
> | >
> | > Subject: Re: [Mingw-users] ONCRPC binaries for MinGW32 - 
> where to put
> | > it.
> | >
> | >
> | > I plan to answer this via www.mingw.org.  While I'm doing 
> that upload
> | > the package somewhere that I can download it.  Package it as
> | > you would
> | > for download from MinGW and give me the location to each 
> file.  I'll
> | > download and review them.
> | >
> | > Earnie.
> | >
> | > Bill Page wrote:
> | > > Ernie,
> | > >
> | > > You wrote:
> | > >
> | > >
> | > >>Why, why hot just ask MinGW to host the packages?
> | > >
> | > >
> | > > I think it would be great if the ONC rpc package
> | > > could be made part of MinGW/Msys.
> | > >
> | > > What do we need to do to make this happen?
> | > >
> | > > Regards,
> | > > Bill Page.
> | > >
> | > >
> | > >>Subject: Re: [Mingw-users] ONCRPC binaries for MinGW32 -
> | > >>where to put it.
> | > >>
> | > >>
> | > >>Mike Thomas wrote:
> | > >>
> | > >>>Until someone with the time and knowledge offers to do
> | > >>
> | > >>that, I think
> | > >>
> | > >>>it might be better just to distribute the MinGW32 binaries
> | > >>
> | > >>from one of
> | > >>
> | > >>>the the MinGW32 library sites eg
> | > >>
> | > >>http://mingwrep.sourceforge.net, or
> | > >>
> | > >>http://jrfonseca.dyndns.org/projects/gnu-win32/software/port
> | ed/index.h
> | >>
> | >>>tml.
> | >>>
> | >>
> | >>Why, why hot just ask MinGW to host the packages?
> | >>
> | >>
> | >>>My main concern is that the package might branch into 
> incompatible
> | >>>streams as happened with windows ports of libintl (?) and related
> | >>>libraries - a problem discussed on the MinGW32 list 
> within the past
> | >>>year.
> | >>>
> | >>
> | >>A problem that could have been avoided if we all work together.

\start
Date: Tue, 22 Jul 2003 13:01:54 -0400
From: Bill Page
To: list
Subject: Axiom debugging

Tim,

Using the June 14 version of Axiom downloaded from

  http://axiom.tenkan.org 

and some of your debugging hints from you email of
Friday, July 18, 2003 6:54 PM, I get a Segmentation
fault in interpsys when I enter the following statements

(1) -> [1,2,3,1]::Set Integer

(2) -> )lisp (setq *print-array* t)

(2) -> )lisp (hget |$ConstructorCache| '|Integer|)

Since I do not really understand what is going on in
these commands, I don't know if this should be expected
or not.

Can you reproduce and explain what I see?

\start
Date: Tue, 22 Jul 2003 21:51:32 +0200
From: David Mentre
To: list
Subject: Re: booklet function

Hello Tim,

I'm glad to see that the program suits your need. 

Tim Daly writes:

> I've made some modifications to your program 

Could you send those modifications, privately to me or on the list. So I
can put an updated version on the web and keep up with your
modifications. :)

\start
Date: Tue, 22 Jul 2003 16:14:45 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Axiom debugging

Bill,

The segfault is likely because the result is circular.

(For the non-lisper among you it is possible and very common to
create lists that have pointers back into the same list. When
you try to print such an object the printer will loop infinitely.
The *print-circle* variable tells the printer to watch for this
condition. Basically you just create a table of nodes that you've
seen before and if the node shows up again you just output a 
tombstone rather than follow the node).

It shouldn't happen if you first do 

(1) -> [1,2,3,1]::Set Integer

(2) -> )lisp (setq *print-array* t)

(2) -> )lisp (setq *print-circle* t)

(2) -> )lisp (hget |$ConstructorCache| '|Integer|)

\start
Date: Tue, 22 Jul 2003 16:40:48 -0400
From: Bill Page
To: list
Subject: RE: Axiom debugging

Tim,

OK, thanks. Now I understand... more or less. (It will
be more as time goes on <grin>). Is it "normal" for a
lisp application to segfault in this way rather than
having the error caught in some gentler way?? No matter.

What I am actually looking for is a simpler example of
an Axiom set function that actually fails. So far nothing
seems wrong. But according to my current only limited
understanding, it seems that each type which can be used
to construct a set needs to have it's own "set method".
Via if $ has SETCAT? Right? So sets constructed of things
of rather different and complex types might be required
in order to display this wrong unset-like behaviour
(duplicate elements). Any suggestions?

> Bill,
> 
> The segfault is likely because the result is circular.
> 
> (For the non-lisper among you it is possible and very common to
> create lists that have pointers back into the same list. When
> you try to print such an object the printer will loop infinitely.
> The *print-circle* variable tells the printer to watch for this
> condition. Basically you just create a table of nodes that you've
> seen before and if the node shows up again you just output a 
> tombstone rather than follow the node).
> 
> It shouldn't happen if you first do 
> 
> (1) -> [1,2,3,1]::Set Integer
> 
> (2) -> )lisp (setq *print-array* t)
> 
> (2) -> )lisp (setq *print-circle* t)
> 
> (2) -> )lisp (hget |$ConstructorCache| '|Integer|)

\start
Date: 22 Jul 2003 16:56:42 -0400
From: Camm Maguire
To: list
Subject: Re: source access

Greetings!  Also, do you have a |Join| call runnable from interpsys
which illustrates the problem?

Tim Daly writes:

> GCL won't handle a large number of arguments to a compiled function.
> There is a file called "nocompil.lisp" which contains Join. Join is
> called with a large number of arguments and so it is not compiled.

\start
Date: 22 Jul 2003 16:56:01 -0400
From: Camm Maguire
To: list
Subject: Re: source access

Greetings!  I'm assuming you are referring to the limit of 63
arguments in c_apply_n.  Would a larger limit solve your problem, or
be desirable/helpful?  Or would the only improvement come from an
unlimited compiled call?

Take care,

Tim Daly writes:

> GCL won't handle a large number of arguments to a compiled function.
> There is a file called "nocompil.lisp" which contains Join. Join is
> called with a large number of arguments and so it is not compiled.

\start
Date: Tue, 22 Jul 2003 18:15:24 -0400
From: Tim Daly
To: Bill Page
Subject: set function breakage

Bill,

> What I am actually looking for is a simpler example of
> an Axiom set function that actually fails. So far nothing
> seems wrong. 

Why do you believe that the Set function fails?
The example of sets failing that I gave was actually a GCL
common lisp example vs CCL common lisp. It was not an Axiom
level failure. (To recall, the example was:

(setq a '(a))
(setq b '(b c))
in GCL:
(set-difference b a) ==> (c b)
in CCL:
(set-difference b a) ==> (b c)

Both of these results are correct as they are both valid sets
and the order of the result of set-difference is unspecified).

The main Axiom failure is actually in the compiler. If you do:

(1) -> )co xpoly )con XPR

the compile will eventually die with a stack overflow. The above
command says to compile the domain XPR from xpoly.spad. This
will eventually involve walking the tree of domains that XPR
uses. Walking this tree involves finding all of the domains it
depends on and adding them to a list to be processed (the DEPENDS list).
Each domain in the DEPENDS list now needs to be processed in the
same way so the DEPENDS list is augmented with yet more domains.
Somewhere this process gets lost and the domain Ring shows up
in an infinite regression. It is not yet apparent to me why this
happens but since the original system can compile XPR (a CCL system)
and the new system cannot (a GCL system) I suspect a difference in
the underlying definition of the common lisp primitives. So far
the set-difference order is the only one I've found. It is a very
tedious process to follow the compiler (especially since it isn't
documented, sigh) and the first direct common lisp primitive shows
up about 80 levels deep in the execution stack. Nevertheless, all
of the code is there so there is no magic. 

If you want to watch the domain-level functions get called from
a particular domain (e.g CHAR) you can look in the int/algebra
directory. You will find either CHAR.lsp or CHAR.NRLIB/code.lsp.
That file will contain the lisp code that results from compiling
the domain. You can trace any (or all) functions from that domain.
(Indeed there is a file called "monitor.lisp.pamphlet" that will
do those kind of things. It exists only for debugging reasons).

If you want to trace CHAR operations you can look at this lisp
code, load it as interpreted code, and watch it execute. type:

)cd (yourpath)/int/algebra
)lisp (load "CHAR.NRLIB/code.lsp")
)lisp (trace |CHAR;=;2$B;1|)
)lisp (trace |CHAR;<;2$B;2|)
....

(look at the code.lsp file for the rest of the names).

Generally, for debugging I create a file called d.lisp
that contains a sequence of commands so I can rerun them
every time I restart Axiom. So, for instance, my current
file says things like:

(in-package "BOOT")   ;;; where Axiom runs
#+:akcl
(defun S- (l1 l2)
 (reverse (set-difference l1 l2 :test #'equal)))
#-akcl
(defun S- (l1 l2)
 (reverse (set-difference l1 l2 :test #'equal)))
(load "RING.NRLIB/code.lsp")
... etc

Then when I start Axiom I type:

)lisp (load "/tmp/d.lisp")

Additionally it is sometimes helpful to run debugsys rather than
interpsys. Common lisp gives you some debugging facilities. For example,
trace takes conditions that allow you to control what it does. Also
you can use the step function. So you can type:

)lisp (step (+ (* 2 4) 5))

and watch each step of the evaluation. Since all of Axiom is really
just common lisp (boot files turn into int/interp/fn.clisp files,
spad files become int/interp/fn.NRLIB/code.lsp files and 
lisp files just become int/interp/lisp files) you can watch anything
execute.

The best place to look for the failure is likely in some subfunction
of |knownInfo|. You can watch this function execute by typing:

)lisp (setq *print-arry* t)    ;; show the contents of vectors
)lisp (setq *print-circle* t)  ;; watch for circular structures
)lisp (setq *print-pretty* t)  ;; indent reasonably
)lisp (setq *print-length* 5)  ;; limit the length to some value
)lisp (setq *print-level* 5)   ;; limit the depth to some value
)lisp (trace |knownInfo|)
)co xpoly )con XPR           

Let me know if you have any other questions. 

\start
Date: Tue, 22 Jul 2003 18:17:50 -0400
From: Tim Daly
To: Bill Page
Subject: set function breakage

Bill,

I forgot to mention that you can drop directly in lisp by typing:
)fin
and return to the prompt by typing:
(restart)

Also, you can control whether Axiom will stop on errors by typing
)set break break

If you type:
)set break
Axiom will show you the various options.

\start
Date: Tue, 22 Jul 2003 18:20:40 -0400
From: Tim Daly
To: Camm Maguire
Subject: set function breakage

Camm,

> Greetings!  I'm assuming you are referring to the limit of 63
> arguments in c_apply_n.  Would a larger limit solve your problem, or
> be desirable/helpful?  Or would the only improvement come from an
> unlimited compiled call?

I no longer know. I remember debugging this problem with Schelter
years ago but, having found a solution, it is gone from my heap.
The issue had to do with the compiler building call execution
sequences. I'd just as soon leave it alone for now. The Join
function is rarely called so it is not a performance issue.

\start
Date: Tue, 22 Jul 2003 18:24:13 -0400
From: Tim Daly
To: Camm Maguire
Subject: set function breakage

Camm,

> Greetings!  Also, do you have a |Join| call runnable from interpsys
> which illustrates the problem?

I believe, thought I'm no longer sure, that if you construct a 
function with more than 63 arguments the compiler complains or
the code fails. Clearly you would never do this by hand but
compilers built on top of common lisp can exceed this limit
with ease. I'm not sure where Axiom creates such an argument
list.

\start
Date: Tue, 22 Jul 2003 18:35:21 -0400
From: Tim Daly
To: Camm Maguire
Subject: noisy knownInfo function

*,

I've rewritten the knownInfo function to be a bit noisier.
It basically prints out which branch of the COND it takes
(0 thru 10) and the value of |pred|. You may find this
useful for debugging the )co xpoly )con XPR bug

The nature of the bug, as I understand it so far, is that Axiom
algebra code can contain conditions on operations based on categories.
Thus you can say that 
if (a domain) R HAS (some category)
  then (it has this operation)

This allows Axiom to conditionally define functions (say inverse)
only if the domain is built on something which has division.

You can save this into the file knownInfo.lisp and load it when
you start Axiom:

)lisp (load "knownInfo.lisp")

Then when you run the compiler it will complain bitterly:

)co xpoly )con XPR

and you can watch the compiler work.

Tim
=====================================================================
(in-package 'boot)
(DEFUN |knownInfo| (|pred|) 
 (PROG (|attr| |x| |cat| |a| |vmode| |l| |LETTMP#1| |vv| |catlist| |u| 
        |ISTMP#1| |name| |ISTMP#2| |op| |ISTMP#3| |sig| |v| |ww|) 
(format t "knownInfo (0) ~a~%" |pred|)
  (cond 
   ((eq |pred| t) 
(format t "fastexit~%")
t)
   (t
  (RETURN 
   (SEQ 
    (COND 
     ((BOOT-EQUAL |pred| (QUOTE T))
(format t "knownInfo (1) ~a~%" |pred|)
      (QUOTE T))
     ((|member| |pred| (|get| (QUOTE |$Information|) (QUOTE |special|) |$e|))
(format t "knownInfo (2) ~a~%" |pred|)
      (QUOTE T))
     ((AND 
       (PAIRP |pred|)
       (EQ (QCAR |pred|) (QUOTE OR))
       (PROGN (SPADLET |l| (QCDR |pred|)) (QUOTE T)))
(format t "knownInfo (3) ~a~%" |pred|)
      (PROG (#0=#:G3573) 
       (SPADLET #0# NIL)
       (RETURN 
        (DO ((#1=#:G3579 NIL #0#) (#2=#:G3580 |l| (CDR #2#)) (|u| NIL))
            ((OR #1# (ATOM #2#) (PROGN (SETQ |u| (CAR #2#)) NIL)) #0#)
            (SEQ (EXIT (SETQ #0# (OR #0# (|knownInfo| |u|)))))))))
     ((AND 
       (PAIRP |pred|)
       (EQ (QCAR |pred|) (QUOTE AND))
       (PROGN (SPADLET |l| (QCDR |pred|)) (QUOTE T)))
(format t "knownInfo (4) ~a~%" |pred|)
      (PROG (#3=#:G3587) 
       (SPADLET #3# (QUOTE T))
       (RETURN 
        (DO ((#4=#:G3593 NIL (NULL #3#)) (#5=#:G3594 |l| (CDR #5#)) (|u| NIL))
        ((OR #4# (ATOM #5#) (PROGN (SETQ |u| (CAR #5#)) NIL)) #3#)
        (SEQ (EXIT (SETQ #3# (AND #3# (|knownInfo| |u|)))))))))
     ((AND 
       (PAIRP |pred|)
       (EQ (QCAR |pred|) (QUOTE |or|))
       (PROGN (SPADLET |l| (QCDR |pred|)) (QUOTE T)))
(format t "knownInfo (5) ~a~%" |pred|)
      (PROG (#6=#:G3601) 
       (SPADLET #6# NIL)
       (RETURN 
        (DO ((#7=#:G3607 NIL #6#) (#8=#:G3608 |l| (CDR #8#)) (|u| NIL))
            ((OR #7# (ATOM #8#) (PROGN (SETQ |u| (CAR #8#)) NIL)) #6#)
            (SEQ (EXIT (SETQ #6# (OR #6# (|knownInfo| |u|)))))))))
     ((AND 
       (PAIRP |pred|)
       (EQ (QCAR |pred|) (QUOTE |and|))
       (PROGN (SPADLET |l| (QCDR |pred|)) (QUOTE T)))
(format t "knownInfo (6) ~a~%" |pred|)
      (PROG (#9=#:G3615) 
       (SPADLET #9# (QUOTE T))
       (RETURN 
        (DO ((#10=#:G3621 NIL (NULL #9#))
             (#11=#:G3622 |l| (CDR #11#))
             (|u| NIL))
            ((OR #10# (ATOM #11#) (PROGN (SETQ |u| (CAR #11#)) NIL)) #9#)
            (SEQ (EXIT (SETQ #9# (AND #9# (|knownInfo| |u|)))))))))
     ((AND 
       (PAIRP |pred|)
       (EQ (QCAR |pred|) (QUOTE ATTRIBUTE))
       (PROGN 
        (SPADLET |ISTMP#1| (QCDR |pred|))
        (AND 
         (PAIRP |ISTMP#1|)
         (PROGN 
          (SPADLET |name| (QCAR |ISTMP#1|))
          (SPADLET |ISTMP#2| (QCDR |ISTMP#1|))
          (AND 
           (PAIRP |ISTMP#2|)
           (EQ (QCDR |ISTMP#2|) NIL)
           (PROGN (SPADLET |attr| (QCAR |ISTMP#2|)) (QUOTE T)))))))
(format t "knownInfo (7) ~a~%" |pred|)
      (SPADLET |v| (|compForMode| |name| |$EmptyMode| |$e|))
      (COND 
       ((NULL |v|) 
        (|stackSemanticError| 
         (CONS 
          (QUOTE |can't find category of |)
          (CONS |name| NIL)) NIL))
       ((QUOTE T) 
        (SPADLET |LETTMP#1| (|compMakeCategoryObject| (CADR |v|) |$e|))
        (SPADLET |vv| (CAR |LETTMP#1|))
        (COND 
         ((NULL |vv|) 
          (|stackSemanticError| 
           (CONS 
            (QUOTE |can't make category of |)
            (CONS |name| NIL)) NIL))
         ((|member| |attr| (ELT |vv| 2)) (QUOTE T))
         ((SPADLET |x| (|assoc| |attr| (ELT |vv| 2))) (|knownInfo| (CADR |x|)))
         ((QUOTE T) NIL)))))
     ((AND 
       (PAIRP |pred|)
       (EQ (QCAR |pred|) (QUOTE |has|))
       (PROGN 
        (SPADLET |ISTMP#1| (QCDR |pred|))
        (AND 
         (PAIRP |ISTMP#1|)
         (PROGN 
          (SPADLET |name| (QCAR |ISTMP#1|))
          (SPADLET |ISTMP#2| (QCDR |ISTMP#1|))
          (AND 
           (PAIRP |ISTMP#2|)
           (EQ (QCDR |ISTMP#2|) NIL)
           (PROGN (SPADLET |cat| (QCAR |ISTMP#2|)) (QUOTE T)))))))
(format t "knownInfo (8) ~a~%" |pred|)
      (COND 
       ((AND 
         (PAIRP |cat|)
         (EQ (QCAR |cat|) (QUOTE ATTRIBUTE))
         (PROGN (SPADLET |a| (QCDR |cat|)) (QUOTE T)))
(format t "knownInfo (8a) ~a~%" |pred|)
        (|knownInfo| (CONS (QUOTE ATTRIBUTE) (CONS |name| |a|))))
       ((AND 
          (PAIRP |cat|)
          (EQ (QCAR |cat|) (QUOTE SIGNATURE))
          (PROGN (SPADLET |a| (QCDR |cat|)) (QUOTE T)))
(format t "knownInfo (8b) ~a~%" |pred|)
         (|knownInfo| (CONS (QUOTE SIGNATURE) (CONS |name| |a|))))
       ((AND 
          (PAIRP |name|)
          (EQ (QCAR |name|) (QUOTE |Union|)))
(format t "knownInfo (8c) ~a~%" |pred|)
         NIL)
       ((QUOTE T) 
(format t "knownInfo (8d) ~a~%" |pred|)
         (SPADLET |v| (|compForMode| |name| |$EmptyMode| |$e|))
(format t "compForMode v ~a~%" |v|)
         (COND 
          ((NULL |v|)
(format t "knownInfo (8da) ~a~%" |pred|) 
           (|stackSemanticError| 
            (CONS 
             (QUOTE |can't find category of |) 
             (CONS |name| NIL)) NIL))
          ((QUOTE T) 
(format t "knownInfo (8db) ~a~%" |pred|)
           (SPADLET |vmode| (CADR |v|))
           (COND 
            ((BOOT-EQUAL |cat| |vmode|)
(format t "knownInfo (8dba) ~a~%" |pred|)
              (QUOTE T))
            ((AND 
               (PAIRP |vmode|)
               (EQ (QCAR |vmode|) (QUOTE |Join|))
               (PROGN (SPADLET |l| (QCDR |vmode|)) (QUOTE T))
               (|member| |cat| |l|))
(format t "knownInfo (8dbb) ~a~%" |pred|)
              (QUOTE T))
            ((QUOTE T) 
(format t "knownInfo (8dbc) ~a~%" |pred|)
              (SPADLET |LETTMP#1| (|compMakeCategoryObject| |vmode| |$e|))
;(format t "LETTMP#1 ~a~%" |LETTMP#1|)
              (SPADLET |vv| (CAR |LETTMP#1|))
;(format t "vv ~a~%" |vv|)
              (SPADLET |catlist| (ELT |vv| 4))
(format t "catlist ~a~%" |catlist|)
              (COND 
               ((NULL |vv|)
(format t "knownInfo (8dbba) ~a~%" |pred|) 
                (|stackSemanticError| 
                 (CONS 
                  (QUOTE |can't make category of |)
                  (CONS |name| NIL)) NIL))
               ((|member| |cat| (CAR |catlist|))
(format t "knownInfo (8dbbb) ~a~%" |pred|)
                (QUOTE T))
               ((AND 
                  (SPADLET |u| (|assoc| |cat| (CADR |catlist|)))
(progn
 (format t "cadr catlist ~a~%" (CADR |catlist|))
 (format t "u ~a~%" |u|)
 (format t "cadr u ~a~%" (CADR |u|))
 t)
                  (|knownInfo| (CADR |u|)))
(format t "knownInfo (8dbbc) ~a~%" |pred|)
                 (QUOTE T))
               ((PROG (#12=#:G3629) 
                 (SPADLET #12# NIL)
                 (RETURN 
                  (DO ((#13=#:G3635 NIL #12#)
                       (#14=#:G3636 (CADR |catlist|) (CDR #14#))
                       (|u| NIL))
                      ((OR #13# (ATOM #14#) (PROGN (SETQ |u| (CAR #14#)) NIL))
                        #12#)
                      (SEQ 
                       (EXIT 
                        (SETQ #12# 
                         (OR #12# 
                          (AND 
                           (|AncestorP| |cat| (LIST (CAR |u|)))
(and (format t "knownInfo (8dbbd) ~a~%" |pred|) t)
                           (|knownInfo| (CADR |u|))))))))))
                 (QUOTE T))
               ((QUOTE T) NIL)))))))))
     ((AND 
       (PAIRP |pred|)
       (EQ (QCAR |pred|) (QUOTE SIGNATURE))
       (PROGN 
        (SPADLET |ISTMP#1| (QCDR |pred|))
        (AND 
         (PAIRP |ISTMP#1|)
         (PROGN 
          (SPADLET |name| (QCAR |ISTMP#1|))
          (SPADLET |ISTMP#2| (QCDR |ISTMP#1|))
          (AND 
           (PAIRP |ISTMP#2|)
           (PROGN 
            (SPADLET |op| (QCAR |ISTMP#2|))
            (SPADLET |ISTMP#3| (QCDR |ISTMP#2|))
            (AND 
             (PAIRP |ISTMP#3|)
             (PROGN (SPADLET |sig| (QCAR |ISTMP#3|)) (QUOTE T)))))))))
(format t "knownInfo (9) ~a~%" |pred|)
      (SPADLET |v| (|get| |op| (QUOTE |modemap|) |$e|))
      (DO ((#15=#:G3648 |v| (CDR #15#)) (|w| NIL))
          ((OR (ATOM #15#) (PROGN (SETQ |w| (CAR #15#)) NIL)) NIL)
          (SEQ 
           (EXIT 
            (PROGN 
             (SPADLET |ww| (CDAR |w|))
             (SEQ 
              (COND 
               ((AND 
                 (BOOT-EQUAL (LENGTH |ww|) (LENGTH |sig|))
                 (|SourceLevelSubsume| |ww| |sig|))
               (COND 
                ((BOOT-EQUAL (CAADR |w|) (QUOTE T))
                 (EXIT (RETURN (QUOTE T)))))))))))))
     ((QUOTE T)
(format t "knownInfo (10) ~a~%" |pred|)
       NIL)))) 
 ))
)) 

\start
Date: Tue, 22 Jul 2003 19:53:37 -0400
From: Bill Page
To: list
Subject: RE: set function breakage

Tim,

On Tuesday, July 22, 2003 6:15 PM you wrote:
>
>[Bill]
> > What I am actually looking for is a simpler example of
> > an Axiom set function that actually fails. So far nothing
> > seems wrong. 
> 
> Why do you believe that the Set function fails?

Again, as reported by Juergen Weiss

  http://mail.gnu.org/archive/html/axiom-developer/2003-06/msg00088.html

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

coercels.input is "fairly" simple:

------

alternatingGroup 4
% :: List Permutation Integer
li := %
pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
p : pgr := first  li
q : pgr := first  li
basis  := [p,q,p*p,p*q, q*p,q*q, p*q*q, p*q*p, q*p*q,q*q*p,q*p*q*q,q*q*p*q]
% :: Set MonoidRing(Polynomial PrimeField 5,Permutation Integer)

------

But simpler would be better. Quite a lot of algebra has
to be loaded to execute these statements.

> The example of sets failing that I gave was actually a GCL
> common lisp example vs CCL common lisp. It was not an Axiom
> level failure. (To recall, the example was:
> 
> (setq a '(a))
> (setq b '(b c))
> in GCL:
> (set-difference b a) ==> (c b)
> in CCL:
> (set-difference b a) ==> (b c)
> 
> Both of these results are correct as they are both valid sets
> and the order of the result of set-difference is unspecified).
> 

As you say, this is not really a failure. There is no (should
not be) any assumption of order.

> The main Axiom failure is actually in the compiler. If you do:
> 
> (1) -> )co xpoly )con XPR
> 
> the compile will eventually die with a stack overflow. The above
> command says to compile the domain XPR from xpoly.spad. This
> will eventually involve walking the tree of domains that XPR
> uses. Walking this tree involves finding all of the domains it
> depends on and adding them to a list to be processed (the 
> DEPENDS list).

I think you said this earlier yourself: If somewhere in there
a coercion to type Set fails, perhaps "walking the tree" might
fail?

Thanks very much of the additional tutorial material on
Axiom/lisp debugging methods in your previous message.

\start
Date: Tue, 22 Jul 2003 20:30:33 -0400
From: Bill Page
To: list
Subject: RE: set function breakage

I wrote:

> 
> But simpler would be better. Quite a lot of algebra has
> to be loaded to execute these statements.
> 

Here's a somewhat simpler example that fails.

----

pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
p:pgr := 1
q:pgr := 1
set [p,q]

----

So it seems that some of the set properties of the domain

  Set MonoidRing(Polynomial PrimeField 5, Permutation Integer)

fail somehow.

\start
Date: Tue, 22 Jul 2003 21:25:55 -0400
From: Tim Daly
To: Bill Page
Subject: Sets in MonoidRing

> Here's a somewhat simpler example that fails.
> 
> ----
> 
> pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> p:pgr := 1
> q:pgr := 1
> set [p,q]
> 
> ----
> 
> So it seems that some of the set properties of the domain
> 
>   Set MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> 
> fail somehow.
> 

Very interesting. This is indeed a bug.

An interesting data point is that the downloadable version is
using algebra code that was compiled with the NAG image. That
means that the generated code.lsp files should all correctly
represent the associated algebra. So the problem does not
appear to be in the algebra code which would normally be
the first place to look. Once we've eliminated the algebra
code the problem must either be in the axiom interpreter or
the underlying lisp.

\start
Date: Tue, 22 Jul 2003 21:43:10 -0400
From: Tim Daly
To: Bill Page
Subject: Sets in MonoidRing

Another data point: 
given:

> pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> p:pgr := 1

one? p ==> false

but the answer should be:

one? p ==> false


The Tim Daly of the problem, as I now understand it, is that CCL had
a builtin, non-Common lisp function called ONEP. Clearly this
has affected the code. The lsp/ccl source tree has the CCL version
of the code and I'll have to understand what the function ONEP
is designed to do and add it to the set of common lisp functions.

\start
Date: Tue, 22 Jul 2003 21:57:28 -0400
From: Bill Page
To: list
Subject: RE: Sets in MonoidRing

Tim,

> 
> Another data point: 
> given:
> 
> > pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> > p:pgr := 1
> 
> one? p ==> false
> 
> but the answer should be:
> 
> one? p ==> false
> 

I think you meant?

  one? p ==> true

But note that

  a:pgr := 2
  b:pgr := 2
  (a=b)::Boolean

also gives false!

I have seen numerous places in the algebra where
one? was commented out and replaced with or defined
as

 x->(x=1)::Boolean

or equivalent.

> 
> The root of the problem, as I now understand it, is that
> CCL had a builtin, non-Common lisp function called ONEP.
> Clearly this has affected the code. The lsp/ccl source
> tree has the CCL version of the code and I'll have to
> understand what the function ONEP is designed to do and
> add it to the set of common lisp functions.
> 

But doesn't the example above suggest something wrong
with testing for equality?

Is there/was there also a builtin function for zero? Is
equality converted to

  zero? (lhs-rhs)

But presumably equality is/should be a more primative
notion in general.

\start
Date: Tue, 22 Jul 2003 22:06:34 -0400
From: Tim Daly
To: Bill Page
Subject: Sets in MonoidRing

You're right, the answer should be 

one? p ==> true.

Perhaps the problem isn't in the code but the (human) interpreter :-)

Equality could also be at the root of the problem. Common lisp
has several notions of equality: eq, eql, equal and the differences
are subtle. 

\start
Date: Wed, 23 Jul 2003 03:13:59 -0400
From: Richard Stallman
To: Richard Fateman
Subject: Re: GCL used commercially?
Cc: Stavros Macrakis, David Turner, Sam Steingold

    The commercial version, which was enhanced by Symbolics and then
    "Macsyma Inc" for about 20 years, is not public.  The Macsyma INc
    people supported and enhanced AKCL.  I do not know if their
    changes to AKCL were made public, but I suspect not.

Can anyone find out?

What was the license of AKCL at the time?  Did it permit them
to distribute an improved version and not release the source?
The LGPL does not permit such a thing.

\start
Date: Wed, 23 Jul 2003 03:14:25 -0400
From: Richard Stallman
To: Camm Maguire
Subject: Re: GCL compliance with GNU GPL
Cc: Stavros Macrakis, David Turner, Sam Steingold

We should think seriously about switching GCL to the GPL,
not assume that the goal is to avoid this.

    2) I am concerned with free software authors who might insist for some
       reason on a BSD-like license.  Specifically axiom.

Would they have any particular rational reason for thinking they need
this?  Note that we have no intention of changing to either of the BSD
licenses.

    3) I feel that any 'predominant' free compiler for a given language
       will likely not restrict the license of code merely compiled with
       it.

That is true in any case.  Code compiled with GCL's compiler is
copyright by its author, not by the copyright holders of GCL.

    6) Its obviously not right to use emacs' unexec under the LGPL without
       special permission.  I'm confused as to how this situation arose.
       I find some unexec files in the May 10 1994 release of gcl-1.0.
       Did Dr. Schelter ever discuss this with you or any other emacs
       developers? 

Alas, there is no chance I would remember after ten years, sorry.

\start
Date: Wed, 23 Jul 2003 10:00:36 +0100
From: Mike Dewar
To: Tim Daly
Subject: Re: Sets in MonoidRing
Cc: Bill Page

Hi Tim,

If I remember rightly the CCL onep function returns true if its argument
is a fixnum, float, bigfloat or complex number, and its value is 1,
false otherwise.

Cheers, Mike.

On Tue, Jul 22, 2003 at 09:43:10PM -0400, Tim Daly wrote:
> 
> Another data point: 
> given:
> 
> > pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> > p:pgr := 1
> 
> one? p ==> false
> 
> but the answer should be:
> 
> one? p ==> false
> 
> 
> The root of the problem, as I now understand it, is that CCL had
> a builtin, non-Common lisp function called ONEP. Clearly this
> has affected the code. The lsp/ccl source tree has the CCL version
> of the code and I'll have to understand what the function ONEP
> is designed to do and add it to the set of common lisp functions.

\start
Date: Tue, 22 Jul 2003 20:08:27 -0700
From: Thomas F. Burdick
To: Richard Stallman
Subject: Re: GCL used commercially?
Cc: Camm Maguire, Stavros Macrakis, Richard Fateman, David Turner, Sam Steingold

Richard Stallman writes:
 >     I think that the Macsyma company used Austin-Kyoto-Common-Lisp
 >     (which I believe is related to GCL) for its unix-sun/hp/.... version.
 > 
 > GCL is the same program as was formerly called AKCL.  The developers
 > agreed to make it a GNU package.
 > 
 > I believe Macsyma is released under the GPL now, so there would
 > be no difficulty running it on GCL even if GCL were GPL'd.

I believe that "Maxima" is the free software program, and "Macsyma" is
commercial/proprietary.  They share some heritage, but Macsyma has had
a *lot* of work done on its code base as a proprietary software.

\start
Date: Wed, 23 Jul 2003 12:42:06 +0200
From: Juergen Weiss
To: Bill Page
Subject: RE: Sets in MonoidRing

These examples (at least the ones I tested) work with
cmu cl. So the one? example is certainly a good start
for debugging. 

> You're right, the answer should be 
> 
> one? p ==> true.
> 
> Perhaps the problem isn't in the code but the (human) interpreter :-)
> 
> Equality could also be at the root of the problem. Common lisp
> has several notions of equality: eq, eql, equal and the differences
> are subtle. 

\start
Date: Wed, 23 Jul 2003 07:38:08 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: Sets in MonoidRing
Cc: Bill Page

Joergen,

If I understand you correctly you said that 

given          pgr:=MonoidRing(...
and            p:pgr:=1
that in CMUCL  one? p ==> true
but in GCL     one? p ==> false

If this is true then that is a great help in debugging this problem.

\start
Date: Wed, 23 Jul 2003 14:14:18 +0200
From: Juergen Weiss
To: list
Subject: RE: Sets in MonoidRing
Cc: Bill Page

Yes, exactly.


> 
> Joergen,
> 
> If I understand you correctly you said that 
> 
> given          pgr:=MonoidRing(...
> and            p:pgr:=1
> that in CMUCL  one? p ==> true
> but in GCL     one? p ==> false
> 
> If this is true then that is a great help in debugging this problem.
> 
> Tim


\start
Date: Wed, 23 Jul 2003 09:26:24 -0400
From: Tim Daly
To: list
Subject: KNOWN.BUGS.pamphet (July 23, 2003)

*,

I collected the known bugs into the attached KNOWN.BUGS.pamphlet file.
To see the report type:

noweave -delay KNOWN.BUGS.pamphlet >KNOWN.BUGS.tex
latex KNOWN.BUGS.tex
  -- (or which amounts to the same thing)
document KNOWN.BUGS    

To get an input file of the failures type:

notangle -ROPENINPUTFILE KNOWN.BUGS.pamphlet >KNOWN.BUGS.input

This is the first step in trying to organize the bug tracking
in some more rational form. I used to maintain a file (see
src/input/bugs.input.pamphlet) that was used to regression-test
known bugs. This is the latest version of that.

If I missed a bug or something needs changing let me know.

Tim

===================== KNOWN.BUGS.pamphlet ===================

\documentclass{article}
\usepackage{src/scripts/axiom}
\begin{document}
\title{\$SPAD KNOWN.BUGS}
\author{Nicolas Bourbaki}
\maketitle
\begin{abstract}
\end{abstract}
\eject
\tableofcontents
\eject
\section{Bug Reports}
Bug reporting tags should be shown here. These are simply a symbol
proceeded by two dashes and followed by a colon and starting in 
column 1. This section will allow software to process this file.

This file has several output chunks. The default output chunk will
include all of the bug reports. The OPEN output chunk will give a
list of the open bugs. The CLOSED output chunk will give a list
of the closed bugs. The OPENINPUTFILE output chunk will create a
standard .input file that demonstrates OPEN bugs for use in debugging.
The CLOSEDINPUTFILE output chunk will create a standard .input file
of closed bugs for use in regression testing.
<<bug000000>>=
-----------------------------------------------------------------------
--BugNumber: 
--Version: 
--Opened: 
--OpenedBy: 
--Closed: 
--ClosedBy: 
--Component:
--Description:
--ErrorMsg:
--Example:
@
\subsection{Bug 000001}
<<bug000001>>=
-----------------------------------------------------------------------
--BugNumber: 000001 
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: Spad Compiler
--Description: Certain spad files fail to compile
--ErrorMsg: Value stack overflow
--Example:
)clear all
)cd /spad/int/algebra
)co xpoly )con XPR
@
\subsection{Bug 000002}
<<bug000002>>=
-----------------------------------------------------------------------
--BugNumber: 000002
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: polynomials are parsed improperly
--Explanation:
--ErrorMsg: 1 is not of type POSITIVE-FIXNUM
--Example: 
)clear all
-- nag added code to rewrite polynomials so less functions are called
-- it appears that this function does not work.
x+x*x
@
\subsection{Bug 000003}
<<bug000003>>=
-----------------------------------------------------------------------
--BugNumber: 000003
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: dynamic functions won't execute
--Explanation:
--ErrorMsg: MANEXP is invalid as a function
--Example: 
)clear all
draw(x, x=-1..1)
@
\subsection{Bug 000004}
<<bug000004>>=
-----------------------------------------------------------------------
--BugNumber: 000004
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: default extensions on )read is broken
--Explanation:
--ErrorMsg: The file bugs.input is needed but does not exist
--Example: 
)clear
-- this is where all input files live
-- the cd command sets the default input path
)cd /home/axiomgnu/new/src/input
-- bugs should be extended to bugs.input but it is not
)read bugs
@
\subsection{Bug 000005}
<<bug000005>>=
-----------------------------------------------------------------------
--BugNumber: 000005
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: build process
--Description: depsys re-build fails
--Explanation:
--ErrorMsg: Error: Cannot get relocated section contents
--Example: 
-- assume that Axiom already exists
-- > cd /spad
-- > make
-- ...
-- Loading /home/axiomgnu/new/lsp/gcl-2.4.1/cmpnew/collectfn.o
-- parse_key_new is undefined
--
-- could be a bug due to using a gcl-2.5.2 build but changing
-- GCLVERSION to gcl-2.4.1
@
\subsection{Bug 000006}
<<bug000006>>=
-----------------------------------------------------------------------
--BugNumber: 000006
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: build process
--Explanation:
--Description: duplicate functions exists. optimizer complains during rebuild
--ErrorMsg: Warn foo redefined in #pX.fn. Originally in #pY.fn
--Example: 
-- assuming Axiom has already been built. 
-- >rm /spad/obj/linux/bin/interpsys
-- >cd /spad
-- >make
@
\subsection{Bug 000007}
<<bug000007>>=
-----------------------------------------------------------------------
--BugNumber: 000007
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: protect* functions should be #:NAG only
--Explanation:
--ErrorMsg: 
--Example: 
@
\subsection{Bug 000008}
<<bug000008>>=
-----------------------------------------------------------------------
--BugNumber: 000008
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: algebra
--Description: one? function calls need to be restored
--Explanation:
--ErrorMsg: 
--Example: 
@
\subsection{Bug 000009}
<<bug000009>>=
-----------------------------------------------------------------------
--BugNumber: 000009
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: build process
--Description: export DAASE=/home/axiomgnu/new/share
--Explanation: the DAASE global variable needs to exist during build
--             and it needs to point to the default copy of the various
--             .daase files which describe the algebra
--ErrorMsg: Error: Cannot open the file 
--          /home/axiomgnu/new/share/algebra/algebra/compress.daase.
--Example: 
@
\subsection{Bug 000010}
<<bug000010>>=
-----------------------------------------------------------------------
--BugNumber: 000010
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: export DAASE=/home/axiomgnu/new/share
--Explanation: This needs to default to mnt/sys in interpreter
--ErrorMsg: Error: Cannot open the file 
--          /home/axiomgnu/new/share/algebra/algebra/compress.daase.
--Example: 
@
\subsection{Bug 000011}
<<bug000011>>=
-----------------------------------------------------------------------
--BugNumber: 000011
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: algebra
--Description: duplicate definition of a function in PSETCAT
--Explanation: 
--ErrorMsg: Warning: PSETCAT-;exactQuo has a duplicate definition in this file
--Example: 
@
\subsection{Bug 000012}
\begin{verbatim}
   LODO1 abbreviates domain LinearOrdinaryDifferentialOperator1 
****** comp fails at level 1 with expression: ******
((DEF (|LinearOrdinaryDifferentialOperator1| A)
      (NIL (|DifferentialRing|)) (NIL NIL)
      (|LinearOrdinaryDifferentialOperator| A
          (|elt| A |differentiate|))))
****** level 1  ******
$x:= (DEF (LinearOrdinaryDifferentialOperator1 A) (NIL (DifferentialRing)) (NIL NIL) (LinearOrdinaryDifferentialOperator A (elt A differentiate)))
$m:= $EmptyMode
$f:=
((((|$DomainsInScope| # #))))
 
   >> Apparent user error:
   bad == form 
   (DEF (LinearOrdinaryDifferentialOperator1 A) ( ) ( ) (LinearOrdinaryDifferentialOperator A (elt A differentiate)))

protected-symbol-warn called with (NIL)
\end{verbatim}
<<bug000012>>=
-----------------------------------------------------------------------
--BugNumber: 000012
--Version: Monday June 9, 2003 at 01:30:39 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: algebra
--Description: LODO1 fails to bootstrap
--Explanation: 
--ErrorMsg: ****** comp fails at level 1 with expression: ******
--Example: 
@
\subsection{Bug 000013}
\begin{verbatim}
****** comp fails at level 2 with expression: ******
\end{verbatim}
[[(|LinearOrdinaryDifferentialOperator| A | << |]]
[[    (|elt| A |differentiate|) | >> |)]]
\begin{verbatim}
****** level 2  ******
$x:= (elt A differentiate)
$m:= $EmptyMode
$f:=
((((|differentiate| # # #) (~= # # #) (= # # #) (|coerce| # # #) ...)))
 
   >> Apparent user error:
   Operation  differentiate missing from domain: A

protected-symbol-warn called with (NIL)
\end{verbatim}
<<bug000013>>=
-----------------------------------------------------------------------
--BugNumber: 000013
--Version: Monday June 9, 2003 at 01:30:39 
--Opened: 20030608 
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: algebra
--Description: LODO2 fails to bootstrap
--Explanation: 
--ErrorMsg: ****** comp fails at level 2 with expression: ******
--Example: 
@
\subsection{Bug 000014}
The last command in coercels.input converts the result to a set.
With gcl, the result contains duplicate elements. Problem does not
occur with cmu cl.
<<bug000014>>=
-----------------------------------------------------------------------
--BugNumber: 000014
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030701
--OpenedBy: Juergen Weiss, Bill Page
--Closed: 00000000
--ClosedBy: 
--Component: algebra
--Description: duplicate set element
--Explanation:
--ErrorMsg: 
--Example: 
alternatingGroup 4
% :: List Permutation Integer
li := %
pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
p : pgr := first  li
q : pgr := first  li
basis  := [p,q,p*p,p*q, q*p,q*q, p*q*q, p*q*p, q*p*q,q*q*p,q*p*q*q,q*q*p*q]
% :: Set          MonoidRing(Polynomial PrimeField 5,Permutation Integer)
-- a simple example
-- this fails in GCL but works in CMUCL
m:pgr :=1
n:pgr :=1
set[m,n]
--Example 2
one? m
@
\subsection{Bug 000015}
Axiom used to take a -rm argument which pushes a call to the lisp function
(|inputFile2RecordFile| '"foo.input"). This no longer works. The command
[[axiom -rm foo.input]] should succeed.
<<bug000015>>=
-----------------------------------------------------------------------
--BugNumber: 000015
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030701
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: 
--Explanation:
--ErrorMsg: throw: tag not found |writifyTag|
--Example: 
@
\subsection{Bug 000016}
Axiom used to take a -rv argument which pushes a call to the lisp function
(|verifyRecordFile| '"foo.rec"). This no longer works. The command
[[axiom -rv foo.rec]] should succeed.
<<bug000016>>=
-----------------------------------------------------------------------
--BugNumber: 000016
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030701
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: 
--Explanation:
--ErrorMsg: 
--Example: 
@
\subsection{Bug 000017}
Axiom needs to be linked with the OpenMath library. The library needs
a common lisp API written for GCL.
<<bug000017>>=
-----------------------------------------------------------------------
--BugNumber: 000017
--Version: Thursday June 5, 2003 at 14:52:04 
--Opened: 20030701
--OpenedBy: Tim Daly
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: 
--Explanation:
--ErrorMsg: OM-STRINGTOSTRINGPTR is invalid as a function
--Example: 
OMwrite sin(x)
@
\subsection{Bug 000018}
In some versions of GCL the LOG10 function returns improperly rounded values.
The symptom is:
\begin{verbatim}
(24) -> [1000]
   (24)  [100]
\end{verbatim}
The common lisp failure can be shown with:
\begin{verbatim}
(25) -> )lisp (log10 1000)
Value = 2.9999999999999996
\end{verbatim}
This previous boot code was:
\begin{verbatim}
    u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR LOG10 u
and should be restored when the GCL bug is fixed.
    u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR ((LOG10 u) + 0.0000001)
\end{verbatim}
<<bug000018>>=
-----------------------------------------------------------------------
--BugNumber: 000018
--Version: Friday July 18, 2003 at 13:33:22 
--Opened: 20030718
--OpenedBy: Joergen Weiss
--Closed: 00000000
--ClosedBy: 
--Component: interpreter
--Description: 
--Explanation: log10 in GCL returns a bad value for log10(1000)
--ErrorMsg: 
--Example: 
)lisp (log10 1000)
@
\section{CLOSED bugs}
The CLOSED output chunk will give a list of the closed bugs.
<<CLOSED>>=
@
\section{CLOSED .input file}
The CLOSEDINPUTFILE output chunk will create a standard .input file
of closed bugs for use in regression testing.
<<CLOSEDINPUTFILE>>=
@
\section{OPEN bugs}
The OPEN output chunk will give a list of the open bugs.
<<OPEN>>=
<<bug000000>>
<<bug000001>>
<<bug000002>>
<<bug000003>>
<<bug000004>>
<<bug000005>>
<<bug000006>>
<<bug000007>>
<<bug000008>>
<<bug000009>>
<<bug000010>>
<<bug000011>>
<<bug000012>>
<<bug000013>>
<<bug000015>>
<<bug000016>>
<<bug000017>>
<<bug000018>>
@
\section{OPEN .input file}
The OPENINPUTFILE output chunk will create a
standard .input file that demonstrates OPEN bugs for use in debugging.
<<OPENINPUTFILE>>=
)set message autoload off
)set break resume
<<bug000001>>
<<bug000002>>
<<bug000003>>
<<bug000004>>
<<bug000017>>
<<bug000018>>
@
\section{The default report}
The default output chunk will include all of the bug reports.
<<*>>=
<<bug000000>>
<<bug000001>>
<<bug000002>>
<<bug000003>>
<<bug000004>>
<<bug000005>>
<<bug000006>>
<<bug000007>>
<<bug000008>>
<<bug000009>>
<<bug000010>>
<<bug000011>>
<<bug000012>>
<<bug000013>>
<<bug000014>>
<<bug000015>>
<<bug000016>>
<<bug000017>>
<<bug000018>>
@
\eject
\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}
\end{document}

\start
Date: Wed, 23 Jul 2003 09:22:42 -0700
From: Richard Fateman
To: Richard Stallman
Subject: Re: GCL used commercially?
Cc: Stavros Macrakis, David Turner, Sam Steingold

Richard Stallman wrote:
>     The commercial version, which was enhanced by Symbolics and then
>     "Macsyma Inc" for about 20 years, is not public.  The Macsyma INc
>     people supported and enhanced AKCL.  I do not know if their
>     changes to AKCL were made public, but I suspect not.
> 
> Can anyone find out?
> 
> What was the license of AKCL at the time?  Did it permit them
> to distribute an improved version and not release the source?
> The LGPL does not permit such a thing.
> 
> _______________________________________________
RMS and others:

1. My recollection is that the Kyoto people wanted
their code separated, so that to run Austin-Kyoto Common Lisp
you had to set up the Kyoto code and then run Bill Schelter's
  "change script" to make it into Austin-Kyoto.
Officially you also needed to write to the authors
to tell them you were using it. And various other things.
I do not believe the Kyoto people made a fuss about re-use,
though I don't know if IBM or Ibuki or Austin Code Works
(see below) made specific deals.

2. The KCL licensing can be viewed in
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/kcl/kcl/license.txt

among other things it says
.........
(c) Copyright Taiichi Yuasa and Masami Hagiya, 1984.  All rights reserved.
Copying of this file is authorized to users who have executed the true 
and proper "License Agreement for Kyoto Common LISP" with SIGLISP.

.........
I see no evidence that these authors ever surrendered their
copyrights, though in GCL documentation, also at CMU it says


    Versions 1.0 and above of GCL (aka versions 1-625 and above of
    AKCL) no longer require the kcl.tar file, and are covered by the
    GNU General Public Library License.

It could be that that declaration happened without the true original
authors' permission
and that someone (misunderstanding the nature of GPL?) thought that
(say, because he was willing to give up rights to HIS contributions to
AKCL) that ALL of AKCL, reborn as GCL, would be covered by GPL.
This could have been Bill Schelter, who also asked DOE to release
their 1982 source of Macsyma under GPL.  (Rather than, say, a BSD-like
license). In fact the DOE license is not GPL, if you look at it,
since one cannot send copies to Cuba or such countries.  I don't think 
Bill was much interested in legal issues,
but he was generous with his code, intending it to be given
to anyone interested in using it. He made not have understood that
a GPL would inhibit some people from using it, RMS notwithstanding.
It is not possible to ask Bill Schelter, but the authors are, so far
as I know, still alive.

3. At least two companies (Austin Code Works, Ibuki) sold improved 
versions of KCL, or tried to. These are mentioned in the
various license and info files at cmu,... see the text file
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/gcl/0.doc
for example.

As for stuff built on top of AKCL....

   a. I think that some version of the Axiom computer algebra
system required KCL, and that Bill Schelter consulted for
IBM to make it work better for that purpose.

   b. As previously mentioned, commercial Macsyma used a version
of KCL.

RMS' question seems directed to find out
if these various people (macsyma inc, ...) might be
in violation of some version of GPL.  My point is quite
different.

To reiterate:
I think that these 4 companies relied on GCL or AKCL or some predecessor
NOT being under GPL. They had no wish to distribute to their
competitors any improvements they developed.


   For good reasons or not, if AKCL were under GPL those companies
probably would not have used it, enhanced it, productized
it, or (especially) sold it.

  They wanted a piece of code that they could use without
paying, and that they could improve at their own expense, and
then use for their (proprietary) purposes and sell.

Whether they could have been convinced to forego their
capitalist impulses and celebrate free software is,
I think, not possible to answer at this time.

If I understand the objections of some people of the
maxima group to GPL, rather than LGLP, it is that it
would inhibit some future company that might pick up and
enhance maxima at its expense, and for its own profit, and
that it would start with the
initial work of this group.

  For a small enough
specialized and highly technical market, such a
company MIGHT make sense.  This is a different situation
from a very common, widely distributed, technically
"shallower" piece of software where 100,000 people
might plausibly contribute useful additions and corrections.

One solution for such a company would be to not use GCL;
using a commercial lisp might seem to increase its costs,
but note that keeping a full-time GCL expert alive and
well in a company might cost $100,000 or more
  per year (salary, support,benefits, overhead). Using
a "non-free" lisp might be cheaper than a free one. So
I am not personally so worried about using GCL for
maxima, so long as it also runs on other lisps.

\start
Date: Wed, 23 Jul 2003 12:47:19 -0400
From: Tim Daly
To: Richard Fateman, Richard Stallman
Subject: GCL used commercially

Richard[s],

I was the Axiom (nee Scratchpad) developer at IBM Research who worked
with Bill Schelter on AKCL. At the time AKCL was licensed first from
Kyoto thru Yuasa and Hagiya. Bill had an agreement that allowed him
to make changes atop the original (KCL). He built a mechanism that
merged the original with his own version of patch to construct AKCL.
IBM, in order to distribute Scratchpad, had a license with both the
KCL group and Schelter and had permission to distribute Scratchpad
with AKCL. I was part of those discussions.

At the time my efforts involved porting Scratchpad from MacLisp and
Lisp/VM to Common Lisp. Scratchpad eventually ran on any Common Lisp
including Symbolics, Golden Common Lisp, Lucid, Franz, AKCL, CMUCL
(Spice, actually, which later morphed into CMUCL), and IBUKI.

When Scratchpad was sold to NAG (Numerical Algorithms Group) as "Axiom"
the whole Axiom effort was replatformed from AKCL to CCL (Arthur Norman's
Codemist Common Lisp). The NAG version runs on CCL. Arthur Norman has
released a version of CCL under modified BSD and the sources are distributed
as part of the Axiom system. 

In the readme file Bill comments that the last version distributed
under the old license was akcl-1-624 which was, in fact, the last
version that Scratchpad used.


GCL may not in fact be a direct derivative of KCL. I know that Bill
had plans to rewrite the KCL pieces of the system and, given his
level of productive output, likely succeeded. Unfortunately we parted
ways once Axiom came out.

The basic build process involved compiling a file called "merge.c"
which was Bill's "patch" program. It took .V files and did context
sensitive replacements from KCL sources to AKCL sources. The .V files
no longer exist and there are no @s[ replacement instructions left.
The merge.c program still exists in the source tree but appears unused.
Thus I believe, but cannot prove, that he completely rewrote the KCL part.

Bill was extremely sensitive to licensing issues and we had numerous
discussions on the subject. I believe, knowing Bill, that he somehow
resolved the licensing issue with the KCL people. He was very careful
about the licensing issue. He was also deeply aware of the GPL issues
as he was a contributor to Emacs sources (look for his name in the
dbg handling under Emacs). It is unlikely that he included anything
without knowing he had permission.

As to the issue of distributing the improvements I believe, but can no
longer prove, that the IBM contract was written so that all changes
made by Bill were freely distributable. Scratchpad was a research
project and I know that, up until the issue of selling Scratchpad
started, I could freely distribute the Scratchpad sources if asked. I
know that various people have (or had) copies of the sources. The 
attitude at IBM Research (at least as I understood it) was very
close to the one Stallman expected which was "sources? sure. what
format would you like them in? tape or 5in floppy?". Bill had basically
the same attitude. What little money he made off AKCL was due to services,
not to selling source code, at least as far as I'm aware.

Actually, IBM did pay for the services. Bill was under contract
with IBM. At the time we had no plans to sell Scratchpad. We favored
Bill's AKCL because (a) Bill could help us port it to many platforms
(I wanted Scratchpad to run on everything, including DOS) and (b) Bill
was very receptive to helping us optimize Scratchpad as he was also
a user and contributor. Furthermore he was an excellent mathematician
so he could handle the complexity of Axiom's algebra.

The language you use to implement a system (such as Maxima) should not
be affected by the language implementation (GCL, Franz) license. At
some point you have to try to separate church and state. Isn't there
any way to be a programmer without becoming a lawyer also? Must I learn
about lache, estopple, waiver, and abandonment in order to program?
These days I feel like I should major in Law with a minor in CompSci.

Tim Daly

P.S. I'll take the $100,000 a year to maintain GCL :-)

\start
Date: Wed, 23 Jul 2003 13:58:00 -0400
From: Tim Daly
To: Richard Fateman
Subject: Re: GCL used commercially
Cc: Richard Stallman

Fateman wrote:

> Thanks for the info! I guess I was mistaken in thinking Bill
> was not concerned with the details of the legal issues.
> 
> If Bill rewrote GCL from the ground up, that would explain
> the change in license terms.
> 
> RJF
> 
> PS, this was not sent to the maxima mailing list.. are the
> relevant people cc'd by virtue of one of the other lists?

re: did we copy the relevant people? probably not. unfortunately i have
to wait until i get home to resend it as i didn't copy my work email
either. you're welcome to forward it to the gcl and maxima lists.

> PPS
> As a rough cut, my guess is that at a relatively lean company
> $100,000 would be divided this way:
> 
> $50k salary
> $10k maintenance of computer system for that person
>       (hardware, software, staff, upgrades)
> $30k health, retirement, soc. sec. benefits
> $10k company admin. (secretarial, accounting, office rental, phone..)
> 
> Your $50k would then be taxed, of course.

$50k, $100k, Hey, I'm cheap and easy. Any number with a comma in
it that supports my coding addiction is most welcome :-). 

Currently I'm muttering about ways to support the Axiom developers. 
One suggestion I'm pursuing heavily is to try to set up a tax-exempt 
corp so we can go after corporate grants or govt grants. There are so 
few Axiom-quality math experts that I think I need to tempt them with 
cash. I'm willing to work for nothing (actually, Axiom's cost me about
$2500 in "incidental expenses" (invited talks that didn't get fully
paid for, copies of the axiom textbook I give out for free, phone calls
to developers, hosting, media for the Rosetta CD I give out, etc) so far.)
Axiom's real strength is as a research platform rather than a compute
engine and I'd like to convince researchers to write it into their
grants. A corporate name would make it so much easier for companies
to handle especially if they can get a tax break. And the NSF could
probably be convinced to support a researcher or two. Plus the corporate
route will enable the code to remain free and available even if I get
hit by the proverbial bus.

\start
Date: Wed, 23 Jul 2003 11:41:36 -0700 (PDT)
From: Cliff Yapp
To: Richard Fateman, Richard Stallman
Subject: Re: GCL used commercially?
Cc: David Turner, Sam Steingold, Stavros Macrakis

--- Richard Fateman wrote:

> This could have been Bill Schelter, who also asked DOE to release
> their 1982 source of Macsyma under GPL.  (Rather than, say, a
> BSD-like license). In fact the DOE license is not GPL, if you look 
> at it, since one cannot send copies to Cuba or such countries.

Um, that's not part of the license - it's a condition imposed by U.S.
export restrictions.  We went through all that on the list, and it was
finally settled by David Turner of the FSF.  Maxima is GPL.  That does
not relate to the GCL case however, since GCL apparently has a
different history than Maxima.

> I  don't think Bill was much interested in legal issues,
> but he was generous with his code, intending it to be given
> to anyone interested in using it. 

Yes.  I for one am very grateful for his generosity, but his casual
approach to licensing sure has raised a point or two.

> He made not have understood that
> a GPL would inhibit some people from using it, RMS notwithstanding.
> It is not possible to ask Bill Schelter, but the authors are, so far
> as I know, still alive.

Would they have the authority to make a license change?

> RMS' question seems directed to find out
> if these various people (macsyma inc, ...) might be
> in violation of some version of GPL.  

Well, David K. Schmidt seems to be the contact point for commercial
Macsyma now but I'd be surprised if they
have any (L)GPL issues, particularly given the history Dr. Fateman has
given.

> If I understand the objections of some people of the
> maxima group to GPL, rather than LGLP, it is that it
> would inhibit some future company that might pick up and
> enhance maxima at its expense, and for its own profit, and
> that it would start with the initial work of this group.

As far as Maxima goes, I think the consensus was that this was
probably a good thing.  A few people thought the idea of allowing
closed work wasn't a bad idea, but most agreed that losing one
commercial Macsyma was enough, and that a permanently free 
platform would be a much better, if slower, way to develop things.

> For a small enough
> specialized and highly technical market, such a
> company MIGHT make sense.  This is a different situation
> from a very common, widely distributed, technically
> "shallower" piece of software where 100,000 people
> might plausibly contribute useful additions and corrections.

The problem is, in Maxima's space anyway, that Mathematica and Maple
have pretty much gained full control of the market, and have huge
inertia.  If a company were to challenge that using a closed fork of
Maxima as a base and fail (as Macsyma Inc did) then all the work would
be lost again, and researchers using it would be stuck depending on
unsupportable extensions to Maxima.  Maxima's entry into the equation
is basically like that of GNU/Linux - be good enough and free, and get
better with time.  The free aspect is the killer feature.

> One solution for such a company would be to not use GCL;
> using a commercial lisp might seem to increase its costs,
> but note that keeping a full-time GCL expert alive and
> well in a company might cost $100,000 or more
>   per year (salary, support,benefits, overhead). Using
> a "non-free" lisp might be cheaper than a free one. So
> I am not personally so worried about using GCL for
> maxima, so long as it also runs on other lisps.

Indeed, I have always thought ACL was the logical choice for people
wishing to do commercial lisp work.  It is an excellent, commercially
supported and well documented product, from what I can see.

I still don't understand why it would be desirable to prevent software
from using GCL, regardless of license, but perhaps I'm missing
something.  Why aren't the lisp environment and the lisp program
treated as two separate entities?  If a person creates and distributes
a lisp image using GCL to make a software package, why can't it be
handled such that the GCL source must be included, but the lisp program
itself is a separate thing?

\start
Date: Wed, 23 Jul 2003 21:15:48 +0200
From: David Mentre
To: Bill Page
Subject: Re: set function breakage

Hello Bill,

On my home-compiled Axiom (from Tenkan CVS), it fails just after
defining "p".

"Page, Bill" writes:

> pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> p:pgr := 1

Here, interpsys outputs "Cannot open the file
/[...]/new/mnt/linux/algebra/PF.o."


> q:pgr := 1
> set [p,q]


Any idea on what is going wrong? I've checked, my axiom CVS is up to
date. And with a binary release of Axiom made by Tim, your example work.

\start
Date: Wed, 23 Jul 2003 21:24:59 +0200
From: David Mentre
To: Tim Daly
Subject: Re: Sets in MonoidRing

Hello Tim,

Tim Daly writes:

>> pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
>> p:pgr := 1
>> q:pgr := 1
>> set [p,q]
>> 
>> ----
>> 
>> So it seems that some of the set properties of the domain
>> 
>>   Set MonoidRing(Polynomial PrimeField 5, Permutation Integer)
>> 
>> fail somehow.
>> 
>
> Very interesting. This is indeed a bug.

Maybe a stupid idea, but wouldn't be possible to print a parallel trace
of Axiom's common lisp code running on CCL and GCL while the faulting
code executes? By comparing those two traces side by side, it would
indicate where the behavior of lisps diverges and maybe pinpoint a bad
behavior.

I don't know if it is doable however. As far as I have understood, the
tracing facilities of GCL are targeted towards a specific previously
known function but not all functions in general.

\start
Date: Wed, 23 Jul 2003 15:39:49 -0400
From: Bill Page
To: David Mentre, Bill Page
Subject: RE: set function breakage

David,

The version of axiom to which I am referring is the run-time
system that Tim prepared "by hand" and uploaded to

  http://axiom.tenkan.org

This is a complete version of Axiom for Linux systems that
cannot (yet) be build automatically from the CVS sources
since it depends on pre-existing lisp code that should
otherwise be produced by compiling the axiom spad code.
(Tim, please correct me if I am wrong on the details.)

Tim made this version of axiom available because people
were getting anxious to get there hands on a running system
again even though this version cannot really be the long
term basis for Axiom development. So far it is just a good
speculation that the problems we see in this run-time
version are connected to the problems of compiling axiom
from source.

The message you get from axiom built from CVS is probably
due to the fact that only a small fraction of the algebra
code has been compiled. Attempting to compile some of the
missing logic will quickly get you to the stack overflow
problem that we have been talking about.


> 
> Hello Bill,
> 
> On my home-compiled Axiom (from Tenkan CVS), it fails just after
> defining "p".
> 
> "Page, Bill" writes:
> 
> > pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> > p:pgr := 1
> 
> Here, interpsys outputs "Cannot open the file
> /[...]/new/mnt/linux/algebra/PF.o."
> 
> 
> > q:pgr := 1
> > set [p,q]
> 
> 
> Any idea on what is going wrong? I've checked, my axiom CVS is up to
> date. And with a binary release of Axiom made by Tim, your 
> example work.
> 

\start
Date: Wed, 23 Jul 2003 15:51:29 -0400
From: Tim Daly
To: David Mentre
Subject: Re: set function breakage
Cc: Bill Page

David,

The difference between the CVS version and the download version 
is the algebra subdirectory. The download version was compiled
with the NAG compiler which can compile all of the algebra vs
the CVS version which can't. If you copy the algebra subdirectory
from the download version it should work.

\start
Date: Wed, 23 Jul 2003 15:57:30 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Sets in MonoidRing

David,

In fact, the parallel trace idea is how I've tried to debug the
compiler problem. Unfortunately it is not really that simple
(there is no such thing as a simple job) as the code differs
in the two lisps. However for this case we can compare GCL vs
CMUCL which would be running exactly the same code.

You can trace anything you can get your hands on in any common 
lisp. The trick is to figure out where Axiom hides stuff. The
hardest part is that even at 2.5Ghz a computation can take a
second or so. That's 2.5 BILLION (U.S. :-) ) instructions that
can be wrong. I've had a parallel trace walk going for 3 days
chasing the compiler bug and still not cornered it. The system
is very complex and takes a lot of skill and patience to debug
even the simple things, mostly because the person who's job it
was (me) didn't document the damn thing. We're gonna fix that.

\start
Date: Wed, 23 Jul 2003 21:52:50 +0200
From: David Mentre
To: Bill Page
Subject: Re: set function breakage

Thanks Bill for your explanation. I was just thinking that the code you
mentionned was also triggering the stack overflow.

"Page, Bill" writes:

> Attempting to compile some of the
> missing logic will quickly get you to the stack overflow
> problem that we have been talking about.

Yes, I have been able to reproduce the bug using Tim's detailed
explanations on )co xpoly )con XPR.

\start
Date: Wed, 23 Jul 2003 22:17:33 +0200
From: David Mentre
To: Tim Daly
Subject: Re: set function breakage
Cc: Bill Page

Tim Daly writes:

> If you copy the algebra subdirectory from the download version it
> should work.

Err no.

I've tried to compiled the CVS xpoly.spad with your prebuild Axiom and
it fails, in the same way as with GCL.

What I have done:

* In ~/pub/axiom-libre/axiom-cvs-2003-06-25-dm-i386/new/new/src/algebra:

 - notangle xpoly.spad.pamphlet > /tmp/xpoly.spad

* In the directory where I have untared axiom.linux.20030614.tgz:

 - export AXIOM=/home/david/00-poubelle/axiom/mnt/linux/

 - PATH=$AXIOM/bin:$PATH

 - axiom

* Under pre-build Axiom:

(1) -> )cd /tmp
   The current AXIOM default directory is /tmp/ 
(1) -> )co xpoly )con XPR
[...]
   compiling local outTerm : (R,E) -> OutputForm
Time: 0.03 SEC.

   compiling exported coerce : $ -> OutputForm
Time: 0.22 SEC.

 
   >> System error:
   Value stack overflow.

protected-symbol-warn called with (NIL)


So the bug would be in the algebra???

\start
Date: Wed, 23 Jul 2003 16:41:16 -0400
From: Tim Daly
To: David Mentre
Subject: Re: set function breakage
Cc: Bill Page

Oh. I misunderstood.

First, the difference between prebuilt and CVS is the algebra subdirectory.
Second, the algebra code works (mostly) in prebuilt.
Third, )co xpoly fails in all versions. That is the bug we're all looking
to kill. 

I thought you were trying to run the Set of MonoidRing example.
That should work in the prebuilt version. If you want to change the
interpreter you can make the mods to the sources, rebuild the sources,
and then copy the newly-built interpsys into the prebuilt version.
In general I have an interpsys in the prebuilt version that is just
a symbolic link to one of a series of interpsys images.

\start
Date: Wed, 23 Jul 2003 16:47:58 -0400
From: Bill Page
To: Tim Daly
Subject: axiom names and lisp names

Tim,

How do I translate from the axiom name of a variable
to the lisp name? What I would like to do (maybe you
can do it faster?) is use our simple example where

  pgr:=MonoidRing(...)

  p:pgr:=1

  q:pgr:=1

  (p=q)::Boolean
       false

fails. And follow this by something like

  )lisp (equal p q)
  )lisp (eql p q)
  )lisp (eq p q)

but of course I need to know the real lisp names for
p and q.

BTW, I notice that

  (p=1)::Boolean
     false

but

  p-q
      0

and even

  p-1
      0

I still think this points at a failure in the underlying
lisp equality (or maybe the Equation constructor algebra).

\start
Date: Wed, 23 Jul 2003 16:47:40 -0400
From: Tim Daly
To: David Mentre, Bill Page
Subject: RE: set function breakage

Sorry, I misspoke again. (Some day I'll learn to speak English correctly)

The "Set MonoidRing" example can be executed in the prebuilt version
(in that sense it "should work") however the prebuilt version will
give a bad result. I don't believe the CVS version will even execute
the Set MonoidRing example using the CVS algebra.

\start
Date: Wed, 23 Jul 2003 19:02:57 -0400
From: Richard Stallman
To: Thomas F. Burdick
Subject: Re: GCL used commercially?
Cc: Camm Maguire, Stavros Macrakis, Richard Fateman, David Turner, Sam Steingold

     > I believe Macsyma is released under the GPL now, so there would
     > be no difficulty running it on GCL even if GCL were GPL'd.

    I believe that "Maxima" is the free software program, and "Macsyma" is
    commercial/proprietary.

I guess you're right.  We don't have much reason to care about
Macsyma, though.

\start
Date: Wed, 23 Jul 2003 21:58:28 -0400
From: Tim Daly
To: Bill Page
Subject: where is the symbol?

Bill,

You'd think that your question about where the symbol is interned
would be easy to answer but it is not. The top level loop uses Bill
Burge's dreaded zipper parser. You can see it in action by executing
the following sequence:

)lisp (setq $DALYMODE t)    ;;; this is a special mode of the top level
                            ;;; interpreter. If $DALYMODE is true then
                            ;;; any top-level form that begins with an
                            ;;; open-paren is considered a lisp expression.
                            ;;; For almost everything I ever do I end up
                            ;;; peeking at the lisp so this bit of magic helps.
(trace |intloopProcessString|) ;; from int-top.boot.pamphlet
(trace |intloopProcess|)       ;; the third argument is the "zippered" input
(trace |intloopSpadProcess|)   ;; now it is all clear, no? sigh.

Anyway, I'm working on your answer.

\start
Date: Wed, 23 Jul 2003 23:06:34 -0400
From: Tim Daly
To: Bill Page, Camm Maguire
Subject: where is the symbol?

Bill, Camm,

You'd think that your question about where the symbol is interned
would be easy to answer but it is not. The top level loop uses Bill
Burge's dreaded zipper parser. You can see it in action by executing
the following sequence:

)lisp (setq $DALYMODE t)    ;;; this is a special mode of the top level
                            ;;; interpreter. If $DALYMODE is true then
                            ;;; any top-level form that begins with an
                            ;;; open-paren is considered a lisp expression.
                            ;;; For almost everything I ever do I end up
                            ;;; peeking at the lisp so this bit of magic helps.
(trace |intloopProcessString|) ;; from int-top.boot.pamphlet
(trace |intloopProcess|)       ;; the third argument is the "zippered" input
(trace |intloopSpadProcess|)   ;; now it is all clear, no? sigh.
(trace |phInterpret|)          ;; from int-top.boot.pamphlet
(trace |intInterpretPform|)    ;; from intint.lisp.pamphlet
(trace |processInteractive|)   ;; from i-toplev.boot.pamphlet
(setq $reportInstantiations t) ;; shows what domains were created
(trace |processInteractive1|)  ;; from i-toplev.boot.pamphlet

ah HA! I remember now. There is the notion of a "frame" which is
basically a namespace in Axiom or an alist in Common Lisp. It is
possible to maintain different "frames" and move among them. There
is the notion of the current frame and it contains all the defined
variables. At any given time the current frame is available as
|$InteractiveFrame|. This variable is used in |processInteractive1|.
If you do:

a:=7
(pprint |$InteractiveFrame|)

you'll see |a| show up on the alist. When you do the 

pgr:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
p:pgr:=1

you'll see |p| show up with 2 other things: (|p| mode value)
where mode is the "type" of the variable. The value is the
internal value. In this case MonoidRing has an internal
representation. You can find out what the internal representation
of a MonoidRing is by first asking where the source file is:

(do this at a shell prompt, not in axiom)
asq -so MonoidRing ==> mring.spad

     -- or -- in Axiom type:

)show MonoidRing

and you'll see a line that reads: 
Issue )edit (yourpath)/../../src/algebra/mring.spad

If you look in mring.spad.pamphlet you'll see line 91 that reads:

   Rep := List Term

which says that we will store elements of type MonoidRing as a list
of Term objects. Term is defined in the same file (as a macro, which
is what '==>' means in spad files) on line 43:

   Term ==> Record(coef: R, monom: M)

which means that elements of a MonoidRing are Lists of Records.
The 'R' is defined on line 42 as the first argument to MonoidRing
which in this case is 'Polynomial PrimeField 5'. The 'M' is also
defined on line 42 as the second argument to MonoidRing and in this
case is 'Permutation Integer'. So the real representation is

  List Record(coef: Polynomial PrimeField 5, monom: Permutation Integer)

In the |$InteractiveFrame| we printed out you can see in the |value|
field that the value is:

(|value| (|MonoidRing| (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|))) WRAPPED ((0 . 1) . #<vector 08af33d4>))

which basically means that we know how the MonoidRing was constructed and
what it's current value is. The (0 . 1) likely means that this is the
zeroth (constant) term with a leading coefficient of 1. This is just a
guess as I haven't decoded the representation of either Polynomial PrimeField 
or Permutation Integer. You can do the same deconstruction of these two
domains by setting

pi:=Permutation Integer
z:pi:=1

pp5:=Polynomial PrimeField 5
w:pp5:=1

and following the same steps as above: 
 (pprint |$InteractiveFrame|)
 )show pi
 (find the source file)
 (find the representation and decode it)

 (pprint |$InteractiveFrame|)
 )show pp5
 (find the source file)
 (find the representation and decode it)

Be sure to set $DALYMODE to nil if you plan to use Axiom for any
real computation. Otherwise every expression that begins with an
open-paren will go directly to lisp.

Sorry I took so long but it's been a while.
Hope this helps.

\start
Date: Thu, 24 Jul 2003 12:36:46 +1000
From: Mike Thomas
To: Richard Stallman, Camm Maguire
Subject: Re: GCL compliance with GNU GPL - Axiom question, AKCL tarball licences
Cc: David Turner, Sam Steingold, Stavros Macrakis

Hi There Everyone.

I would like to ask a question and add some data points on Austin-Kyoto
Common Lisp (AKCL) licencing (and consequently GNU Common Lisp - GCL) to the
discussion, which may provide some clues as to Bill Schelter's (and possibly
by implication the commercial Macsyma developers) understanding of the kind
of licence which applied to AKCL in the early 1990's.

First the question:


AXIOM LICENCE QUESTION

Richard Stallman wrote:

|     3) I feel that any 'predominant' free compiler for a given language
|        will likely not restrict the license of code merely compiled with
|        it.
|
| That is true in any case.  Code compiled with GCL's compiler is
| copyright by its author, not by the copyright holders of GCL.

What obligations would the FSF consider applied to the Axiom developers if
they built Axiom (BSD licence) and released the resulting binary using a
strictly GPL'ed Gnu Common Lisp with no exception clauses added?

My understanding a few days ago was that we were considering adding an
exception clause to the GPL for GCL which would allow it's use in non-source
disclosure situations.  Is that still on the table?

And now for some Macyma Blue Sky Mining:



AKCL HISTORY SAMPLES

Richard STALLMAN wrote in reply to Camm Maguire:

|     6) Its obviously not right to use emacs' unexec under the LGPL without
|        special permission.  I'm confused as to how this situation arose.
|        I find some unexec files in the May 10 1994 release of gcl-1.0.
|        Did Dr. Schelter ever discuss this with you or any other emacs
|        developers?
|
| Alas, there is no chance I would remember after ten years, sorry.


I think this is getting very interesting.

Richard FATEMAN wrote in another email stream:

"I think that the Macsyma company used Austin-Kyoto-Common-Lisp
(which I believe is related to GCL) for its unix-sun/hp/.... version.
I do not know if they are still in a position to distribute
it, but I understand that there are still sales being made of
Macsyma for Windows by Kalman Reti.  Kalman may have more
information."


I've looked a little further into the AKCL side of this.

Bill Schelter apparently produced the three AKCL tarballs (not the only
ones) listed below from 1992 to 1995 with the only actual legal claim made
by himself that I have seen being listed in the README files, which are
essentially identical across the three tarballs, the latest of which being
listed in full at the bottom of this email for everyone's convenience.  The
relevant extract is just a disclaimer (I may have missed the licencing terms
but maybe not).

"W. Schelter, the University of Texas, and other parties provide this
program on an "as is" basis without warranty of any kind, either
expressed or implied, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose."

All three of these packages contained GPL code (unex's and gnumalloc) and
also code for HP which mentions emacs but does not have a clear specific
licence statement at the top of the file (See Richard F's mention of HP
above).

AKCL tarballs dated 1992 and 1995 from:

 http://ftp.uni-koeln.de/programming/lisp/

akcl-1-609.tar.z        18-Mar-1992 09:45   558k
akcl-1-615.tar.z        13-Aug-1992 10:14   557k

and from:


http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/kcl/a
kcl/v619b/

akcl.tgz                09-Jun-1995 20:49   590k


The grep hits for "Free Software Foundation" and "emacs" are listed further
down in this now rather voluminous email.

I will leave it to someone else to sort out the legal implications of these
items, and to find out:

1. The details of earlier releases of AKCL.  I am fairly certain I used AKCL
on a SUN platform as early as 1990 - two years before the (file modification
or copying?) date on the earliest of the three tarballs mentioned above.

2. The date and version of AKCL used by the Macsyma commercial entities to
make commercial releases and also which items of the source tree found their
way into those commercial releases and what effect those items might have on
the legality of the non-disclosure of the commercially written Macsyma
source code retained by those entities and their present day assignees.

3. Why Bill Schelter chose LGPL rather than GPL at the time of the change
over to GCL.
Clearly, at some stage after the last of the three tarballs I have listed he
must have come to grips with the implications of the GPL code present in
AKCL and taken appropriate action by associating it with the FSF and LGPL.
Surely someone from the FSF must have played a part in that process and must
actually be able to remember something about what happened?

I remain your's truly,

Mike Thomas.

(Aside to Tim Daly who separately mentioned (tongue-in-cheek I think) having
to study law to be a computer programmer - I was a geochemist who became a
patent examiner but now claim to be a software engineer when it comes to
money making.  What is a computer programmer anyway?  In the end we all run
the risk of being technological age ditch diggers with sparkly bits of paper
on our walls unless we take note of the fact that it is the lawyers who
attend parties in Mercedes cars rather than ourselves.)

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



FGREP "Free Software Foundation"

$ fgrep -r "Free Software Foundation" /c/akcl*
/c/akcl1-609/c/gnumalloc.c:   Copyright (C) 1985, 1987 Free Software
Foundation,
 Inc.
/c/akcl1-609/c/gnumalloc.c:(C) 1985 Free Software Foundation, Inc."; and
include
 following the
/c/akcl1-609/c/unexelf.c:/* Copyright (C) 1985, 1986, 1987, 1988 Free
Software F
oundation, Inc.
/c/akcl1-609/c/unexelf.c:    the Free Software Foundation; either version 1,
or
(at your option)
/c/akcl1-609/doc/dbl.el:;; Copyright (C) 1988 Free Software Foundation, Inc.
/c/akcl1-615/c/gnumalloc.c:   Copyright (C) 1985, 1987 Free Software
Foundation,
 Inc.
/c/akcl1-615/c/gnumalloc.c:(C) 1985 Free Software Foundation, Inc."; and
include
 following the
/c/akcl1-615/c/unexelf.c:/* Copyright (C) 1985, 1986, 1987, 1988 Free
Software F
oundation, Inc.
/c/akcl1-615/c/unexelf.c:    the Free Software Foundation; either version 1,
or
(at your option)
/c/akcl1-615/doc/dbl.el:;; Copyright (C) 1988 Free Software Foundation, Inc.
/c/akclv619b/c/gnumalloc.c:   Copyright (C) 1985, 1987 Free Software
Foundation,
 Inc.
/c/akclv619b/c/gnumalloc.c:(C) 1985 Free Software Foundation, Inc."; and
include
 following the
/c/akclv619b/c/unexelf.c:/* Copyright (C) 1985, 1986, 1987, 1988 Free
Software F
oundation, Inc.
/c/akclv619b/c/unexelf.c:    the Free Software Foundation; either version 1,
or
(at your option)
/c/akclv619b/c/unexlin.c:/* Copyright (C) 1985, 1986, 1987, 1988 Free
Software F
oundation, Inc.
/c/akclv619b/c/unexlin.c:    the Free Software Foundation; either version 1,
or
(at your option)
/c/akclv619b/doc/dbl.el:;; Copyright (C) 1988 Free Software Foundation, Inc.
/c/akclv619b/dos/signal.h:Copyright (C) 1989 Free Software Foundation




FGREP -r -i EMACS


/c/akcl1-609/c/ChangeLog:	source level debugging.   The emacs file dbl.el
was added.
/c/akcl1-609/c/ChangeLog:	* Add alternate malloc.c file from gnu emacs, if
you
/c/akcl1-609/c/gnumalloc.c: *	U of M Modified: 20 Jun 1983 ACT: strange
hacks for Emacs
/c/akcl1-609/c/gnumalloc.c: * No longer Emacs-specific; can serve as
all-purpose malloc for GNU.
/c/akcl1-609/c/gnumalloc.c: * You should call malloc_init to reinitialize
after loading dumped Emacs.
/c/akcl1-609/c/gnumalloc.c:#ifdef emacs
/c/akcl1-609/c/gnumalloc.c:#endif /* emacs */
/c/akcl1-609/c/gnumalloc.c:#ifndef emacs
/c/akcl1-609/c/gnumalloc.c: * there. Once Emacs has dumped there is no
reason to continue
/c/akcl1-609/c/gnumalloc.c: * by running emacs linked (and a large
allocation) with the debugger and
/c/akcl1-609/c/unexelf.c: * In the temacs dump below, notice that the Global
Offset Table
/c/akcl1-609/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -h temacs
/c/akcl1-609/c/unexelf.c:temacs:
/c/akcl1-609/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -h xemacs
/c/akcl1-609/c/unexelf.c:xemacs:
/c/akcl1-609/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -f temacs
/c/akcl1-609/c/unexelf.c:temacs:
/c/akcl1-609/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -f xemacs
/c/akcl1-609/c/unexelf.c:xemacs:
/c/akcl1-609/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -o temacs
/c/akcl1-609/c/unexelf.c:temacs:
/c/akcl1-609/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -o xemacs
/c/akcl1-609/c/unexelf.c:xemacs:
/c/akcl1-609/c/unexelf.c:#ifndef emacs
/c/akcl1-609/c/unexelf.c:#define emacs
/c/akcl1-609/c/unexelf.c:#if defined(emacs) || !defined(DEBUG)
/c/akcl1-609/c/unexhp9k800.c:   plan to think about it, or about whether
other Emacs maintenance
/c/akcl1-609/c/unexhp9k800.c:     int dummy1, dummy2;	/* not used by emacs
*/
/c/akcl1-609/c/Vmalloc.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/c/Vmalloc.c: * additions for emacs.
/c/akcl1-609/doc/akcl.el:;; You should copy find-doc.el, akcl.el,
lisp-complete.el to the emacs/lisp directory.
/c/akcl1-609/doc/dbl.el:;; Run akcl under Emacs
/c/akcl1-609/doc/dbl.el:;; This file is part of GNU Emacs.
/c/akcl1-609/doc/dbl.el:;; GNU Emacs is distributed in the hope that it will
be useful, but
/c/akcl1-609/doc/dbl.el:;; Refer to the GNU Emacs General Public License for
full details.
/c/akcl1-609/doc/dbl.el:;; Emacs, but only under the conditions described in
the GNU Emacs
/c/akcl1-609/doc/dbl.el:;; been given to you along with GNU Emacs so you can
know your rights and
/c/akcl1-609/doc/dbl.el:;; This causes the emacs command dbl-next to be
defined, and runs
/c/akcl1-609/doc/DOC:In emacs load (load "dbl.el") from the akcl/doc
directory.
/c/akcl1-609/doc/DOC:EMACS COMMANDS:
/c/akcl1-609/doc/DOC:   When visiting a lisp buffer (if akcl.el is loaded in
your emacs) the command
/c/akcl1-609/doc/DOC:emacs command.
/c/akcl1-609/doc/docstrings:A facility for completion and on line help in
emacs, for common lisp
/c/akcl1-609/doc/docstrings:To use this facility you must have gnu emacs,
and you must copy the
/c/akcl1-609/doc/docstrings:lsp/*.el files into the emacs/lisp directory.
/c/akcl1-609/doc/docstrings:cp lsp/*.el /usr/local/src/emacs/lisp
/c/akcl1-609/doc/docstrings:(or onto a path in the emacs load-path)
/c/akcl1-609/doc/docstrings:window, just as emacs does.
/c/akcl1-609/doc/edoc:emacs -batch -l doc-com $@
/c/akcl1-609/doc/enhancements:It is trivial to sort the table by ticks in
gnu emacs using the command
/c/akcl1-609/doc/find-doc.el:;; in emacs.  I have tried to emulate the usage
pattern of the tags facility
/c/akcl1-609/doc/find-doc.el:;; For c files you may use the appropriate
primitive in emacs/etc
/c/akcl1-609/doc/makefile:# requires gnu emacs, to be in the search path
/c/akcl1-609/doc/makefile:EMACS=emacs
/c/akcl1-609/doc/makefile:install: current-emacs-path print_doc edoc
DOC-keys.el
/c/akcl1-609/doc/makefile:	${EMACS} -batch -l tmp.el~
/c/akcl1-609/doc/makefile:current-emacs-path: print_doc
/c/akcl1-609/doc/makefile:	echo '(generate-new-buffer "emacs-path")' \
/c/akcl1-609/doc/makefile:	'(write-file "emacs-path")' > tmp.el~
/c/akcl1-609/doc/makefile:	${EMACS} -batch -l tmp.el~
/c/akcl1-609/doc/makefile:	cp ${ELISP} `cat emacs-path`
/c/akcl1-609/doc/makefile:	cp print_doc   `cat emacs-path`/../etc
/c/akcl1-609/doc/makefile:	cp edoc   `cat emacs-path`/../etc
/c/akcl1-609/merge.c:the original file.  There is an emacs program merge.el
which can
/c/akcl1-609/README:   If you use gnu emacs, a convenient method for viewing
documentation
/c/akcl1-609/README:do make in the doc directory.  Adding the following to
your .emacs
/c/akcl1-609/README:for gnu emacs.   You will have to have write permission
in the
/c/akcl1-609/README:emacs directory, and LBINDIR for this, so you may need
to
/c/akcl1-609/README:% emacs h/sun3-os4.defs
/c/akcl1-609/README:% emacs h/sun3-os4.h
/c/akcl1-609/V/bin/dpp.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/alloc.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/array.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/assignment.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/backq.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/bds.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/big.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/bind.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/bitop.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/block.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/cfun.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/character.d:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/cmpaux.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/earith.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/error.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/eval.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/file.d:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/format.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/gbc.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/hash.d:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/iteration.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/list.d:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/macros.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/main.c:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/mapfun.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/number.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/num_arith.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/num_co.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/num_comp.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/num_log.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/num_pred.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/num_rand.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/package.d:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/pathname.d:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/predicate.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/print.d:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/read.d:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/c/sequence.d:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/string.d:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/structure.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/symbol.d:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/toplevel.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/typespec.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/unixfasl.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/unixfsys.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/unixint.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/unixsave.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/unixsys.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/c/unixtime.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpbind.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpcall.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpcatch.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpenv.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpeval.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpflet.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpfun.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpif.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpinit.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpinline.lsp:This file was constructed using emacs
and  merge.el
/c/akcl1-609/V/cmpnew/cmplabel.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmplam.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmplet.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmploc.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpmain.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpmulti.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpopt.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpspecial.lsp:This file was constructed using emacs
and  merge.el
/c/akcl1-609/V/cmpnew/cmptag.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmptop.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmptype.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmputil.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpvar.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpvs.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/cmpwt.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/cmpnew/lfun_list.lsp:This file was constructed using emacs
and  merge.el
/c/akcl1-609/V/cmpnew/makefile:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/h/att_ext.h:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/h/bds.h:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/h/cmpinclude.h:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/h/eval.h:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/h/external.h:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/h/frame.h:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/h/include.h:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/h/num_include.h:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/h/object.h:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/h/symbol.h:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/h/vs.h:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/lsp/arraylib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/autoload.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/cmpinit.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/defmacro.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/defstruct.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/describe.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/evalmacros.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/iolib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/makefile:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/numlib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/packlib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/predlib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/seqlib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/setf.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/top.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/lsp/trace.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/makefile:This file was constructed using emacs and  merge.el
/c/akcl1-609/V/o/makefile:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/unixport/init_kcl.lsp:This file was constructed using emacs
and  merge.el
/c/akcl1-609/V/unixport/makefile:This file was constructed using emacs and
merge.el
/c/akcl1-609/V/unixport/makefile:	emacs -batch -l aix-crt0.el
/c/akcl1-609/V/unixport/makefile:	emacs -batch -l ncrt0.el
/c/akcl1-609/V/unixport/makefile:	emacs -batch -l gcrt0.el
/c/akcl1-609/V/unixport/makefile:	emacs -batch -l hpbsd-crt0.el
/c/akcl1-609/V/unixport/sys_kcl.c:This file was constructed using emacs and
merge.el
/c/akcl1-609/xbin/compare-src:for v in `echo doc/* xbin/* | sed -e
"/~/d"` -e "/emacs-path/d" -e "/xbin\/kcl/d" ;
/c/akcl1-615/c/ChangeLog:	source level debugging.   The emacs file dbl.el
was added.
/c/akcl1-615/c/ChangeLog:	* Add alternate malloc.c file from gnu emacs, if
you
/c/akcl1-615/c/gnumalloc.c: *	U of M Modified: 20 Jun 1983 ACT: strange
hacks for Emacs
/c/akcl1-615/c/gnumalloc.c: * No longer Emacs-specific; can serve as
all-purpose malloc for GNU.
/c/akcl1-615/c/gnumalloc.c: * You should call malloc_init to reinitialize
after loading dumped Emacs.
/c/akcl1-615/c/gnumalloc.c:#ifdef emacs
/c/akcl1-615/c/gnumalloc.c:#endif /* emacs */
/c/akcl1-615/c/gnumalloc.c:#ifndef emacs
/c/akcl1-615/c/gnumalloc.c: * there. Once Emacs has dumped there is no
reason to continue
/c/akcl1-615/c/gnumalloc.c: * by running emacs linked (and a large
allocation) with the debugger and
/c/akcl1-615/c/unexelf.c: * In the temacs dump below, notice that the Global
Offset Table
/c/akcl1-615/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -h temacs
/c/akcl1-615/c/unexelf.c:temacs:
/c/akcl1-615/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -h xemacs
/c/akcl1-615/c/unexelf.c:xemacs:
/c/akcl1-615/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -f temacs
/c/akcl1-615/c/unexelf.c:temacs:
/c/akcl1-615/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -f xemacs
/c/akcl1-615/c/unexelf.c:xemacs:
/c/akcl1-615/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -o temacs
/c/akcl1-615/c/unexelf.c:temacs:
/c/akcl1-615/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -o xemacs
/c/akcl1-615/c/unexelf.c:xemacs:
/c/akcl1-615/c/unexelf.c:#ifndef emacs
/c/akcl1-615/c/unexelf.c:#define emacs
/c/akcl1-615/c/unexelf.c:#if defined(emacs) || !defined(DEBUG)
/c/akcl1-615/c/unexhp9k800.c:   plan to think about it, or about whether
other Emacs maintenance
/c/akcl1-615/c/unexhp9k800.c:     int dummy1, dummy2;	/* not used by emacs
*/
/c/akcl1-615/c/Vmalloc.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/c/Vmalloc.c: * additions for emacs.
/c/akcl1-615/doc/akcl.el:;; You should copy find-doc.el, akcl.el,
lisp-complete.el to the emacs/lisp directory.
/c/akcl1-615/doc/dbl.el:;; Run akcl under Emacs
/c/akcl1-615/doc/dbl.el:;; This file is part of GNU Emacs.
/c/akcl1-615/doc/dbl.el:;; GNU Emacs is distributed in the hope that it will
be useful, but
/c/akcl1-615/doc/dbl.el:;; Refer to the GNU Emacs General Public License for
full details.
/c/akcl1-615/doc/dbl.el:;; Emacs, but only under the conditions described in
the GNU Emacs
/c/akcl1-615/doc/dbl.el:;; been given to you along with GNU Emacs so you can
know your rights and
/c/akcl1-615/doc/dbl.el:;; This causes the emacs command dbl-next to be
defined, and runs
/c/akcl1-615/doc/DOC:In emacs load (load "dbl.el") from the akcl/doc
directory.
/c/akcl1-615/doc/DOC:EMACS COMMANDS:
/c/akcl1-615/doc/DOC:   When visiting a lisp buffer (if akcl.el is loaded in
your emacs) the command
/c/akcl1-615/doc/DOC:emacs command.
/c/akcl1-615/doc/docstrings:A facility for completion and on line help in
emacs, for common lisp
/c/akcl1-615/doc/docstrings:To use this facility you must have gnu emacs,
and you must copy the
/c/akcl1-615/doc/docstrings:lsp/*.el files into the emacs/lisp directory.
/c/akcl1-615/doc/docstrings:cp lsp/*.el /usr/local/src/emacs/lisp
/c/akcl1-615/doc/docstrings:(or onto a path in the emacs load-path)
/c/akcl1-615/doc/docstrings:window, just as emacs does.
/c/akcl1-615/doc/edoc:emacs -batch -l doc-com $@
/c/akcl1-615/doc/enhancements:It is trivial to sort the table by ticks in
gnu emacs using the command
/c/akcl1-615/doc/find-doc.el:;; in emacs.  I have tried to emulate the usage
pattern of the tags facility
/c/akcl1-615/doc/find-doc.el:;; For c files you may use the appropriate
primitive in emacs/etc
/c/akcl1-615/doc/makefile:# requires gnu emacs, to be in the search path
/c/akcl1-615/doc/makefile:EMACS=emacs
/c/akcl1-615/doc/makefile:install: current-emacs-path print_doc edoc
DOC-keys.el
/c/akcl1-615/doc/makefile:	${EMACS} -batch -l tmp.el~
/c/akcl1-615/doc/makefile:current-emacs-path: print_doc
/c/akcl1-615/doc/makefile:	echo '(generate-new-buffer "emacs-path")' \
/c/akcl1-615/doc/makefile:	'(write-file "emacs-path")' > tmp.el~
/c/akcl1-615/doc/makefile:	${EMACS} -batch -l tmp.el~
/c/akcl1-615/doc/makefile:	cp ${ELISP} `cat emacs-path`
/c/akcl1-615/doc/makefile:	cp print_doc   `cat emacs-path`/../etc
/c/akcl1-615/doc/makefile:	cp edoc   `cat emacs-path`/../etc
/c/akcl1-615/merge.c:the original file.  There is an emacs program merge.el
which can
/c/akcl1-615/README:   If you use gnu emacs, a convenient method for viewing
documentation
/c/akcl1-615/README:do make in the doc directory.  Adding the following to
your .emacs
/c/akcl1-615/README:for gnu emacs.   You will have to have write permission
in the
/c/akcl1-615/README:emacs directory, and LBINDIR for this, so you may need
to
/c/akcl1-615/README:% emacs h/sun3-os4.defs
/c/akcl1-615/README:% emacs h/sun3-os4.h
/c/akcl1-615/V/bin/dpp.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/alloc.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/array.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/assignment.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/backq.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/bds.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/big.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/bind.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/bitop.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/block.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/cfun.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/character.d:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/cmpaux.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/earith.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/error.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/eval.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/file.d:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/format.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/gbc.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/hash.d:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/iteration.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/list.d:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/macros.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/main.c:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/mapfun.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/number.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/num_arith.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/num_co.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/num_comp.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/num_log.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/num_pred.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/num_rand.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/num_sfun.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/package.d:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/pathname.d:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/predicate.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/print.d:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/read.d:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/c/sequence.d:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/string.d:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/structure.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/symbol.d:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/toplevel.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/typespec.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/unixfasl.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/unixfsys.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/unixint.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/unixsave.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/unixsys.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/c/unixtime.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpbind.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpcall.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpcatch.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpenv.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpeval.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpflet.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpfun.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpif.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpinit.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpinline.lsp:This file was constructed using emacs
and  merge.el
/c/akcl1-615/V/cmpnew/cmplabel.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmplam.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmplet.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmploc.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpmain.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpmulti.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpopt.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpspecial.lsp:This file was constructed using emacs
and  merge.el
/c/akcl1-615/V/cmpnew/cmptag.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmptop.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmptype.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmputil.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpvar.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpvs.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/cmpwt.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/cmpnew/lfun_list.lsp:This file was constructed using emacs
and  merge.el
/c/akcl1-615/V/cmpnew/makefile:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/h/att_ext.h:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/h/bds.h:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/h/cmpinclude.h:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/h/eval.h:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/h/external.h:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/h/frame.h:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/h/include.h:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/h/num_include.h:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/h/object.h:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/h/symbol.h:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/h/vs.h:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/lsp/arraylib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/autoload.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/cmpinit.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/defmacro.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/defstruct.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/describe.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/evalmacros.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/iolib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/makefile:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/numlib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/packlib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/predlib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/seq.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/seqlib.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/setf.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/top.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/lsp/trace.lsp:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/makefile:This file was constructed using emacs and  merge.el
/c/akcl1-615/V/o/makefile:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/unixport/init_kcl.lsp:This file was constructed using emacs
and  merge.el
/c/akcl1-615/V/unixport/makefile:This file was constructed using emacs and
merge.el
/c/akcl1-615/V/unixport/makefile:	emacs -batch -l aix-crt0.el
/c/akcl1-615/V/unixport/makefile:	emacs -batch -l ncrt0.el
/c/akcl1-615/V/unixport/makefile:	emacs -batch -l gcrt0.el
/c/akcl1-615/V/unixport/makefile:	emacs -batch -l hpbsd-crt0.el
/c/akcl1-615/V/unixport/sys_kcl.c:This file was constructed using emacs and
merge.el
/c/akcl1-615/xbin/compare-src:for v in `echo doc/* xbin/* | sed -e
"/~/d"` -e "/emacs-path/d" -e "/xbin\/kcl/d" ;
/c/akclv619b/c/ChangeLog:	source level debugging.   The emacs file dbl.el
was added.
/c/akclv619b/c/ChangeLog:	* Add alternate malloc.c file from gnu emacs, if
you
/c/akclv619b/c/gnumalloc.c: *	U of M Modified: 20 Jun 1983 ACT: strange
hacks for Emacs
/c/akclv619b/c/gnumalloc.c: * No longer Emacs-specific; can serve as
all-purpose malloc for GNU.
/c/akclv619b/c/gnumalloc.c: * You should call malloc_init to reinitialize
after loading dumped Emacs.
/c/akclv619b/c/gnumalloc.c:#ifdef emacs
/c/akclv619b/c/gnumalloc.c:#endif /* emacs */
/c/akclv619b/c/gnumalloc.c:#ifndef emacs
/c/akclv619b/c/gnumalloc.c: * there. Once Emacs has dumped there is no
reason to continue
/c/akclv619b/c/gnumalloc.c: * by running emacs linked (and a large
allocation) with the debugger and
/c/akclv619b/c/unexelf.c: * In the temacs dump below, notice that the Global
Offset Table
/c/akclv619b/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -h temacs
/c/akclv619b/c/unexelf.c:temacs:
/c/akclv619b/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -h xemacs
/c/akclv619b/c/unexelf.c:xemacs:
/c/akclv619b/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -f temacs
/c/akclv619b/c/unexelf.c:temacs:
/c/akclv619b/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -f xemacs
/c/akclv619b/c/unexelf.c:xemacs:
/c/akclv619b/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -o temacs
/c/akclv619b/c/unexelf.c:temacs:
/c/akclv619b/c/unexelf.c:raid:/nfs/raid/src/dist-18.56/src> dump -o xemacs
/c/akclv619b/c/unexelf.c:xemacs:
/c/akclv619b/c/unexelf.c:#ifndef emacs
/c/akclv619b/c/unexelf.c:#define emacs
/c/akclv619b/c/unexelf.c:#if defined(emacs) || !defined(DEBUG)
/c/akclv619b/c/unexhp9k800.c:   plan to think about it, or about whether
other Emacs maintenance
/c/akclv619b/c/unexhp9k800.c:     int dummy1, dummy2;	/* not used by emacs
*/
/c/akclv619b/c/unexlin.c:Define this if you do not want to try to save
Emacs's pure data areas
/c/akclv619b/c/unexlin.c:you must write a startup routine for your machine
in Emacs's crt0.c.
/c/akclv619b/c/unexlin.c:If NO_REMAP is defined, Emacs uses the system's
crt0.o.
/c/akclv619b/c/unexlin.c:#ifndef emacs
/c/akclv619b/c/unexlin.c:#ifdef emacs
/c/akclv619b/c/unexlin.c:#endif /* emacs */
/c/akclv619b/c/unexlin.c:#ifdef emacs
/c/akclv619b/c/unexlin.c:	PERROR ("temacs");
/c/akclv619b/c/unexlin.c:		PERROR ("xemacs");
/c/akclv619b/c/Vmalloc.c:This file was constructed using emacs and  merge.el
/c/akclv619b/c/Vmalloc.c: * additions for emacs.
/c/akclv619b/doc/akcl.el:;; You should copy find-doc.el, akcl.el,
lisp-complete.el to the emacs/lisp directory.
/c/akclv619b/doc/dbl.el:;; Run akcl under Emacs
/c/akclv619b/doc/dbl.el:;; This file is part of GNU Emacs.
/c/akclv619b/doc/dbl.el:;; GNU Emacs is distributed in the hope that it will
be useful, but
/c/akclv619b/doc/dbl.el:;; Refer to the GNU Emacs General Public License for
full details.
/c/akclv619b/doc/dbl.el:;; Emacs, but only under the conditions described in
the GNU Emacs
/c/akclv619b/doc/dbl.el:;; been given to you along with GNU Emacs so you can
know your rights and
/c/akclv619b/doc/dbl.el:;; This causes the emacs command dbl-next to be
defined, and runs
/c/akclv619b/doc/DOC:In emacs load (load "dbl.el") from the akcl/doc
directory.
/c/akclv619b/doc/DOC:EMACS COMMANDS:
/c/akclv619b/doc/DOC:   When visiting a lisp buffer (if akcl.el is loaded in
your emacs) the command
/c/akclv619b/doc/DOC:emacs command.
/c/akclv619b/doc/docstrings:A facility for completion and on line help in
emacs, for common lisp
/c/akclv619b/doc/docstrings:To use this facility you must have gnu emacs,
and you must copy the
/c/akclv619b/doc/docstrings:lsp/*.el files into the emacs/lisp directory.
/c/akclv619b/doc/docstrings:cp lsp/*.el /usr/local/src/emacs/lisp
/c/akclv619b/doc/docstrings:(or onto a path in the emacs load-path)
/c/akclv619b/doc/docstrings:window, just as emacs does.
/c/akclv619b/doc/edoc:emacs -batch -l doc-com $@
/c/akclv619b/doc/enhancements:It is trivial to sort the table by ticks in
gnu emacs using the command
/c/akclv619b/doc/find-doc.el:;; in emacs.  I have tried to emulate the usage
pattern of the tags facility
/c/akclv619b/doc/find-doc.el:;; For c files you may use the appropriate
primitive in emacs/etc
/c/akclv619b/doc/makefile:# requires gnu emacs, to be in the search path
/c/akclv619b/doc/makefile:EMACS=emacs
/c/akclv619b/doc/makefile:install: current-emacs-path print_doc edoc
DOC-keys.el
/c/akclv619b/doc/makefile:	${EMACS} -batch -l tmp.el~
/c/akclv619b/doc/makefile:current-emacs-path: print_doc
/c/akclv619b/doc/makefile:	echo '(generate-new-buffer "emacs-path")' \
/c/akclv619b/doc/makefile:	'(write-file "emacs-path")' > tmp.el~
/c/akclv619b/doc/makefile:	${EMACS} -batch -l tmp.el~
/c/akclv619b/doc/makefile:	cp ${ELISP} `cat emacs-path`
/c/akclv619b/doc/makefile:	cp print_doc   `cat emacs-path`/../etc
/c/akclv619b/doc/makefile:	cp edoc   `cat emacs-path`/../etc
/c/akclv619b/merge.c:the original file.  There is an emacs program merge.el
which can
/c/akclv619b/README:   If you use gnu emacs, a convenient method for viewing
documentation
/c/akclv619b/README:do make in the doc directory.  Adding the following to
your .emacs
/c/akclv619b/README:for gnu emacs.   You will have to have write permission
in the
/c/akclv619b/README:emacs directory, and LBINDIR for this, so you may need
to
/c/akclv619b/README:% emacs h/sun3-os4.defs
/c/akclv619b/README:% emacs h/sun3-os4.h
/c/akclv619b/V/bin/dpp.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/bin/makefile:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/alloc.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/array.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/assignment.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/backq.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/bds.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/big.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/bind.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/bitop.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/block.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/cfun.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/character.d:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/cmpaux.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/earith.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/error.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/eval.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/file.d:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/format.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/gbc.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/hash.d:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/iteration.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/list.d:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/macros.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/main.c:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/mapfun.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/number.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/num_arith.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/num_co.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/num_comp.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/num_log.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/num_pred.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/num_rand.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/num_sfun.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/package.d:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/pathname.d:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/predicate.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/print.d:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/read.d:This file was constructed using emacs and  merge.el
/c/akclv619b/V/c/sequence.d:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/string.d:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/structure.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/symbol.d:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/toplevel.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/typespec.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/unixfasl.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/unixfsys.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/unixint.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/unixsave.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/unixsys.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/c/unixtime.c:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpbind.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpcall.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpcatch.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpenv.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpeval.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpflet.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpfun.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpif.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpinit.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpinline.lsp:This file was constructed using emacs
and  merge.el
/c/akclv619b/V/cmpnew/cmplabel.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmplam.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmplet.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmploc.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpmain.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpmulti.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpopt.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpspecial.lsp:This file was constructed using emacs
and  merge.el
/c/akclv619b/V/cmpnew/cmptag.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmptop.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmptype.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmputil.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpvar.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpvs.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/cmpwt.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/cmpnew/lfun_list.lsp:This file was constructed using emacs
and  merge.el
/c/akclv619b/V/cmpnew/makefile:This file was constructed using emacs and
merge.el
/c/akclv619b/V/h/att_ext.h:This file was constructed using emacs and
merge.el
/c/akclv619b/V/h/bds.h:This file was constructed using emacs and  merge.el
/c/akclv619b/V/h/cmpinclude.h:This file was constructed using emacs and
merge.el
/c/akclv619b/V/h/eval.h:This file was constructed using emacs and  merge.el
/c/akclv619b/V/h/external.h:This file was constructed using emacs and
merge.el
/c/akclv619b/V/h/frame.h:This file was constructed using emacs and  merge.el
/c/akclv619b/V/h/include.h:This file was constructed using emacs and
merge.el
/c/akclv619b/V/h/num_include.h:This file was constructed using emacs and
merge.el
/c/akclv619b/V/h/object.h:This file was constructed using emacs and
merge.el
/c/akclv619b/V/h/symbol.h:This file was constructed using emacs and
merge.el
/c/akclv619b/V/h/vs.h:This file was constructed using emacs and  merge.el
/c/akclv619b/V/lsp/arraylib.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/autoload.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/cmpinit.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/defmacro.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/defstruct.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/describe.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/evalmacros.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/iolib.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/listlib.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/makefile:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/numlib.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/packlib.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/predlib.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/seq.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/seqlib.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/setf.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/top.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/lsp/trace.lsp:This file was constructed using emacs and
merge.el
/c/akclv619b/V/makefile:This file was constructed using emacs and  merge.el
/c/akclv619b/V/o/makefile:This file was constructed using emacs and
merge.el
/c/akclv619b/V/unixport/init_kcl.lsp:This file was constructed using emacs
and  merge.el
/c/akclv619b/V/unixport/makefile:This file was constructed using emacs and
merge.el
/c/akclv619b/V/unixport/makefile:	emacs -batch -l aix-crt0.el
/c/akclv619b/V/unixport/makefile:	emacs -batch -l ncrt0.el
/c/akclv619b/V/unixport/makefile:	emacs -batch -l gcrt0.el
/c/akclv619b/V/unixport/makefile:	emacs -batch -l hpbsd-crt0.el
/c/akclv619b/V/unixport/sys_kcl.c:This file was constructed using emacs and
merge.el
/c/akclv619b/xbin/compare-src:for v in `echo doc/* xbin/* | sed -e
"/~/d"` -e "/emacs-path/d" -e "/xbin\/kcl/d" ;

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

AKCL README

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

Description of AKCL system.

OVERVIEW:

The AKCL system contains original files and change files (usually V/*
files).  The change files are then combined with files in the original
KCL distribution.  The latter is the June 1987 version.  The utility
merge, takes files from the original distribution and modifies them
according to a prescription in a `change file'.  The change files
reside in the directory V.  The enhancements include enhancements to
the lisp compiler, loader, garbage collector and to the basic C code.
If installed properly NOTHING in the original kcl directory should be
overwritten.  Files which have not changed will have only a link copy
in the akcl directory, and files which do change will have a changed
copy in the akcl directory, and an unchanged file in the kcl
directory.  To ensure that you do not accidentally alter a file in the
original directory you might wish to make the files there unwritable.
You do not need to do a make in the kcl directory.


OBTAINING SOURCES:
-----------------
* There are source files on rascal.ics.utexas.edu:pub/akcl-XX.tar.Z
You probably want the highest XX version number.  For example
akcl-1-605.tar.Z would allow you to build the version 1-605 of AKCL.  In
the following this compressed tar file is simply referred to as
akcl.tar.Z.   You will also need to obtain the original kcl distribution
of June 1987.  That is referred to as kcl.tar.Z and is also available
on rascal.   An alternate source for these files is
cli.com:akcl/akcl-XX.tar.Z
In general the bandwidth to rascal is higher than to cli.com.
Rascal's address is rascal.ics.utexas.edu (128.83.138.20).

* If you cannot obtain these files via internet, a cartridge tape (sun
compatible) or diskettes containing akcl, and kcl sources may be
obtained for $250 US plus shipping, from J. Schelter, 1715
Barnswallow, Autin TX 78746.  This would be in standard tar format.
Some machines on which akcl compiles are 386 under System V (eg
Microport), Sun's (sparc,sun3's), HP under hpux and 4.3, Dec mips ultrix,
Sgi mips irix.

MAKING THE SYSTEM:
==================
To make the whole system, if you have obtained akcl.tar.Z and
kcl.tar.Z

UNCOMPRESS and UNTAR the SOURCES:
--------------------------------

Change to a directory in which you wish to put the kcl and akcl
subdirectories.  Make sure the two files kcl.tar.Z and akcl.tar.Z are
in your current directory.    When you extract the files make sure the write
file write dates are as in the distribution--make needs this.

% mkdir kcl
% (cd kcl ; uncompress -c ../kcl.tar.Z | tar  xvf -)
% mkdir akcl
% cd akcl
% uncompress -c ../akcl.tar.Z | tar  xvf -


ADD MACHINE DEFINITIONS TO MAKEFILES:
------------------------------------

Determine the NAME of your machine by looking in the MACHINES file (eg
sun3-os4).  Also remember where you untarred kcl.tar.Z (eg
/public/kcl)

	% add-defs sun3-os4 /public/kcl

	(in general % add-defs NAME DIRECTORY-WHERE-KCL-IS)

	You should finally be ready to go!

RUNNING MAKE:
------------

	% make -f Smakefile

NOTE: Smakefile is a special makefile which causes make to be run
twice, the first time building a saved_kcl using some interpreted
code, and the second time compiling itself.  If this does not run
twice you will be using a good deal of interpreted code as well as a
combination of old and new compiler, which while sufficient to compile
the new compiler, would not be good for general use.  If you later
change files it will be sufficient to just use the regular makefile
(which has by now been slightly altered).

The make should continue without error.   There may be occasional
warnings from the C compiler, but all files should compile successfully
producing .o files.

The V/* change files will only be used if they are newer (normally the
case) than the existing files.  If you have modified files in the akcl
directory, eg. c/array.c, but wish merge to overwrite that with its
merged version, you could for example % touch V/c/array.c.  Building
akcl successfuly through the second pass, will mail a version info
message to akcl so we know which cpu, c compiler and os levels are
working properly, as well as printing out a message "Make of AKCL xxx
completed", where xxx stands for the version number.

When it has finally finished you may invoke AKCL by using

TRY IT OUT:
----------

% xbin/kcl
AKCL (Austin Kyoto Common Lisp)  Version(1.65) Wed Sep 21 00:52:31 CDT 1988
Contains Enhancements by W. Schelter
>(+ 2 3)

>5


COPY THE COMMAND SCRIPT:
-----------------------

	* You should copy xbin/kcl to /usr/local/bin or some place on users
	search paths.   This is so that users may conveniently invoke the saved
	image with a first arg equal to the directory where the image resides.
	(some things like faslink, autoload,.. need to know the system directory).


ELIMINATE SOME FILES?
--------------------

What to keep if you have no space!  The only files which are ESSENTIAL
to running of AKCL COMMON LISP once you have built the system (if you are
using sfasl, as is default on a sun eg).

    unixport/saved_kcl
    /usr/local/bin/akcl                (copy of xbin/akcl)

    Also if you are able to use sfasl, you may even `strip saved_kcl`.
Of course keeping sources, documentation, etc. is desirable:
    doc/DOC
    doc/DOC-keys.el
And there are a few unloaded files */*.lisp which are useful to keep.
For example lsp/make.lisp, cmpnew/collectfn.lsp


DOCUMENTATION:
==============
   If you use gnu emacs, a convenient method for viewing documentation
of common lisp functions (or functions in an extended system), is
provided by the doc/find-doc.el file.  This will be installed when you
do make in the doc directory.  Adding the following to your .emacs
file will allow you to use C-h d to find documentation.

(autoload 'find-doc "find-doc" nil t)
(global-set-key "d" 'find-doc)
(visit-doc-file "/public/akcl/doc/DOC")

See the file find-doc.el for more information.
Otherwise you may use the describe command inside lisp.
For example (describe 'print) will print out information about
print.   You may also peruse the file doc/DOC.


INSTALL:
=======
After the system has been built, in the main akcl directory

% make install

will copy the command to execute kcl to the LBINDIR,
and will also attempt to install the documentation interface
for gnu emacs.   You will have to have write permission in the
emacs directory, and LBINDIR for this, so you may need to
be super user.


TROUBLE SHOOTING (some common problems reported):
----------------

1) Did you extract the files with the original write dates--make
depends heavily on this?

2) Did you use -O on a compiler which puts out bad code?  Any time you
change the settings or use a new c compiler this is a tricky point.

3) A sample transcript from a correct make is included under
doc/sample-make.  If yours compiles less often or does things
differently, something is wrong, probably with dates or the clock on
the server or something.

4) If you can't save an image, try doing so on the file server rather
than a client.

5) Doing the make on a client with the main files on a server, has
sometimes caused random breakage.  The large temp files used by the C
compiler seem to sometimes get transferred incorrectly.  Solution: use
the server for the compile.

6) Did you make changes in the .defs or .h files, other than just
commenting out a CC=gcc line?


CHANGING THINGS: MAYBE EDIT TWO FILES:
--------------------

Normally you should not need to edit ANY files.  There may be some
parameter sizes you wish to change or if you don't have gcc where
we have made that the default, then see CC below.


EDIT the appropriate h/NAME.defs file.   These are definitions to
be included in the various makefiles.

For example if the `NAME' of your machine is sun3-os4.

% emacs h/sun3-os4.defs

   * CC: set C compiler options.  For example, if you are using the GNU
     C compiler:

     CC = gcc -msoft-float -DVOL=volatile -I$(AKCLDIR)/o

         Or, if you are using the conventional UNIX C compiler:

     CC = cc -DVOL= -I. -I$(AKCLDIR)/o

   * ODIR_DEBUG:

     ODIR_DEBUG= -g

     If you want files in the main c source compiled with debugging
     information.   Note this is incompatible with OFLAGS= -O on
     some compilers.   Size will be smaller without -g, but you
     are then helpless in the face of problems.

   * INITFORM: The normal thing is to just have the one form
     required for fast loading.

    INITFORM=(si::build-symbol-table)


-----------

EDIT the file h/NAME.h  (eg h/sun3-os4.h)

(Actually you probably don't need to change it)

This file will be included by virtually every compilation of C
files, except the translated C produced by kcl.

% emacs h/sun3-os4.h

      if you wish to change a parameter such as MAXPAGE 16384 established
      in bsd.h (ie. number of 2000 byte pages you want as your absolute max
      swap space).   MAXPAGE must be a power of 2.

      #undef MAXPAGE
      #define MAXPAGE (2 * 16384)

      You may similarly redefine VSSIZE the maximum size for the value
      stack (running very deep recursion interpreted may well require this).



DISCLAIMER:
----------

W. Schelter, the University of Texas, and other parties provide this
program on an "as is" basis without warranty of any kind, either
expressed or implied, including, but not limited to, the implied
warranties of merchantability and fitness for a particular purpose.


Bill Schelter
wfs@math.utexas.edu

See the file doc/contributors for a partial list of people who have
made helpful contributions to ports etc.

\start
Date: Wed, 23 Jul 2003 23:58:53 -0400
From: Tim Daly
To: Mike Thomas
Subject: GCL compliance and Bill Schelter
Cc: Camm Maguire, Richard Stallman, Sam Steingold, Stavros Macrakis

Mike,

The AKCL tarballs are a non-issue as I believe it can be shown that
Bill rewrote the KCL portion of the system. I know it was his intention
to do so quite early in the game and he had about 10 years to achieve it.
We could probably compare the KCL and GCL sources if necessary. Else we
could contact the KCL people who may no longer care if it is GPLed.
I know for a fact that the AKCL merge mechanism is no longer used.
This mechanism allowed Bill to patch the KCL sources to make AKCL.

The copyright for GCL would follow Bill's estate so his son, who I've
spoken to in the past, is the likely holder-of-record for the copyright.
However, an argument could be made for "abandonment" (since I believe
his son has taken no interest in GCL) making Camm the potential 
copyright holder-of-record.

It is entirely possible that the portions of Emacs that exist in GCL
were authored by Bill. I know that I sat at his elbow when he found a
problem with using gdb under a shell in an Emacs buffer. He stopped
what we were debugging, downloaded the Emacs sources, fixed the problem,
and uploaded a patch. So I know for a fact that he has authored code
in Emacs. I don't know where or how to verify who authored unexec.

Suppose I write a common lisp program like Axiom (licensed under 
modified BSD). Suppose I use a GPLed Common Lisp and save a binary
image of the loaded program. If saving the image requires my common lisp
program to ALSO be GPLed then it is not possible to develop programs
using a GPLed Common Lisp. Some consideration has to be made of the
fact that GPL grew up in a C world where compilers, not interpreters,
were the norm. Either that or GCL should be very careful about declaring
itself to be GPLed as the save-system mechanism (as well as other
mechanisms) become useless. I don't believe it is the intention of
GPL to require every Common Lisp programmer to GPL their code. The
language should be separate from the programs written in that language.

It should be sufficient to ensure that the GPLed (or LGPLed) Common
Lisp sources and Axiom sources are available to rebuild the system. If
saving the image requires Axiom to also be GPLed then I cannot work. I
do not have the copyright and could not GPL Axiom even if it were
required.

\start
Date: Thu, 24 Jul 2003 03:08:10 -0400
From: William Sit
To: list
Subject: Re: set output script yes

Tim Daly wrote on 
Sat, 21 Jun 2003 06:59:57 -0400
> I have no idea what ")set output scripts yes" should do.

I think this refers to outputing in the IBM Script Markup Language
(predecessor to GML, SGML, HTML), which is similar in concept to tex. It
must be kind of obsolete by now, but up to until the early 1990, it was
still used to typeset mathematical papers. The Axiom book might have
been written using Script (AKA GML or BookMaster). If true, to make the
book available to the general scientific public will require translating
from script to tex (such a program might exist already but a simple
search does not provide one and indeed the sentiment from replies to
such conversion questions is it is difficult to do automatically in
general).

I would think fixing any missing output routines for script is NOT
worthwhile. In fact, that option and related code should be removed.
There are more desirable output formats than script (such as XML,
MathML). But either one is a big project.

\start
Date: Thu, 24 Jul 2003 10:08:18 +0100
From: Mike Dewar
To: David Mentre
Subject: Re: set function breakage
Cc: Bill Page

Hi Guys,

I wonder if the clue here is the message:

>    >> System error:
>    Value stack overflow.
> 
> protected-symbol-warn called with (NIL)

This is a CCL feature which I added for the following reason.  As some
of you know, CCL uses a byte-code interpreter for normal lisp code,
which is compact and portable but slower than compiled code in some (but
not all) cases.  Arthur Norman provided us with some simple but powerful
profiling tools and a mechanism for identifying perfomance-critical
functions, converting them to C and compiling them into the Lisp kernel.
As a result of this we were able to make the CCL version of Axiom not
only smaller and much more robust than the AKCL version, but at least as
fast if not faster.  However the drawback with this approach was that if
you wanted to take some existing algebra code and tinker with it (the
normal approach to Axiom development :-) ) then you might find that you
couldn't re-define a function beacuse it was compiled into the CCL
kernel.

To get round this I added some facilities to both Axiom and CCL to warn
users when they tried to re-define a kernel function and to allow them
to do so.  At the top level in Axiom you can go:
)set kernel
to see these options.  The defaults are chosen to prevent spurios
warings/re-definitions when algebra code is loaded from the default
library files (axiom.lib et al).

I believe that all the changes I made were to CCL and that the the
kernel options in Axiom simply toggle a couple of flags (in the usual
places setvars.boot and setvart.boot), but I might be wrong.  Sorry if
this is a red herring but it might help somebody track down the bug ...

Regards, Mike.

On Wed, Jul 23, 2003 at 10:17:33PM +0200, David MENTRE wrote:
> Tim Daly writes:
> 
> > If you copy the algebra subdirectory from the download version it
> > should work.
> 
> Err no.
> 
> I've tried to compiled the CVS xpoly.spad with your prebuild Axiom and
> it fails, in the same way as with GCL.
> 
> What I have done:
> 
> * In ~/pub/axiom-libre/axiom-cvs-2003-06-25-dm-i386/new/new/src/algebra:
> 
>  - notangle xpoly.spad.pamphlet > /tmp/xpoly.spad
> 
> * In the directory where I have untared axiom.linux.20030614.tgz:
> 
>  - export AXIOM=/home/david/00-poubelle/axiom/mnt/linux/
> 
>  - PATH=$AXIOM/bin:$PATH
> 
>  - axiom
> 
> * Under pre-build Axiom:
> 
> (1) -> )cd /tmp
>    The current AXIOM default directory is /tmp/ 
> (1) -> )co xpoly )con XPR
> [...]
>    compiling local outTerm : (R,E) -> OutputForm
> Time: 0.03 SEC.
> 
>    compiling exported coerce : $ -> OutputForm
> Time: 0.22 SEC.
> 
>  
>    >> System error:
>    Value stack overflow.
> 
> protected-symbol-warn called with (NIL)
> 
> 
> So the bug would be in the algebra???

\start
Date: Thu, 24 Jul 2003 10:17:55 +0100
From: Mike Dewar
To: William Sit
Subject: Re: set output script yes

Hi William,

The Axiom book was written in LaTeX, and translated to htex for use in
the Axiom browser.  Tim has (or should have) the complete sources in the
CVS tree.

Mike.

On Thu, Jul 24, 2003 at 03:08:10AM -0400, William Sit wrote:
> Tim Daly wrote on 
> Sat, 21 Jun 2003 06:59:57 -0400
> > I have no idea what ")set output scripts yes" should do.
> 
> I think this refers to outputing in the IBM Script Markup Language
> (predecessor to GML, SGML, HTML), which is similar in concept to tex. It
> must be kind of obsolete by now, but up to until the early 1990, it was
> still used to typeset mathematical papers. The Axiom book might have
> been written using Script (AKA GML or BookMaster). If true, to make the
> book available to the general scientific public will require translating
> from script to tex (such a program might exist already but a simple
> search does not provide one and indeed the sentiment from replies to
> such conversion questions is it is difficult to do automatically in
> general).
> 
> I would think fixing any missing output routines for script is NOT
> worthwhile. In fact, that option and related code should be removed.
> There are more desirable output formats than script (such as XML,
> MathML). But either one is a big project.
> 
> William

\start
Date: Thu, 24 Jul 2003 15:08:05 +1000
From: Mike Thomas
To: list
Subject: RE: GCL compliance and Bill Schelter
Cc: Camm Maguire <Camm Maguire>, Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

Hi Tim.

| The AKCL tarballs are a non-issue as I believe it can be shown that
| Bill rewrote the KCL portion of the system. I know it was his intention
| to do so quite early in the game and he had about 10 years to achieve it.

Just to clarify my point, I'm not talking about the implications of the
Kyoto Common Lisp (KCL) licence for the later usage of AKCL.

Rather, I am talking about the implications of those items of source code in
the purely AKCL, Bill Schelter enhanced/added parts of those tarballs.  That
code includes unexec and gnumalloc, neither of which appear to have been
substantially written by Bill and both of which are GPL with the exception
of the HP code which stands in an ambiguous position due to a lack of a
licence statement in the particular tarballs under consideration, but which
seems to have been intended for use in Emacs.  In fact I think that the HP
code is NOT GPL, but I would not like to bet on it and so that possibility
is worth consideration.

This is not, by the way, intended to minimise the relevance of KCL to AKCL
licencing from a legal point of view - in that part of my last email I was
just considering the potential implications of the GPL code in AKCL for the
commercial branch of Macsyma.

Incidentally, the V directory in each of those tarballs mentioned in my
earlier email contains the patches needed to produce AKCL from the original
KCL sources as mentioned by yourself earlier.

| We could probably compare the KCL and GCL sources if necessary. Else we
| could contact the KCL people who may no longer care if it is GPLed.
| I know for a fact that the AKCL merge mechanism is no longer used.
| This mechanism allowed Bill to patch the KCL sources to make AKCL.

Agreed.

| The copyright for GCL would follow Bill's estate so his son, who I've
| spoken to in the past, is the likely holder-of-record for the copyright.
| However, an argument could be made for "abandonment" (since I believe
| his son has taken no interest in GCL) making Camm the potential
| copyright holder-of-record.
|
| It is entirely possible that the portions of Emacs that exist in GCL
| were authored by Bill. I know that I sat at his elbow when he found a
| problem with using gdb under a shell in an Emacs buffer. He stopped
| what we were debugging, downloaded the Emacs sources, fixed the problem,
| and uploaded a patch. So I know for a fact that he has authored code
| in Emacs. I don't know where or how to verify who authored unexec.

Spencer W. Thomas, Bob Desinger (at least) for the various unexec files in
the early AKCL tarball, and at least three authors without surnames or just
represented by initials for GNU malloc.  Also M. Frigo for the Linux unexec
in the later tarball.

| Suppose I write a common lisp program like Axiom (licensed under
| modified BSD). Suppose I use a GPLed Common Lisp and save a binary
| image of the loaded program. If saving the image requires my common lisp
| program to ALSO be GPLed then it is not possible to develop programs
| using a GPLed Common Lisp. Some consideration has to be made of the
| fact that GPL grew up in a C world where compilers, not interpreters,
| were the norm. Either that or GCL should be very careful about declaring
| itself to be GPLed as the save-system mechanism (as well as other
| mechanisms) become useless. I don't believe it is the intention of
| GPL to require every Common Lisp programmer to GPL their code. The
| language should be separate from the programs written in that language.

I agree in relation to the language per se (the purely linguistic elements),
but I think that the library implementations are another matter (regrettably
in the case of languages such as Lisp which of course have substantial
runtimes and are traditionally saved out to form new images).

Equally unfortunate in this case is that one Common Lisp does not equal
another when it comes to portability so it is easy to get stuck with one
implementation of the language.

| It should be sufficient to ensure that the GPLed (or LGPLed) Common
| Lisp sources and Axiom sources are available to rebuild the system. If
| saving the image requires Axiom to also be GPLed then I cannot work.

Yes, it's a nasty bind and particularly galling considering the amount of
work that has recently gone into making Axiom work with GCL.

| I
| do not have the copyright and could not GPL Axiom even if it were
| required.

To clarify, I underatand that (IBM or NAG?) released the code with licencing
conditions on it which cannot be changed.

>From a practical point of view, I would hate to look a gift horse (free BSD
Axiom)in the mouth when the gift came from such an appalling example (IBM,
at the very least from the Thomas J Watson years apparently) of the
subjugation of moral responsibility to commercial and 20th century right
wing political imperatives.

\start
Date: Thu, 24 Jul 2003 07:42:41 -0400
From: Tim Daly
To: Mike Thomas
Subject: GCL compliance and Bill Schelter
Cc: Camm Maguire <Camm Maguire>, Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

re: unexec and gnumalloc


> Rather, I am talking about the implications of those items of source code in
> the purely AKCL, Bill Schelter enhanced/added parts of those tarballs.  That
....

I have no way to determine the authorship of that code. It was not
common practice years ago  to write your initials on every piece of 
code you changed. Indeed, it was considered egotistical. We used
RSCS with some local cover functions which still exist in the Axiom
codebase (mget.c, mput.c) but the RSCS archives are long gone. Among 
the things Bill and I worked on was the free storage algorithms but 
I don't remember which memory allocator we used.

re: Emacs code

> Spencer W. Thomas, Bob Desinger (at least) for the various unexec files in
> the early AKCL tarball, and at least three authors without surnames or just
> represented by initials for GNU malloc.  Also M. Frigo for the Linux unexec
> in the later tarball.

Again I should stress that names don't always show up in code that
gets changed. I know I've sent patches to Camm for GCL but it is
unlikely that my name is mentioned anywhere nor should it be.

re: GCL and GPL

> | It should be sufficient to ensure that the GPLed (or LGPLed) Common
> | Lisp sources and Axiom sources are available to rebuild the system. If
> | saving the image requires Axiom to also be GPLed then I cannot work.
> 
> Yes, it's a nasty bind and particularly galling considering the amount of
> work that has recently gone into making Axiom work with GCL.

Clearly there is a compromise position which is reasonable. The
position is that language facilities (such as saving system
images) do not require programs written in that language to be
GPLed. The compromise exists between C and GCC despite the fact
that large portions of C code is automatically linked in as a
library and, worse yet, the GPLed compiler code sequences are
generated inline with running code that is not GPL. A runnable
C binary contains very little that is actually new code.

Every language creates a "platform" just as every operating system
creates a "platform". In C the platform includes both library code
and compiler code sequences. That doesn't have anything to do with
the work and intentions of the C programmer.

The work and intentions of the Common Lisp developer are similar
in spirit. Saving a system is equivalent to linking code. The
GCL code could be GPLed as long as it is clear that save-system
images are LGPLed or certainly licensed in such a way as to allow
Common Lisp programmers to work.

If the FSF insists that I can no longer use GCL to develop Axiom
I'd have to argue the case. I'm an (albeit minor) author of AKCL
and GCL is a derivative work. I'd have to claim "copy rights" in
the GCL work and refuse to allow it to be GPLed unless some 
compromise is reached.

I believe that GPL is a good idea but AKCL was written to support
Scratchpad (now Axiom) and I helped with its development. It is
unreasonable beyond belief that I would be prevented from using 
my own work to develop code. Bill shared my office, my computer,
and my coffee while we worked on that code. He'd turn in his grave
if he knew that the GPL was being used to steal my code and my rights.

re: Axiom's copyright

Yes, Axiom was released by NAG under license conditions which I cannot
change. However, if I did hold the ability to change the license it is
unlikely that I would change it anyway. I ran the license (modified BSD)
text thru Stallman and got his blessing on it being a free software
license.

> To clarify, I underatand that (IBM or NAG?) released the code with licencing
> conditions on it which cannot be changed.

> >From a practical point of view, I would hate to look a gift horse (free BSD
> Axiom)in the mouth when the gift came from such an appalling example (IBM,
> at the very least from the Thomas J Watson years apparently) of the
> subjugation of moral responsibility to commercial and 20th century right
> wing political imperatives.

I have to react to this screed with anger. You grossly paint IBM and,
by proximity, NAG with some sort of political mud. Corporations are made
up of people, of which I was one, and I am incensed that you would sling
such unfounded assertions at people I hold in the highest regard and
deepest respect. The people at NAG and IBM Research are among the best
I've ever worked with. If you want to argue politics please find another
forum.

\start
Date: Thu, 24 Jul 2003 13:45:19 +0100
From: Mike Dewar
To: Mike Thomas
Subject: Re: GCL compliance and Bill Schelter
Cc: Camm Maguire <Camm Maguire>, Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

On Thu, Jul 24, 2003 at 03:08:05PM +1000, Mike Thomas wrote:
<snip>
> To clarify, I underatand that (IBM or NAG?) released the code with licencing
> conditions on it which cannot be changed.
NAG released the code, with IBM's agreement, under the BSD license.  We
agreed on this license for a number of reasons which are frankly none of
your business.
 
> From a practical point of view, I would hate to look a gift horse (free BSD
> Axiom)in the mouth when the gift came from such an appalling example (IBM,
> at the very least from the Thomas J Watson years apparently) of the
> subjugation of moral responsibility to commercial and 20th century right
> wing political imperatives.
The "gift", as you call it, came from NAG, not IBM.  Perhaps you would
like to retract this statement or clarify in what way we are "an
appalling example of the subjugation of moral responsibility to
commercial and 20th century right wing political imperatives".

\start
Date: Thu, 24 Jul 2003 05:28:08 -0700 (PDT)
From: Cliff Yapp
To: Mike Thomas
Subject: Re: [Maxima] GCL compliance and Bill Schelter
Cc: Camm Maguire, Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

--- Tim Daly wrote:

> If the FSF insists that I can no longer use GCL to develop Axiom
> I'd have to argue the case. I'm an (albeit minor) author of AKCL
> and GCL is a derivative work. I'd have to claim "copy rights" in
> the GCL work and refuse to allow it to be GPLed unless some 
> compromise is reached.

Clearly, what we need here is a definite statement from the FSF on this
issue.  IMHO it would be folly to restrict GCL to only work with GPL
code.  I agree that issues such as the C compiler and how it works
would also crop up, and I don't thing that forest fire should be lit.  
 
> I believe that GPL is a good idea but AKCL was written to support
> Scratchpad (now Axiom) and I helped with its development. It is
> unreasonable beyond belief that I would be prevented from using 
> my own work to develop code. Bill shared my office, my computer,
> and my coffee while we worked on that code. He'd turn in his grave
> if he knew that the GPL was being used to steal my code and my
> rights.

There has been some uncertainty for quite a while on how the GPL and
Lisp interact.  If we (particularly the FSF) can finally resolve the
questions/issues here it would do the community a real service.  If the
GPL in this case is preventing other types of licenses, particularly
free software licensed programs, from being developed, run, or compiled
into usable form on the platform it provides, than something is wrong
and needs to be fixed.  Let's hash it out now so we can all get back to
coding.

\start
Date: Thu, 24 Jul 2003 09:00:31 -0400
From: Tim Daly
To: Cliff Yapp
Subject: GCL compliance and Bill Schelter
Cc: Richard Stallman, Camm Maguire, David Turner, Sam Steingold, Stavros Macrakis

> There has been some uncertainty for quite a while on how the GPL and
> Lisp interact.  If we (particularly the FSF) can finally resolve the
> questions/issues here it would do the community a real service.  If the
> GPL in this case is preventing other types of licenses, particularly
> free software licensed programs, from being developed, run, or compiled
> into usable form on the platform it provides, than something is wrong
> and needs to be fixed.  Let's hash it out now so we can all get back to
> coding.

Axiom, like other systems, builds a great deal of "system state" which
is saved in a runtime image. This builds on the language facilities
available in, I believe, all Common Lisp systems. (And also Smalltalk-like
languages). This save-system mechanism (as it is called in GCL) is the
Lisp equivalent of linking. Code I load into the system, especially
compiled code, is dynamically linked with external symbols in the image.
Indeed, the hardest part of AKCL/GCL has been the issue of dynamic linking.

I would make the analogy that in C one uses a linker to combine compiler
output and libraries to create a "save-system" image runnable binary.
Lisp combines compiler output and the lisp runtime (essentially a big
library) to create a "save-system" image. The linker just happens to
be internal to the interpreter.

My argument is that the GPL has grown out of a compiler-style mindset
and needs to take into account other styles of programming. 

It must be possible to write a GPLed Common Lisp language supporting
this common feature that allows users to write in Common Lisp without
being GPLed. Without this proviso it will not be possible to write
Common Lisp code in any other "free" license. Surely this can't be
the intention of the Free Software Foundation. 

\start
Date: Thu, 24 Jul 2003 21:21:10 +0200
From: David Mentre
To: Bill Page
Subject: Re: axiom names and lisp names

Hello Bill,

"Page, Bill" writes:

> How do I translate from the axiom name of a variable
> to the lisp name? 

As Tim told it in a previous email
(http://mail.gnu.org/archive/html/axiom-developer/2003-07/msg00094.html),
you should look at the produced common lisp during compilation in file
MODULE.lsp or MODULE.NRLIB/code.lsp do find defined symbols.

The only thing I can say (and that Tim told me) is that for category
three symbols are defined. More precisely, taking RNG (associative
rings, see catddef.spad) as example:

* The original SPAD source (in catdef.spad):

)abbrev category RNG Rng
   Rng(): Category == Join(AbelianGroup,SemiGroup)

* It produces the following lisp code (in RNG.lsp):

(|/VERSIONCHECK| 2) 

(SETQ |Rng;AL| (QUOTE NIL))   ;; <=== this is a cache

(DEFUN |Rng| NIL   ;; <== this is a dummy function called to construct RNG
                   ;;     "methods" 
  (LET (#:G82722) 
    (COND 
      (|Rng;AL|)   ;; <== either the functions exist
      (T (SETQ |Rng;AL| (|Rng;|))))))  ;; <= or we call the real constructor

(DEFUN |Rng;| NIL  ;; <== here is the real constructor for the category's "methods"
  (PROG (#1=#:G82720) 
    (RETURN 
      (PROG1 
        (LETT #1# (|Join| (|AbelianGroup|) (|SemiGroup|)) |Rng|)
        (SETELT #1# 0 (QUOTE (|Rng|))))))) 

(MAKEPROP (QUOTE |Rng|) (QUOTE NILADIC) T) 


So, as a summary, for the RNG category, we have the |Rng;AL| cache, the
|Rng| caching constructor and the |Rng;| real constructor.

The final MAKEPROP should probably add the constructor in a more global
structure, but I haven't been able to find its definition.

Unfortunalty, a lot remains to discover and say about the way
constructors work.

Best regards and I hope it helps a little,

\start
Date: Thu, 24 Jul 2003 15:59:40 -0400
From: Richard Stallman
To: Cliff Yapp
Subject: Re: GCL used commercially?
Cc: Richard Fateman, David Turner, Sam Steingold, Stavros Macrakis

    I still don't understand why it would be desirable to prevent software
    from using GCL, regardless of license, but perhaps I'm missing
    something.

A non-free program is an scheme to induce computer users to give up
their freedom.  It's a harmful practice, one that on general principle
we wish to replace, not help.

\start
Date: Thu, 24 Jul 2003 13:37:24 -0700
From: Richard Fateman
To: Richard Stallman
Subject: Re: GCL used commercially

Richard Stallman wrote:
<snip>
> 
> We have to ask, does it matter to us what they did?  Did their use of
> AKCL do anything for GCL or for the free software community?  Did
> their enhancements yield any code that improved GCL, or that we had
> the option to use in GCL?  I can't tell the answer for certain from
> the information I have, but I suspect that the answer is no.
> 
> If that is so, I think there was no reason we should see value in the
> use of GCL by such companies.  It doesn't do any good for our freedom,
> it only helps them make non-free software.
> 
  Here's the argument: It helps companies build non-free software on GCL 
which might not
ever be produced otherwise. They are motivated by profit (e.g. food, 
clothing,
shelter, Tivo...) As a result, it helps provide us a choice between
free and non-free software (I use both GIMP and Photoshop).  I count this as
increasing my freedom, though I understand your perspective.
RJF

\start
Date: Thu, 24 Jul 2003 16:55:44 -0400
From: Bill Page
To: Richard Stallman
Subject: RE: GCL used commercially?
Cc: Cliff Yapp, Richard Fateman, David Turner, Sam Steingold, Stavros Macrakis

Richard et al.

Thank you - finally something that doesn't sound like a lawyer talking
about programming! And I hope it is something that everyone here agrees
with otherwise I would really wonder why they are here ...

In my opinion all source code, including algebra, lisp and any more
conventional code developed to enhance Axiom, should under the terms of
any license, ensure that that source code be made openly available to
those who desire it. By now it should also be well understood by
everyone that this does not preclude anyone from enhancing Axiom and
selling Axiom as a commercial product. All they incure in doing so is
the legal obligation to make all the associated source code available.

Maybe it is important to point out that this should not discourage
anyone from claiming the usual kind of "ownership" and credit that is
associated with intellectual effort. One of the points of the legal
stuff, as I understand it, is precisely to protect these intellectual
rights *in return* for full disclosure of the ideas and/or software.

It seems to me that this same goal also applys (or at least should
apply) to GCL. I agree that allowing others to base commercial products
on GCL which extend GCL itself (and similarly for Axiom) without
requiring complete accessibily of the source code would be a bad thing.

On the other hand, it seems clear to me that there is nothing wrong with
using GCC and/or GCL (or even Axiom, or more probably Aldor (the library
compiler part of Axiom) to produce a program that does something
substantially different (i.e. is no longer a compiler, lisp interpreter
or a computer algebra system) and selling that new thing without
releasing the specific code for that product. Although one might still
wish to point out that such a commercial practice is bad for software
development in general. And the people who buy such products should be
aware that they may encure some disadvantages because of this in the
long run.

Have I said anything that doesn't make sense to anyone?

> 
>> I still don't understand why it would be desirable to 
>> prevent software from using GCL, regardless of license, but
>> perhaps I'm missing something.
> 
> A non-free program is an scheme to induce computer users to 
> give up their freedom.  It's a harmful practice, one that on 
> general principle we wish to replace, not help.
> 

\start
Date: 24 Jul 2003 17:24:52 -0400
From: Camm Maguire <Camm Maguire>
To: list
Subject: Re: GCL compliance and Bill Schelter
Cc: Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

Greetings, gentle people!

I must confess that I don't even have time now to adequately ponder
the flurry of latest emails.  I'd like to make the following points,
which I hope will calm and clarify.

1) I will do everything in my power to ensure that GCL's license will
   never force a license onto projects that use it as a compiler.
   This is not only achievable, but from my understanding, not even
   controversial among the existing participants of this
   discussion. Please, everyone, rest assured.

2) There are several different ways to achieve 1), some more difficult
   than others, including possibly doing nothing at all if it can be
   shown that Dr. Schelter received permission to use unexec more than
   10 years ago.  Frankly I think this is the most likely actuality,
   especially given his work with emacs over the years.  But the
   actual path to 1) is not yet clear in my mind, and probably won't
   be for some time.  In the mean time, we have the status quo, which,
   with all its ambiguities, is just as functional as its always been.

3) This having been said, it is my opinion that axiom would be better
   served by a GPL license.  It is of course completely up to the
   axiom developers and any other relevant parties, certainly not me,
   but I feel that the existing BSD license places all the volunteer
   work being poured into axiom at risk of being hijacked by a
   commercial fork of the code.  The last thing I am is a lawyer, but
   my understanding of the BSD license is that anyone, including the
   developers, can, if they so chose, relicense their copy/modified
   version of the code under the GPL.  This does not violate the BSD
   license, to my understanding, and should require no special
   permission.  After all, one can make a commercial fork of BSD code
   without permission, so one should certainly be able also to make a
   GPL fork of said code.  

   Again, this decision lies in the hands of others than me; I just
   state this here to clarify the point that should a GPL license for
   axiom ever be desired, it should not require extensive negotiations
   with other parties, who are free to continue to distribute the code
   prior to such a fork under a BSD license.

4) The basic confusion surrounding this discussion stems from a
   misunderstanding, IMHO, of how GCL (or lisp in general) works
   technically.  Tim basically hit the nail on the head.  I will try to
   summarize separately in a note to RMS, but the basic idea is that
   unlike in C programming, lisp executables have the entire compiler,
   linker, and image saver -- basically all of GCL -- in the
   executable itself.  I'm still not sure to what extent this is as a
   result of an early GCL design decision, or to what extent it is
   mandated by the Common Lisp standard.  In any case, there is a
   *long* history of GCL usage in this mode, which it would be
   completely unfair to suddenly disrupt.  I repeat I will do all in
   my power to avoid this.

5) From the perspective of fairness, this 'common lisp usage' as
   outlined in 4) cuts both ways.  Say someone writes a two line BSD
   lisp file which modifies the compiler to print 'hello world' when
   compiling a file.  Say the resulting image is BSD licensed.  Then
   someone could make a proprietary fork, release a binary with no
   source, and effectively hijack GCL.  Even if the image had some
   intermediate license which required the distributor to just
   distribute the GCL source, we've effectively permitted someone to
   distribute a modified GCL compiler without releasing their
   modifications, which is against even the LGPL.  

   On the other hand, it is quite unfair I feel to force large user
   space programs like maxima, acl2 and axiom to choose the GPL for
   their substantial code base because of GCL.  The way this is
   typically handled in LGPL situations is to define an 'application
   interface' as a wall between an LGPL'ed "library" and the user's
   main code.  Any changes on one side of the wall must have
   modifications distributed in source, whereas there are no
   restrictions to changes on the other side of this 'wall'.  Perhaps
   the common lisp hyperspec could be a definition of such an
   interface.  Code using functions in this spec might be
   unrestricted, whereas modification of the functions themselves
   would be LGPL'ed.  I feel this is what clisp was trying to achieve
   with its exception clause, but I'm really just speculating here.

6) I'd be interested to know from the perspective of maxima, acl2, and
   axiom users whether typical usage of the *final distributed binary*
   (as opposed to intermediate images in the build process) would
   require the ability to dump new images and/or load compiled
   modules.  

7) I realize these issues are important, as demonstrated with
   exceptional clarity recently by this SCO/Linux mess.  (Can anyone
   imagine how much worse the situation might be had SCO not
   itself distributed Linux under the GPL?)  But I must confess I'm a
   bit tired of this discussion, and its eating up what little time I
   have to push GCL forward.  Can we please get back to the code now?
   I trust a solution will present itself in time, and until then, we
   should be content with the status quo.

\start
Date: 24 Jul 2003 23:26:34 -0400
From: Camm Maguire
To: list
Subject: Small patches

Greetings!  Tim, do you need these?

=============================================================================
--- /fix/t1/camm/axiom/axiom/new/new/src/boot/ptyout.boot.pamphlet	2002-12-21 22:14:36.000000000 +0000
+++ ptyout.boot.pamphlet	2003-07-24 00:41:55.000000000 +0000
@@ -801,11 +801,11 @@
     (DECLARE (SPECIAL |$bfClamming|))
     (RETURN
       (PROGN
-        (SETQ |a| (PACKAGE-NAME *PACKAGE*))
+        (SETQ boottran::|a| (PACKAGE-NAME *PACKAGE*))
         (IN-PACKAGE 'BOOTTRAN)
         (SETQ |$bfClamming| NIL)
         (BOOTTOCLLINES NIL |fn|)
-        (IN-PACKAGE |a|)))))
+        (IN-PACKAGE |a|) (makunbound 'boottran::|a|)))))
 
 (DEFUN BOOTCLAM (|fn|) (PROG () (RETURN (BOOTCLAMLINES NIL |fn|))))
 
@@ -927,7 +927,7 @@
     (DECLARE (SPECIAL |$bfClamming|))
     (RETURN
       (PROGN
-        (SETQ |b| (PACKAGE-NAME *PACKAGE*))
+        (SETQ boottran::|b| (PACKAGE-NAME *PACKAGE*))
         (IN-PACKAGE 'BOOTTRAN)
         (SETQ |$bfClamming| NIL)
         (SETQ |infn| (|shoeAddbootIfNec| |fn|))
@@ -936,7 +936,7 @@
                       *LISP-SOURCE-FILETYPE*))
         (|shoeOpenInputFile| |a| |infn|
             (|shoeClLines| |a| |infn| NIL |outfn|))
-        (IN-PACKAGE |b|)
+        (IN-PACKAGE |b|)(makunbound 'boottran::|b|)
         (LOAD |outfn|)))))
 
 (DEFUN BO (|fn|)
@@ -944,13 +944,13 @@
     (DECLARE (SPECIAL |$GenVarCounter| |$bfClamming|))
     (RETURN
       (PROGN
-        (SETQ |b| (PACKAGE-NAME *PACKAGE*))
+        (SETQ boottran::|b| (PACKAGE-NAME *PACKAGE*))
         (IN-PACKAGE 'BOOTTRAN)
         (SETQ |$GenVarCounter| 0)
         (SETQ |$bfClamming| NIL)
         (SETQ |infn| (|shoeAddbootIfNec| |fn|))
         (|shoeOpenInputFile| |a| |infn| (|shoeToConsole| |a| |fn|))
-        (IN-PACKAGE |b|)))))
+        (IN-PACKAGE |b|)(makunbound 'boottran::|b|)))))
 
 (DEFUN BOCLAM (|fn|)
   (PROG (|$bfClamming| |$GenVarCounter| |infn|)
@@ -1949,10 +1949,10 @@
   (PROG (|b| |a|)
     (RETURN
       (PROGN
-        (SETQ |a| (PACKAGE-NAME *PACKAGE*))
+        (SETQ boottran::|a| (PACKAGE-NAME *PACKAGE*))
         (IN-PACKAGE 'BOOTTRAN)
         (SETQ |b| (|bStreamNull| |s|))
-        (IN-PACKAGE |a|)
+        (IN-PACKAGE |a|)(makunbound 'boottran::|a|)
         |b|))))
 
 (DEFUN PSTTOMC (|string|)
=============================================================================
--- /fix/t1/camm/axiom/axiom/new/new/src/interp/foam_l.lisp.pamphlet	2003-06-18 19:05:18.000000000 +0000
+++ foam_l.lisp.pamphlet	2003-07-23 23:03:11.000000000 +0000
@@ -852,13 +852,13 @@
        ( (and (ATOM u) (ATOM v)) (eql u v))
        ( (or (ATOM u) (ATOM v)) nil)
        ( (equal (length u) (length v)) (|magicEq1| u v)) 
-       nil ))
+       (t nil) ))
 
 (defun |magicEq1| (u v)
  (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
        ( (or (atom u) (atom v)) nil)
        ( (|politicallySound| (car u) (car v)) (|magicEq1| (cdr u) (cdr v)))
-       nil ))
+       (t nil) ))
 
 @
 \eject

\start
Date: Thu, 24 Jul 2003 23:38:02 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Small patches

Camm,

It appears that in pytout.boot you're changing the package of
the variable. why? Is there some common lisp change from old
version to new version I need to be aware of? What happens 
if I change a package in mid function?

In foam_l.lisp it appears that the cond clause is not a list.
I'd have thought that would cause an error. I'll patch it.

\start
Date: 25 Jul 2003 00:06:20 -0400
From: Camm Maguire
To: list
Subject: Re: Small patches

Greetings!

Tim Daly writes:

> Camm,
> 
> It appears that in pytout.boot you're changing the package of
> the variable. why? Is there some common lisp change from old
> version to new version I need to be aware of? What happens 
> if I change a package in mid function?
> 

When you (setq |a| (package-name *package*)), |a| lives in the initial
package and is not accessible in boottran when you invoke (in-package
'boottran) ... (in-package |a|)

> In foam_l.lisp it appears that the cond clause is not a list.
> I'd have thought that would cause an error. I'll patch it.
> 

Indeed it does when the .lisp is loaded at a )fin lisp prompt.  I
think the fact that it does not show up in the normal make procedure
might mean that other such potential bugs are being masked, maybe even
the ones related to the infinite recursion.  Can you shed light on why
this did not cause the build to fail?

Also, in my build, I'm getting a lot of 

***** Domain ? already {present,defined, can't really remember} ****** 

in the algebra portion.  Do you see this?  Sounds relevant.

\start
Date: Fri, 25 Jul 2003 09:31:20 +0100
From: Mike Dewar
To: Richard Stallman
Subject: Re: GCL used commercially?
Cc: Richard Fateman, Cliff Yapp, David Turner, Sam Steingold, Stavros Macrakis

That is a very broad and misleading statement.  Many so-called "free"
licenses, in particular the GPL, require computer users to give up their
freedom as well.  Of course there are other free licenses, such as the
BSD-style licenses, which don't do this.

On Thu, Jul 24, 2003 at 03:59:40PM -0400, Richard Stallman wrote:
>     I still don't understand why it would be desirable to prevent software
>     from using GCL, regardless of license, but perhaps I'm missing
>     something.
> 
> A non-free program is an scheme to induce computer users to give up
> their freedom.  It's a harmful practice, one that on general principle
> we wish to replace, not help.

\start
Date: Fri, 25 Jul 2003 09:28:45 +1000
From: Mike Thomas
To: Mike Dewar
Subject: RE: GCL compliance and Bill Schelter
Cc: Camm Maguire, Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

Hi Mike.

Unfortunately I didn't made my point clearly enough and you have got the
wrong end of the stick.

| > From a practical point of view, I would hate to look a gift
| horse (free BSD
| > Axiom)in the mouth when the gift came from such an appalling
| example (IBM,
| > at the very least from the Thomas J Watson years apparently) of the
| > subjugation of moral responsibility to commercial and 20th century right
| > wing political imperatives.
| The "gift", as you call it, came from NAG, not IBM.  Perhaps you would
| like to retract this statement or clarify in what way we are "an
| appalling example of the subjugation of moral responsibility to
| commercial and 20th century right wing political imperatives".

I didn't make myself sufficiently clear, I was referring to IBM, not NAG.

If you would like to look further into why I said this about IBM in the
Thomas J Watson years, I suggest you read:

Black, Edwin, "IBM and the Holocaust - The Strategic Alliance Between Nazi
Germany and America's Most Powerful Corporation", 2001, Little, Brown and
Company, London.

I'm sorry for not being sufficiently clear on that and for not being
sufficiently clear on my real (but unfortunately implied) point, which was:

  - I felt that it was better not to try and link the licencing terms of
Axiom with the licencing terms of GCL through the GPL.

\start
Date: Fri, 25 Jul 2003 10:19:35 +1000
From: Mike Thomas
To: list
Subject: RE: GCL compliance and Bill Schelter
Cc: Camm Maguire, Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

Hi Tim.

| > To clarify, I underatand that (IBM or NAG?) released the code
| with licencing
| > conditions on it which cannot be changed.
|
| > >From a practical point of view, I would hate to look a gift
| horse (free BSD
| > Axiom)in the mouth when the gift came from such an appalling
| example (IBM,
| > at the very least from the Thomas J Watson years apparently) of the
| > subjugation of moral responsibility to commercial and 20th century right
| > wing political imperatives.
|
| I have to react to this screed with anger. You grossly paint IBM and,
| by proximity, NAG with some sort of political mud. Corporations are made
| up of people, of which I was one, and I am incensed that you would sling
| such unfounded assertions at people I hold in the highest regard and
| deepest respect. The people at NAG and IBM Research are among the best
| I've ever worked with. If you want to argue politics please find another
| forum.

Sorry about that; I did not make my point very well.  Please see my separate
reply to Mike Dewar.

I assumed that neither you nor anyone else from recent IBM history would be
offended by a reference to the Thomas J Watson years as presumably none of
you would have participated either directly or indirectly in the events
mentioned in the reference I passed on to Mike.

I saw the release of the Axiom code as (in a certain sense) a minor Karmic
event not to be messed with by the implications of day to day considerations
such as GPL licencing.  Rather than arguing politics I was trying (not very
well) to put that slant on it.  I would also like Axiom to remain licenced
as it currently is - BSD.

\start
Date: Fri, 25 Jul 2003 03:59:20 -0400
From: Richard Stallman
To: Tim Daly
Subject: Re: GCL compliance and Bill Schelter
Cc: Camm Maguire, David Turner, Sam Steingold, Stavros Macrakis

The first message I received about Axiom seemed to imply it was
released as non-free software by NAG, but now it looks like Axiom is
free software today.  Sorry for the confusion.

If Axiom is released under the revised BSD license
then there is no difficulty linking it (in any sense)
with GPL-covered code.

    Suppose I write a common lisp program like Axiom (licensed under 
    modified BSD). Suppose I use a GPLed Common Lisp and save a binary
    image of the loaded program. If saving the image requires my common lisp
    program to ALSO be GPLed then it is not possible to develop programs
    using a GPLed Common Lisp.

This is a misunderstanding.  Including a GPL-covered program in a
combination means the combination as a whole is covered by the GPL.
However, any individual piece can have a more permissive license,
such as for instance the revised BSD license.

\start
Date: Thu, 24 Jul 2003 21:25:44 -0700
From: Bakul Shah
To: Camm Maguire
Subject: Re: GCL compliance and Bill Schelter
Cc: Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

> 3) This having been said, it is my opinion that axiom would be better
>    served by a GPL license.  It is of course completely up to the
>    axiom developers and any other relevant parties, certainly not me,
>    but I feel that the existing BSD license places all the volunteer
>    work being poured into axiom at risk of being hijacked by a
>    commercial fork of the code.

Just clarifying something....

The code base that such a commericial project may start from
*does not* suddenly become closed.  An open source developer
is perfectly free and able to continue working on the
non-commercial branch.  No volunteer work gets lost.  What
you may not get are *further* changes made by the commercial
project.

What may happen is that someone other than the volunteers
makes money.  Is that what you are calling "being hijacked"?

>                                  The last thing I am is a lawyer, but
>    my understanding of the BSD license is that anyone, including the
>    developers, can, if they so chose, relicense their copy/modified
>    version of the code under the GPL.  This does not violate the BSD
>    license, to my understanding, and should require no special
>    permission.  After all, one can make a commercial fork of BSD code
>    without permission, so one should certainly be able also to make a
>    GPL fork of said code.  

Commercial forking is allowed and done *with* the permission
given in the BSD license!  But I believe you can not take BSD
licensed code and put it under GPL due to the following in
the BSD license:

 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.

As I understand it, by requiring that source be available
GPL modifies condition 2. above and hence runs afoul of the
BSD license.  But I am not a lawyer!

But if this is the case and if Lisp & Maxima remain intermingled
does it mean Maxima can't be used with CMUCL?:-):-(

Personally I am *glad* there are two competing free licenses
even if there are headaches such as this one.

\start
Date: Fri, 25 Jul 2003 09:55:16 +0100
From: Mike Dewar
To: Camm Maguire
Subject: re: GCL compliance and Bill Schelter
Cc: Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

Camm,

Licensing issues seem to develop into religous wars and since releasing
Axiom under the BSD I've spent more time justifying that decision to
free-software advocates than helping people try to undrstand and use the
code.  I can't help thinking the free software community needs to get a
better perspective.  Its a simple fact that for all sorts of practical
reasons it is unlikely that we could have released the code under the
GPL.  I don't agree with your point about axiom being "better served" by
a GPL license since I don't agree that building commercial products on
top of Axiom would be a bad thing (this is the model that MuPad have
tried to adopt, although with limited success as far as I can see - a
free kernel with proprietory user interfaces, help systems, IDEs etc.).
However we should agree to differ on this.

As far as your point about building a GPL'd product using BSD code, I
believe that you are correct although I have heard opinions to the
contrary.  The broad principles should be OK, it seems that the devil is
in the detail and that making sure that the correct notices, disclaimers
etc. appear in the right places is a little tricky.

As for your specific question (6) about Axiom users saving custom
images, the fact is that as far as I know nobody outside IBM and NAG
ever did this when Axiom was built on AKCL and while its would have been
possible with the CCL version the procedure was never documented so I'm
confident that it didn't happen!  The only significant advantage to a
user of doing this would be to save an image with their favourite
libraries pre-loaded, which these days isn't a big time saving. 

Kind regards, Mike.

On Thu, Jul 24, 2003 at 05:24:52PM -0400, Camm Maguire wrote:
> Greetings, gentle people!
> 
> I must confess that I don't even have time now to adequately ponder
> the flurry of latest emails.  I'd like to make the following points,
> which I hope will calm and clarify.
> 
> 1) I will do everything in my power to ensure that GCL's license will
>    never force a license onto projects that use it as a compiler.
>    This is not only achievable, but from my understanding, not even
>    controversial among the existing participants of this
>    discussion. Please, everyone, rest assured.
> 
> 2) There are several different ways to achieve 1), some more difficult
>    than others, including possibly doing nothing at all if it can be
>    shown that Dr. Schelter received permission to use unexec more than
>    10 years ago.  Frankly I think this is the most likely actuality,
>    especially given his work with emacs over the years.  But the
>    actual path to 1) is not yet clear in my mind, and probably won't
>    be for some time.  In the mean time, we have the status quo, which,
>    with all its ambiguities, is just as functional as its always been.
> 
> 3) This having been said, it is my opinion that axiom would be better
>    served by a GPL license.  It is of course completely up to the
>    axiom developers and any other relevant parties, certainly not me,
>    but I feel that the existing BSD license places all the volunteer
>    work being poured into axiom at risk of being hijacked by a
>    commercial fork of the code.  The last thing I am is a lawyer, but
>    my understanding of the BSD license is that anyone, including the
>    developers, can, if they so chose, relicense their copy/modified
>    version of the code under the GPL.  This does not violate the BSD
>    license, to my understanding, and should require no special
>    permission.  After all, one can make a commercial fork of BSD code
>    without permission, so one should certainly be able also to make a
>    GPL fork of said code.  
> 
>    Again, this decision lies in the hands of others than me; I just
>    state this here to clarify the point that should a GPL license for
>    axiom ever be desired, it should not require extensive negotiations
>    with other parties, who are free to continue to distribute the code
>    prior to such a fork under a BSD license.
> 
> 4) The basic confusion surrounding this discussion stems from a
>    misunderstanding, IMHO, of how GCL (or lisp in general) works
>    technically.  Tim basically hit the nail on the head.  I will try to
>    summarize separately in a note to RMS, but the basic idea is that
>    unlike in C programming, lisp executables have the entire compiler,
>    linker, and image saver -- basically all of GCL -- in the
>    executable itself.  I'm still not sure to what extent this is as a
>    result of an early GCL design decision, or to what extent it is
>    mandated by the Common Lisp standard.  In any case, there is a
>    *long* history of GCL usage in this mode, which it would be
>    completely unfair to suddenly disrupt.  I repeat I will do all in
>    my power to avoid this.
> 
> 5) From the perspective of fairness, this 'common lisp usage' as
>    outlined in 4) cuts both ways.  Say someone writes a two line BSD
>    lisp file which modifies the compiler to print 'hello world' when
>    compiling a file.  Say the resulting image is BSD licensed.  Then
>    someone could make a proprietary fork, release a binary with no
>    source, and effectively hijack GCL.  Even if the image had some
>    intermediate license which required the distributor to just
>    distribute the GCL source, we've effectively permitted someone to
>    distribute a modified GCL compiler without releasing their
>    modifications, which is against even the LGPL.  
> 
>    On the other hand, it is quite unfair I feel to force large user
>    space programs like maxima, acl2 and axiom to choose the GPL for
>    their substantial code base because of GCL.  The way this is
>    typically handled in LGPL situations is to define an 'application
>    interface' as a wall between an LGPL'ed "library" and the user's
>    main code.  Any changes on one side of the wall must have
>    modifications distributed in source, whereas there are no
>    restrictions to changes on the other side of this 'wall'.  Perhaps
>    the common lisp hyperspec could be a definition of such an
>    interface.  Code using functions in this spec might be
>    unrestricted, whereas modification of the functions themselves
>    would be LGPL'ed.  I feel this is what clisp was trying to achieve
>    with its exception clause, but I'm really just speculating here.
> 
> 6) I'd be interested to know from the perspective of maxima, acl2, and
>    axiom users whether typical usage of the *final distributed binary*
>    (as opposed to intermediate images in the build process) would
>    require the ability to dump new images and/or load compiled
>    modules.  
> 
> 7) I realize these issues are important, as demonstrated with
>    exceptional clarity recently by this SCO/Linux mess.  (Can anyone
>    imagine how much worse the situation might be had SCO not
>    itself distributed Linux under the GPL?)  But I must confess I'm a
>    bit tired of this discussion, and its eating up what little time I
>    have to push GCL forward.  Can we please get back to the code now?
>    I trust a solution will present itself in time, and until then, we
>    should be content with the status quo.

\start
Date: Fri, 25 Jul 2003 09:59:39 +0100
From: Mike Dewar
To: Mike Thomas
Subject: Re: GCL compliance and Bill Schelter
Cc: Camm Maguire <Camm Maguire>, Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

Hi Mike,

Your point seemed very plain to me.  You described the source of the
"gift" of Axiom code as "an appalling example of the subjugation ... "
etc.  You copied the message to the axiom-developer list where everybody
knows that NAG was that source.  I'm happy to accept your clarification,
and to resume my place amongst the good guys :-)  I would however echo
Tim Daly's comments about the IBM team, who were (and still are,
although they are no longer working together) a tremendous bunch of
individuals.

Cheers, Mike.

On Fri, Jul 25, 2003 at 09:28:45AM +1000, Mike Thomas wrote:
> Hi Mike.
> 
> Unfortunately I didn't made my point clearly enough and you have got the
> wrong end of the stick.
> 
> | > From a practical point of view, I would hate to look a gift
> | horse (free BSD
> | > Axiom)in the mouth when the gift came from such an appalling
> | example (IBM,
> | > at the very least from the Thomas J Watson years apparently) of the
> | > subjugation of moral responsibility to commercial and 20th century right
> | > wing political imperatives.
> | The "gift", as you call it, came from NAG, not IBM.  Perhaps you would
> | like to retract this statement or clarify in what way we are "an
> | appalling example of the subjugation of moral responsibility to
> | commercial and 20th century right wing political imperatives".
> 
> I didn't make myself sufficiently clear, I was referring to IBM, not NAG.
> 
> If you would like to look further into why I said this about IBM in the
> Thomas J Watson years, I suggest you read:
> 
> Black, Edwin, "IBM and the Holocaust - The Strategic Alliance Between Nazi
> Germany and America's Most Powerful Corporation", 2001, Little, Brown and
> Company, London.
> 
> I'm sorry for not being sufficiently clear on that and for not being
> sufficiently clear on my real (but unfortunately implied) point, which was:
> 
>   - I felt that it was better not to try and link the licencing terms of
> Axiom with the licencing terms of GCL through the GPL.

\start
Date: 25 Jul 2003 11:33:50 -0400
From: Camm Maguire
To: Bakul Shah
Subject: Re: GCL compliance and Bill Schelter
Cc: Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

Greetings, and thanks for your note!

Bakul Shah writes:

> > 3) This having been said, it is my opinion that axiom would be better
> >    served by a GPL license.  It is of course completely up to the
> >    axiom developers and any other relevant parties, certainly not me,
> >    but I feel that the existing BSD license places all the volunteer
> >    work being poured into axiom at risk of being hijacked by a
> >    commercial fork of the code.
> 
> Just clarifying something....
> 
> The code base that such a commericial project may start from
> *does not* suddenly become closed.  An open source developer
> is perfectly free and able to continue working on the
> non-commercial branch.  No volunteer work gets lost.  What
> you may not get are *further* changes made by the commercial
> project.
> 
> What may happen is that someone other than the volunteers
> makes money.  Is that what you are calling "being hijacked"?
> 

1) I think it is important to restate that one is completely free to
   sell a GPL'ed program commercially.  I'd guess that at present,
   more money is made from sales of GPL'ed GNU/Linux (e.g. Redhat,
   Suse, IBM, etc.) than from sales of closed source BSD derivatives.
   This actual working example speaks louder to me than all other
   theoretical speculations.  This is not about money, but freedom or
   liberty.  By all means, sell free software, profit and be happy!
   But please, just don't close the source.

2) 'Hijacking' does not necessarily follow from a closed source
   proprietary fork of a BSD program, but certainly can, and is
   arguably quite plausible, though whether or not it is likely
   depends on the circumstances in each particular case.  Here is how
   it works, at least in my mind.  

   To flourish, a free software program must have an active,
   knowledgeable, and dedicated group of developers, volunteers or
   otherwise.  To motivate and and provide feedback to these
   developers, the program needs as large and as varied a group of
   users as possible.  

   So say this exists for a BSD program, and suddenly someone makes a
   closed source proprietary fork, and over the course of some time,
   improves the program significantly.  There is an enormous pressure
   on the user base to stop using the free version and buy and use the
   closed version instead.  The feedback and motivation for the free
   program developers steadily deteriorates, perhaps to the point
   where they feel no one cares about the free program any longer, and
   it has lost the race against the closed proprietary version.  The
   developers start to do something else.  Over time, people even
   forget how the code works.  The barrier for someone completely new
   to the code to take on the project becomes exceedingly high, as
   they are effectively on their own with a steep learning curve.  The
   program is effectively 'hijacked'.

   Now there are cases where BSD code does not follow this path, at
   least not yet.  One highly successful example is postgresql.  Then
   there are cases where some diluted form of the above is at play.
   In my personal opinion, the great difference in developer mindshare
   between the Linux and BSD kernel projects is due in part to the
   commercial mindshare drain into projects like BSDI, in part due to
   early legal conflicts with commercial entities claiming rights to
   the same code, and in part due to the feeling among some would be
   contributors that their contributions are not adequately protected
   for posterity (e.g. via the mechanism outlined above), all of which
   are in part due to the nature of the BSD license.  And then there
   are some projects where the above scenario appears to dominate the
   program's evolution, for example with the early browser Mosaic.
   The source to Mosaic was always available, but it was largely
   rendered useless for some time by the dominant binary only
   distributions of Netscape and then IE, until Netscape again opened
   the source and forked Mozilla.

> >                                  The last thing I am is a lawyer, but
> >    my understanding of the BSD license is that anyone, including the
> >    developers, can, if they so chose, relicense their copy/modified
> >    version of the code under the GPL.  This does not violate the BSD
> >    license, to my understanding, and should require no special
> >    permission.  After all, one can make a commercial fork of BSD code
> >    without permission, so one should certainly be able also to make a
> >    GPL fork of said code.  
> 
> Commercial forking is allowed and done *with* the permission
> given in the BSD license!  But I believe you can not take BSD
> licensed code and put it under GPL due to the following in
> the BSD license:
> 
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions
>  * are met:
>  * 1. Redistributions of source code must retain the above copyright
>  *    notice, this list of conditions and the following disclaimer.
>  * 2. Redistributions in binary form must reproduce the above copyright
>  *    notice, this list of conditions and the following disclaimer in the
>  *    documentation and/or other materials provided with the distribution.
> 
> As I understand it, by requiring that source be available
> GPL modifies condition 2. above and hence runs afoul of the
> BSD license.  But I am not a lawyer!
> 

I am certainly not a lawyer either, but my understanding here is a bit
different.  BSD basically says one cannot remove the copyright notice,
disclaimer, etc., and one cannot remove the condition that they not be
removed.  The GPL in no way contradicts this, but rather *adds* a
restriction that binary distributions must be accompanied by source to
those who want it.  If BSD said something like 'no extra requirements
may be placed on the distribution of this code or its modifications',
then the GPL would not be compatible.  It is also my understanding
that nothing in the BSD license explicitly grants permission for
commercial closed source forks as apart from GPL'ed forks.

> But if this is the case and if Lisp & Maxima remain intermingled
> does it mean Maxima can't be used with CMUCL?:-):-(
> 

Precisely.  I think if you're interpretation of BSD were correct,
Maxima could not distribute an image compiled with CMUCL.  Just to
restate, I don't think this is the case, and believe there is no
problem with Maxima/cmucl.

> Personally I am *glad* there are two competing free licenses
> even if there are headaches such as this one.
> 

I also have nothing against people who want to BSD their code.  But I
do contribute to some BSD'ed open source projects, and feel somewhat
uneasy in that my contributions might be commercially 'hijacked'.
Just my feelings/opinions, of course.

\start
Date: Fri, 25 Jul 2003 11:55:51 -0400
From: Tim Daly
To: list
Subject: axiom-legal@nongnu.org
Cc: Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

*,

The axiom-developer mailing list is being buried by the license
discussion issue. Clearly the license issue is NEVER going to
go away so I've taken steps to redirect it.

axiom-legal@nongnu.org is a new mailing list for legal issues.

Please carefully update your CC: list to use the new mailing list.
We need the axiom-developer mailing list for programming issues.
In fact, we need the developer time even more.

\start
Date: 25 Jul 2003 11:51:16 -0400
From: Camm Maguire
To: Mike Dewar
Subject: Re: GCL compliance and Bill Schelter
Cc: Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

Greetings!

Mike Dewar writes:

> Camm,
> 
> Licensing issues seem to develop into religous wars and since releasing
> Axiom under the BSD I've spent more time justifying that decision to
> free-software advocates than helping people try to undrstand and use the
> code.  I can't help thinking the free software community needs to get a
> better perspective.  Its a simple fact that for all sorts of practical
> reasons it is unlikely that we could have released the code under the
> GPL.  I don't agree with your point about axiom being "better served" by
> a GPL license since I don't agree that building commercial products on
> top of Axiom would be a bad thing (this is the model that MuPad have
> tried to adopt, although with limited success as far as I can see - a
> free kernel with proprietory user interfaces, help systems, IDEs etc.).
> However we should agree to differ on this.
> 

Let me please state that I respect your position greatly.  And let me
please reiterate that I think the actions of NAG and IBM in releasing
axiom are nothing but extremely praiseworthy.  And let me finally
state that even in the case of GPL'ed programs, I think there is
nothing wrong with commercial companies making a living selling and
supporting the program.  I think Redhat, Suse, and IBM are good
examples of this with respect to sales of GNU/Linux, and also examples
that such sales and profit need not necessitate closing the source.

> As far as your point about building a GPL'd product using BSD code, I
> believe that you are correct although I have heard opinions to the
> contrary.  The broad principles should be OK, it seems that the devil is
> in the detail and that making sure that the correct notices, disclaimers
> etc. appear in the right places is a little tricky.
> 

Agreed.

> As for your specific question (6) about Axiom users saving custom
> images, the fact is that as far as I know nobody outside IBM and NAG
> ever did this when Axiom was built on AKCL and while its would have been
> possible with the CCL version the procedure was never documented so I'm
> confident that it didn't happen!  The only significant advantage to a
> user of doing this would be to save an image with their favourite
> libraries pre-loaded, which these days isn't a big time saving. 
> 

Great, good to know -- thanks!  What about loading binary object
(e.g. '.o') files?

Take care,

> Kind regards, Mike.
> 
> On Thu, Jul 24, 2003 at 05:24:52PM -0400, Camm Maguire wrote:
> > Greetings, gentle people!
> > 
> > I must confess that I don't even have time now to adequately ponder
> > the flurry of latest emails.  I'd like to make the following points,
> > which I hope will calm and clarify.
> > 
> > 1) I will do everything in my power to ensure that GCL's license will
> >    never force a license onto projects that use it as a compiler.
> >    This is not only achievable, but from my understanding, not even
> >    controversial among the existing participants of this
> >    discussion. Please, everyone, rest assured.
> > 
> > 2) There are several different ways to achieve 1), some more difficult
> >    than others, including possibly doing nothing at all if it can be
> >    shown that Dr. Schelter received permission to use unexec more than
> >    10 years ago.  Frankly I think this is the most likely actuality,
> >    especially given his work with emacs over the years.  But the
> >    actual path to 1) is not yet clear in my mind, and probably won't
> >    be for some time.  In the mean time, we have the status quo, which,
> >    with all its ambiguities, is just as functional as its always been.
> > 
> > 3) This having been said, it is my opinion that axiom would be better
> >    served by a GPL license.  It is of course completely up to the
> >    axiom developers and any other relevant parties, certainly not me,
> >    but I feel that the existing BSD license places all the volunteer
> >    work being poured into axiom at risk of being hijacked by a
> >    commercial fork of the code.  The last thing I am is a lawyer, but
> >    my understanding of the BSD license is that anyone, including the
> >    developers, can, if they so chose, relicense their copy/modified
> >    version of the code under the GPL.  This does not violate the BSD
> >    license, to my understanding, and should require no special
> >    permission.  After all, one can make a commercial fork of BSD code
> >    without permission, so one should certainly be able also to make a
> >    GPL fork of said code.  
> > 
> >    Again, this decision lies in the hands of others than me; I just
> >    state this here to clarify the point that should a GPL license for
> >    axiom ever be desired, it should not require extensive negotiations
> >    with other parties, who are free to continue to distribute the code
> >    prior to such a fork under a BSD license.
> > 
> > 4) The basic confusion surrounding this discussion stems from a
> >    misunderstanding, IMHO, of how GCL (or lisp in general) works
> >    technically.  Tim basically hit the nail on the head.  I will try to
> >    summarize separately in a note to RMS, but the basic idea is that
> >    unlike in C programming, lisp executables have the entire compiler,
> >    linker, and image saver -- basically all of GCL -- in the
> >    executable itself.  I'm still not sure to what extent this is as a
> >    result of an early GCL design decision, or to what extent it is
> >    mandated by the Common Lisp standard.  In any case, there is a
> >    *long* history of GCL usage in this mode, which it would be
> >    completely unfair to suddenly disrupt.  I repeat I will do all in
> >    my power to avoid this.
> > 
> > 5) From the perspective of fairness, this 'common lisp usage' as
> >    outlined in 4) cuts both ways.  Say someone writes a two line BSD
> >    lisp file which modifies the compiler to print 'hello world' when
> >    compiling a file.  Say the resulting image is BSD licensed.  Then
> >    someone could make a proprietary fork, release a binary with no
> >    source, and effectively hijack GCL.  Even if the image had some
> >    intermediate license which required the distributor to just
> >    distribute the GCL source, we've effectively permitted someone to
> >    distribute a modified GCL compiler without releasing their
> >    modifications, which is against even the LGPL.  
> > 
> >    On the other hand, it is quite unfair I feel to force large user
> >    space programs like maxima, acl2 and axiom to choose the GPL for
> >    their substantial code base because of GCL.  The way this is
> >    typically handled in LGPL situations is to define an 'application
> >    interface' as a wall between an LGPL'ed "library" and the user's
> >    main code.  Any changes on one side of the wall must have
> >    modifications distributed in source, whereas there are no
> >    restrictions to changes on the other side of this 'wall'.  Perhaps
> >    the common lisp hyperspec could be a definition of such an
> >    interface.  Code using functions in this spec might be
> >    unrestricted, whereas modification of the functions themselves
> >    would be LGPL'ed.  I feel this is what clisp was trying to achieve
> >    with its exception clause, but I'm really just speculating here.
> > 
> > 6) I'd be interested to know from the perspective of maxima, acl2, and
> >    axiom users whether typical usage of the *final distributed binary*
> >    (as opposed to intermediate images in the build process) would
> >    require the ability to dump new images and/or load compiled
> >    modules.  
> > 
> > 7) I realize these issues are important, as demonstrated with
> >    exceptional clarity recently by this SCO/Linux mess.  (Can anyone
> >    imagine how much worse the situation might be had SCO not
> >    itself distributed Linux under the GPL?)  But I must confess I'm a
> >    bit tired of this discussion, and its eating up what little time I
> >    have to push GCL forward.  Can we please get back to the code now?
> >    I trust a solution will present itself in time, and until then, we
> >    should be content with the status quo.

\start
Date: 25 Jul 2003 18:03:48 +0200
From: Nicolas Neuss
To: Mike Dewar
Subject: Re: GCL used commercially?
Cc: Richard Stallman

Mike Dewar writes:

> That is a very broad and misleading statement.  Many so-called "free"
> licenses, in particular the GPL, require computer users to give up their
> freedom as well.  Of course there are other free licenses, such as the
> BSD-style licenses, which don't do this.
> 
> Mike. 

I agree with this more or less.  There is an interesting viewpoint that the
GPL makes the *software* free (whereas the BSD licenses would give its
users maximal freedom, even the freedom to "enslave" it).

I heard this first in a message by Linus Torvalds (who knows?)

http://groups.google.com/groups?selm=9h99ei%24v01%241%25cesium.transmeta.com%40ifi.uio.no

Note that this is *not* the FSF's interpretation!

\start
Date: Fri, 25 Jul 2003 17:47:07 -0400
From: Richard Stallman
To: Bill Page
Subject: Re: GCL used commercially?
Cc: Richard Fateman, Cliff Yapp, David Turner, Sam Steingold, Stavros Macrakis

    On the other hand, it seems clear to me that there is nothing wrong with
    using GCC and/or GCL (or even Axiom, or more probably Aldor (the library
    compiler part of Axiom) to produce a program that does something
    substantially different (i.e. is no longer a compiler, lisp interpreter
    or a computer algebra system) and selling that new thing without
    releasing the specific code for that product.

Many people hold that opinion, but the GNU Project is based on the
idea that non-free software constitutes a social and ethical problem
merely because it is non-free.  Whether it uses GCC or GCL or both or
neither is not the point, ethically speaking; what's wrong about it is
keeping the users divided and helpless.

Whether to permit the use of some GNU tool or GNU library for non-free
software only is a different question, more strategic than ethical.
In some cases there we legally have no say--for instance, the output
of GCC is not subject to our copyright.  In some cases we've decided
that it is better to permit this even though legally we could deny
permission; Bison's parser file is an example.  But when we make such
a decision, it is a strategic one; it is not because we think that
non-free projects deserve our cooperation.  They never deserve our
cooperation.  They deserve to be replaced with free software.

\start
Date: 25 Jul 2003 22:18:47 -0400
From: Camm Maguire
To: list
Subject: Re: hascategory bug

Greetings!  Some real progress to report on the infinite recusion
bug.  Almost but not quite there.

The bottom line is that (|Ring|) is totally correct until |Algebra| is
executed, at which point the fourth element returned by (|Ring|) is
overwritten by the result returned in the fourth element of the vector
returned by |Algebra|.  The point of this overwrite is at the
following form of |JoinInner| (int/interp/category.clisp):

 (SETELT |$NewCatVec| 4 (CONS |c| (CONS |FundamentalAncestors| (CONS
 (CADDR (ELT |$NewCatVec| 4)) NIL))))

called from |Algebra;| (int/algebra/ALGEBRA.NRLIB/code.lsp) through 

(|Join| (|Ring|) (|Module| (QUOTE |t#1|)) (|mkCategory| (QUOTE
|domain|) (QUOTE (((|coerce| ($ |t#1|)) T))) NIL (QUOTE NIL) NIL))

I haven't parsed |JoinInner| yet, but my guess is that there is a
copy-seq in there which is not getting executed in the assignment of
|$NewCatVec| before the setelt.

Just have to figure out how to set a break in lisp to confirm.
Hopefully should not be long now.

\start
Date: Fri, 25 Jul 2003 23:09:11 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: hascategory bug

Man, I'm impressed. I've been chasing this bug for a while with 
no real success. I'm going to look at the same code and see what
I can find.

\start
Date: 26 Jul 2003 01:59:49 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] Re: hascategory bug

Greetings again!  OK here it is:

--- ../../../../../axiom2/new/new/src/interp/category.boot.pamphlet	2003-05-05 03:14:25.000000000 +0000
+++ category.boot.pamphlet	2003-07-26 05:43:49.000000000 +0000
@@ -471,7 +471,7 @@
         n:= SIZE $NewCatVec
         FundamentalAncestors:= [[b.(0),condition,n],:FundamentalAncestors]
         $NewCatVec:= LENGTHENVEC($NewCatVec,n+1)
-        copied:= true
+        copied:= false
         originalvector:= false
         $NewCatVec.n:= b.(0)
   if not copied then $NewCatVec:= COPY_-SEQ $NewCatVec


At least in GCL, the code for lengthenvec need not copy the vec to a
new location:

(macros.lisp)

(defun lengthenvec (v n)
  (if (adjustable-array-p v) (adjust-array v n)
    (replace (make-array n) v)))

In this case, the array is adjustable, and again at least in GCL, the
adjust-array need not and in this case does not do a copy.

I think I just compiled xpoly ok.  Trying now a full algebra build.

Take care,

Tim Daly writes:

> Man, I'm impressed. I've been chasing this bug for a while with 
> no real success. I'm going to look at the same code and see what
> I can find.

\start
Date: Sat, 26 Jul 2003 12:48:08 +0200
From: David Mentre
To: list
Subject: (optimize safety) and interpsys building error

Hello Axiom's hackers,

I though it would have been a good idea to have a version of Axiom that
would have been compiled with all the bells and whistles activated, i.e.
with (declaim (optimize safety)) (see patch below).  Well, it is not as
easy as I first thought.

When building intersys, the build fails with the following message:
  Error:  Lisps arglist maximum surpassed
  Fast links are on: do (si::use-fast-links nil) for debugging
  Error signalled by GET-NAG-CHAPTER.

Has anybody an idea why it fails with (declaim (optimize safety)) and
not with the usual build (safety 0)?

Best regards,
d.

--- axiom-cvs-2003-06-25/new/new/src/boot/Makefile.pamphlet	Wed May  7 21:28:56 2003
+++ axiom-cvs-2003-06-25-dm/new/new/src/boot/Makefile.pamphlet	Fri Jul 25 21:35:58 2003
@@ -1095,13 +1095,13 @@
 the final {\bf SAVESYS} image. This S-expression will be given to
 a clean lisp image, loaded with the compiled files, and saved.
  
-Note that the \' symbol should not appear in this S-expression
+Note that the ' symbol should not appear in this S-expression
 because the {\bf CMD0} command will be expanded into a shell
 echo command and it will be surrounded by single quotes at the
 expansion. Adding a single quote symbol will break this expansion.
 
 <<environment>>= 
-CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
+CMD0=	(progn (declaim (optimize safety)) (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
  
 @
 \subsection{boothdr.lisp \cite{1}}
@@ -1110,7 +1110,7 @@
 ${OUT}/boothdr.${O}: ${MID}/boothdr.lisp
 	@ echo 1 making ${OUT}/boothdr.${O} from ${MID}/boothdr.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn  (compile-file "boothdr.lisp" :output-file "${OUT}/boothdr.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) (compile-file "boothdr.lisp" :output-file "${OUT}/boothdr.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1144,7 +1144,7 @@
 ${OUT}/btincl2.${O}: ${MID}/btincl2.lisp
 	@ echo 4 making ${OUT}/btincl2.${O} from ${MID}/btincl2.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn ${DEPS} (compile-file "btincl2.lisp" :output-file "${OUT}/btincl2.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) ${DEPS} (compile-file "btincl2.lisp" :output-file "${OUT}/btincl2.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1172,7 +1172,7 @@
 btincl2.boot: btincl2.boot.pamphlet
 	@echo 7 making btincl2.boot from btincl2.boot.pamphlet
 	@( ${SPADBIN}/notangle btincl2.boot.pamphlet >btincl2.boot ; \
-	echo '(progn (boottran::boottocl "btincl2.boot") (${BYE}))' | ${BOOTSYS} )
+	echo '(progn (declaim (optimize safety)) (boottran::boottocl "btincl2.boot") (${BYE}))' | ${BOOTSYS} )
 
 @
 
@@ -1187,7 +1187,7 @@
 ${OUT}/btpile2.${O}: ${MID}/btpile2.lisp
 	@ echo 8 making ${OUT}/btpile2.${O} from ${MID}/btpile2.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn ${DEPS} (compile-file "btpile2.lisp" :output-file "${OUT}/btpile2.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) ${DEPS} (compile-file "btpile2.lisp" :output-file "${OUT}/btpile2.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1215,7 +1215,7 @@
 btpile2.boot: btpile2.boot.pamphlet
 	@echo 11 making btpile2.boot from btpile2.boot.pamphlet
 	@( ${SPADBIN}/notangle btpile2.boot.pamphlet >btpile2.boot ; \
-	echo '(progn (boottran::boottocl "btpile2.boot") (${BYE}))' | ${BOOTSYS} )
+	echo '(progn (declaim (optimize safety)) (boottran::boottocl "btpile2.boot") (${BYE}))' | ${BOOTSYS} )
 
 @
 
@@ -1230,7 +1230,7 @@
 ${OUT}/btscan2.${O}: ${MID}/btscan2.lisp
 	@ echo 12 making ${OUT}/btscan2.${O} from ${MID}/btscan2.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn ${DEPS} (compile-file "btscan2.lisp" :output-file "${OUT}/btscan2.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) ${DEPS} (compile-file "btscan2.lisp" :output-file "${OUT}/btscan2.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1258,7 +1258,7 @@
 btscan2.boot: btscan2.boot.pamphlet
 	@echo 15 making btscan2.boot from btscan2.boot.pamphlet
 	@( ${SPADBIN}/notangle btscan2.boot.pamphlet >btscan2.boot ; \
-	echo '(progn (boottran::boottocl "btscan2.boot") (${BYE}))' | ${BOOTSYS} )
+	echo '(progn (declaim (optimize safety)) (boottran::boottocl "btscan2.boot") (${BYE}))' | ${BOOTSYS} )
 
 @
 
@@ -1268,7 +1268,7 @@
 ${OUT}/exports.${O}: ${MID}/exports.lisp
 	@ echo 16 making ${OUT}/exports.${O} from ${MID}/exports.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn  (compile-file "exports.lisp" :output-file "${OUT}/exports.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety))  (compile-file "exports.lisp" :output-file "${OUT}/exports.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1298,7 +1298,7 @@
 ${OUT}/npextras.${O}: ${MID}/npextras.lisp
 	@ echo 19 making ${OUT}/npextras.${O} from ${MID}/npextras.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn  (compile-file "npextras.lisp" :output-file "${OUT}/npextras.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety))  (compile-file "npextras.lisp" :output-file "${OUT}/npextras.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1333,7 +1333,7 @@
 ${OUT}/ptyout.${O}: ${MID}/ptyout.lisp
 	@ echo 22 making ${OUT}/ptyout.${O} from ${MID}/ptyout.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn ${DEPS} (compile-file "ptyout.lisp" :output-file "${OUT}/ptyout.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) ${DEPS} (compile-file "ptyout.lisp" :output-file "${OUT}/ptyout.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1360,7 +1360,7 @@
 ptyout.boot: ptyout.boot.pamphlet
 	@echo 25 making ptyout.boot from ptyout.boot.pamphlet
 	@( ${SPADBIN}/notangle ptyout.boot.pamphlet >ptyout.boot ; \
-	   echo '(progn (boottran::boottocl "ptyout.boot") (${BYE}))' | ${BOOTSYS} )
+	   echo '(progn (declaim (optimize safety)) (boottran::boottocl "ptyout.boot") (${BYE}))' | ${BOOTSYS} )
 
 @
 
@@ -1375,7 +1375,7 @@
 ${OUT}/tyextra.${O}: ${MID}/tyextra.lisp
 	@ echo 26 making ${OUT}/tyextra.${O} from ${MID}/tyextra.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn ${DEPS} (compile-file "tyextra.lisp" :output-file "${OUT}/tyextra.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) ${DEPS} (compile-file "tyextra.lisp" :output-file "${OUT}/tyextra.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1403,7 +1403,7 @@
 tyextra.boot: tyextra.boot.pamphlet
 	@echo 29 making tyextra.boot from tyextra.boot.pamphlet
 	@( ${SPADBIN}/notangle tyextra.boot.pamphlet >tyextra.boot ; \
-	echo '(progn (boottran::boottocl "tyextra.boot") (${BYE}))' | ${BOOTSYS} )
+	echo '(progn (declaim (optimize safety)) (boottran::boottocl "tyextra.boot") (${BYE}))' | ${BOOTSYS} )
 
 @
 
@@ -1418,7 +1418,7 @@
 ${OUT}/typars.${O}: ${MID}/typars.lisp
 	@ echo 30 making ${OUT}/typars.${O} from ${MID}/typars.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn ${DEPS} (compile-file "typars.lisp" :output-file "${OUT}/typars.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) ${DEPS} (compile-file "typars.lisp" :output-file "${OUT}/typars.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1445,7 +1445,7 @@
 typars.boot: typars.boot.pamphlet
 	@echo 33 making typars.boot from typars.boot.pamphlet
 	@( ${SPADBIN}/notangle typars.lisp.pamphlet >typars.boot ; \
-	echo '(progn (boottran::boottocl "typars.boot") (${BYE}))' | ${BOOTSYS} )
+	echo '(progn (declaim (optimize safety)) (boottran::boottocl "typars.boot") (${BYE}))' | ${BOOTSYS} )
 
 @
 
@@ -1460,7 +1460,7 @@
 ${OUT}/typrops.${O}: ${MID}/typrops.lisp
 	@ echo 34 making ${OUT}/typrops.${O} from ${MID}/typrops.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn ${DEPS} (compile-file "typrops.lisp" :output-file "${OUT}/typrops.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) ${DEPS} (compile-file "typrops.lisp" :output-file "${OUT}/typrops.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1488,7 +1488,7 @@
 typrops.boot: typrops.boot.pamphlet
 	@echo 37 making typrops.boot from typrops.boot.pamphlet
 	@( ${SPADBIN}/notangle  typrops.boot.pamphlet >typrops.boot ; \
-	echo '(progn (boottran::boottocl "typrops.boot") (${BYE}))' | ${BOOTSYS} )
+	echo '(progn (declaim (optimize safety)) (boottran::boottocl "typrops.boot") (${BYE}))' | ${BOOTSYS} )
 
 @
 
@@ -1503,7 +1503,7 @@
 ${OUT}/tytree1.${O}: ${MID}/tytree1.lisp
 	@ echo 38 making ${OUT}/tytree1.${O} from ${MID}/tytree1.lisp
 	@ ( cd ${MID} ; \
-	   echo '(progn ${DEPS} (compile-file "tytree1.lisp" :output-file "${OUT}/tytree1.${O}") (${BYE}))' | ${LISPSYS}  )
+	   echo '(progn (declaim (optimize safety)) ${DEPS} (compile-file "tytree1.lisp" :output-file "${OUT}/tytree1.${O}") (${BYE}))' | ${LISPSYS}  )
  
 @
 
@@ -1531,7 +1531,7 @@
 tytree1.boot: tytree1.boot.pamphlet
 	@echo 41 making tytree1.boot from tytree1.boot.pamphlet
 	@( ${SPADBIN}/notangle tytree1.boot.pamphlet >tytree1.boot ; \
-	echo '(progn (boottran::boottocl "tytree1.boot") (${BYE}))' | ${BOOTSYS} )
+	echo '(progn (declaim (optimize safety)) (boottran::boottocl "tytree1.boot") (${BYE}))' | ${BOOTSYS} )
 
 @
 \section{Making the documentation}
--- axiom-cvs-2003-06-25/new/new/src/interp/Makefile.pamphlet	Sat Jun 28 00:27:27 2003
+++ axiom-cvs-2003-06-25-dm/new/new/src/interp/Makefile.pamphlet	Sat Jul 26 12:12:49 2003
@@ -517,6 +517,7 @@
 	        ${OUT}/slam.${LISP} ${LOADSYS}
 	@ echo 3 making ${DEPSYS} 
 	@ echo '(load "${OUT}/sys-pkg")' > ${OUT}/makedep.lisp
+	@ echo '(declaim (optimize safety))' >> ${OUT}/makedep.lisp
 	@ echo '(push :oldboot *features*)' >>${OUT}/makedep.lisp
 	@ echo '(load "${OUT}/nocompil")' >> ${OUT}/makedep.lisp
 	@ echo '(load "${OUT}/util")' >> ${OUT}/makedep.lisp
@@ -590,6 +591,7 @@
 	@ cp -p ${SRC}/doc/msgs/s2-us.msgs ${SPAD}/doc/msgs
 #	@ cp -p ${SRC}/doc/msgs/co-eng.msgs ${SPAD}/doc/msgs
 	@ echo '(load "${OUT}/sys-pkg")' > ${OUT}/makeint.lisp
+	@ echo '(declaim (optimize safety))' >> ${OUT}/makeint.lisp
 	@ echo '(load "${OUT}/nocompil")' >> ${OUT}/makeint.lisp
 	@ echo '(load "${OUT}/util")' >> ${OUT}/makeint.lisp
 	@ echo '(in-package "BOOT")' >> ${OUT}/makeint.lisp
@@ -621,7 +623,7 @@
 ${DEBUGSYS}: ${MID}/debugsys.lisp
 	@ echo 7 building debugsys
 	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${MID}/debugsys.lisp") (user::spad-save "${DEBUGSYS}"))' | ${LISPSYS} )
+	  echo '(progn  (declaim (optimize safety)) (gbc t) (load "${MID}/debugsys.lisp") (user::spad-save "${DEBUGSYS}"))' | ${LISPSYS} )
 	@ echo 8 ${DEBUGSYS} created
 
 @
@@ -6279,7 +6281,7 @@
 
 ${MNT}/${SYS}/algebra/exposed.${O} : ${MID}/exposed.lsp ${LISPSYS}
 	@ echo 616 making ${MNT}/${SYS}/algebra/exposed.${O} from ${MID}/exposed.lsp
-	@ echo '(progn  (compile-file "${MID}/exposed.lsp" :output-file "${MNT}/${SYS}/algebra/exposed.${O}") (${BYE}))' | ${LISPSYS} 
+	@ echo '(progn (declaim (optimize safety)) (compile-file "${MID}/exposed.lsp" :output-file "${MNT}/${SYS}/algebra/exposed.${O}") (${BYE}))' | ${LISPSYS} 
 
 
 ${OUT}/database.date:
--- axiom-cvs-2003-06-25/new/new/src/interp/util.lisp.pamphlet	Sat Jul 12 18:43:09 2003
+++ axiom-cvs-2003-06-25-dm/new/new/src/interp/util.lisp.pamphlet	Fri Jul 25 21:18:04 2003
@@ -1106,6 +1106,7 @@
       (if (member (file-namestring lib) nooptimize :test #'string=)
        (setq compiler::*speed* 0)
        (setq compiler::*speed* 3))
+#+:akcl (declaim (optimize safety))
       (compile-lib-file dotlsp :output-file doto)))))))
 
 @

\start
Date: Sat, 26 Jul 2003 08:46:07 -0400
From: Tim Daly
To: Camm Maguire
Subject: hascategory bug

Camm,

I'm rebuilding the system now. An absolutely awesome piece of detective
work on your part. I looked at that code before but (wrongly) concluded
that it must copy so I walked right past the bug. If the algebra code
compiles this removes the biggest remaining block to building Axiom.
I still have to finish the algebra lattice but I know how to do that.

Gratefully,
Tim

\start
Date: Sat, 26 Jul 2003 09:25:29 -0400
From: Tim Daly
To: list
Subject: hascategory bug
Cc: Camm Maguire

*,

Thanks to Camm's debugging efforts the algebra file xpoly.spad
now compiles. I'll work on completing the lattice of algebra builds.
This should allow us to build Axiom from the sources in the near
future.

Tim

\start
Date: 26 Jul 2003 10:37:08 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] hascategory bug

Greetings!  No problem -- I really want GCL to be of service to axiom.

I was just thinking a bit about this.  lengthenvec appears to be only
used in this one place, so the true->false patch is fine.  But if it
were to be used elsewhere in the code with similar assumptions, it
might be better to rename it to lengthen-uniquely or some such, and
have it check if the adjusted array was copied, and return a copy-seq
if not, leaving the true flag alone.  Would eliminate a possible extra
copy too.  You doubtlessly know best.


Could someone please let me know if this also removes the 'duplicate
set' issue Juergen reported in coercls.input or some such, which I
have not yet seen here?  And, in general, whether or not all bugs
varying with the underlying lisp have been resolved?  If the answer to
this is true, would the best thing for me to work on be the GCL lisp
interface to the openmath lib?

Take care,

Tim Daly writes:

> Camm,
> 
> I'm rebuilding the system now. An absolutely awesome piece of detective
> work on your part. I looked at that code before but (wrongly) concluded
> that it must copy so I walked right past the bug. If the algebra code
> compiles this removes the biggest remaining block to building Axiom.
> I still have to finish the algebra lattice but I know how to do that.

\start
Date: Sat, 26 Jul 2003 16:49:22 +0200
From: David Mentre
To: Tim Daly
Subject: Hack to fix debugsys

Hello Tim,

Here is a quick hack that fixes the debugsys issue (debugsys that cannot
be build because the path are hard coded):

diff -u axiom-cvs-2003-06-25/new/new/src/interp/Makefile.pamphlet axiom-cvs-2003-06-25-debugsys/new/new/src/interp/Makefile.pamphlet
--- axiom-cvs-2003-06-25/new/new/src/interp/Makefile.pamphlet	Sat Jun 28 00:27:27 2003
+++ axiom-cvs-2003-06-25-debugsys/new/new/src/interp/Makefile.pamphlet	Sat Jul 26 16:35:17 2003
@@ -903,11 +903,16 @@
 are echoed into a temporary file which gets loaded into the lisp image.
 We simply captured that temporary file, replaced the .o files with .lisp
 files (or .lsp or .clisp) and saved it here.
+
+Please notice that while building {\bf debugsys.lisp}, we substitute the
+hard coded path [[/home/axiomgnu/new]] with the value of [[$SPD]]
+variable. It is a quick hack but better than nothing.
 <<debugsys.lisp (MID from IN)>>=
 ${MID}/debugsys.lisp: ${IN}/debugsys.lisp.pamphlet
 	@ echo 39 making ${MID}/debugsys.lisp from ${IN}/debugsys.lisp.pamphlet
 	@ (cd ${MID} ; \
-	   ${SPADBIN}/notangle ${IN}/debugsys.lisp.pamphlet >debugsys.lisp )
+	   ${SPADBIN}/notangle ${IN}/debugsys.lisp.pamphlet | \
+	   sed -e "s@/home/axiomgnu/new/@${SPD}/@g" > debugsys.lisp )
 
 @
 <<debugsys.lisp.dvi (DOC from IN)>>=
diff -u axiom-cvs-2003-06-25/new/new/src/interp/debugsys.lisp.pamphlet axiom-cvs-2003-06-25-debugsys/new/new/src/interp/debugsys.lisp.pamphlet
--- axiom-cvs-2003-06-25/new/new/src/interp/debugsys.lisp.pamphlet	Sat Jul 12 18:43:09 2003
+++ axiom-cvs-2003-06-25-debugsys/new/new/src/interp/debugsys.lisp.pamphlet	Sat Jul 26 16:37:17 2003
@@ -28,12 +28,9 @@
 as the only use for a debugsys image is to debug a deep system
 problem in interpsys. Thus we can assume that all of these files
 exist. Note that these files are {\bf hard coded} to assume they
-live under {\bf /home/axiomgnu/new}. You need to do a global
-search and replace if you don't place them there. We should write
-lisp code to grab the {\bf AXIOM} shell variable but since (a)
-there is hardly any reason to use this level of debugging and (b)
-if you're screwing around here you've got much harder problems
-to solve so this is not an issue.
+live under {\bf /home/axiomgnu/new}. A global search and replace is made
+by the Makefile (see Makefile.dvi in same directory) to replace this
+hard coded path with the current absolute path.
 
 For debugging purposes you can add anything to this file
 and it will show up in the debugsys image. 

\start
Date: Sat, 26 Jul 2003 17:44:09 +0200
From: David Mentre
To: list
Subject: On savannah CVS, no Makefile nor Makefile.dvi

Hello Tim,

I think that you should put on savannah CVS only .pamphlet files, except
of course top Makefile for starting the make process. All other files
(*.dvi, Makefile) should be generated by the CVS user. The rationale is
that the CVS should have only the sources.

Of course, this does not preclude us to put in source or binary
distributions (axiom.tar.gz) un-pamphleted .dvi files or Makefile.

What do you think of it?

\start
Date: 26 Jul 2003 18:13:30 +0200
From: Juergen Weiss
To: list
Subject: serveral bugs in codebase

Hi,

here is a list of bugs I found, with suggested fixes:

*** intint.lisp 2003/06/20 20:13:06     1.1
--- intint.lisp 2003/06/20 20:35:24
***************
*** 63,69 ****
  ;;   (|npProcessSynonym| str))
  
  (defun |SpadInterpretFile| (fn)
!       (|SpadInterpretStream| nil fn nil) )
  
  (defun |intNewFloat| ()
    (list '|Float|))
--- 63,69 ----
  ;;   (|npProcessSynonym| str))
  
  (defun |SpadInterpretFile| (fn)
!       (|SpadInterpretStream| 1 fn nil) )
  
  (defun |intNewFloat| ()
    (list '|Float|))


*** macros.lisp 2003/03/22 20:24:23     1.1
--- macros.lisp 2003/06/16 19:56:44
***************
*** 297,303 ****
   "Needed by spadCompileOrSetq" 1)
   
  (defun -REPEAT (BD SPL)
!   (let (u g g1 inc final xcl xv il rsl tll funPLUS funGT fun? funIdent)
      (DO ((X SPL (CDR X)))
          ((ATOM X)
           (LIST 'spadDO (NREVERSE IL) (LIST (MKPF (NREVERSE XCL) 'OR) XV)
--- 297,303 ----
   "Needed by spadCompileOrSetq" 1)
   
  (defun -REPEAT (BD SPL)
!   (let (u g g1 inc final xcl xv il rsl tll funPLUS funGT fun? funIdent funPLUSform funGTform)
      (DO ((X SPL (CDR X)))
          ((ATOM X)
           (LIST 'spadDO (NREVERSE IL) (LIST (MKPF (NREVERSE XCL) 'OR) XV)



in newaux.lisp, the binding powers of +-> should be:
         (+-\> 998 112) ; was 998 102 


the following error leads to undefined var error
if checked at runtime

*** define.boot 2003/03/22 20:24:23     1.1
--- define.boot 2003/06/21 21:16:46
***************
*** 1181,1187 ****
   
  compCapsuleItems(itemlist,$predl,$e) ==
    $TOP__LEVEL: local
!   $myFunctorBody :local := data    ---needed for translator
    $signatureOfForm: local
    $suffix: local:= 0
    for item in itemlist repeat $e:= compSingleCapsuleItem(item,$predl,$e)
--- 1172,1178 ----
   
  compCapsuleItems(itemlist,$predl,$e) ==
    $TOP__LEVEL: local
!   $myFunctorBody :local -- := data    ---needed for translator
    $signatureOfForm: local
    $suffix: local:= 0
    for item in itemlist repeat $e:= compSingleCapsuleItem(item,$predl,$e)

diff -c -r1.1 format.boot
*** format.boot 2003/03/22 20:24:23     1.1
--- format.boot 2003/06/20 23:04:52
***************
*** 703,716 ****
              if CAR next = 'dbN then dbN := CADR next
              else argL := next
              keyStuff  := IFCDR keyStuff
!             next      := IFCAR KeyStuff
          oneMsg  := returnStLFromKey(key,argL,dbN)
          allMsgs := ['" ", :NCONC (oneMsg,allMsgs)]
      allMsgs
--- 703,716 ----
              if CAR next = 'dbN then dbN := CADR next
              else argL := next
              keyStuff  := IFCDR keyStuff
!             next      := IFCAR keyStuff
          oneMsg  := returnStLFromKey(key,argL,dbN)
          allMsgs := ['" ", :NCONC (oneMsg,allMsgs)]
      allMsgs


wrong # of args
*** i-map.boot  2003/03/22 20:24:23     1.1
--- i-map.boot  2003/06/20 18:37:48
***************
*** 690,696 ****
  
    locals := SETDIFFERENCE(COPY $localVars, parms)
    if locals then
!     lets := [['LET, l, ''UNINITIALIZED__VARIABLE, op] for l in locals]
      body := ['PROGN, :lets, body]
  
    reportFunctionCompilation(op,fnName,parms,
--- 690,696 ----
  
    locals := SETDIFFERENCE(COPY $localVars, parms)
    if locals then
!     lets := [['LET, l, ''UNINITIALIZED__VARIABLE] for l in locals]
      body := ['PROGN, :lets, body]



I'm not really sure if this change is correct,
the original code for sure is incorrect.

*** i-spec1.boot        2003/03/22 20:24:23     1.1
--- i-spec1.boot        2003/06/20 21:13:15
***************
*** 897,914 ****
    -- for one index variable case for now.  may generalize later
    for iter in itrl repeat
      iter is ['WHILE,pred] =>
!       predVec := mkIterZippedFun($indexList,pred,zipType,$localVars)
        s := [mkAtreeNode 'swhile,predVec,s]
      iter is ['UNTIL,pred] =>
!       predVec := mkIterZippedFun($indexList,pred,zipType,$localVars)
        s := [mkAtreeNode 'suntil,predVec,s]
      iter is ['SUCHTHAT,pred] =>
        putTarget(pred,$Boolean)
!       predVec := mkIterZippedFun($indexList,pred,zipType,$localVars)
        s := [mkAtreeNode 'select,predVec,s]
    s
  
! mkIterZippedFun(indexList,funBody,zipType,$localVars) ==
    -- transform funBody into a lamda with $index as the parameter
    numVars:= #$indexVars
    for [var,:.] in $indexVars repeat
--- 897,914 ----
    -- for one index variable case for now.  may generalize later
    for iter in itrl repeat
      iter is ['WHILE,pred] =>
!       predVec := mkIterZippedFun($indexVars,pred,zipType,$localVars)
        s := [mkAtreeNode 'swhile,predVec,s]
      iter is ['UNTIL,pred] =>
!       predVec := mkIterZippedFun($indexVars,pred,zipType,$localVars)
        s := [mkAtreeNode 'suntil,predVec,s]
      iter is ['SUCHTHAT,pred] =>
        putTarget(pred,$Boolean)
!       predVec := mkIterZippedFun($indexVars,pred,zipType,$localVars)
        s := [mkAtreeNode 'select,predVec,s]
    s
  
! mkIterZippedFun($indexVars,funBody,zipType,$localVars) ==
    -- transform funBody into a lamda with $index as the parameter
    numVars:= #$indexVars
    for [var,:.] in $indexVars repeat

wrong # of args
*** i-spec2.boot        2003/03/22 20:24:23     1.1
--- i-spec2.boot        2003/06/20 18:46:33
***************
*** 550,556 ****
              compFailure ['"   The type of the local variable",
                :bright name,'"has changed in the computation."]
          if dm and isSubDomain(dm,om) then put(name,'mode,om,$env)
!         ['LET,name,objVal value,$mapName]
                 -- $mapName is set in analyzeMap
        om := objMode value
        dm := get(name, 'mode, $env) or objMode(get(name, 'value, $e))
--- 550,556 ----
              compFailure ['"   The type of the local variable",
                :bright name,'"has changed in the computation."]
          if dm and isSubDomain(dm,om) then put(name,'mode,om,$env)
!         ['LET,name,objVal value]
                 -- $mapName is set in analyzeMap
        om := objMode value
        dm := get(name, 'mode, $env) or objMode(get(name, 'value, $e))



avoid infinite loop, if autoload fails

*** lisplib.boot        2003/03/22 20:24:23     1.1
--- lisplib.boot        2003/06/29 17:10:24
***************
*** 216,222 ****
      SETF(SYMBOL_-FUNCTION cnam,mkAutoLoad(fn, cnam))
   
  autoLoad(abb,cname) ==
!   if not GET(cname,'LOADED) then loadLib cname
    SYMBOL_-FUNCTION cname
   
  setAutoLoadProperty(name) ==
--- 216,224 ----
      SETF(SYMBOL_-FUNCTION cnam,mkAutoLoad(fn, cnam))
   
  autoLoad(abb,cname) ==
!   if not GET(cname,'LOADED) then
!       FMAKUNBOUND cname
!       loadLib cname
    SYMBOL_-FUNCTION cname
   
  setAutoLoadProperty(name) ==


*** msg.boot    2003/06/20 20:13:07     1.1
--- msg.boot    2003/07/09 20:59:59
***************
*** 379,388 ****
  -------------------
  --%   a-list stuff
  desiredMsg (erMsgKey,:optCatFlag) ==
!     isKeyQualityP(erMsgKey,'show)   => TRUE
!     isKeyQualityP(erMsgKey,'stifle) => NIL
      not null optCatFlag  => CAR optCatFlag
!     TRUE
   
  isKeyQualityP (key,qual)  ==
      --returns pair if found, else NIL
--- 379,388 ----
  -------------------
  --%   a-list stuff
  desiredMsg (erMsgKey,:optCatFlag) ==
!     isKeyQualityP(erMsgKey,'show)   => true
!     isKeyQualityP(erMsgKey,'stifle) => false
      not null optCatFlag  => CAR optCatFlag
!     true
   
  isKeyQualityP (key,qual)  ==
      --returns pair if found, else NIL


\start
Date: Sat, 26 Jul 2003 19:55:24 +0200
From: David Mentre
To: Tim Daly
Subject: About noweb and cross-referencing

Hello Tim,

I told you once that noweb had some cross-referencing facilities, that
would help navigate within a pamphlet. I have dug into the manual and I
can can give now further information.

The main trick is to use the hyperref LaTeX package and the -index
option of noweave.

Suppose we have a simple pamphlet:
--doc start--
\documentclass{article}
\usepackage{hyperref}
\usepackage{noweb}

\begin{document}

An explanation.

<<with a piece of code>>=
int f(int a) {
  return 0;
}

@ 

The main program.

<<the main>>=
<<with a piece of code>>
void main(void) {
  f();
}

@

\end{document}
--doc end--

Using option -index (or -x) option when weaving:
  noweave -index -delay demo.c.nw > demo.tex
  latex demo.tex
  latex demo.tex
  xdvi demo.dvi &

It produces a document with cross-referencing between code chunks.

Moreover, noweb, if compiled with Icon support (so not for noweb
included in Axiom but for a noweb included in a linux distribution like
Debian), has certain facilities to analyse source code and find
identifiers.

For example, doing:
  noweave -autodefs c -index -delay demo.c.nw > demo.tex
  pdflatex demo.tex
  pdflatex demo.tex
  xpdf demo.pdf

shows a PDF file with complete cross-referencing.

Cross-referencing also works for HTML output (see noweave option
-html). 

I know it is also possible to build a index of all symbol definitions at
the end of the document, however I can't remember the LaTeX command
right now. Let me know if you need it.
 
\start
Date: Sat, 26 Jul 2003 22:32:43 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel] hascategory bug

sorry, guys. i was out for the day and just got back. rational replies
on the morrow. -- t

\start
Date: 27 Jul 2003 11:41:14 -0400
From: Camm Maguire
To: Juergen Weiss
Subject: Re: serveral bugs in codebase

Greetings!  Thanks for this work!

Juergen Weiss writes:

> Hi,
> 
> here is a list of bugs I found, with suggested fixes:
> 

I ran into a few of these too.  They only appear under GCL when the
file in question is loaded from source (i.e. interpreted), or compiled
with safety turned on.  GCL has the ability to bypass these checks for
verified code for the purposes of speed, and this appears to be the
default setting in the axiom build.  I don't know if the axiom source
is setting this explicitly or not.  I'm trying a build now with the
default safety in saved_gcl turned on -- if the axiom source does not
turn it off, this should assist greatly in debugging.  Once everything
works, we should turn it off again to maximize performance. Even
debugsys appears to load compiled code, currently compiled with no
safety checks, from the autoload directory.

I'm using (proclaim '(optimize (safety 3))).  One can check the values
with (compiler::print-compiler-info).

> Hello Axiom's hackers,
> 
> I though it would have been a good idea to have a version of Axiom that
> would have been compiled with all the bells and whistles activated, i.e.
> with (declaim (optimize safety)) (see patch below).  Well, it is not as
> easy as I first thought.
> 
> When building intersys, the build fails with the following message:
>   Error:  Lisps arglist maximum surpassed
>   Fast links are on: do (si::use-fast-links nil) for debugging
>   Error signalled by GET-NAG-CHAPTER.
> 
> Has anybody an idea why it fails with (declaim (optimize safety)) and
> not with the usual build (safety 0)?

\start
Date: Sun, 27 Jul 2003 12:54:33 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: serveral bugs in codebase

In util.lisp.pamphlet you'll see that there is a function called
makelib which is used to build algebra compiles. I ran into issues
of compiler problems with AKCL on the IBM RT (basically a very, very
large hair dryer that also occasionally ran code). At the end of the
code you'll notice that Axiom sets the compiler::*speed* variable.
(check util.lisp.pamphlet line 1107).

This code is not used at the moment as it assumes you you have a
fully compiled and working algebra library which we do not have.
Remember that building Axiom traditionally required a running Axiom.

util.lisp contains several "rebuild" functions.

\start
Date: Sun, 27 Jul 2003 13:14:36 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: [Gcl-devel] hascategory bug

Camm,

Indeed, lengthenvec appears to be used in only one place. I'll put it
on the list of things to change. Currently it works so changing it is
not a high priority.

I'm now looking into the duplicate set issue.

\start
Date: Sun, 27 Jul 2003 14:39:40 -0400
From: Richard Stallman
To: Mike Dewar
Subject: Re: GCL used commercially?
Cc: Richard Fateman, Cliff Yapp, David Turner, Sam Steingold, Stavros Macrakis

    That is a very broad and misleading statement.  Many so-called "free"
    licenses, in particular the GPL, require computer users to give up their
    freedom as well.

The GPL only stops you from denying other users their freedom.
See http://www.gnu.org/philosophy/freedom-or-power.html for
more explanation.

\start
Date: Sun, 27 Jul 2003 16:12:38 -0400
From: Tim Daly
To: list
Subject: Duplicate set issue
Cc: Camm Maguire

Camm,

The duplicate set issue still occurs.

As a developer note you can see the interpreter searching for
operations by doing the following:

)lisp (setq |$monitorNewWorld| t)

The messages are terse but you can more about what the interpreter
is trying to do.

\start
Date: Sun, 27 Jul 2003 16:15:00 -0400
From: Tim Daly
To: list
Subject: Duplicate set issue
Cc: Camm Maguire

Camm,

The duplicate set issue test is:

dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
p:dom:=1
set [p,p] ==> {1,1}

  but should be
          
          ==> {1}

\start
Date: Sun, 27 Jul 2003 22:26:27 +0200
From: Juergen Weiss
To: list
Subject: RE: Duplicate set issue
Cc: Camm Maguire

Hi,

I think, the test p = 1 or one? p will be easier to track.
Sets are rather complicated objects.

> Camm,
> 
> The duplicate set issue test is:
> 
> dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> p:dom:=1
> set [p,p] ==> {1,1}
> 
>   but should be
>           
>           ==> {1}
> 

\start
Date: Sun, 27 Jul 2003 16:38:47 -0400
From: Tim Daly
To: David Mentre
Subject: Hack to fix debugsys

David,

I've generalized the file debugsys.lisp.pamphlet so it dynamically
looks up the path and constructs the files to load. I'll send it
to you shortly (once I complete a build and test it). Basically
I just defined a function at the top of the file which will look
for the value of $AXIOM and use it to find the files.

\start
Date: Sun, 27 Jul 2003 16:48:44 -0400
From: Tim Daly
To: David Mentre
Subject: Re: On savannah CVS, no Makefile nor Makefile.dvi

> I think that you should put on savannah CVS only .pamphlet files, except
> of course top Makefile for starting the make process. All other files
> (*.dvi, Makefile) should be generated by the CVS user. The rationale is
> that the CVS should have only the sources.
> 
> Of course, this does not preclude us to put in source or binary
> distributions (axiom.tar.gz) un-pamphleted .dvi files or Makefile.
> 
> What do you think of it?

I agree that all files on savannah should be either in pamphlet or 
booklet format. Binary tar files will exist (similar to the one on
the axiom.tenkan.org website) but should not be in the build tree.

The root Makefile.pamphlet will have its associated .dvi file though
as that's where the starting comments live. An argument could probably
be made for a README file-chunk in the root Makefile.pamphlet because
people expect a "README" file somewhere. 

But, yes, the intention is that there will be ONLY documented files
in the source tree. The key transition from commercial to open source
depends on the documentation and I want to make it as easy as possible
to do (and as hard as possible to ignore).

\start
Date: Sun, 27 Jul 2003 16:52:08 -0400
From: Tim Daly
To: Juergen Weiss
Subject: Re: serveral bugs in codebase

Juergen,

I see what changes you've made but I don't understand what you are
trying to do. Why are these changes being made? What is the nature
of the bug you're trying to solve?

In general, when I make a change to the sources I clip out the 
changed code and make a code chunk that explains what was wrong
with the old code and what the new code does to fix it. Since I
don't understand either about these changes I don't know what to
write. Please help.

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

here is a list of bugs I found, with suggested fixes:

*** intint.lisp 2003/06/20 20:13:06     1.1
--- intint.lisp 2003/06/20 20:35:24
***************
*** 63,69 ****
  ;;   (|npProcessSynonym| str))
  
  (defun |SpadInterpretFile| (fn)
!       (|SpadInterpretStream| nil fn nil) )
  
  (defun |intNewFloat| ()
    (list '|Float|))
--- 63,69 ----
  ;;   (|npProcessSynonym| str))
  
  (defun |SpadInterpretFile| (fn)
!       (|SpadInterpretStream| 1 fn nil) )
  
  (defun |intNewFloat| ()
    (list '|Float|))


*** macros.lisp 2003/03/22 20:24:23     1.1
--- macros.lisp 2003/06/16 19:56:44
***************
*** 297,303 ****
   "Needed by spadCompileOrSetq" 1)
   
  (defun -REPEAT (BD SPL)
!   (let (u g g1 inc final xcl xv il rsl tll funPLUS funGT fun? funIdent)
      (DO ((X SPL (CDR X)))
          ((ATOM X)
           (LIST 'spadDO (NREVERSE IL) (LIST (MKPF (NREVERSE XCL) 'OR) XV)
--- 297,303 ----
   "Needed by spadCompileOrSetq" 1)
   
  (defun -REPEAT (BD SPL)
!   (let (u g g1 inc final xcl xv il rsl tll funPLUS funGT fun? funIdent funPLUSform funGTform)
      (DO ((X SPL (CDR X)))
          ((ATOM X)
           (LIST 'spadDO (NREVERSE IL) (LIST (MKPF (NREVERSE XCL) 'OR) XV)



in newaux.lisp, the binding powers of +-> should be:
         (+-\> 998 112) ; was 998 102 


the following error leads to undefined var error
if checked at runtime

*** define.boot 2003/03/22 20:24:23     1.1
--- define.boot 2003/06/21 21:16:46
***************
*** 1181,1187 ****
   
  compCapsuleItems(itemlist,$predl,$e) ==
    $TOP__LEVEL: local
!   $myFunctorBody :local := data    ---needed for translator
    $signatureOfForm: local
    $suffix: local:= 0
    for item in itemlist repeat $e:= compSingleCapsuleItem(item,$predl,$e)
--- 1172,1178 ----
   
  compCapsuleItems(itemlist,$predl,$e) ==
    $TOP__LEVEL: local
!   $myFunctorBody :local -- := data    ---needed for translator
    $signatureOfForm: local
    $suffix: local:= 0
    for item in itemlist repeat $e:= compSingleCapsuleItem(item,$predl,$e)

diff -c -r1.1 format.boot
*** format.boot 2003/03/22 20:24:23     1.1
--- format.boot 2003/06/20 23:04:52
***************
*** 703,716 ****
              if CAR next = 'dbN then dbN := CADR next
              else argL := next
              keyStuff  := IFCDR keyStuff
!             next      := IFCAR KeyStuff
          oneMsg  := returnStLFromKey(key,argL,dbN)
          allMsgs := ['" ", :NCONC (oneMsg,allMsgs)]
      allMsgs
--- 703,716 ----
              if CAR next = 'dbN then dbN := CADR next
              else argL := next
              keyStuff  := IFCDR keyStuff
!             next      := IFCAR keyStuff
          oneMsg  := returnStLFromKey(key,argL,dbN)
          allMsgs := ['" ", :NCONC (oneMsg,allMsgs)]
      allMsgs


wrong # of args
*** i-map.boot  2003/03/22 20:24:23     1.1
--- i-map.boot  2003/06/20 18:37:48
***************
*** 690,696 ****
  
    locals := SETDIFFERENCE(COPY $localVars, parms)
    if locals then
!     lets := [['LET, l, ''UNINITIALIZED__VARIABLE, op] for l in locals]
      body := ['PROGN, :lets, body]
  
    reportFunctionCompilation(op,fnName,parms,
--- 690,696 ----
  
    locals := SETDIFFERENCE(COPY $localVars, parms)
    if locals then
!     lets := [['LET, l, ''UNINITIALIZED__VARIABLE] for l in locals]
      body := ['PROGN, :lets, body]



I'm not really sure if this change is correct,
the original code for sure is incorrect.

*** i-spec1.boot        2003/03/22 20:24:23     1.1
--- i-spec1.boot        2003/06/20 21:13:15
***************
*** 897,914 ****
    -- for one index variable case for now.  may generalize later
    for iter in itrl repeat
      iter is ['WHILE,pred] =>
!       predVec := mkIterZippedFun($indexList,pred,zipType,$localVars)
        s := [mkAtreeNode 'swhile,predVec,s]
      iter is ['UNTIL,pred] =>
!       predVec := mkIterZippedFun($indexList,pred,zipType,$localVars)
        s := [mkAtreeNode 'suntil,predVec,s]
      iter is ['SUCHTHAT,pred] =>
        putTarget(pred,$Boolean)
!       predVec := mkIterZippedFun($indexList,pred,zipType,$localVars)
        s := [mkAtreeNode 'select,predVec,s]
    s
  
! mkIterZippedFun(indexList,funBody,zipType,$localVars) ==
    -- transform funBody into a lamda with $index as the parameter
    numVars:= #$indexVars
    for [var,:.] in $indexVars repeat
--- 897,914 ----
    -- for one index variable case for now.  may generalize later
    for iter in itrl repeat
      iter is ['WHILE,pred] =>
!       predVec := mkIterZippedFun($indexVars,pred,zipType,$localVars)
        s := [mkAtreeNode 'swhile,predVec,s]
      iter is ['UNTIL,pred] =>
!       predVec := mkIterZippedFun($indexVars,pred,zipType,$localVars)
        s := [mkAtreeNode 'suntil,predVec,s]
      iter is ['SUCHTHAT,pred] =>
        putTarget(pred,$Boolean)
!       predVec := mkIterZippedFun($indexVars,pred,zipType,$localVars)
        s := [mkAtreeNode 'select,predVec,s]
    s
  
! mkIterZippedFun($indexVars,funBody,zipType,$localVars) ==
    -- transform funBody into a lamda with $index as the parameter
    numVars:= #$indexVars
    for [var,:.] in $indexVars repeat

wrong # of args
*** i-spec2.boot        2003/03/22 20:24:23     1.1
--- i-spec2.boot        2003/06/20 18:46:33
***************
*** 550,556 ****
              compFailure ['"   The type of the local variable",
                :bright name,'"has changed in the computation."]
          if dm and isSubDomain(dm,om) then put(name,'mode,om,$env)
!         ['LET,name,objVal value,$mapName]
                 -- $mapName is set in analyzeMap
        om := objMode value
        dm := get(name, 'mode, $env) or objMode(get(name, 'value, $e))
--- 550,556 ----
              compFailure ['"   The type of the local variable",
                :bright name,'"has changed in the computation."]
          if dm and isSubDomain(dm,om) then put(name,'mode,om,$env)
!         ['LET,name,objVal value]
                 -- $mapName is set in analyzeMap
        om := objMode value
        dm := get(name, 'mode, $env) or objMode(get(name, 'value, $e))



avoid infinite loop, if autoload fails

*** lisplib.boot        2003/03/22 20:24:23     1.1
--- lisplib.boot        2003/06/29 17:10:24
***************
*** 216,222 ****
      SETF(SYMBOL_-FUNCTION cnam,mkAutoLoad(fn, cnam))
   
  autoLoad(abb,cname) ==
!   if not GET(cname,'LOADED) then loadLib cname
    SYMBOL_-FUNCTION cname
   
  setAutoLoadProperty(name) ==
--- 216,224 ----
      SETF(SYMBOL_-FUNCTION cnam,mkAutoLoad(fn, cnam))
   
  autoLoad(abb,cname) ==
!   if not GET(cname,'LOADED) then
!       FMAKUNBOUND cname
!       loadLib cname
    SYMBOL_-FUNCTION cname
   
  setAutoLoadProperty(name) ==


*** msg.boot    2003/06/20 20:13:07     1.1
--- msg.boot    2003/07/09 20:59:59
***************
*** 379,388 ****
  -------------------
  --%   a-list stuff
  desiredMsg (erMsgKey,:optCatFlag) ==
!     isKeyQualityP(erMsgKey,'show)   => TRUE
!     isKeyQualityP(erMsgKey,'stifle) => NIL
      not null optCatFlag  => CAR optCatFlag
!     TRUE
   
  isKeyQualityP (key,qual)  ==
      --returns pair if found, else NIL
--- 379,388 ----
  -------------------
  --%   a-list stuff
  desiredMsg (erMsgKey,:optCatFlag) ==
!     isKeyQualityP(erMsgKey,'show)   => true
!     isKeyQualityP(erMsgKey,'stifle) => false
      not null optCatFlag  => CAR optCatFlag
!     true
   
  isKeyQualityP (key,qual)  ==
      --returns pair if found, else NIL


\start
Date: Sun, 27 Jul 2003 16:56:48 -0400
From: Tim Daly
To: David Mentre
Subject: Re: About noweb and cross-referencing

David,

I've found the latex method of creating cross-references. 
I've added it to the CATS documentation. I haven't yet
tried to add it to the regular pamphlet files. The latex 
mechanism involves running makeindex, latexing the resulting
file  and then doing
\include{foo.ind}

I've also taken your suggestion about a converged .bib file
for Axiom. I used it for the CATS documentation and will
eventually expand it to be used by the document command.

\start
Date: Sun, 27 Jul 2003 16:59:01 -0400
From: Tim Daly
To: Juergen Weiss
Subject: serveral bugs in codebase
Cc: Camm Maguire

Juergen,

The safety 3 idea is a good one. I'll look further into how Axiom
manipulates that. It should help up clean up the code quite a bit.

\start
Date: Sun, 27 Jul 2003 17:27:52 -0400
From: Tim Daly
To: list
Subject: diffing pamphlet files

*,

In general, it would be useful (but not required) if everyone modified
the pamphlet files and used the following switches on diff:

diff -Naur old new

The diff flags give a standard format for patch files so I can
apply them easily.

\start
Date: 27 Jul 2003 21:44:13 -0400
From: Camm Maguire
To: list
Subject: Re: serveral bugs in codebase

Hi Tim!  Are you perhaps referring to the email on this issue I sent
earlier?

In any case, I've made some progress here (compiling with safety 3).
Two issues:

1) There is still some large call to (apply #'append ....) somewhere
   that is exceeding the 63 maximum argument limit david noted
   earlier.  Just experimenting, axiom appears to need more than twice
   this value, but 4x appears to work.  The portable way to fix this
   is just to write out the large switch statement in c_apply_n in
   eval.c.  

   Until I make up my mind on the best thing to do here, you can
   'play' if you like with what I'm running at the moment.  3 of the
   11 Debian platforms support the cdecl calling convention, which
   allows for generic unlimited argument passing.  This won't work on
   the others, but maybe there is an answer there too.  Sure is better
   than the enormous switch statement.  Here is a patch which will
   allow unlimited argument passing in c_apply_n, and 4x space in
   apply (this latter can easily be made unlimited too.):

--- ../../../../../../../gcl-2.5.4/o/funlink.c	Sat Mar  1 17:37:37 2003
+++ funlink.c	Sun Jul 27 20:13:39 2003
@@ -243,9 +243,19 @@
 #define LCAST(a) (*a)
 /*  #endif */
 
+#define ELLIPTIC_CALL
+
 object
 c_apply_n(object (*fn)(), int n, object *x)
 {object res=Cnil;
+#ifdef ELLIPTIC_CALL
+ object *stack;
+
+ if (!(stack=alloca(n*sizeof(*stack))))
+   FEerror("Cannot alloca stack for elliptic call", 0);
+ memcpy(stack,x,n*sizeof(*stack));
+ res=fn();
+#else
  switch(n){
     case 0:  res=LCAST(fn)();break;
     case 1:  res=LCAST(fn)(x[0]);break;
@@ -566,6 +576,7 @@
          x[57],x[58],x[59],x[60],x[61],x[62],x[63]);break;
   default: FEerror("Exceeded call-arguments-limit ",0);
   } 
+#endif
 
  return res;
 }
--- ../../../../../../../gcl-2.5.4/o/eval.c	Fri Feb 14 19:38:28 2003
+++ eval.c	Sun Jul 27 20:13:51 2003
@@ -1147,7 +1147,7 @@
        ,2,MAX_ARGS,NONE,OO,OO,OO,OO,void,Lapply,(object fun,...),"")
 {	int m,n=VFUN_NARGS;
 	object list;
-	object buf[MAX_ARGS];
+	object buf[4*MAX_ARGS];
 	object *base=buf;
 	va_list ap;
 	va_start(ap,fun);
@@ -1159,7 +1159,7 @@
 	list = va_arg(ap,object);
 	va_end(ap);
 	while (!endp(list))
-	  { if (m >= MAX_ARGS) FEerror(" Lisps arglist maximum surpassed",0);
+	  { if (m >= 4*MAX_ARGS) FEerror(" Lisps arglist maximum surpassed",0);
 	    *base++ = Mcar(list);
 	    list = Mcdr(list);
 	    m++;}


2) |data| is unbound in compCapsuleItems in define.boot.pamphlet.  I'm
         assuming Juergen is right here and you need

--- ../../../../../axiom2/new/new/src/interp/define.boot.pamphlet	Sat Dec 21 17:14:36 2002
+++ define.boot.pamphlet	Sun Jul 27 20:23:03 2003
@@ -1193,7 +1193,7 @@
  
 compCapsuleItems(itemlist,$predl,$e) ==
   $TOP__LEVEL: local
-  $myFunctorBody :local := data    ---needed for translator
+  $myFunctorBody :local -- := data    ---needed for translator
   $signatureOfForm: local
   $suffix: local:= 0
   for item in itemlist repeat $e:= compSingleCapsuleItem(item,$predl,$e)

3) Is the 'set' command you supplied supposed to be invoked in
   interpsys?  What is the exact simpler 'one?' command referred to by
   Juergen?

Tim Daly writes:

> Juergen,
> 
> The safety 3 idea is a good one. I'll look further into how Axiom
> manipulates that. It should help up clean up the code quite a bit.

\start
Date: Sun, 27 Jul 2003 22:44:10 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: serveral bugs in codebase

Camm,

The duplicate set issue test is:

dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
p:dom:=1
set [p,p] ==> {1,1}

  but should be
          
          ==> {1}

the other test is:

  one? p  ==> false

but should be
       
          ==> true

As mentioned in a previous email Axiom stores its variable bindings
in a "frame" which, internally is an alist stored in the variable
|$InteractiveFrame|

If you create the 'dom' variable above you can see it by doing:

)lisp (pprint |$InteractiveFrame|)


btw, you can type

)lisp (setq $DALYMODE t)

and then any line that begins with an open-paren at the Axiom
prompt will be given directly to the lisp. e.g. after setting
$dalymode above you can type:

(pprint |$InteractiveFrame|)

directly to the Axiom prompt. It makes lisp debugging easier.

\start
Date: 28 Jul 2003 10:09:28 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] Re: serveral bugs in codebase

Greetings!  OK as a first disclaimer, I am currently working in a tree
compiled with safety 3.  I had to make the unlimited argument changes
in GCL as earlier posted, and to remove the reference to as yet
uninitialized |data| in define.boot.pamphlet.

I get an interpsys, and try to execute the commands below.  First,
|output| is unbound in i-toplevel recordAndPrint.  So I substitute
with format in the .clisp.  Then when trying p:dom:=1, it tries to
load PF.o, which I don't have.  I did a full check out last week, and
there is no PF.???  file anywhere.  So I grab PF.spad from Juergen's
tree and compile it.  It needs FAXF.o, which also doesn't exist.  My
original 'make' appeared to work without problems, but I appear to
only have a partial algebra build.

Awaiting advice...

Take care,

Tim Daly writes:

> Camm,
> 
> The duplicate set issue test is:
> 
> dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> p:dom:=1
> set [p,p] ==> {1,1}
> 
>   but should be
>           
>           ==> {1}
> 
> the other test is:
> 
>   one? p  ==> false
> 
> but should be
>        
>           ==> true
> 
> As mentioned in a previous email Axiom stores its variable bindings
> in a "frame" which, internally is an alist stored in the variable
> |$InteractiveFrame|
> 
> If you create the 'dom' variable above you can see it by doing:
> 
> )lisp (pprint |$InteractiveFrame|)
> 
> 
> btw, you can type
> 
> )lisp (setq $DALYMODE t)
> 
> and then any line that begins with an open-paren at the Axiom
> prompt will be given directly to the lisp. e.g. after setting
> $dalymode above you can type:
> 
> (pprint |$InteractiveFrame|)
> 
> directly to the Axiom prompt. It makes lisp debugging easier.

\start
Date: Mon, 28 Jul 2003 16:36:40 +0200
From: Juergen Weiss
To: Camm Maguire
Subject: RE: [Gcl-devel] Re: serveral bugs in codebase

Hi 

the original algebra files are in the algebra directory.
Their name consists of lowercase letters with .spad(.pamphlet)
extension. In most of the algebra files are serveral
modules (categories, domains, packages). Each has a long
name (usually starting with an uppercase letter followed
by lowercase (and uppercase) letters) and an abbreviation
(defined with the )abbr command) consisting of uppercase
letters only. This name is used as the name for the
compiled module. Tim arranged things in the makefile,
so that the original algebra files are split up
in files containing only one module with allcaps filenames.

> 
> Greetings!  OK as a first disclaimer, I am currently working in a tree
> compiled with safety 3.  I had to make the unlimited argument changes
> in GCL as earlier posted, and to remove the reference to as yet
> uninitialized |data| in define.boot.pamphlet.
> 
> I get an interpsys, and try to execute the commands below.  First,
> |output| is unbound in i-toplevel recordAndPrint.  So I substitute
> with format in the .clisp.  Then when trying p:dom:=1, it tries to
> load PF.o, which I don't have.  I did a full check out last week, and
> there is no PF.???  file anywhere.  So I grab PF.spad from Juergen's
> tree and compile it.  It needs FAXF.o, which also doesn't exist.  My
> original 'make' appeared to work without problems, but I appear to
> only have a partial algebra build.
> 
> Awaiting advice...
> 
> Take care,
> 
> Tim Daly writes:
> 
> > Camm,
> > 
> > The duplicate set issue test is:
> > 
> > dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> > p:dom:=1
> > set [p,p] ==> {1,1}
> > 
> >   but should be
> >           
> >           ==> {1}
> > 
> > the other test is:
> > 
> >   one? p  ==> false
> > 
> > but should be
> >        
> >           ==> true
> > 
> > As mentioned in a previous email Axiom stores its variable bindings
> > in a "frame" which, internally is an alist stored in the variable
> > |$InteractiveFrame|
> > 
> > If you create the 'dom' variable above you can see it by doing:
> > 
> > )lisp (pprint |$InteractiveFrame|)
> > 
> > 
> > btw, you can type
> > 
> > )lisp (setq $DALYMODE t)
> > 
> > and then any line that begins with an open-paren at the Axiom
> > prompt will be given directly to the lisp. e.g. after setting
> > $dalymode above you can type:
> > 
> > (pprint |$InteractiveFrame|)
> > 
> > directly to the Axiom prompt. It makes lisp debugging easier.

\start
Date: 28 Jul 2003 11:04:54 -0400
From: Camm Maguire
To: list
Subject: Re: [Gcl-devel] Re: serveral bugs in codebase

Hello again!

Tim Daly writes:

> Camm,
> 
> The duplicate set issue test is:
> 
> dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> p:dom:=1
> set [p,p] ==> {1,1}
> 
>   but should be
>           
>           ==> {1}
> 
> the other test is:
> 
>   one? p  ==> false
> 
> but should be
>        
>           ==> true
> 

OK, I think this has to do with the |output| in recordAndPrint in
i-toplevel being unbound.  In the default non-safety compile mode,
this is not checked for.  I replaced the form

(|output| |x'| |md'|))

with 

(format t "output replace ~S ~S ~%" |x'| |md'|))

in i-toplevel.clisp, managed to compile the needed algebra files from
Juergen's tree by hand, and then get what I think is the proper
behavior, with reformatted output of course:

=============================================================================
(1) -> dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)

output replace (|MonoidRing| (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|))) (|Domain|) 
                                                                 Type: Domain
(2) -> p:dom:=1
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PF.o for 
      domain PrimeField 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PRIMES.o 
      for package IntegerPrimesPackage 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SET.o for
      domain Set 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/POLY.o 
      for domain Polynomial 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ALIST.o 
      for domain AssociationList 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PERM.o 
      for domain Permutation 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/MRING.o 
      for domain MonoidRing 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SMP.o for
      domain SparseMultivariatePolynomial 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SUP.o for
      domain SparseUnivariatePolynomial 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SAOS.o 
      for domain SingletonAsOrderedSet 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/UPMP.o 
      for package UnivariatePolynomialMultiplicationPackage 
   Loading /fix/t1/camm/axiom/axiom/new/new/int/algebra/IPF.NRLIB/code 
      for domain InnerPrimeField 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/TABLE.o 
      for domain Table 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/HASHTBL.o
      for domain HashTable 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/INTABL.o 
      for domain InnerTable 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ZMOD.o 
      for domain IntegerMod 

output replace (((0 . 1) . #<vector 0998e32c>)) (|MonoidRing| (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|))) 
                Type: MonoidRing(Polynomial PrimeField 5,Permutation Integer)
(3) -> set [p,p]
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/FSAGG-.o 
      for domain FiniteSetAggregate& 

output replace #<vector 09fc0efc> (|Set| (|MonoidRing| (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|)))) 
            Type: Set MonoidRing(Polynomial PrimeField 5,Permutation Integer)
(4) -> one? p

output replace T (|Boolean|) 
                                                                Type: Boolean
(5) -> 
=============================================================================

I can't yet see where |output| is supposed to be initialized.  All
occurrences I've found treat this symbol as a 'let-initialized'
local.  A similar situation appears to exist with the |data| variable
in define.boot.pamphlet.  Tim, what is the idea in these code
fragments?

=============================================================================
i-toplevel.boot.pamphlet
=============================================================================
--% Result Output Printing

recordAndPrint(x,md) ==
  --  Prints out the value x which is of type m, and records the changes
  --  in environment $e into $InteractiveFrame
  --  $printAnyIfTrue  is documented in setvart.boot. controlled with )se me any
  if md = '(Any) and $printAnyIfTrue  then
    md' := first  x
    x' := rest x
  else
    x' := x
    md' := md
  $outputMode: local := md   --used by DEMO BOOT
  mode:= (md=$EmptyMode => quadSch(); md)
  if (md ^= $Void) or $printVoidIfTrue then
    if null $collectOutput then TERPRI $algebraOutputStream
    if $QuietCommand = false then
      output(x',md')

      ^^^^^^  unbound function

  putHist('%,'value,objNewWrap(x,md),$e)
  if $printTimeIfTrue or $printTypeIfTrue then printTypeAndTime(x',md')
  if $printStorageIfTrue then printStorage()
  if $printStatisticsSummaryIfTrue then printStatisticsSummary()
  if FIXP $HTCompanionWindowID then mkCompanionPage md
  $mkTestFlag = true => recordAndPrintTest md
  $runTestFlag =>
    $mkTestOutputType := md
    'done
  'done

=============================================================================
define.boot.pamphlet
=============================================================================
compCapsuleItems(itemlist,$predl,$e) ==
  $TOP__LEVEL: local
  $myFunctorBody :local  := data    ---needed for translator

                            ^^^^  unbound variable
       
  $signatureOfForm: local
  $suffix: local:= 0
  for item in itemlist repeat $e:= compSingleCapsuleItem(item,$predl,$e)
  $e
 
=============================================================================

Take care,


> As mentioned in a previous email Axiom stores its variable bindings
> in a "frame" which, internally is an alist stored in the variable
> |$InteractiveFrame|
> 
> If you create the 'dom' variable above you can see it by doing:
> 
> )lisp (pprint |$InteractiveFrame|)
> 
> 
> btw, you can type
> 
> )lisp (setq $DALYMODE t)
> 
> and then any line that begins with an open-paren at the Axiom
> prompt will be given directly to the lisp. e.g. after setting
> $dalymode above you can type:
> 
> (pprint |$InteractiveFrame|)
> 
> directly to the Axiom prompt. It makes lisp debugging easier.

\start
Date: Mon, 28 Jul 2003 17:21:31 +0200
From: Juergen Weiss
To: Camm Maguire
Subject: RE: [Gcl-devel] Re: serveral bugs in codebase

Hi,

the data in compCapsuleItems is obviously wrong. $myFunctorBody
should be bound to nil. It's in my list and Tim will take care
of it. 

The function output is defined in i-output.boot and you really
need that file. So I'm a bit suprised, that the function is not
found. 


> Hello again!
> 
> Tim Daly writes:
> 
> > Camm,
> > 
> > The duplicate set issue test is:
> > 
> > dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> > p:dom:=1
> > set [p,p] ==> {1,1}
> > 
> >   but should be
> >           
> >           ==> {1}
> > 
> > the other test is:
> > 
> >   one? p  ==> false
> > 
> > but should be
> >        
> >           ==> true
> > 
> 
> OK, I think this has to do with the |output| in recordAndPrint in
> i-toplevel being unbound.  In the default non-safety compile mode,
> this is not checked for.  I replaced the form
> 
> (|output| |x'| |md'|))
> 
> with 
> 
> (format t "output replace ~S ~S ~%" |x'| |md'|))
> 
> in i-toplevel.clisp, managed to compile the needed algebra files from
> Juergen's tree by hand, and then get what I think is the proper
> behavior, with reformatted output of course:
> 
> =
==========================
==========================
============
> ===============
> (1) -> dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> 
> output replace (|MonoidRing| (|Polynomial| (|PrimeField| 5)) 
> (|Permutation| (|Integer|))) (|Domain|) 
>                                                               
>    Type: Domain
> (2) -> p:dom:=1
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PF.o for 
>       domain PrimeField 
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PRIMES.o 
>       for package IntegerPrimesPackage 
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SET.o for
>       domain Set 
>    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/POLY.o 
>       for domain Polynomial 
>    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ALIST.o 
>       for domain AssociationList 
>    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PERM.o 
>       for domain Permutation 
>    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/MRING.o 
>       for domain MonoidRing 
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SMP.o for
>       domain SparseMultivariatePolynomial 
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SUP.o for
>       domain SparseUnivariatePolynomial 
>    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SAOS.o 
>       for domain SingletonAsOrderedSet 
>    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/UPMP.o 
>       for package UnivariatePolynomialMultiplicationPackage 
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/int/algebra/IPF.NRLIB/code 
>       for domain InnerPrimeField 
>    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/TABLE.o 
>       for domain Table 
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/HASHTBL.o
>       for domain HashTable 
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/INTABL.o 
>       for domain InnerTable 
>    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ZMOD.o 
>       for domain IntegerMod 
> 
> output replace (((0 . 1) . #<vector 0998e32c>)) (|MonoidRing| 
> (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|))) 
>                 Type: MonoidRing(Polynomial PrimeField 
> 5,Permutation Integer)
> (3) -> set [p,p]
>    Loading 
> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/FSAGG-.o 
>       for domain FiniteSetAggregate& 
> 
> output replace #<vector 09fc0efc> (|Set| (|MonoidRing| 
> (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|)))) 
>             Type: Set MonoidRing(Polynomial PrimeField 
> 5,Permutation Integer)
> (4) -> one? p
> 
> output replace T (|Boolean|) 
>                                                               
>   Type: Boolean
> (5) -> 
> =
==========================
==========================
============
> ===============
> 
> I can't yet see where |output| is supposed to be initialized.  All
> occurrences I've found treat this symbol as a 'let-initialized'
> local.  A similar situation appears to exist with the |data| variable
> in define.boot.pamphlet.  Tim, what is the idea in these code
> fragments?
> 
> =
==========================
==========================
============
> ===============
> i-toplevel.boot.pamphlet
> =
==========================
==========================
============
> ===============
> --% Result Output Printing
> 
> recordAndPrint(x,md) ==
>   --  Prints out the value x which is of type m, and records 
> the changes
>   --  in environment $e into $InteractiveFrame
>   --  $printAnyIfTrue  is documented in setvart.boot. 
> controlled with )se me any
>   if md = '(Any) and $printAnyIfTrue  then
>     md' := first  x
>     x' := rest x
>   else
>     x' := x
>     md' := md
>   $outputMode: local := md   --used by DEMO BOOT
>   mode:= (md=$EmptyMode => quadSch(); md)
>   if (md ^= $Void) or $printVoidIfTrue then
>     if null $collectOutput then TERPRI $algebraOutputStream
>     if $QuietCommand = false then
>       output(x',md')
> 
>       ^^^^^^  unbound function
> 
>   putHist('%,'value,objNewWrap(x,md),$e)
>   if $printTimeIfTrue or $printTypeIfTrue then 
> printTypeAndTime(x',md')
>   if $printStorageIfTrue then printStorage()
>   if $printStatisticsSummaryIfTrue then printStatisticsSummary()
>   if FIXP $HTCompanionWindowID then mkCompanionPage md
>   $mkTestFlag = true => recordAndPrintTest md
>   $runTestFlag =>
>     $mkTestOutputType := md
>     'done
>   'done
> 
> =
==========================
==========================
============
> ===============
> define.boot.pamphlet
> =
==========================
==========================
============
> ===============
> compCapsuleItems(itemlist,$predl,$e) ==
>   $TOP__LEVEL: local
>   $myFunctorBody :local  := data    ---needed for translator
> 
>                             ^^^^  unbound variable
>        
>   $signatureOfForm: local
>   $suffix: local:= 0
>   for item in itemlist repeat $e:= 
> compSingleCapsuleItem(item,$predl,$e)
>   $e
>  
> =
==========================
==========================
============
> ===============
> 
> Take care,
> 
> 
> > As mentioned in a previous email Axiom stores its variable bindings
> > in a "frame" which, internally is an alist stored in the variable
> > |$InteractiveFrame|
> > 
> > If you create the 'dom' variable above you can see it by doing:
> > 
> > )lisp (pprint |$InteractiveFrame|)
> > 
> > 
> > btw, you can type
> > 
> > )lisp (setq $DALYMODE t)
> > 
> > and then any line that begins with an open-paren at the Axiom
> > prompt will be given directly to the lisp. e.g. after setting
> > $dalymode above you can type:
> > 
> > (pprint |$InteractiveFrame|)
> > 
> > directly to the Axiom prompt. It makes lisp debugging easier.

\start
Date: 28 Jul 2003 14:44:11 -0400
From: Camm Maguire
To: Juergen Weiss
Subject: Re: [Gcl-devel] Re: serveral bugs in codebase

Greetings!  OK, the following caused an apparent truncation of my
i-output.clisp file:
=============================================================================
--- ../../../../../axiom2/new/new/src/interp/i-output.boot.pamphlet	2003-06-18 19:05:18.000000000 +0000
+++ i-output.boot.pamphlet	2003-07-28 18:28:41.000000000 +0000
@@ -427,8 +427,8 @@
     head := [term,:head]
     tail := rest tail
   REVERSE head
-;  REVERSIP head
-; REVERSIP is a function specific to CCL
+--;  REVERSIP head
+--; REVERSIP is a function specific to CCL
    
 outputTranSEQ ['SEQ,:l,exitform] ==
   if exitform is ['exit,.,a] then exitform := a
=============================================================================

With the unlimited arg change, the |data| change, and with safety 3, I
now get:

=============================================================================
(1) -> dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)

   (1)  MonoidRing(Polynomial PrimeField 5,Permutation Integer)
                                                                 Type: Domain
(2) -> p:dom:=1
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PF.o for 
      domain PrimeField 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PERM.o 
      for domain Permutation 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/MRING.o 
      for domain MonoidRing 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/UPMP.o 
      for package UnivariatePolynomialMultiplicationPackage 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/IPF.o for
      domain InnerPrimeField 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/TABLE.o 
      for domain Table 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/HASHTBL.o
      for domain HashTable 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/INTABL.o 
      for domain InnerTable 
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ZMOD.o 
      for domain IntegerMod 

   (2)  1
                Type: MonoidRing(Polynomial PrimeField 5,Permutation Integer)
(3) -> one? p

   (3)  true
                                                                Type: Boolean
(4) -> set [p,p]
   Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/FSAGG-.o 
      for domain FiniteSetAggregate& 

   (4)  {1}
            Type: Set MonoidRing(Polynomial PrimeField 5,Permutation Integer)
(5) -> 
=============================================================================

Am retrying now with safety 0.

Take care,


"Juergen Weiss" writes:

> Hi,
> 
> the data in compCapsuleItems is obviously wrong. $myFunctorBody
> should be bound to nil. It's in my list and Tim will take care
> of it. 
> 
> The function output is defined in i-output.boot and you really
> need that file. So I'm a bit suprised, that the function is not
> found. 
> 
> > 
> > Hello again!
> > 
> > Tim Daly writes:
> > 
> > > Camm,
> > > 
> > > The duplicate set issue test is:
> > > 
> > > dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> > > p:dom:=1
> > > set [p,p] ==> {1,1}
> > > 
> > >   but should be
> > >           
> > >           ==> {1}
> > > 
> > > the other test is:
> > > 
> > >   one? p  ==> false
> > > 
> > > but should be
> > >        
> > >           ==> true
> > > 
> > 
> > OK, I think this has to do with the |output| in recordAndPrint in
> > i-toplevel being unbound.  In the default non-safety compile mode,
> > this is not checked for.  I replaced the form
> > 
> > (|output| |x'| |md'|))
> > 
> > with 
> > 
> > (format t "output replace ~S ~S ~%" |x'| |md'|))
> > 
> > in i-toplevel.clisp, managed to compile the needed algebra files from
> > Juergen's tree by hand, and then get what I think is the proper
> > behavior, with reformatted output of course:
> > 
> > ==============================================================
> > ===============
> > (1) -> dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer)
> > 
> > output replace (|MonoidRing| (|Polynomial| (|PrimeField| 5)) 
> > (|Permutation| (|Integer|))) (|Domain|) 
> >                                                               
> >    Type: Domain
> > (2) -> p:dom:=1
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PF.o for 
> >       domain PrimeField 
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PRIMES.o 
> >       for package IntegerPrimesPackage 
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SET.o for
> >       domain Set 
> >    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/POLY.o 
> >       for domain Polynomial 
> >    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ALIST.o 
> >       for domain AssociationList 
> >    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PERM.o 
> >       for domain Permutation 
> >    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/MRING.o 
> >       for domain MonoidRing 
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SMP.o for
> >       domain SparseMultivariatePolynomial 
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SUP.o for
> >       domain SparseUnivariatePolynomial 
> >    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SAOS.o 
> >       for domain SingletonAsOrderedSet 
> >    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/UPMP.o 
> >       for package UnivariatePolynomialMultiplicationPackage 
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/int/algebra/IPF.NRLIB/code 
> >       for domain InnerPrimeField 
> >    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/TABLE.o 
> >       for domain Table 
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/HASHTBL.o
> >       for domain HashTable 
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/INTABL.o 
> >       for domain InnerTable 
> >    Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ZMOD.o 
> >       for domain IntegerMod 
> > 
> > output replace (((0 . 1) . #<vector 0998e32c>)) (|MonoidRing| 
> > (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|))) 
> >                 Type: MonoidRing(Polynomial PrimeField 
> > 5,Permutation Integer)
> > (3) -> set [p,p]
> >    Loading 
> > /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/FSAGG-.o 
> >       for domain FiniteSetAggregate& 
> > 
> > output replace #<vector 09fc0efc> (|Set| (|MonoidRing| 
> > (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|)))) 
> >             Type: Set MonoidRing(Polynomial PrimeField 
> > 5,Permutation Integer)
> > (4) -> one? p
> > 
> > output replace T (|Boolean|) 
> >                                                               
> >   Type: Boolean
> > (5) -> 
> > ==============================================================
> > ===============
> > 
> > I can't yet see where |output| is supposed to be initialized.  All
> > occurrences I've found treat this symbol as a 'let-initialized'
> > local.  A similar situation appears to exist with the |data| variable
> > in define.boot.pamphlet.  Tim, what is the idea in these code
> > fragments?
> > 
> > ==============================================================
> > ===============
> > i-toplevel.boot.pamphlet
> > ==============================================================
> > ===============
> > --% Result Output Printing
> > 
> > recordAndPrint(x,md) ==
> >   --  Prints out the value x which is of type m, and records 
> > the changes
> >   --  in environment $e into $InteractiveFrame
> >   --  $printAnyIfTrue  is documented in setvart.boot. 
> > controlled with )se me any
> >   if md = '(Any) and $printAnyIfTrue  then
> >     md' := first  x
> >     x' := rest x
> >   else
> >     x' := x
> >     md' := md
> >   $outputMode: local := md   --used by DEMO BOOT
> >   mode:= (md=$EmptyMode => quadSch(); md)
> >   if (md ^= $Void) or $printVoidIfTrue then
> >     if null $collectOutput then TERPRI $algebraOutputStream
> >     if $QuietCommand = false then
> >       output(x',md')
> > 
> >       ^^^^^^  unbound function
> > 
> >   putHist('%,'value,objNewWrap(x,md),$e)
> >   if $printTimeIfTrue or $printTypeIfTrue then 
> > printTypeAndTime(x',md')
> >   if $printStorageIfTrue then printStorage()
> >   if $printStatisticsSummaryIfTrue then printStatisticsSummary()
> >   if FIXP $HTCompanionWindowID then mkCompanionPage md
> >   $mkTestFlag = true => recordAndPrintTest md
> >   $runTestFlag =>
> >     $mkTestOutputType := md
> >     'done
> >   'done
> > 
> > ==============================================================
> > ===============
> > define.boot.pamphlet
> > ==============================================================
> > ===============
> > compCapsuleItems(itemlist,$predl,$e) ==
> >   $TOP__LEVEL: local
> >   $myFunctorBody :local  := data    ---needed for translator
> > 
> >                             ^^^^  unbound variable
> >        
> >   $signatureOfForm: local
> >   $suffix: local:= 0
> >   for item in itemlist repeat $e:= 
> > compSingleCapsuleItem(item,$predl,$e)
> >   $e
> >  
> > ==============================================================
> > ===============
> > 
> > Take care,
> > 
> > 
> > > As mentioned in a previous email Axiom stores its variable bindings
> > > in a "frame" which, internally is an alist stored in the variable
> > > |$InteractiveFrame|
> > > 
> > > If you create the 'dom' variable above you can see it by doing:
> > > 
> > > )lisp (pprint |$InteractiveFrame|)
> > > 
> > > 
> > > btw, you can type
> > > 
> > > )lisp (setq $DALYMODE t)
> > > 
> > > and then any line that begins with an open-paren at the Axiom
> > > prompt will be given directly to the lisp. e.g. after setting
> > > $dalymode above you can type:
> > > 
> > > (pprint |$InteractiveFrame|)
> > > 
> > > directly to the Axiom prompt. It makes lisp debugging easier.

\start
Date: Mon, 28 Jul 2003 17:34:08 -0400
From: Camm Maguire
To: gcc@gcc.gnu.org
Subject: portable cdecl 'elliptic' function calls

Greetings!  On 3 of the 11 Debian architectures (i386, m68k, and ia64),
the cdecl calling convention is available, making the following code
possible:

object
c_apply_n(object (*fn)(), int n, object *x)
{object res=Cnil;
#if 1
 object *stack;

 if (!(stack=alloca(n*sizeof(*stack))))
   FEerror("Cannot allocate stack for elliptic call", 0);
 memcpy(stack,x,n*sizeof(*stack));
 res=fn();

As one might guess, this is taken from GCL and is used to call C
functions with a runtime-determined number of arguments.  

I know that the portable way to do this is with a switch statement on
n, but this would always be something of a workaround, limiting the
argument list to some presumably large number, and taking up a fair
bit of space in the code.

My question is whether there is an alternative call analogous to the
one outlined above for the other 8 Debian architectures (arm,
mips(el), alpha, hppa, sparc, ppc, s390), giving an unlimited to
within system stack memory runtime-determined argument list to a C
function call on these platforms as well?

Advice much appreciated, 

\start
Date: Mon, 28 Jul 2003 18:37:46 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: serveral bugs in codebase

Camm,

(forward from Mike Dewar. His mail is hung up due to the large number
of recipients)

> Great, good to know -- thanks!  What about loading binary object
> (e.g. '.o') files?
This is probably necessary - it certainly was in the AKCL days.  Making
a single image with all the algebra code pre-loaded doesn't make sense
(its way to big) and interpreted lisp code is way too slow to be usefuL
for serious problems.

Mike.

\start
Date: Mon, 28 Jul 2003 18:35:53 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: serveral bugs in codebase

Camm,

At present the CVS tree does not build all of the algebra. Until
your latest patch it couldn't. There are still about 25% of the
domains to compile which is why PF and FAXF don't exist.

The binary version was hand-built. It differs from the CVS version
primarily in the algebra. If you build Axiom from CVS you need to
download the binary version, copy the CVS interpsys over into the
binary /spad/mnt/linux/bin directory and execute it from there.
Be sure to reset your $AXIOM variable to /spad/mnt/linux first.

I'm working to update the algebra build makefile. The algebra forms
a lattice (with cycles) and I'm working out that lattice. It used
to be the case that you needed a working axiom to build axiom. In
the near future you'll be able to build it from scratch. Until that
time you need a "working" axiom (i.e. the binary version).

\start
Date: Mon, 28 Jul 2003 20:11:11 -0400
From: Tim Daly
To: Juergen Weiss
Subject: your patches

Juergen,

I've applied some of your patches but left others out.

(a) The SpadInterpretStream patch is ok. It should be a number.
(b) The funPLUSform ... patch is ok.
(c) The LED/NUD table patch is suspect. Why do you think we need to
    change the LED/NUD value for +-> and why is 112 the right value?
(d) data patch. I couldn't prove that data was ALWAYS unbound so I
    added the line:
    if (BOUNDP 'data) then ...
    It has the same effect as removing it as you did but is safer.
    I commented out the data usage on the initialization line as you did.
(e) the indexList -> indexVars change was not made. It requires more study
    on my part before I'm comfortable with it.
(f) the LET code is unchanged. LET takes 2 values but this is a compiler
    internal form, not a lisp (let form so I have to prove that only
    2 of the three arguments are ever used.
(g) the suggested autoLoad change will break autoLoad. If the autoLoad
    doesn't work then the whole build process is broken and the infinite
    load loop isn't the issue. This change was not applied.
(h) TRUE -> true, NIL -> false was applied

In general I need to PROVE that a change to the code won't break
anything else before I apply it. That involves following all possible
code paths (as in the SpadInterpretStream case). This is painful but
necessary to ensure that we don't break things. Sometimes the interactions
are very subtle. As a side-effect I ended up writing a simple explanation
of the top level loop code so, while painful, it was useful as it forced
me to document.

\start
Date: Mon, 28 Jul 2003 20:19:10 -0400
From: Tim Daly
To: list
Subject: boottran::boottocl

*,

If you are making changes to boot code it is sometimes helpful to
check the generated lisp code to ensure it does what you want.
You can convert an individual boot file to common lisp using the
boottran::boottocl function:

)fin       -- drop into common lisp
(boottran::boottocl "foo.boot") 

when you do this it creates a foo.clisp file in ../../int/interp

Alternatively if you work from the pamphlet file the process is
more painful as you have to do

)cd (yourpath)/int/interp
)sys notangle ../../src/interp/foo.boot.pamphlet >foo.boot
)fin
(boottran::boottocl "foo.boot") 
(restart)

The )cd step tells axiom to cd to the int/interp subdirectory.
The )sys notangle... extracts the boot file from the pamphlet file
The )fin step drops into common lisp
The (bootran... converts the "foo.boot" file to "foo.clisp"
The (restart) re-enters the top level loop

\start
Date: Mon, 28 Jul 2003 20:33:59 -0400
From: Tim Daly
To: David Mentre
Subject: booklet.c.pamphlet

David,

I promised to send you the changed booklet pamphlet but didn't.
Mea Culpa. Here it is.

Aside from screwing over the C format I changed it to output
the chunk unchanged if it did not contain a protocol specifier.
I also added additional documentation.

====================== booklet.c.pamphlet ============================

\documentclass{article}
\usepackage{../../src/scripts/tex/noweb}
\begin{document}
\title{\$SPAD/src/doc booklet.c}
\author{David Mentre}
\maketitle
\begin{abstract}
Booklet preprocesses a file and expands protocol specifiers in chunk names
\end{abstract}
\eject
\tableofcontents
\eject
\section{Start}
This is the booklet program. It scans the input file for a set of chunk
names that contain ``protocol specifiers''. These protocol specifiers
are replaced by their results. Any other normal chunk is undisturbed.

A protocol specifier is a prefix within the chunk name. For the moment
this program recognizes only one protocol specifier, the ``file:''
protocol. This is used to specify a file which will be included into
the file (similar to C style \#include statements). The syntax is:

[[<<file:PATH-AND-FILENAME>>]]

where PATH-AND-FILENAME can be any valid file system name.

See appendix \ref{part:requirements} for description of what the original
requirements were specified.

<<version>>=
"v0.1"

@ 

Needed includes and global variable. Nothing special.

The command line allows you to specify a [[-v]] flag. If this flag
is present then [[verbose]] is set to 1 and we print on stdout what
we are doing.
<<*>>=
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int verbose = 0;

@ 

\section{Recursive parsing and expansion}

Recursive routine used to expand pamphlet files to file descriptor
[[out]]. The input is taken from file named [[filename]].

Without error, it returns [[0]]. On error, it prints on stderr a trace
and returns [[-1]].

We read input file character by character. We rely on libc buffering for
performance. If we find the opening [[<<]] of a chunk we call [[find_url]]
to handle the chunk. Note that the two characters we swallow will be
output by [[find_url]] if this is not a protocol chunk.

<<*>>=
int recursive_parsing(FILE * out, char *filename)
{
  FILE *f;
  int c;
  
  if (verbose) /* was -v specified? */
    printf("Parsing input file '%s'\n", filename);

  f = fopen(filename, "r");
  if (f == NULL) /* we couldn't open the input file */
  { fprintf(stderr, "error: cannot open input file '%s'\n", filename);
    perror("fopen");
    return -1;
  }

  c = fgetc(f);
  while (c != EOF) 
  { if (c == '<') 
    { /* maybe an opening '<<'? */
      int c2 = fgetc(f);

      if (c2 == EOF) 
      { fputc(c, out);
        return 0;
      }
      if (c2 == '<') 
      { /* yep, we have a '<<' */
        if (find_url(out, f)) 
        { fprintf(stderr, "error: while parsing file '%s'\n", filename);
          return 1;
        }
      } 
      else 
      { fputc(c, out);
        fputc(c2, out);
      }
    } 
    else 
    { fputc(c, out);
    }
    c = fgetc(f);
  }
  
  return 0;
}

@ 

We define a routine that, given an [[url]], do the needed lookup to find
what kind of url it is, open it and puts it content into file descriptor
[[out]].

If the chunk name does not contain a protocol specifier we recognize
then we ignore the input.
<<*>>=

int url_dispatch(FILE *out, unsigned char *url)
{ int i = 0;
  char c = '\0';
  if (verbose) printf("Found URL:'%s'\n", url);
  if (strncmp(url, "file:", 5) == 0) 
  { recursive_parsing(out, &url[5]);
  }
  else /* no protocol specifier. dump the chunk name */
  { fputc('<',out);
    fputc('<',out);
    for(c=url[i++]; c != '\0'; c=url[i++])
      fputc(c,out);
    fputc('>',out);
    fputc('>',out);
  }
  return 0;
}
@ 

We define a routine that find a booklet URL in file descriptor [[f]]. We
now that we have already found the start of URL [[<<]]. So we look for
the end of URL sign ([[>>]]) and store the found URL in [[buf]]. Once we
have our URL, we call the dispatch routine on it to expand it.

If, for any reason, we do not find a valid chunk name we output the
characters we found so the original file is unchanged. If we do find
a valid chunk name we call [[url_dispatch]] to look for a protocol
specifier.

We use a buffer of fixed size [[buf]] to store the search URL. {\bf
FIXME: this restriction should be fixed in a later version.}

<<*>>=
#define BUF_SIZE 1024

int find_url(FILE *out, FILE *f)
{
  unsigned char buf[BUF_SIZE];
  int c = fgetc(f);
  int i = 0;
  
  while ((i < BUF_SIZE) && (c != EOF)) 
  { if (c == '>') /* start of '>>'? */
    { int c2 = fgetc(f);
      if (c2 == EOF) 
      { buf[i] = 0;
        fprintf(stderr,"error: end of file after first '>' of URL:'%s'\n",buf);
        return -1;
      }
      if (c2 == '>')  /* yep, we found a valid chunk */
      { buf[i] = 0;
        url_dispatch(out, buf); /* look for a protocol specifier */
        return 0;
      }
      /* no, just a single '>' */
      buf[i] = (unsigned char)c;
      i++;
      c = fgetc(f);
    } 
    else  /* just a random character, add it to the buffer */ 
    { buf[i] = (unsigned char)c;
      i++;
      c = fgetc(f);
    }
  }
  if (i == 0) /* we got no characters */
  { fprintf(stderr, "error: empty url\n");
    return -1;
  }
  if (i == BUF_SIZE) /* we overflowed the buffer */
  { fprintf(stderr, "internal error: buf exhausted in function find_url()\n");
    return -1;
  }
  buf[i] = 0;
  fprintf(stderr, "error: non terminating URL:'%s'\n", buf);
  return -1;
}
@ 

Print how to use this program.
<<*>>=
void print_usage(void)
{
  printf("booklet %s\n", <<version>>);
  printf("usage: booklet [-v] bookletfile pamphletfile\n");
}

@ 

\section {main}

<<print usage and exit>>=
print_usage();
exit(-1);
@ 

We parse command line to take our arguments, we open files and then call
recursive expansion.

{\bf FIXME: maybe it would be better to do output on a temporary file
  and move it to destination if no error?}

<<*>>=
int main(int argc, char **argv) 
{
  FILE *out;
  
  if (argc < 3 || argc > 4) 
  { <<print usage and exit>>    
  }
  if (argc == 3) /* -v was not specified */
  { out = fopen(argv[2], "w");
    if (out == NULL) /* we can't write the output file */
    { fprintf(stderr, "error: unable to open output file '%s'\n", argv[2]);
      perror("fopen");
      exit(-1);
    }
    if (recursive_parsing(out, argv[1])) /* parsing failed */
      return -1;
  } 
  else /* -v was specified? */
  { if (strncmp(argv[1], "-v", 2) == 0) /* -v was specified */
    { verbose = 1; 
    } 
    else /* an unknown option was specified */
    { fprintf(stderr, "bad option '%s'\n", argv[1]);
      <<print usage and exit>>
    }
    out = fopen(argv[3], "w");
    if (out == NULL) /* we couldn't open the input file */
    { fprintf(stderr, "error: unable to open input file '%s'\n", argv[3]);
      perror("fopen");
      exit(1);
    }
    if (recursive_parsing(out, argv[2])) /* parsing failed */
      return -1;
  }
  fclose(out);
  return 0;
}

@

\appendix
\section{Initial requirements for booklet made by Tim Daly}
\label{part:requirements}

\begin{verbatim}

I need a simple C program to do the following:

booklet [-v] bookletfile pamphletfile

The booklet function is basically a recursive macro-expander.

The booklet function takes as input the name of a booklet file and the
name of a pamphlet file. 

The bookletfile is any file that contains special strings of the form:
@<<file:filename>>
which we will call a booklet URL. 

The booklet function replaces the whole booklet URL including the
surrounding @<< and >> symbols by the contents of filename.

The replaced text should be exact with no extra leading or trailing
characters so that x@<<file:filename1>>@<<file:filename2>>y where filename1
contains a single byte 'a' and filename2 contains a single byte 'b'
should result in the inline string 'xaby'.

The replaced text is recursively searched for any instance of a
booklet URL and these are replaced inline.

The resulting text is output to the pamphletfile.

The -v flag is optional. If supplied the booklet function write the
replacement actions to standard output thus:
in (filename1) replacing @<<file:filename2>> with text from (filename2)
where (filename1) is the file containing the booklet URL and
filename2 is the parsed filename from the booklet URL. This will
allow the user to trace where replacements are specified and where
the replacement came from.

If the file is not found the booklet function should fail with a clear
diagnostic traceback that outputs the containing file, the failing
booklet URL, and a recursive traceback. This should allow the user to
easily find the path of embeds that led to the failing line. The
failing booklet program should return a -1 to the shell.

Note that the filename in the booklet URL can contain a relative or
absolute pathname and will have to follow system-specific naming
conventions (forward-slash for unix, backslash for windows).

At this time only the file: protocol specifier is needed.

It should be a design criteria that the file: portion of the booklet URL
be considered one of a set of cases for a "protocol specifier" which will
be further specified in the future as needed (likely containing such
things as "http:", "pamphlet:", etc). 

It should be a design criteria that each protocol specifier has it's own
associated parser as the syntax of the booklet URL may vary based on the
protocol specifier. Thus,
@<<file:filename>> parses the 'filename' portion as a path and file spec.
@<<http:web>> parses the 'web' portion as any valid URL

Note that the booklet program should be developed as a literate program
and be contained in a single pamphlet file that does not use booklet URLs.
This is required so that the booklet function does not depend on itself.

(Axiom will build on multiple platforms and portions of the system will
be specified in booklet files. We need this program to be standalone
as it will be built very early in the process (even before the common
lisp). This will allow portions of the system to be written as booklet
files. The protocol specifiers will be used later to fetch pamphlet
files mentioned in the reference section of a pamphlet. Since we have
not used this feature yet there is no reason to implement anything. 
However, as we expect to use this feature in the future it is important
that the booklet function be (a) flexible enough to add other protocol
specifiers and (b) documented as a pamphlet file so others can change it.)

If this is unclear please ask questions.

\start
Date: 28 Jul 2003 20:37:53 -0400
From: Camm Maguire
To: list
Subject: Re: serveral bugs in codebase

Greetings!  Here are my resulst thus far:

1) Copying the linux binary from tenkan, and using my compiled
   interpsys in that directory, I get a slightly modified result from
   the one reported:

        (3) -> set [p,p]
   Loading /fix/t1/camm/axiom/noncvs/axiom/mnt/linux/algebra/URAGG-.o 
      for domain UnaryRecursiveAggregate& 
   There are no exposed library operations named elt but there are 51 
      unexposed operations with that name. Use HyperDoc Browse or issue
                               )display op elt
      to learn more about the available operations.
 
   Cannot find a definition or applicable library operation named elt 
      with argument type(s) 
        List MonoidRing(Polynomial PrimeField 5,Permutation Integer)
      
      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.
(3) -> one? p

   Loading /fix/t1/camm/axiom/noncvs/axiom/mnt/linux/algebra/BOOLEAN.o 
      for domain Boolean 
   (3)  false
                                                                Type: Boolean

2) Taking the same interpsys, copying over the missing algebra clisp
   files from Juergen's tree, compiling them by hand, and then
   executing the above, all works correctly.

3) These two results with safety set to 0.   My current understanding
   is that the large argument patch is only necessary when compiling
   with safety >=2, as GCL will inline the large apply call otherwise.
   In any case, the |data| patch for define.boot.pamphlet has been
   applied. 

4) Logical next step is to diff Juergen's clisp files with the ones
   pertaining to the binary.  These alas are not in the tarball.

5) Are we sure we know this problem persists in a clean system
   recompiled with the lengthvec patch?  I currently cannot reproduce
   it from source, only partially with some binary only modules.

6) Does everyone else see this elt message in 1)?  Perhaps this
   indicates a syntax error or is otherwise illustrative?

Tim Daly writes:

> Camm,
> 
> At present the CVS tree does not build all of the algebra. Until
> your latest patch it couldn't. There are still about 25% of the
> domains to compile which is why PF and FAXF don't exist.
> 
> The binary version was hand-built. It differs from the CVS version
> primarily in the algebra. If you build Axiom from CVS you need to
> download the binary version, copy the CVS interpsys over into the
> binary /spad/mnt/linux/bin directory and execute it from there.
> Be sure to reset your $AXIOM variable to /spad/mnt/linux first.
> 
> I'm working to update the algebra build makefile. The algebra forms
> a lattice (with cycles) and I'm working out that lattice. It used
> to be the case that you needed a working axiom to build axiom. In
> the near future you'll be able to build it from scratch. Until that
> time you need a "working" axiom (i.e. the binary version).

\start
Date: Mon, 28 Jul 2003 20:53:54 -0400
From: Tim Daly
To: Camm Maguire
Subject: interpsys and algebra

Camm,

I think you're running into limitations due to the interactions
of the hand-built image and your interpsys image. You really need
the fully compiled algebra with the new patches which does not yet
exist. I'm still working on that level of build machinery.

You may be able to use your new interpsys, install it into the
hand-built directory, and recompile all of the algebra files 
that are used in this example. You can figure out which algebra
files are used by running an example, looking for messages like:
   Loading /fix/t1/camm/axiom/noncvs/axiom/mnt/linux/algebra/URAGG.o 
and then at an axiom prompt typing:
)show URAGG
and it will tell you the source spad file to compile.

======================================================================
Greetings!  Here are my resulst thus far:

1) Copying the linux binary from tenkan, and using my compiled
   interpsys in that directory, I get a slightly modified result from
   the one reported:

        (3) -> set [p,p]
   Loading /fix/t1/camm/axiom/noncvs/axiom/mnt/linux/algebra/URAGG-.o 
      for domain UnaryRecursiveAggregate& 
   There are no exposed library operations named elt but there are 51 
      unexposed operations with that name. Use HyperDoc Browse or issue
                               )display op elt
      to learn more about the available operations.
 
   Cannot find a definition or applicable library operation named elt 
      with argument type(s) 
        List MonoidRing(Polynomial PrimeField 5,Permutation Integer)
      
      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.
(3) -> one? p

   Loading /fix/t1/camm/axiom/noncvs/axiom/mnt/linux/algebra/BOOLEAN.o 
      for domain Boolean 
   (3)  false
                                                                Type: Boolean

2) Taking the same interpsys, copying over the missing algebra clisp
   files from Juergen's tree, compiling them by hand, and then
   executing the above, all works correctly.

3) These two results with safety set to 0.   My current understanding
   is that the large argument patch is only necessary when compiling
   with safety >=2, as GCL will inline the large apply call otherwise.
   In any case, the |data| patch for define.boot.pamphlet has been
   applied. 

4) Logical next step is to diff Juergen's clisp files with the ones
   pertaining to the binary.  These alas are not in the tarball.

5) Are we sure we know this problem persists in a clean system
   recompiled with the lengthvec patch?  I currently cannot reproduce
   it from source, only partially with some binary only modules.

6) Does everyone else see this elt message in 1)?  Perhaps this
   indicates a syntax error or is otherwise illustrative?


\start
Date: Tue, 29 Jul 2003 11:29:27 +1000
From: Fergus Henderson
To: Camm Maguire
Subject: Re: portable cdecl 'elliptic' function calls

On 28-Jul-2003, Camm Maguire <Camm Maguire> wrote:
> object
> c_apply_n(object (*fn)(), int n, object *x)
> {object res=Cnil;
> #if 1
>  object *stack;
> 
>  if (!(stack=alloca(n*sizeof(*stack))))
>    FEerror("Cannot allocate stack for elliptic call", 0);
>  memcpy(stack,x,n*sizeof(*stack));
>  res=fn();

This code is extremely non-portable.

I suggest you try using libffi, which is included in the GCC sources.
See libffi/README.

\start
Date: 28 Jul 2003 21:36:44 -0400
From: Camm Maguire
To: list
Subject: Re: interpsys and algebra

Greetings!  OK, I'm inferring from what you write that it would be
better for me to wait until you've completed this latest round of
construction.  If you still see this problem at that point, or if I
misunderstand and there is a way you'd like me to debug it now, in
either case, please send me a note to wake me up and I'll try to take
a look. 

Tim Daly writes:

> Camm,
> 
> I think you're running into limitations due to the interactions
> of the hand-built image and your interpsys image. You really need
> the fully compiled algebra with the new patches which does not yet
> exist. I'm still working on that level of build machinery.
> 
> You may be able to use your new interpsys, install it into the
> hand-built directory, and recompile all of the algebra files 
> that are used in this example. You can figure out which algebra
> files are used by running an example, looking for messages like:
>    Loading /fix/t1/camm/axiom/noncvs/axiom/mnt/linux/algebra/URAGG.o 
> and then at an axiom prompt typing:
> )show URAGG
> and it will tell you the source spad file to compile.
> 
> Tim
> 
> ======================================================================
> Greetings!  Here are my resulst thus far:
> 
> 1) Copying the linux binary from tenkan, and using my compiled
>    interpsys in that directory, I get a slightly modified result from
>    the one reported:
> 
>         (3) -> set [p,p]
>    Loading /fix/t1/camm/axiom/noncvs/axiom/mnt/linux/algebra/URAGG-.o 
>       for domain UnaryRecursiveAggregate& 
>    There are no exposed library operations named elt but there are 51 
>       unexposed operations with that name. Use HyperDoc Browse or issue
>                                )display op elt
>       to learn more about the available operations.
>  
>    Cannot find a definition or applicable library operation named elt 
>       with argument type(s) 
>         List MonoidRing(Polynomial PrimeField 5,Permutation Integer)
>       
>       Perhaps you should use "@" to indicate the required return type, 
>       or "$" to specify which version of the function you need.
> (3) -> one? p
> 
>    Loading /fix/t1/camm/axiom/noncvs/axiom/mnt/linux/algebra/BOOLEAN.o 
>       for domain Boolean 
>    (3)  false
>                                                                 Type: Boolean
> 
> 2) Taking the same interpsys, copying over the missing algebra clisp
>    files from Juergen's tree, compiling them by hand, and then
>    executing the above, all works correctly.
> 
> 3) These two results with safety set to 0.   My current understanding
>    is that the large argument patch is only necessary when compiling
>    with safety >=2, as GCL will inline the large apply call otherwise.
>    In any case, the |data| patch for define.boot.pamphlet has been
>    applied. 
> 
> 4) Logical next step is to diff Juergen's clisp files with the ones
>    pertaining to the binary.  These alas are not in the tarball.
> 
> 5) Are we sure we know this problem persists in a clean system
>    recompiled with the lengthvec patch?  I currently cannot reproduce
>    it from source, only partially with some binary only modules.
> 
> 6) Does everyone else see this elt message in 1)?  Perhaps this
>    indicates a syntax error or is otherwise illustrative?

\start
Date: Mon, 28 Jul 2003 22:15:21 -0400
From: Tim Daly
To: Camm Maguire
Subject: todo

It would be possible for you to reconstruct that algebra but
it would be painful. It would be better if you wait until I
get the makefile further along so we know we're all building
the same set of mistakes.

If you're feeling ambitious you could look at the issue of getting
openmath support added to gcl. The ccl subdirectory has the code
that implements the api. I haven't had time to look at that issue
yet.

\start
Date: Tue, 29 Jul 2003 07:50:18 +0100 (GMT Daylight Time)
From: Arthur Norman
To: Camm Maguire
Subject: Re: portable cdecl 'elliptic' function calls

On Mon, 28 Jul 2003, Camm Maguire wrote:
> Greetings!  On 3 of the 11 Debian architectures (i386, m68k, and ia64),
> the cdecl calling convention is available...
> ...
> As one might guess, this is taken from GCL and is used to call C
> functions with a runtime-determined number of arguments.
>
> I know that the portable way to do this is with a switch statement on
> n, but this would always be something of a workaround, limiting the
> argument list to some presumably large number, and taking up a fair
> bit of space in the code.
>
In CSL/CCL what I do to support arbitrary arg counts involves that ugly
switch statement up to some fixed limit, but beyond that I do what is in
effect a source-code remapping so that args N, N+1, N+2,... get packed
into a regular Lisp vector and passed as one argument

Eg a call
   (f a1 a2 a3 a4 ... a20, a21, ...)
is mapped to
   (f a1 a2 a3 a4 ... (vector a20 a21 ...))
and a function definition
   (defun f (a1 ... a20 ...)
      ... a23 ...)
becomes
   (defun f (a1 ... vec-of-rest)
      ... (elt vec-of-rest 4) ...)
This clearly carries an overhead in performance in such cases but comes
closer to living within the C standard.

\start
Date: Tue, 29 Jul 2003 15:12:53 +0200 (CEST)
From: Bertfried Fauser
To: list
Subject: Bourbaki

Hi,

just for amusement, from the history of math web-page at St-Andrews:
 	"Henri Cartan, Andre Weil, Jean Dieudonne, Claude Chevalley, and
Alexander Grothendieck wrote collectively under the name of Bourbaki and
Bourbaki's Elements de mathematique contains more than 30 volumes."

If you look at Christophe Reutenauers web-page you will even see a
'picture' of Bourbaki
http://www.lacim.uqam.ca/~christo/Bourbaki.html

As far as I know, it was firstly N.N. Bourbaki and later Nicolas N.
Bourbaki.

You may note, that 'Boubakism' was coined to reject a formal 'abstract
nonsense' approch to mathematics, categories were in its infancy then. A
strongly typed system as AXIOM has lots of 'boubakism' spirit. In this
sense it has some tone to write pamphlet (also with conotation?)  files
under this name. There was a Bourbaki driven attempt in the 70ies to put
set theoretic based mathematics to schools, which failed ... however.

\start
Date: Mon, 28 Jul 2003 15:13:07 +0100
From: Mike Dewar
To: Camm Maguire
Subject: Re: GCL compliance and Bill Schelter
Cc: Richard Stallman, David Turner, Sam Steingold, Stavros Macrakis

> Great, good to know -- thanks!  What about loading binary object
> (e.g. '.o') files?
This is probably necessary - it certainly was in the AKCL days.  Making
a single image with all the algebra code pre-loaded doesn't make sense
(its way to big) and interpreted lisp code is way too slow to be usefuL
for serious problems.

Mike.

\start
Date: Tue, 29 Jul 2003 11:52:29 -0400
From: Richard Stallman
To: Richard Fateman
Subject: Re: GCL used commercially

      Here's the argument: It helps companies build non-free software on GCL 
    which might not
    ever be produced otherwise.

In and of itself, that is an undesirable consequence: more non-free
programs offer nothing to people who value their freedom, tempt others
to devalue their freedom so as to enjoy the practical benefits, and
make our community fall further behind.  Unless they somehow lead to
substantial contributions to GCL, they do not help free software.

\start
Date: Tue, 29 Jul 2003 20:46:49 +0200
From: David Mentre
To: Tim Daly
Subject: Re: On savannah CVS, no Makefile nor Makefile.dvi

Tim Daly writes:

> The root Makefile.pamphlet will have its associated .dvi file though
> as that's where the starting comments live. An argument could probably
> be made for a README file-chunk in the root Makefile.pamphlet because
> people expect a "README" file somewhere. 

I totally agree with you on the above points.

\start
Date: Wed, 30 Jul 2003 09:09:50 +0200
From: David Mentre
To: Tim Daly
Subject: Re: KNOWN.BUGS.pamphet (July 23, 2003)

Hello Tim,

It is probably not crucial at that point but you made me remember:

Tim Daly writes:

> This is the first step in trying to organize the bug tracking
> in some more rational form. 

For bug tracking, there is also the bug tracking facilities of Savannah:
 http://savannah.nongnu.org/bugs/?group=axiom

On that:

 (1) either you prefer to maintain manually KNOWN.BUGS.pamphet

 (2) or either you want to use Savannah facilities.

   In that case:

    (a) you can do it yourself

    (b) I propose to help you if you want.

      In that case:

      (i) you need to add me as an Axiom savannah developer (log into
          savannah, go into Administration>Main>Manage members
          https://savannah.nongnu.org/project/admin/userperms.php?group=axiom

          and add my savannah login ("dmentre") into the project)

      (ii) In the above page, in the Managing Members Permissions part,
           you must give me at least Tech rights (and maybe Admin rights
           if you want me to help you on other parts of the savannah
           system).

      From that, I would enter the bugs into the database. It would help
      us track them in a central facility, available online.


Please note that Free Software projects often use such a system and it
is very useful for external people to report bugs without subscribing to
mailing lists. While not being as a good hacker as Camm, I could help
for more administrative task.

\start
Date: Wed, 30 Jul 2003 07:02:11 -0400
From: Tim Daly
To: David Mentre
Subject: Lightning and Thunder 

David,

Well, you asked for it...
You are now a God-like figure on the Axiom project. 
Use your newfound powers wisely.
You have my sympathy.

\start
Date: Tue, 29 Jul 2003 11:52:32 -0400
From: Richard Stallman
To: list
Subject: Re: GCL compliance and Bill Schelter
Cc: Cliff Yapp, Camm Maguire, David Turner, Sam Steingold, Stavros Macrakis

    I would make the analogy that in C one uses a linker to combine compiler
    output and libraries to create a "save-system" image runnable binary.
    Lisp combines compiler output and the lisp runtime (essentially a big
    library) to create a "save-system" image. The linker just happens to
    be internal to the interpreter.

I think that is entirely uncontroversial.  The GPL doesn't refer to
specific technical details of how programs are combined into something
larger--those details don't matter.

    It must be possible to write a GPLed Common Lisp language supporting
    this common feature that allows users to write in Common Lisp without
    being GPLed. Without this proviso it will not be possible to write
    Common Lisp code in any other "free" license.

All GPL-compatible free software licenses are ok for linking with
GPL-covered code, for any kind of linking.

\start
Date: Wed, 30 Jul 2003 23:37:13 +0200
From: David Mentre
To: list
Subject: Re: Lightning and Thunder

Hello Tim,

Tim Daly writes:

> You are now a God-like figure on the Axiom project. 
> Use your newfound powers wisely.

:-) Many thanks. I've seen that Camm has also joined the Olympus. 

No time to do much things this evening but I'll try to do bug sorting
shortly.

\start
Date: 30 Jul 2003 17:54:54 -0400
From: Camm Maguire
To: Fergus Henderson
Subject: Re: portable cdecl 'elliptic' function calls

Greetings, and thank you for this tip!  I now think I see how to do
this in GCL, and would like to build in dependency on libffi.  Is this
available on everyone's systems?  I'm assuming its packaged at least
everywhere gcc is available.  What about solaris, Mac OS X?

Take care,

Fergus Henderson writes:

> On 28-Jul-2003, Camm Maguire <Camm Maguire> wrote:
> > object
> > c_apply_n(object (*fn)(), int n, object *x)
> > {object res=Cnil;
> > #if 1
> >  object *stack;
> > 
> >  if (!(stack=alloca(n*sizeof(*stack))))
> >    FEerror("Cannot allocate stack for elliptic call", 0);
> >  memcpy(stack,x,n*sizeof(*stack));
> >  res=fn();
> 
> This code is extremely non-portable.
> 
> I suggest you try using libffi, which is included in the GCC sources.
> See libffi/README.

\start
Date: Thu, 31 Jul 2003 09:33:44 +1000
From: Mike Thomas
To: Camm Maguire, Fergus Henderson
Subject: RE: [Gcl-devel] Re: portable cdecl 'elliptic' function calls

Hi Camm.

It must be statically linked with gcc on Windows rather than being
standalone, assuming it's used there at all as it is absent from my Cygwin
and MinGW32 gcc lib directories.

The gcc source seems to imply it works on Windows but some docs I've read on
the web don't list Windows as a target platform for libffi.  (Never built
gcc so can't say which.)

Fergus, did you use it in the Cygwin port of Mercury?


| Greetings, and thank you for this tip!  I now think I see how to do
| this in GCL, and would like to build in dependency on libffi.  Is this
| available on everyone's systems?  I'm assuming its packaged at least
| everywhere gcc is available.  What about solaris, Mac OS X?
|
| Take care,
|
| Fergus Henderson writes:
|
| > On 28-Jul-2003, Camm Maguire <Camm Maguire> wrote:
| > > object
| > > c_apply_n(object (*fn)(), int n, object *x)
| > > {object res=Cnil;
| > > #if 1
| > >  object *stack;
| > >
| > >  if (!(stack=alloca(n*sizeof(*stack))))
| > >    FEerror("Cannot allocate stack for elliptic call", 0);
| > >  memcpy(stack,x,n*sizeof(*stack));
| > >  res=fn();
| >
| > This code is extremely non-portable.
| >
| > I suggest you try using libffi, which is included in the GCC sources.
| > See libffi/README.

\start
Date: Wed, 30 Jul 2003 20:43:25 -0400
From: Tim Daly
To: list
Subject: axiom.input

*,

Another developer note. If you add a file in your home directory called
"axiom.input" it will be read and executed when axiom starts. This is
useful for various reasons including setting various switches. Mine reads:

)lisp (pprint "running /root/axiom.input")
)set quit unprotected
)set message autoload off
)set message startup off

You can execute any command in axiom.input. Be aware that this will
ALSO be run while you are doing a "make" so be careful what you ask do.

\start
Date: Thu, 31 Jul 2003 10:39:14 +0200
From: Juergen Weiss
To: list
Subject: RE: axiom.input

Hi,

my suggestion would be to rename the file to .axiom.input
(or to additionally search to a file of that name) according
to unix practices.

> 
> *,
> 
> Another developer note. If you add a file in your home 
> directory called
> "axiom.input" it will be read and executed when axiom starts. This is
> useful for various reasons including setting various 
> switches. Mine reads:
> 
> )lisp (pprint "running /root/axiom.input")
> )set quit unprotected
> )set message autoload off
> )set message startup off
> 
> You can execute any command in axiom.input. Be aware that this will
> ALSO be run while you are doing a "make" so be careful what 
> you ask do.

\start
Date: Thu, 31 Jul 2003 23:52:52 +1000
From: Fergus Henderson
To: Mike Thomas
Subject: Re: portable cdecl 'elliptic' function calls
Cc: Camm Maguire

On 31-Jul-2003, Mike Thomas wrote:
> Fergus, did you use it [libffi] in the Cygwin port of Mercury?

No.

Camm Maguire <Camm Maguire> wrote:

> | Greetings, and thank you for this tip!  I now think I see how to do
> | this in GCL, and would like to build in dependency on libffi.  Is this
> | available on everyone's systems?  I'm assuming its packaged at least
> | everywhere gcc is available.  What about solaris, Mac OS X?

You should not assume that libffi is implemented everywhere that gcc is
available.  The reason that libffi is included in the GCC distribution
is, I think, because it is used by the Java interpreter.  That is a lot
less widely ported than the GNU C compiler, I would imagine.

The libffi implementation is by its nature not portable;
its implementation depends on the platform's calling convention.
However, the interface is portable, and by using libffi,
the work of implementing this interface for a bunch of different
calling conventions can be shared between all the different
projects that need this functionality.

The difficulty of porting libffi to a different OS will depend on
whether that OS uses the same calling convention as one that libffi
already supports.  If so, as is the case with Cygwin, then it should
be very little work.  If not, it might be a lot of work.

\start
Date: Thu, 31 Jul 2003 19:37:48 +0200
From: David Mentre
To: list
Subject: Bug database on savannah

Hello Tim,

I have added to savannah's bug database of Axiom project all the bugs
mentioned in your file KNOWN.BUGS.pamphet (July 23, 2003).

Unfortunalty, the bug numbers are different from your file (it is
imposed by the system) but the bug orders are the same.

I have tried to make a bug report form which is close to the fields you
have in KNOWN.BUGS.pamphet.

I haven't made any attempt to classify bug severity.

It is possible to add or remove some fields. It is also possible to make
predefined reports (for example, all bugs related to the algebra).

I have taken the liberty to assign the bug related to OpenMath to Camm,
as he proposed to make the necessary bindings in GCL.

Let me know if you need further features.

\start
Date: Thu, 31 Jul 2003 16:03:31 -0400
From: Tim Daly
To: David Mentre
Subject: Re: Bug database on savannah

David,

Excellent job. The main thing you need to do is to be proactive about
listening for bugs on the developer list and adding them (as well as
encouraging developers to do it themselves). The other thing is to
maintain a knownbugs.input file and fixedbugs.input file (see bugs.input
in the src/input subdir). We need to track the bugs in some executable
form so we can check that they "stay fixed" as well as give developers
a set of broken examples to run. Both could be extracted from the
KNOWN.BUGS.pamphlet file. Whether you can get this to work and how
you'd like to make it work is entirely up to you.

\start
Date: 31 Jul 2003 17:50:52 -0400
From: Camm Maguire
To: Fergus Henderson
Subject: Re: portable cdecl 'elliptic' function calls

Greetings, and thanks!

> On 31-Jul-2003, Mike Thomas wrote:
> > Fergus, did you use it [libffi] in the Cygwin port of Mercury?
> 
> No.
> 
> Camm Maguire <Camm Maguire> wrote:
> 
> > | Greetings, and thank you for this tip!  I now think I see how to do
> > | this in GCL, and would like to build in dependency on libffi.  Is this
> > | available on everyone's systems?  I'm assuming its packaged at least
> > | everywhere gcc is available.  What about solaris, Mac OS X?
> 
> You should not assume that libffi is implemented everywhere that gcc is
> available.  The reason that libffi is included in the GCC distribution
> is, I think, because it is used by the Java interpreter.  That is a lot
> less widely ported than the GNU C compiler, I would imagine.
> 
> The libffi implementation is by its nature not portable;
> its implementation depends on the platform's calling convention.
> However, the interface is portable, and by using libffi,
> the work of implementing this interface for a bunch of different
> calling conventions can be shared between all the different
> projects that need this functionality.
> 
> The difficulty of porting libffi to a different OS will depend on
> whether that OS uses the same calling convention as one that libffi
> already supports.  If so, as is the case with Cygwin, then it should
> be very little work.  If not, it might be a lot of work.
> 

OK, so what I'd like to know is how important is an unlimited number
of arguments to a compiled function call?  I'm guessing that the
Debian platform coverage for libffi is probably pretty good, and I
don't think Windows would be too far behind.  Mac OS X, solaris,
others I don't know.  I think its probably worth a configure
option.  This may force some ports to maintain a larger switch
statement if some programs make use of this before libffi is ported,
but I don't think that is a major impediment.  Opinions?

\start
Date: Thu, 31 Jul 2003 19:08:57 -0400
From: Tim Daly
To: Camm Maguire
Subject: unlimited argument lists

Camm,

Axiom gets around the limited argument restriction because there is only
one function that (potentially) uses it and that is the |Join| function.
Since the interpreter doesn't have this restriction we keep the |Join|
function is a special file called nocompil.lisp which is never compiled
(thus, the name). This solution seems to work fine for Axiom and I don't
see the need for any other solution. It would be nice if unlimited args
"just worked" but it is not essential.

\start
Date: 31 Jul 2003 18:34:03 -0600
From: Tom Tromey
To: Mike Thomas
Subject: Re: portable cdecl 'elliptic' function calls

>>>>> "Mike" == Mike Thomas writes:

Mike> The gcc source seems to imply it works on Windows but some docs
Mike> I've read on the web don't list Windows as a target platform for
Mike> libffi.  (Never built gcc so can't say which.)

libffi works fine on Windows.  You can easily find out where it works
by looking in gcc/libffi/configure.in.  There is a big case statement
that sets up the build for all the working platforms.

Things are a little different if you use the closure API.  Then you
have to look in gcc/libffi/include/ffi.h.in to see what platforms
define FFI_CLOSURES.

The "normal" API works on more platforms than the closure API.  I
think libffi works on all the Debian architectures except HPPA.
Nobody has ever done that port.

Tom



