diff --git a/book/2003-07.txt b/book/2003-07.txt new file mode 100644 index 0000000..bb0779d --- /dev/null +++ b/book/2003-07.txt @@ -0,0 +1,13366 @@ +\start +Date: Tue, 1 Jul 2003 10:06:07 +0100 +From: Mike Dewar +To: Jason White +cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: root +To: miked@nag.co.uk +cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: oscas@acm.org +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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: root +To: Michael Wester +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: fateman@cs.berkeley.edu +Cc: axiom-developer@nongnu.org, daly@idsi.net, OSCAS@acm.org +Subject: [Axiom-developer] 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 +Cc: David Turner , LV , axiom-developer@nongnu.org, Sam Steingold , maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: +> . +> +> 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: root +To: amundson@fnal.gov +Cc: axiom-developer@nongnu.org, oscas@acm.org +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Cc: axiom-developer@nongnu.org, oscas@acm.org +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Cc: axiom-developer@nongnu.org, oscas@acm.org +Subject: Re: [Axiom-developer] 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: root +To: apinkus@xs4all.nl +Cc: axiom-developer@nongnu.org, oscas@acm.org +Subject: [Axiom-developer] 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: root +To: OSCAS@ACM.ORG +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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 +Cc: novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + + 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: rms@gnu.org +Cc: novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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. + <>= + +-SPD=/home/axiomgnu/new +-SYS=linux ++SPD=$(shell pwd) ++SYS=$(notdir $(AXIOM)) + SPAD=${SPD}/mnt/${SYS} + LSP=${SPD}/lsp + <> + +\start +Date: Wed, 16 Jul 2003 09:01:30 -0400 +From: Tim Daly +To: david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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@wanadoo.fr +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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 +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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" , +Cc: novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] RE: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: daly@idsi.net +Cc: axiom-developer@nongnu.org, oscas mailing list +Subject: [Axiom-developer] 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, root wrote: +> Jim, +> +> Where can I find the current maxima test cases? +> + +\start +Date: 17 Jul 2003 16:48:06 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: gcl-deve@gnu.org, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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, + +root 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" +Cc: camm@enhanced.com, novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU 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, + +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: +Cc: camm@enhanced.com, novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] RE: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: daly@idsi.net +Cc: gcl-deve@gnu.org, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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, +> +> root 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: root +To: camm@enhanced.com +Cc: gcl-deve@gnu.org, axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] 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 +To: rms@gnu.org +Cc: novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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 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" , +Cc: novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: RE: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: daly@idsi.net +Cc: gcl-deve@gnu.org, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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. + + +root 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 +Cc: gcl-deve@gnu.org, axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] current bug + +Hello Camm, + +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 +Cc: Tim Daly , axiom-developer@nongnu.org, gcl-deve@gnu.org +Subject: Re: [Axiom-developer] current bug + +Hello Cam, + +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 +Cc: Tim Daly , axiom-developer@nongnu.org, gcl-deve@gnu.org +Subject: Re: [Axiom-developer] 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" +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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 +Cc: Tim Daly , axiom-developer@nongnu.org, gcl-deve@gnu.org +Subject: Re: [Axiom-developer] 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: root +To: Tim Daly , axiom-developer@nongnu.org, gcl-deve@gnu.org +Subject: [Axiom-developer] 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: root +To: Tim Daly , axiom-developer@nongnu.org, gcl-deve@gnu.org +Subject: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] 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: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Error when converting to a set + +Greetings! + +root 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: +Subject: RE: [Axiom-developer] 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. + +> -----Original Message----- +> From: +> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> .org] On Behalf Of root +> Sent: Friday, July 18, 2003 2:14 PM +> To: Tim Daly; axiom-developer@nongnu.org; gcl-deve@gnu.org +> Subject: [Axiom-developer] 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 15:01:08 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: +Subject: RE: [Axiom-developer] 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 + +> -----Original Message----- +> From: +> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> .org] On Behalf Of Bill Page +> Sent: Friday, July 18, 2003 2:47 PM +> To: axiom-developer@nongnu.org +> Subject: RE: [Axiom-developer] 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. +> +> > -----Original Message----- +> > From: +> > axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> > [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> > .org] On Behalf Of root +> > Sent: Friday, July 18, 2003 2:14 PM +> > To: Tim Daly; axiom-developer@nongnu.org; gcl-deve@gnu.org +> > Subject: [Axiom-developer] 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 15:52:19 -0400 +From: Richard Stallman +To: "Mike Thomas" +Cc: camm@enhanced.com, novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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 +Cc: novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + + 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" +Cc: novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: Re: [Maxima] RE: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] 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: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: +Cc: novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: Re: [Maxima] Re: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: dpt@exoskeleton.math.harvard.edu (Dylan Thurston) +To: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] list bug + +On Fri, Jul 18, 2003 at 05:13:34PM -0400, root wrote: +> Camm, +>=20 +> 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=20 +> rounded values that are used in the output length computation +> (src/interp/i-output.boot.pamphlet, line 843). +>=20 +> The GCL results are: +> log10(100) =3D=3D> 2.0 +> log10(1000) =3D=3D> 2.9999999999999996 +>=20 +> we take the floor of the results as the length of the number +> giving (floor (log10 1000)) =3D> 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: daly@idsi.net +Cc: Tim Daly , axiom-developer@nongnu.org, gcl-deve@gnu.org +Subject: Re: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] 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: root +To: dpt@math.harvard.edu +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] list bug, log10 + +> > we take the floor of the results as the length of the number +> > giving (floor (log10 1000)) =3D> 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: , "'Mike Thomas'" +Cc: camm@enhanced.com, novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] RE: [Maxima] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +> As for the unexec files, they are far from trivial, and I=20 +> don't see a reason to make them available for non-free=20 +> software. So I think you need to tell people that those files=20 +> can only be used in GPL-covered programs. + +Perhaps alternatives to unexec which do not encumber applications with=20 +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: daly@idsi.net +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org, axiom@tenkan.org +Subject: Re: [Gcl-devel] Re: [Axiom-developer] 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, + +root 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: root +To: Camm Maguire +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org, axiom@tenkan.org +Subject: [Axiom-developer] 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: daly@idsi.net +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org, axiom@tenkan.org +Subject: [Axiom-developer] 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, + +root 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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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 +Cc: camm@enhanced.com, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] hascategory bug + +root 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@enhanced.com. My emails are rejected with error: +: 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: root +To: david.mentre@wanadoo.fr +Cc: camm@enhanced.com, axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] savannah + +I see the time has come to concentrate on getting savannah set up. + +\start +Date: Sun, 20 Jul 2003 07:22:30 -0400 +From: root +To: axiom-developer@nongnu.org +Cc: axiom@tenkan.org +Subject: [Axiom-developer] 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: +<> +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<><>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 <> 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, +<> parses the 'filename' portion as a path and file spec. +<> 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: daly@idsi.net +Cc: camm@enhanced.com, axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: savannah + +root 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: root +To: david.mentre@wanadoo.fr +Cc: camm@enhanced.com, axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Re: savannah + +nope. but it will be found eventually. + +\start +Date: 20 Jul 2003 12:36:58 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] 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? + +root 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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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: daly@idsi.net +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: Re: [Gcl-devel] Re: [Axiom-developer] 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? + +root 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: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] macro table msg + +Greetings! + +root 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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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" , +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: RE: [Gcl-devel] Re: [Axiom-developer] 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=20 +fixnum (bignums are handled differently)? Even if it is, +does it matter? + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com]=20 +> Sent: Sunday, July 20, 2003 7:03 PM +> To: daly@idsi.net +> Cc: axiom-developer@nongnu.org; gcl-devel@gnu.org +> Subject: Re: [Gcl-devel] Re: [Axiom-developer] list bug +>=20 +>=20 +> Greetings! =20 +>=20 +> Have you considered something like: +>=20 +> (first (multiple-value-list (round (log 1000 10)))) +>=20 +> 3 +>=20 +> ? +>=20 +> Is this relevant to the 'duplicate member in set' bug we were +> discussing earlier? I'm referring to that reported by Juergen in: +>=20 + +\start +Date: Sun, 20 Jul 2003 15:13:26 -0400 +From: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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. ++<>= ++ 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 ++<> + -- 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: root +To: weiss@uni-mainz.de +Cc: camm@enhanced.com, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] list bug + +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: root +To: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Cc: daly@idsi.net +Subject: [Axiom-developer] 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: +Subject: [Axiom-developer] 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. + +> -----Original Message----- +> From: gcl-devel-bounces+bill.page1=sympatico.ca@gnu.org +> [mailto:gcl-devel-bounces+bill.page1=sympatico.ca@gnu.org] On +> Behalf Of root +> Sent: Saturday, July 19, 2003 9:50 PM +> To: camm@enhanced.com +> Cc: axiom@tenkan.org; axiom-developer@nongnu.org; +> daly@idsi.net; gcl-devel@gnu.org +> Subject: [Gcl-devel] 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: Sun, 20 Jul 2003 23:22:48 +0200 +From: David MENTRE +To: Tim Daly +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] booklet function + +Hello Tim, + +root 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: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] booklet function + +already? I'm impressed! + +\start +Date: Sun, 20 Jul 2003 19:05:51 -0400 +From: Richard Stallman +To: Camm Maguire +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: Re: [Maxima] Re: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org + #48656] Re: GCL compliance with GNU GPL + + 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: +Cc: camm@enhanced.com, novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] RE: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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 + +/* + * 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: rms@gnu.org +Cc: Camm Maguire , stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org, novalis@fsf.org +Subject: [Axiom-developer] GCL used commercially? + +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 +From: Richard Stallman +To: "Mike Thomas" +Date: Mon, 21 Jul 2003 15:40:01 -0400 +Cc: camm@enhanced.com, novalis@fsf.org, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: rms@gnu.org +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu +Subject: [Axiom-developer] Re: GCL used commercially? + +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: rms@gnu.org +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: Re: [Maxima] Re: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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 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 +Cc: camm@enhanced.com, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org, novalis@fsf.org +Subject: [Axiom-developer] Re: GCL used commercially? + + 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" ,axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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). + +> > -----Original Message----- +> > From: Camm Maguire [mailto:camm@enhanced.com] +> > Sent: Sunday, June 22, 2003 4:07 PM +> > To: Juergen Weiss +> > Cc: Jason White; axiom-developer@nongnu.org; gcl-devel@gnu.org +> > Subject: Re: [Axiom-developer] source access +> > +> > +> > 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: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] booklet function + +I've made some modifications to your program so that it outputs +chunk tags that do not contain protocol specifiers. Thus + +<> + +is output unchanged but + +<> + +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: + +<>= +\include{asdf} +@ + +it fails because the \include is quoted. If you try: + +\include{asdf} + +where the file asdf contains the <> 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: [Axiom-developer] source access + +Hi, + + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com]=20 +> Sent: Tuesday, July 22, 2003 2:17 AM +> To: Juergen Weiss; axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] source access +>=20 +>=20 +> Greetings! +>=20 +> "Juergen Weiss" writes: +>=20 +> > 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). +>=20 +> I can't find any settings for the r6000. Might you know where to +> look?=20 + +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=20 +>=20 +> 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. +=20 +> > 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=20 +> > place). +>=20 +> 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: root +To: weiss@uni-mainz.de +Cc: camm@enhanced.com, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] source access + +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'" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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". + +> -----Original Message----- +> From: Mike Thomas [mailto:miketh@brisbane.paradigmgeo.com] +> Sent: Tuesday, July 22, 2003 1:10 AM +> To: Page, Bill +> Subject: RE: [Gcl-devel] 2.5.4 +> +> +> Hi Bill. +> +> Further to this I have passed a package on to Earnie, so +> let's wait and see +> what happens. +> +> +> | -----Original Message----- +> | From: Page, Bill [mailto:Bill.Page@drdc-rddc.gc.ca] +> | Sent: Saturday, July 12, 2003 5:43 AM +> | To: 'Mike Thomas' +> | Cc: 'earnie_boyd@yahoo.com'; gcl-devel@gnu.org +> | Subject: RE: [Gcl-devel] 2.5.4 +> | +> | +> | 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. +> | +> | +> | > -----Original Message----- +> | > From: Mike Thomas [mailto:miketh@brisbane.paradigmgeo.com] +> | > Sent: Wednesday, July 09, 2003 12:13 AM +> | > To: Camm Maguire; gcl-devel@gnu.org +> | > Subject: RE: [Gcl-devel] 3.5.4 +> | > +> | > +> | > 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. +> | > +> | > -----Original Message----- +> | > From: Earnie Boyd [mailto:earnie_boyd@yahoo.com] +> | > Sent: Thursday, June 26, 2003 7:22 AM +> | > To: Bill Page +> | > 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. +> | > > +> | > > +> | > > +> | > >>-----Original Message----- +> | > >>From: Earnie Boyd [mailto:earnie_boyd@yahoo.com] +> | > >>Sent: Wednesday, June 25, 2003 6:37 AM +> | > >>To: Mike Thomas +> | > >>Cc: Bill Page; gcl-devel@gnu.org; daly@idsi.net; +> | > >>axiom-developer@nongnu.org; david.mentre@wanadoo.fr; +> | > >>mingw-users@lists.sourceforge.net +> | > >>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: "Page, Bill" +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: booklet function + +Hello Tim, + +I'm glad to see that the program suits your need. + +root 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: root +To: Bill.Page@drdc-rddc.gc.ca +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: "Page, Bill" +To: "'daly@idsi.net'" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] Axiom debugging + +Tim, + +OK, thanks. Now I understand... more or less. (It will +be more as time goes on ). 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? + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Tuesday, July 22, 2003 4:15 PM +> To: Bill.Page@drdc-rddc.gc.ca +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] 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: 22 Jul 2003 16:56:42 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] source access + +Greetings! Also, do you have a |Join| call runnable from interpsys +which illustrates the problem? + +root 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: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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, + +root 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: root +To: "Page, Bill" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: "Page, Bill" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: Camm Maguire +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: Camm Maguire +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: Camm Maguire +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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 +axiom@tenkan.org +daly@idsi.net +===================================================================== +(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: "Page, Bill" +To: "'daly@idsi.net'" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: "Page, Bill" +To: "'daly@idsi.net'" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] 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: root +To: Bill.Page@drdc-rddc.gc.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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: root +To: Bill.Page@drdc-rddc.gc.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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 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 21:57:28 -0400 +From: "Page, Bill" +To: "'daly@idsi.net'" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: Bill.Page@drdc-rddc.gc.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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 +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu +Subject: [Axiom-developer] Re: GCL used commercially? + + 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 +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: Re: [Maxima] Re: [Axiom-developer] Re: [Gcl-devel] Re: [gnu.org #48656] Re: GCL compliance with GNU GPL + +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: root +Cc: Bill.Page@drdc-rddc.gc.ca, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Sets in MonoidRing + +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: rms@gnu.org +Cc: camm@enhanced.com, stavros.macrakis@verizon.net, license-violation@fsf.org, Richard Fateman , axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org, novalis@fsf.org +Subject: [Axiom-developer] [Gcl-devel] Re: GCL used commercially? + +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: , +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] 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.=20 + +> -----Original Message----- +> From: root [mailto:daly@idsi.net]=20 +> Sent: Wednesday, July 23, 2003 4:07 AM +> To: Bill.Page@drdc-rddc.gc.ca +> Cc: axiom-developer@nongnu.org; daly@idsi.net +> Subject: [Axiom-developer] Sets in MonoidRing +>=20 +>=20 +> You're right, the answer should be=20 +>=20 +> one? p =3D=3D> true. +>=20 +> Perhaps the problem isn't in the code but the (human) interpreter :-) +>=20 +> 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.=20 + +\start +Date: Wed, 23 Jul 2003 07:38:08 -0400 +From: root +To: weiss@uni-mainz.de +Cc: axiom-developer@nongnu.org, Bill.Page@drdc-rddc.gc.ca, daly@idsi.net +Subject: Re: [Axiom-developer] Sets in MonoidRing + +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: +Cc: Bill.Page@drdc-rddc.gc.ca, axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] Sets in MonoidRing + +Yes, exactly. + + +> -----Original Message----- +> From: root [mailto:daly@idsi.net]=20 +> Sent: Wednesday, July 23, 2003 1:38 PM +> To: Juergen Weiss +> Cc: daly@idsi.net; Bill.Page@drdc-rddc.gc.ca;=20 +> axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] Sets in MonoidRing +>=20 +>=20 +> Joergen, +>=20 +> If I understand you correctly you said that=20 +>=20 +> given pgr:=3DMonoidRing(... +> and p:pgr:=3D1 +> that in CMUCL one? p =3D=3D> true +> but in GCL one? p =3D=3D> false +>=20 +> If this is true then that is a great help in debugging this problem. +>=20 +> Tim +> axiom@tenkan.org +> daly@idsi.net +>=20 +>=20 + +\start +Date: Wed, 23 Jul 2003 09:26:24 -0400 +From: Tim Daly +To: axiom-developer@nongnu.org +Cc: axiom@tenkan.org, daly@idsi.net +Subject: [Axiom-developer] 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 +axiom@tenkan.org +daly@idsi.net + +===================== 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. +<>= +----------------------------------------------------------------------- +--BugNumber: +--Version: +--Opened: +--OpenedBy: +--Closed: +--ClosedBy: +--Component: +--Description: +--ErrorMsg: +--Example: +@ +\subsection{Bug 000001} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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. +<>= +----------------------------------------------------------------------- +--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. +<>= +----------------------------------------------------------------------- +--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. +<>= +----------------------------------------------------------------------- +--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. +<>= +----------------------------------------------------------------------- +--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} +<>= +----------------------------------------------------------------------- +--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. +<>= +@ +\section{CLOSED .input file} +The CLOSEDINPUTFILE output chunk will create a standard .input file +of closed bugs for use in regression testing. +<>= +@ +\section{OPEN bugs} +The OPEN output chunk will give a list of the open bugs. +<>= +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +@ +\section{OPEN .input file} +The OPENINPUTFILE output chunk will create a +standard .input file that demonstrates OPEN bugs for use in debugging. +<>= +)set message autoload off +)set break resume +<> +<> +<> +<> +<> +<> +@ +\section{The default report} +The default output chunk will include all of the bug reports. +<<*>>= +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +<> +@ +\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: rms@gnu.org +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu +Subject: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? + +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: fateman@cs.berkeley.edu, rms@gnu.org +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] 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 +axiom@tenkan.org +daly@idsi.net + +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: fateman@cs.berkeley.edu +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, rms@gnu.org, daly@rio.sci.ccny.cuny.edu +Subject: [Axiom-developer] Re: GCL used commercially + +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: C Y +To: Richard Fateman , rms@gnu.org +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu +Subject: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? + +--- 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 (dkschmidt@compuserve.com) 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: "Page, Bill" +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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 +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Sets in MonoidRing + +Hello Tim, + +root 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: "Page, Bill" +To: "'David MENTRE'" , "Page, Bill" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] 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. + + +> -----Original Message----- +> From: David MENTRE [mailto:david.mentre@wanadoo.fr] +> Sent: Wednesday, July 23, 2003 3:16 PM +> To: Page, Bill +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] 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 15:51:29 -0400 +From: root +To: david.mentre@wanadoo.fr +Cc: Bill.Page@drdc-rddc.gc.ca, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: set function breakage + +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: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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. Page1 (E-mail)" +Cc: "Page, Bill" , axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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 +Cc: Bill.Page@drdc-rddc.gc.ca, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: set function breakage + +root 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: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, Bill.Page@drdc-rddc.gc.ca, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: set function breakage + +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: "Page, Bill" +To: "'root'" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: david.mentre@wanadoo.fr, axiom@tenkan.org, Bill.Page@drdc-rddc.gc.ca, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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 +From: Richard Stallman +To: "Thomas F. Burdick" +Date: Wed, 23 Jul 2003 19:02:57 -0400 +Cc: camm@enhanced.com, stavros.macrakis@verizon.net, license-violation@fsf.org, fateman@cs.berkeley.edu, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org, novalis@fsf.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: GCL used commercially? + + > 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: root +To: "Bill Page" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: "Bill Page" , Camm Maguire +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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) . #)) + +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: , "Camm Maguire" +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: GCL compliance with GNU GPL - Axiom question, + AKCL tarball licences + +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: root +To: miketh@brisbane.paradigmgeo.com +Cc: Camm Maguire , novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] GCL compliance and Bill Schelter + +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: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] set output script yes + +Tim Daly daly@idsi.net 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 +Cc: Tim Daly , Bill.Page@drdc-rddc.gc.ca, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: set function breakage + +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: +> root 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 +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] 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 daly@idsi.net 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: +Cc: Camm Maguire , novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] RE: GCL compliance and Bill Schelter + +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: root +To: "Mike Thomas" +Cc: Camm Maguire , novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] GCL compliance and Bill Schelter + +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 +Cc: Camm Maguire , novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] RE: GCL compliance and Bill Schelter + +On Thu, Jul 24, 2003 at 03:08:05PM +1000, Mike Thomas wrote: + +> 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: C Y +To: daly@idsi.net, Mike Thomas +Cc: Camm Maguire , novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Maxima] GCL compliance and Bill Schelter + +--- root 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: root +To: smustudent1@yahoo.com +Cc: novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org, camm@enhanced.com, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, daly@idsi.net +Subject: [Axiom-developer] GCL compliance and Bill Schelter + +> 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: "Page, Bill" +Cc: Tim Daly , axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: C Y +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, fateman@cs.berkeley.edu, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu +Subject: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? + + 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: rms@gnu.org +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@rio.sci.ccny.cuny.edu +Subject: [Axiom-developer] Re: GCL used commercially + +Richard Stallman wrote: + +> +> 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: +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, 'C Y' , fateman@cs.berkeley.edu, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu +Subject: RE: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? + +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? + +> -----Original Message----- +> From: +> axiom-developer-bounces+bill.page1=sympatico.ca@nongnu.org +> [mailto:axiom-developer-bounces+bill.page1=sympatico.ca@nongnu +> .org] On Behalf Of Richard Stallman +> Sent: Thursday, July 24, 2003 4:00 PM +> To: C Y +> Cc: novalis@fsf.org; stavros.macrakis@verizon.net; +> license-violation@fsf.org; fateman@cs.berkeley.edu; +> axiom-developer@nongnu.org; sds@gnu.org; maxima@www.ma.utexas.edu +> Subject: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? +> +> +>> 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 +To: daly@idsi.net +Cc: novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: GCL compliance and Bill Schelter + +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: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] 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: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Small patches + +Greetings! + +root 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 +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, sds@gnu.org, fateman@cs.berkeley.edu, axiom-developer@nongnu.org, C Y , maxima@www.ma.utexas.edu +Subject: Re: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? + +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" +Cc: Camm Maguire , novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: RE: [Axiom-developer] RE: GCL compliance and Bill Schelter + +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: +Cc: Camm Maguire , novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] RE: GCL compliance and Bill Schelter + +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: daly@idsi.net +Cc: camm@enhanced.com, license-violation@fsf.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, gcl-devel@gnu.org, novalis@fsf.org +Subject: [Axiom-developer] Re: GCL compliance and Bill Schelter + +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 +Cc: novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Maxima] Re: GCL compliance and Bill Schelter + +> 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 +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, rms@gnu.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] Re: GCL compliance and Bill Schelter + +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 +Cc: Camm Maguire , novalis@fsf.org, license-violation@fsf.org, rms@gnu.org, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] RE: GCL compliance and Bill Schelter + +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 +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, rms@gnu.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] Re: [Maxima] Re: GCL compliance and Bill + Schelter + +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: root +To: axiom-developer@nongnu.org +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, rms@gnu.org, axiom-legal@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] axiom-legal@nongnu.org + +*, + +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 +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, rms@gnu.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Maxima] Re: [Axiom-developer] Re: GCL compliance and Bill Schelter + +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 +Cc: axiom-developer@nongnu.org, maxima@www.ma.utexas.edu, Richard Stallman +Subject: Re: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? + +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" +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, smustudent1@yahoo.com, fateman@cs.berkeley.edu, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu +Subject: Re: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? + + 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: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] 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: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: Re: [Gcl-devel] Re: [Axiom-developer] 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, + +root 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] (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. + + <>= +-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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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 +axiom@tenkan.org +daly@idsi.net + +\start +Date: Sat, 26 Jul 2003 09:25:29 -0400 +From: root +To: daly@idsi.net +Cc: camm@enhanced.com, axiom@tenkan.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] hascategory bug + +*, + +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 +axiom@tenkan.org +daly@idsi.net + +\start +Date: 26 Jul 2003 10:37:08 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] 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, + +root 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 +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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. + <>= + ${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 ) + + @ + <>= +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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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 +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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. + +<>= +int f(int a) { + return 0; +} + +@ + +The main program. + +<>= +<> +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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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 +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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 +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, sds@gnu.org, fateman@cs.berkeley.edu, axiom-developer@nongnu.org, smustudent1@yahoo.com, maxima@www.ma.utexas.edu +Subject: Re: [Axiom-developer] Re: [Maxima] Re: GCL used commercially? + + 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: root +To: daly@idsi.net +Cc: camm@enhanced.com, axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] Duplicate set issue + +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: root +To: daly@idsi.net +Cc: camm@enhanced.com, axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] Duplicate set issue + +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: +Cc: camm@enhanced.com, axiom@tenkan.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: RE: [Axiom-developer] Duplicate set issue + +Hi, + +I think, the test p =3D 1 or one? p will be easier to track. +Sets are rather complicated objects. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net]=20 +> Sent: Sunday, July 27, 2003 10:15 PM +> To: daly@idsi.net +> Cc: camm@enhanced.com; axiom@tenkan.org;=20 +> axiom-developer@nongnu.org; daly@idsi.net; gcl-devel@gnu.org +> Subject: [Axiom-developer] Duplicate set issue +>=20 +>=20 +> Camm, +>=20 +> The duplicate set issue test is: +>=20 +> dom:=3DMonoidRing(Polynomial PrimeField 5, Permutation Integer) +> p:dom:=3D1 +> set [p,p] =3D=3D> {1,1} +>=20 +> but should be +> =20 +> =3D=3D> {1} +>=20 + +\start +Date: Sun, 27 Jul 2003 16:38:47 -0400 +From: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: root +To: weiss@uni-mainz.de +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: weiss@uni-mainz.de +Cc: camm@enhanced.com, axiom-developer@nongnu.org +Subject: [Axiom-developer] serveral bugs in codebase + +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: root +To: axiom-developer@nongnu.org +Cc: daly@idsi.net +Subject: [Axiom-developer] 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: daly@idsi.net +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] 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? + +root 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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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: daly@idsi.net +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] 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, + +root 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" , +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] RE: [Gcl-devel] Re: serveral bugs in codebase + +Hi=20 + +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. + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com]=20 +> Sent: Monday, July 28, 2003 4:09 PM +> To: daly@idsi.net +> Cc: axiom-developer@nongnu.org; Juergen Weiss; gcl-devel@gnu.org +> Subject: Re: [Gcl-devel] Re: serveral bugs in codebase +>=20 +>=20 +> 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. +>=20 +> 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:=3D1, 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. +>=20 +> Awaiting advice... +>=20 +> Take care, +>=20 +> root writes: +>=20 +> > Camm, +> >=20 +> > The duplicate set issue test is: +> >=20 +> > dom:=3DMonoidRing(Polynomial PrimeField 5, Permutation Integer) +> > p:dom:=3D1 +> > set [p,p] =3D=3D> {1,1} +> >=20 +> > but should be +> > =20 +> > =3D=3D> {1} +> >=20 +> > the other test is: +> >=20 +> > one? p =3D=3D> false +> >=20 +> > but should be +> > =20 +> > =3D=3D> true +> >=20 +> > As mentioned in a previous email Axiom stores its variable bindings +> > in a "frame" which, internally is an alist stored in the variable +> > |$InteractiveFrame| +> >=20 +> > If you create the 'dom' variable above you can see it by doing: +> >=20 +> > )lisp (pprint |$InteractiveFrame|) +> >=20 +> >=20 +> > btw, you can type +> >=20 +> > )lisp (setq $DALYMODE t) +> >=20 +> > 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: +> >=20 +> > (pprint |$InteractiveFrame|) +> >=20 +> > directly to the Axiom prompt. It makes lisp debugging easier. + +\start +Date: 28 Jul 2003 11:04:54 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: serveral bugs in codebase + +Hello again! + +root 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) . #)) (|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 # (|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" , +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] 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.=20 + +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.=20 + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com]=20 +> Sent: Monday, July 28, 2003 5:05 PM +> To: daly@idsi.net +> Cc: axiom-developer@nongnu.org; Juergen Weiss; gcl-devel@gnu.org +> Subject: Re: [Gcl-devel] Re: serveral bugs in codebase +>=20 +>=20 +> Hello again! +>=20 +> root writes: +>=20 +> > Camm, +> >=20 +> > The duplicate set issue test is: +> >=20 +> > dom:=3DMonoidRing(Polynomial PrimeField 5, Permutation Integer) +> > p:dom:=3D1 +> > set [p,p] =3D=3D> {1,1} +> >=20 +> > but should be +> > =20 +> > =3D=3D> {1} +> >=20 +> > the other test is: +> >=20 +> > one? p =3D=3D> false +> >=20 +> > but should be +> > =20 +> > =3D=3D> true +> >=20 +>=20 +> 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 +>=20 +> (|output| |x'| |md'|)) +>=20 +> with=20 +>=20 +> (format t "output replace ~S ~S ~%" |x'| |md'|)) +>=20 +> 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: +>=20 +> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> (1) -> dom:=3DMonoidRing(Polynomial PrimeField 5, Permutation Integer) +>=20 +> output replace (|MonoidRing| (|Polynomial| (|PrimeField| 5))=20 +> (|Permutation| (|Integer|))) (|Domain|)=20 +> =20 +> Type: Domain +> (2) -> p:dom:=3D1 +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PF.o for=20 +> domain PrimeField=20 +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PRIMES.o=20 +> for package IntegerPrimesPackage=20 +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SET.o for +> domain Set=20 +> Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/POLY.o=20 +> for domain Polynomial=20 +> Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ALIST.o=20 +> for domain AssociationList=20 +> Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/PERM.o=20 +> for domain Permutation=20 +> Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/MRING.o=20 +> for domain MonoidRing=20 +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SMP.o for +> domain SparseMultivariatePolynomial=20 +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SUP.o for +> domain SparseUnivariatePolynomial=20 +> Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/SAOS.o=20 +> for domain SingletonAsOrderedSet=20 +> Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/UPMP.o=20 +> for package UnivariatePolynomialMultiplicationPackage=20 +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/int/algebra/IPF.NRLIB/code=20 +> for domain InnerPrimeField=20 +> Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/TABLE.o=20 +> for domain Table=20 +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/HASHTBL.o +> for domain HashTable=20 +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/INTABL.o=20 +> for domain InnerTable=20 +> Loading /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/ZMOD.o=20 +> for domain IntegerMod=20 +>=20 +> output replace (((0 . 1) . #)) (|MonoidRing|=20 +> (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|)))=20 +> Type: MonoidRing(Polynomial PrimeField=20 +> 5,Permutation Integer) +> (3) -> set [p,p] +> Loading=20 +> /fix/t1/camm/axiom/axiom/new/new/mnt/linux/algebra/FSAGG-.o=20 +> for domain FiniteSetAggregate&=20 +>=20 +> output replace # (|Set| (|MonoidRing|=20 +> (|Polynomial| (|PrimeField| 5)) (|Permutation| (|Integer|))))=20 +> Type: Set MonoidRing(Polynomial PrimeField=20 +> 5,Permutation Integer) +> (4) -> one? p +>=20 +> output replace T (|Boolean|)=20 +> =20 +> Type: Boolean +> (5) ->=20 +> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +>=20 +> 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? +>=20 +> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> i-toplevel.boot.pamphlet +> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> --% Result Output Printing +>=20 +> recordAndPrint(x,md) =3D=3D +> -- Prints out the value x which is of type m, and records=20 +> the changes +> -- in environment $e into $InteractiveFrame +> -- $printAnyIfTrue is documented in setvart.boot.=20 +> controlled with )se me any +> if md =3D '(Any) and $printAnyIfTrue then +> md' :=3D first x +> x' :=3D rest x +> else +> x' :=3D x +> md' :=3D md +> $outputMode: local :=3D md --used by DEMO BOOT +> mode:=3D (md=3D$EmptyMode =3D> quadSch(); md) +> if (md ^=3D $Void) or $printVoidIfTrue then +> if null $collectOutput then TERPRI $algebraOutputStream +> if $QuietCommand =3D false then +> output(x',md') +>=20 +> ^^^^^^ unbound function +>=20 +> putHist('%,'value,objNewWrap(x,md),$e) +> if $printTimeIfTrue or $printTypeIfTrue then=20 +> printTypeAndTime(x',md') +> if $printStorageIfTrue then printStorage() +> if $printStatisticsSummaryIfTrue then printStatisticsSummary() +> if FIXP $HTCompanionWindowID then mkCompanionPage md +> $mkTestFlag =3D true =3D> recordAndPrintTest md +> $runTestFlag =3D> +> $mkTestOutputType :=3D md +> 'done +> 'done +>=20 +> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> define.boot.pamphlet +> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> compCapsuleItems(itemlist,$predl,$e) =3D=3D +> $TOP__LEVEL: local +> $myFunctorBody :local :=3D data ---needed for translator +>=20 +> ^^^^ unbound variable +> =20 +> $signatureOfForm: local +> $suffix: local:=3D 0 +> for item in itemlist repeat $e:=3D=20 +> compSingleCapsuleItem(item,$predl,$e) +> $e +> =20 +> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +>=20 +> Take care, +>=20 +>=20 +> > As mentioned in a previous email Axiom stores its variable bindings +> > in a "frame" which, internally is an alist stored in the variable +> > |$InteractiveFrame| +> >=20 +> > If you create the 'dom' variable above you can see it by doing: +> >=20 +> > )lisp (pprint |$InteractiveFrame|) +> >=20 +> >=20 +> > btw, you can type +> >=20 +> > )lisp (setq $DALYMODE t) +> >=20 +> > 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: +> >=20 +> > (pprint |$InteractiveFrame|) +> >=20 +> > 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" +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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. +> +> > -----Original Message----- +> > From: Camm Maguire [mailto:camm@enhanced.com] +> > Sent: Monday, July 28, 2003 5:05 PM +> > To: daly@idsi.net +> > Cc: axiom-developer@nongnu.org; Juergen Weiss; gcl-devel@gnu.org +> > Subject: Re: [Gcl-devel] Re: serveral bugs in codebase +> > +> > +> > Hello again! +> > +> > root 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) . #)) (|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 # (|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,gcl-devel@gnu.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] Re: [Gcl-devel] 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: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] Re: [Gcl-devel] 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: root +To: "Juergen Weiss" +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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: root +To: axiom-developer@nongnu.org +Cc: daly@idsi.net +Subject: [Axiom-developer] 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: root +To: david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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: + +[[<>]] + +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. + +<>= +"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 +#include +#include + +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", <>); + printf("usage: booklet [-v] bookletfile pamphletfile\n"); +} + +@ + +\section {main} + +<>= +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) + { <> + } + 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]); + <> + } + 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} +Date: Sun, 20 Jul 2003 07:22:30 -0400 +From: root +To: axiom-developer@nongnu.org +Cc: axiom@tenkan.org +Subject: [Axiom-developer] booklet function +Lines: 84 + +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: +@<> +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@<>@<>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 @<> 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, +@<> parses the 'filename' portion as a path and file spec. +@<> 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: daly@idsi.net +Cc: axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] Re: [Gcl-devel] 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? + +root 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: root +To: Camm Maguire +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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 +Cc: gcc@gcc.gnu.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: portable cdecl 'elliptic' function calls + +On 28-Jul-2003, 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. + +-- +Fergus Henderson | "I have always known that the pursuit +The University of Melbourne | of excellence is a lethal habit" +WWW: | -- the last words of T. S. Garp. + +\start +Date: 28 Jul 2003 21:36:44 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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. + +root 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 +> axiom@tenkan.org +> daly@idsi.net +> +> ====================================================================== +> 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: root +To: Camm Maguire +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] 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 +Cc: gcc@gcc.gnu.org, axiom-developer@nongnu.org, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] 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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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 +Cc: novalis@fsf.org, stavros.macrakis@verizon.net, license-violation@fsf.org, rms@gnu.org, axiom-developer@nongnu.org, sds@gnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org +Subject: Re: [Maxima] Re: [Axiom-developer] Re: GCL compliance and Bill Schelter + +> 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 +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@rio.sci.ccny.cuny.edu +Subject: [Axiom-developer] 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 +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] On savannah CVS, no Makefile nor Makefile.dvi + +root 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 +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] 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: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, daly@rio.sci.ccny.cuny.edu +Subject: [Axiom-developer] 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: daly@idsi.net +Cc: novalis@fsf.org, license-violation@fsf.org, smustudent1@yahoo.com, maxima@www.ma.utexas.edu, gcl-devel@gnu.org, camm@enhanced.com, stavros.macrakis@verizon.net, axiom-developer@nongnu.org, sds@gnu.org, daly@idsi.net +Subject: [Axiom-developer] Re: GCL compliance and Bill Schelter + + 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: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@rio.sci.ccny.cuny.edu +Subject: [Axiom-developer] Re: Lightning and Thunder + +Hello Tim, + +root 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 +Cc: gcc@gcc.gnu.org, axiom-developer@nongnu.org, maxima@mail.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] 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 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" +Cc: gcc@gcc.gnu.org, axiom-developer@nongnu.org, maxima@mail.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] 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? + + +| -----Original Message----- +| From: gcl-devel-bounces+miketh=brisbane.paradigmgeo.com@gnu.org +| [mailto:gcl-devel-bounces+miketh=brisbane.paradigmgeo.com@gnu.org]On +| Behalf Of Camm Maguire +| Sent: Thursday, July 31, 2003 7:55 AM +| To: Fergus Henderson +| Cc: gcc@gcc.gnu.org; axiom-developer@nongnu.org; +| maxima@mail.ma.utexas.edu; acl2@lists.cc.utexas.edu; gcl-devel@gnu.org +| Subject: [Gcl-devel] 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 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: root +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: "Weiss, Juergen" +To: , +Subject: RE: [Axiom-developer] 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. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net]=20 +> Sent: Thursday, July 31, 2003 2:43 AM +> To: axiom-developer@nongnu.org +> Subject: [Axiom-developer] axiom.input +>=20 +>=20 +> *, +>=20 +> Another developer note. If you add a file in your home=20 +> directory called +> "axiom.input" it will be read and executed when axiom starts. This is +> useful for various reasons including setting various=20 +> switches. Mine reads: +>=20 +> )lisp (pprint "running /root/axiom.input") +> )set quit unprotected +> )set message autoload off +> )set message startup off +>=20 +> 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=20 +> you ask do. + +\start +Date: Thu, 31 Jul 2003 23:52:52 +1000 +From: Fergus Henderson +To: Mike Thomas +Cc: Camm Maguire , gcc@gcc.gnu.org, maxima@mail.ma.utexas.edu, axiom-developer@nongnu.org, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: portable cdecl 'elliptic' function calls + +On 31-Jul-2003, Mike Thomas wrote: +> Fergus, did you use it [libffi] in the Cygwin port of Mercury? + +No. + +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: axiom-developer@nongnu.org +Subject: [Axiom-developer] 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: root +To: david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] 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 +Cc: gcc@gcc.gnu.org, maxima@mail.ma.utexas.edu, axiom-developer@nongnu.org, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] 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 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: root +To: Camm Maguire +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] 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" +Cc: gcc@gcc.gnu.org, axiom-developer@nongnu.org, maxima@mail.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] 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 + + + diff --git a/changelog b/changelog index 3726d2f..6df2664 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,5 @@ +20140418 tpd src/axiom-website/patches.html 20140418.03.tpd.patch +20140418 tpd book/2003-07.txt regularize 20140418 tpd src/axiom-website/patches.html 20140418.02.tpd.patch 20140418 tpd book/2002*.txt, 2003-01..06.txt modified 20140418 tpd src/axiom-website/patches.html 20140418.01.tpd.patch