diff --git a/book/2003-08.txt b/book/2003-08.txt new file mode 100644 index 0000000..07328a4 --- /dev/null +++ b/book/2003-08.txt @@ -0,0 +1,17532 @@ +\start +Date: Fri, 01 Aug 2003 18:33:54 +0200 +From: David MENTRE +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Bug database on savannah + +root writes: + +> 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). + +ok, I'll try to do that. + +\start +Date: Sat, 02 Aug 2003 12:43:01 +0200 +From: David MENTRE +To: Juergen Weiss +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] serveral bugs in codebase + +Hello Juergen, + +Juergen Weiss writes: + +> here is a list of bugs I found, with suggested fixes: + +I have not added the bug you submitted in the bug database as Tim has +already review them and replied for each of them[1]. + +However, if you consider that they are still bugs, please resubmit them +and I'll add them to the bug database (or submit directly them on the +savannah bug system[2] :). + +[1] http://mail.gnu.org/archive/html/axiom-developer/2003-07/msg00195.html +[2] http://savannah.nongnu.org/bugs/?func=addbug&group=axiom + +\start +Date: Sat, 02 Aug 2003 11:47:00 +0200 +From: David MENTRE +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] axiom.input + +"Weiss, Juergen" writes: + +> 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. + +Added as bug #4579. +https://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4579&group_id=2938 + +\start +Date: Sat, 02 Aug 2003 12:04:16 +0200 +From: David MENTRE +To: Camm Maguire +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Re: [Gcl-devel] Re: serveral bugs in codebase + +Camm Maguire writes: + +> In any case, I've made some progress here (compiling with safety 3). + +I have added the bug and your proposed solution as bug #4580. + https://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4580&group_id=2938 + +\start +Date: Sat, 02 Aug 2003 12:14:01 +0200 +From: David MENTRE +To: Jason White +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Axiom for Linux available + +Jason White writes: + +> (1) -> )summary +> cat: /home/jason/axiom/mnt/linux/lib/summary: No such file or directory + +Added as bug #4581. + +https://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4581&group_id=2938 + +\start +Date: Sat, 02 Aug 2003 13:08:21 +0200 +From: David MENTRE +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] New bugs in bug database + +Hello, + +I have tried to store in the bug database all the bugs that have +popped-up (in fact, unpiling the tons of email I had stored). We have +currently 28 opened bugs. + +I think that some of them are already Closed in Tim's tree. But right +know, I keep them open as we can't check. + +For your information, here are some stats (from [1]): + +== Open Bugs By 'Category' +interpreter (12) +build process (6) +algebra (7) +lisp system (2) + +== Open Bugs By 'Bug Group' +bug (25) +feature request (2) + +== Open Bugs By 'Assigned to' +camm (1) +None (26) + + +[1] https://savannah.nongnu.org/bugs/reporting/?group=axiom + +\start +Date: Sat, 02 Aug 2003 15:19:52 +0200 +From: David MENTRE +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] axiom.input + +Hello, + +"Weiss, Juergen" writes: + +> 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. + +This is fixed with the following patch: + +--- src/interp/i-toplev.boot.pamphlet.orig Thu Jul 31 23:27:32 2003 ++++ src/interp/i-toplev.boot.pamphlet Sat Aug 2 15:15:48 2003 +@@ -79,12 +79,12 @@ + SETQ($CURRENT_-DIRECTORY,_*DEFAULT_-PATHNAME_-DEFAULTS_*) + if null(l) then + if $displayStartMsgs then +- sayKeyedMsg("S2IZ0053",[namestring ['axiom,'input]]) ++ sayKeyedMsg("S2IZ0053",[namestring ['_.axiom,'input]]) + readSpadProfileIfThere() + if $displayStartMsgs then spadStartUpMsgs() + if $OLDLINE then + SAY fillerSpaces($LINELENGTH,'"=") +- sayKeyedMsg("S2IZ0050",[namestring ['axiom,'input]]) ++ sayKeyedMsg("S2IZ0050",[namestring ['_.axiom,'input]]) + if $OLDLINE ^= 'END__UNIT + then + centerAndHighlight($OLDLINE,$LINELENGTH,'" ") +@@ -99,7 +99,7 @@ + + readSpadProfileIfThere() == + -- reads SPADPROF INPUT if it exists +- file := ['axiom,'input] ++ file := ['_.axiom,'input] + MAKE_-INPUT_-FILENAME file => + SETQ(_/EDITFILE,file) + _/RQ () + + +\start +Date: Sat, 2 Aug 2003 16:51:52 -0400 +From: root +To: weiss@uni-mainz.de, david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] axiom.input renamed to .axiom.input + +Juergen, David, + +These two patches have been applied. I've also made a note in the +Makefile.pamphlet file as a FAQ item that the file has been renamed. +This is incompatible with previous Axiom versions but is a reasonable +change to follow convention. + +The complete algebra build is coming together. I'm going to be on +vacation at my mom's for the coming weekend so I expect to get a +lot done over the vacation. A build-from-scratch algebra system is +within reach in that timeframe. I've only encountered 4 files that +won't build so far so things are looking very good. + +\start +Date: Sat, 2 Aug 2003 16:10:05 -0400 +From: root +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] conference + +*, + +I'll be away at ISSAC for the week. It is unclear what network access +I will have on any given day so there may be some delay in replies. + +\start +Date: Sat, 2 Aug 2003 10:54:22 -0400 +From: root +To: david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Axiom for Linux available + +David, + +Good job. I'll review the bugs as soon as we return. -- Tim + +\start +Date: Sun, 3 Aug 2003 09:38:40 -0400 +From: root +To: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] contacting Linux distributors + +*, + +We have a major "business" opportunity in the near future. +(No, this isn't spam but it sure starts out that way :-) ) + +RedHat is changing its distribution model so that they maintain less +of a distribution and accept more packages directly from the developers. +I'm unfamiliar with the details of this change but it gives us a chance +to reach a larger audience. + +We need to make a coordinated effort to identify and contact the major +Linux distributors (at least RehHat, SUSE, Debian, etc) to + +(a) understand their policy for "accepting and blessing" a package +(b) understand their requirements for pacakging (rpm, apt, etc) +(c) understand their config requirements +(d) understand their user interface requirements +(e) understand their support requirements + +we need to "market" to them that they have a "hole" in their "product +line" in that they do not have an industrial strength scientific +computation system. We need to explain that Mathematica, Maple, MuPAD, +etc. are widely used and that Axiom can be a free alternative. + +It is still early in our "product cycle" but a stand-alone algebra build +is frightenly close to reality and the rest of the system is targeted +to be built by year end. At which point the first, major effort will be +completed. + +We need to find "distributors" and RedHat's changing business model is +a major opportunity. + +Is there anyone on the list who is interested in "taking the lead" +in the "marketing" department and coordinating "vendor" contacts? +It would involve emailing, cold-calling, and coordinating vendors to +gather the above "market requirements" and then making a plan with +the vendors to coordinate becoming part of their distribution. It is +essential that we find the right people to talk to within each +distributor, that we work closely with them to feed their requirements +to the developers, and that they generally have a positive and professional +experience when working with us. + +I understand that the prevailing "business model" of open source projects +is "build it and they will come". I want to change that to "build it and +deliver it to everyone's desktop". Yes, I know not everyone needs it but +having just one major vendor like RedHat or SUSE would put us in every +school and business worlwide. + +The personal advantage to you is that you get a list of contacts within +the major vendors. You could leverage this to represent other open source +products with the same model. + +I will, unfortunately, be only partially available until Aug 10th, as +I'll be at a conference. So your "classwork" assignment is to discuss +this among yourselves and volunteer to set something up. + +\start +Date: Sun, 3 Aug 2003 09:05:08 -0700 (PDT) +From: C Y +To: daly@idsi.net, axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] Re: [Axiom-mail] contacting Linux distributors + +--- root wrote: + +> We need to make a coordinated effort to identify and contact the +> major Linux distributors (at least RehHat, SUSE, Debian, etc) + +Gentoo :-). + +\start +Date: 04 Aug 2003 10:18:06 -0400 +From: Camm Maguire +To: David MENTRE +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: [Gcl-devel] Re: serveral bugs in codebase + +Thanks David! I hope to have a more elegant option using ffi soon. +Doesn't sound like the priority is too high here. + +Take care, + +David MENTRE writes: + +> Camm Maguire writes: +> +> > In any case, I've made some progress here (compiling with safety 3). +> +> I have added the bug and your proposed solution as bug #4580. +> https://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4580&group_id=2938 +> + +\start +Date: Mon, 04 Aug 2003 14:05:59 +0200 +From: David MENTRE +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] Re: [Axiom-mail] contacting Linux distributors + +Hello Tim, + +root writes: + +> We need to make a coordinated effort to identify and contact the major +> Linux distributors (at least RehHat, SUSE, Debian, etc) to + +As far as Debian is concerned... + +> (a) understand their policy for "accepting and blessing" a package + +... you need to be an official Debian Developer (a long and not so easy +process)... + +> (b) understand their requirements for pacakging (rpm, apt, etc) +> (c) understand their config requirements +> (d) understand their user interface requirements +> (e) understand their support requirements + +... and, for (b) to (e), follow the Debian Policy Manual: + http://www.fr.debian.org/doc/debian-policy/ + +That's said, for Debian there are two alternatives: + + 1. Camm is an official debian developer, so he might be willing to + package Axiom + + 2. A friend of mine wants to make a debian package so he /might/ be + interested in packaging Axiom. Of course, once made, the package + will have to be "blessed" by an official debian developer. It's up + to him now to decide if he wants to do it or no. + + +> we need to "market" to them that they have a "hole" in their "product +> line" in that they do not have an industrial strength scientific +> computation system. We need to explain that Mathematica, Maple, MuPAD, +> etc. are widely used and that Axiom can be a free alternative. + +I personally think that explaining what is Axiom, compared to +Mathematica & Co., is the role of the main page of the Axiom website +(with screenshots, binaries, ...). We will have to present tutorials, +papers, etc. + +I have stored all the references posted by Bill Page and links posted by +Jason White. That might be a good start for a web page. + +By the way, friend of mine in Gulliver (the local Linux User Group here +in Rennes) and I are willing to provide Axiom's binaries for x86, +PowerPC and Linux-Sparc64. + + +> I understand that the prevailing "business model" of open source projects +> is "build it and they will come". I want to change that to "build it and +> deliver it to everyone's desktop". Yes, I know not everyone needs it but +> having just one major vendor like RedHat or SUSE would put us in every +> school and business worlwide. + +I still do believe that "build it and they will come" is the right think +to do. Of course, we can ease the process by providing pre-build +packages. But I think that developers from major and minor linux +distribution will come if we can show the capabilities of Axiom. + + +Sorry to be so negative towards your initial proposal. + +\start +Date: 04 Aug 2003 13:10:09 -0400 +From: Camm Maguire +To: daly@idsi.net +Subject: Re: [Axiom-developer] contacting Linux distributors +Cc: axiom-developer@nongnu.org, axiom-mail@nongnu.org + +Greetings! + +root writes: + +> *, +> +> We have a major "business" opportunity in the near future. +> (No, this isn't spam but it sure starts out that way :-) ) +> +> RedHat is changing its distribution model so that they maintain less +> of a distribution and accept more packages directly from the developers. +> I'm unfamiliar with the details of this change but it gives us a chance +> to reach a larger audience. +> +> We need to make a coordinated effort to identify and contact the major +> Linux distributors (at least RehHat, SUSE, Debian, etc) to +> + +I was planning on submitting/maintaining the Debian pakcage of axiom +when its released. I'm already a Debian developer. I maintain gcl, +maxima, and acl2 for Debian already. + + +> (a) understand their policy for "accepting and blessing" a package +> (b) understand their requirements for pacakging (rpm, apt, etc) +> (c) understand their config requirements +> (d) understand their user interface requirements +> (e) understand their support requirements +> +> we need to "market" to them that they have a "hole" in their "product +> line" in that they do not have an industrial strength scientific +> computation system. We need to explain that Mathematica, Maple, MuPAD, +> etc. are widely used and that Axiom can be a free alternative. +> +> It is still early in our "product cycle" but a stand-alone algebra build +> is frightenly close to reality and the rest of the system is targeted +> to be built by year end. At which point the first, major effort will be +> completed. +> +> We need to find "distributors" and RedHat's changing business model is +> a major opportunity. +> +> Is there anyone on the list who is interested in "taking the lead" +> in the "marketing" department and coordinating "vendor" contacts? +> It would involve emailing, cold-calling, and coordinating vendors to +> gather the above "market requirements" and then making a plan with +> the vendors to coordinate becoming part of their distribution. It is +> essential that we find the right people to talk to within each +> distributor, that we work closely with them to feed their requirements +> to the developers, and that they generally have a positive and professional +> experience when working with us. +> +> I understand that the prevailing "business model" of open source projects +> is "build it and they will come". I want to change that to "build it and +> deliver it to everyone's desktop". Yes, I know not everyone needs it but +> having just one major vendor like RedHat or SUSE would put us in every +> school and business worlwide. +> +> The personal advantage to you is that you get a list of contacts within +> the major vendors. You could leverage this to represent other open source +> products with the same model. +> +> I will, unfortunately, be only partially available until Aug 10th, as +> I'll be at a conference. So your "classwork" assignment is to discuss +> this among yourselves and volunteer to set something up. + +\start +Date: Fri, 08 Aug 2003 22:19:21 +0200 +From: David MENTRE +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] hacking-tips-n-tricks.input.pamphlet + +Hello, + +I have collected Tim's posts on this list regarding way to hack more +easily on Axiom. Here is the resulting .pamphlet file. + +You can produce it with the following commands: + noweave -delay hacking-tips-n-tricks.input.pamphlet > hacking-tips-n-tricks.tex + latex hacking-tips-n-tricks.tex + latex hacking-tips-n-tricks.tex + +(I suppose you have the noweb package installed somewhere) + +Best regards, +d. + +\documentclass{article} +\usepackage{noweb} +\begin{document} +\title{Tips \& tricks to hack on Axiom} +\author{Nicolas Bourbaki} +\date{8th of August, 2003} +\maketitle +\begin{abstract} +This short document gives some hints to hack on Axiom. All of those tips +come from posts by Tim Daly on axiom-developer mailing list during +July 2003. +\end{abstract} + +\tableofcontents + +\section{Playing with lisp in Axiom} + +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) +@ + +\section{Direct typing of lisp under Axiom's interpreter} + +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. + +\section{Setting your startup preferences} + +If you add a file in your home directory called ``[[axiom.input]]'' (or +``[[.axiom.input]]'', depending on your CVS version) it will be read and +executed when axiom starts. This is useful for various reasons including +setting various switches. Mine reads: + +<<.axiom.input>>= +)lisp (pprint "running .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 +\emph{also} be run while you are doing a "make" in Axiom compilation so +be careful what you ask do. + +\section{Knowing the current Axiom's version} + +There is code (called yearweek) in [[src/interp/util.lisp.pamphlet]] +that \emph{timestamps} Axiom during the build process. The format of +Axiom's version number is (badly) documented in the file. It is also +documented in [[src/interp/Makefile.pamphlet]]. It is a variable of the +form: +\begin{quote} + YYYYMMDDxxx where YYYY is the year, MM is the month, DD is the day + and xxx is a unique number identifying a build. +\end{quote} + +Every interpsys image should have a [[*yearweek*]] variable, thus: + +<>= +)lisp *yearweek* +@ + +should give you the current version of your Axiom. + +\section{Controlling Axiom's break behavior} + +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. + +\section{Getting lisp code generated from boot code} + +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 + +\section{Getting lisp code from algebra code} + +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 +@ + +\section{Observing the Axiom interpreter at work} + +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. + +\section{On Axiom's frames} + +Axiom stores its variable bindings in a ``\emph{frame}'' which, +internally is an alist stored in the variable [[|$InteractiveFrame|]]. + +Suppose you have the following Axiom interpreter command: + +<>= +dom:=MonoidRing(Polynomial PrimeField 5, Permutation Integer) +@ + + +If you create the 'dom' variable above you can see it by doing: + +<>= +)lisp (pprint |$InteractiveFrame|) +@ + +\section{Looking into dynamic lookups of Axiom} + +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. + +\end{document} + +\start +Date: Sat, 9 Aug 2003 17:03:58 +0200 +From: "Weiss, Juergen" +To: +Subject: [Axiom-developer] compiling the algebra files with gcl + +Hi, + +I finally managed to get gcl compiled on a debian linux system. So +I tried to compile axiom with gcl as well. + +I used the makefile and the small modifications to the algebra +files, which sucessfully compiled with cmu lisp. I ran into similar +problems as with the cmu build of the algebra, namely that the +database files distributed do not exactly fit the algebra +(especially with linear ordinary differential equations, but some others +as well). Compiling some files with some others manually +preloaded and rebuilding the database files and the interpsys +image several times, I was finally able to compile all algebra +files. Right now, I try to compile all the algebra files from +scratch with the new database files. This will take a while +and I will report success or failure as soon as the compilation +will have finished. + +\start +Date: 09 Aug 2003 21:48:42 -0400 +From: Camm Maguire +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Greetings! + +Great Juergen! I'd especially be interested in the steps you've +taken, and in whether the duplicate set issue remains in your final +build. Please drop me a line if you have the time. + +Take care, + +"Weiss, Juergen" writes: + +> Hi, +> +> I finally managed to get gcl compiled on a debian linux system. So +> I tried to compile axiom with gcl as well. +> +> I used the makefile and the small modifications to the algebra +> files, which sucessfully compiled with cmu lisp. I ran into similar +> problems as with the cmu build of the algebra, namely that the +> database files distributed do not exactly fit the algebra +> (especially with linear ordinary differential equations, but some others +> as well). Compiling some files with some others manually +> preloaded and rebuilding the database files and the interpsys +> image several times, I was finally able to compile all algebra +> files. Right now, I try to compile all the algebra files from +> scratch with the new database files. This will take a while +> and I will report success or failure as soon as the compilation +> will have finished. + +\start +Date: Sun, 10 Aug 2003 09:21:41 +0200 +From: "Weiss, Juergen" +To: "Camm Maguire" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] compiling the algebra files with gcl + +Hi Camm, + +the set issue does not occur anymore. I have put a tgz file +under http://www.uni-mainz.de/~weiss/axiom.algebra.jw.20030810.tgz +It contains the src/algebra (I did not include a diff, because I'm +uncertain about the base), the share/algebra database files, +and a Makefile.inc for the axiom root and a Makefile in the +src/algebra directory. You must fix the axiom root in Makefile.inc, +then you should be able to compile the algebra in src/algebra +directly. Sorry, but I do not have pamphlet files for the +Makefiles. + +The interval.spad file (translated from interval.as) is incomplete +(and some parts are incorrect due to the incompletion), but it +compiles and it lets you compile the rest as well. + + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com] +> Sent: Sunday, August 10, 2003 3:49 AM +> To: Weiss, Juergen +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> +> +> Greetings! +> +> Great Juergen! I'd especially be interested in the steps you've +> taken, and in whether the duplicate set issue remains in your final +> build. Please drop me a line if you have the time. +> +> Take care, +> +> "Weiss, Juergen" writes: +> +> > Hi, +> > +> > I finally managed to get gcl compiled on a debian linux system. So +> > I tried to compile axiom with gcl as well. +> > +> > I used the makefile and the small modifications to the algebra +> > files, which sucessfully compiled with cmu lisp. I ran into similar +> > problems as with the cmu build of the algebra, namely that the +> > database files distributed do not exactly fit the algebra +> > (especially with linear ordinary differential equations, +> but some others +> > as well). Compiling some files with some others manually +> > preloaded and rebuilding the database files and the interpsys +> > image several times, I was finally able to compile all algebra +> > files. Right now, I try to compile all the algebra files from +> > scratch with the new database files. This will take a while +> > and I will report success or failure as soon as the compilation +> > will have finished. + +\start +Date: 11 Aug 2003 12:57:57 -0400 +From: Camm Maguire +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Greetings, and thanks for this! + +Please excuse me, but I am still a bit unclear. After unpacking your +tree, do I need to insert these directories in place of their +counterparts in my copy of the full CVS tree, or can I unpack +elsewhere, and set variables to refer to my existing build where +needed? + +Take care, + +"Weiss, Juergen" writes: + +> Hi Camm, +> +> the set issue does not occur anymore. I have put a tgz file +> under http://www.uni-mainz.de/~weiss/axiom.algebra.jw.20030810.tgz +> It contains the src/algebra (I did not include a diff, because I'm +> uncertain about the base), the share/algebra database files, +> and a Makefile.inc for the axiom root and a Makefile in the +> src/algebra directory. You must fix the axiom root in Makefile.inc, +> then you should be able to compile the algebra in src/algebra +> directly. Sorry, but I do not have pamphlet files for the +> Makefiles. +> +> The interval.spad file (translated from interval.as) is incomplete +> (and some parts are incorrect due to the incompletion), but it +> compiles and it lets you compile the rest as well. +> +> +> > -----Original Message----- +> > From: Camm Maguire [mailto:camm@enhanced.com] +> > Sent: Sunday, August 10, 2003 3:49 AM +> > To: Weiss, Juergen +> > Cc: axiom-developer@nongnu.org +> > Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> > +> > +> > Greetings! +> > +> > Great Juergen! I'd especially be interested in the steps you've +> > taken, and in whether the duplicate set issue remains in your final +> > build. Please drop me a line if you have the time. +> > +> > Take care, +> > +> > "Weiss, Juergen" writes: +> > +> > > Hi, +> > > +> > > I finally managed to get gcl compiled on a debian linux system. So +> > > I tried to compile axiom with gcl as well. +> > > +> > > I used the makefile and the small modifications to the algebra +> > > files, which sucessfully compiled with cmu lisp. I ran into similar +> > > problems as with the cmu build of the algebra, namely that the +> > > database files distributed do not exactly fit the algebra +> > > (especially with linear ordinary differential equations, +> > but some others +> > > as well). Compiling some files with some others manually +> > > preloaded and rebuilding the database files and the interpsys +> > > image several times, I was finally able to compile all algebra +> > > files. Right now, I try to compile all the algebra files from +> > > scratch with the new database files. This will take a while +> > > and I will report success or failure as soon as the compilation +> > > will have finished. + +\start +Date: 11 Aug 2003 15:51:07 -0400 +From: Camm Maguire +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Hello again! Just an update, I replace src/algebra with Juergen's +tree, installed and edited his Makefile.inc, and then attempted a +clean build. + +Fails at this point: + +============================================================================= +0 making /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB from /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.spad + +(AXIOM Sockets) The AXIOM server number is undefined. +----------------------------------------------------------------------------- + Issue )copyright to view copyright notices. + Issue )summary for a summary of useful system commands. + Issue )quit to leave AXIOM and return to shell. +Monday July 28, 2003 at 18:57:13 +----------------------------------------------------------------------------- + +(1) -> Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/apply. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/c-doc. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/c-util. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/profile. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/category. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/compiler. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/define. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/functor. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/info. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/iterator. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/modemap. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/nruncomp. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/package. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/htcheck. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/xruncomp. + Compiling AXIOM source code from file + /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.spad using + old system compiler. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/parsing. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/bootlex. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/def. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/fnewmeta. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/metalex. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/metameta. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/parse. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/postpar. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/postprop. + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/preparse. + 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) +(1) -> Please enter y or yes if you really want to leave the interactive + environment and return to the operating system: +0 making /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/algebra/LODO1.o from /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB +cp: cannot stat `/fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB/code.o': No such file or directory +============================================================================= + +Take care, + +"Weiss, Juergen" writes: + +> Hi Camm, +> +> the set issue does not occur anymore. I have put a tgz file +> under http://www.uni-mainz.de/~weiss/axiom.algebra.jw.20030810.tgz +> It contains the src/algebra (I did not include a diff, because I'm +> uncertain about the base), the share/algebra database files, +> and a Makefile.inc for the axiom root and a Makefile in the +> src/algebra directory. You must fix the axiom root in Makefile.inc, +> then you should be able to compile the algebra in src/algebra +> directly. Sorry, but I do not have pamphlet files for the +> Makefiles. +> +> The interval.spad file (translated from interval.as) is incomplete +> (and some parts are incorrect due to the incompletion), but it +> compiles and it lets you compile the rest as well. +> + +> > -----Original Message----- +> > From: Camm Maguire [mailto:camm@enhanced.com] +> > Sent: Sunday, August 10, 2003 3:49 AM +> > To: Weiss, Juergen +> > Cc: axiom-developer@nongnu.org +> > Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> > +> > +> > Greetings! +> > +> > Great Juergen! I'd especially be interested in the steps you've +> > taken, and in whether the duplicate set issue remains in your final +> > build. Please drop me a line if you have the time. +> > +> > "Weiss, Juergen" writes: +> > +> > > Hi, +> > > +> > > I finally managed to get gcl compiled on a debian linux system. So +> > > I tried to compile axiom with gcl as well. +> > > +> > > I used the makefile and the small modifications to the algebra +> > > files, which sucessfully compiled with cmu lisp. I ran into similar +> > > problems as with the cmu build of the algebra, namely that the +> > > database files distributed do not exactly fit the algebra +> > > (especially with linear ordinary differential equations, +> > but some others +> > > as well). Compiling some files with some others manually +> > > preloaded and rebuilding the database files and the interpsys +> > > image several times, I was finally able to compile all algebra +> > > files. Right now, I try to compile all the algebra files from +> > > scratch with the new database files. This will take a while +> > > and I will report success or failure as soon as the compilation +> > > will have finished. + +\start +Date: Mon, 11 Aug 2003 15:57:11 -0400 +From: root +To: partner@redflag-linux.com +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Red Flag package requirements + +Gentlemen, + +I was given this address as a contact point for the developers of +your Linux distribution. + +My name is Tim Daly. I am the lead developer on the Axiom project +(http://savannah.nongnu.org/projects/axiom). Axiom is a computer +algebra system that was originally developed at IBM Research. It +was later sold commercially by the Numerical Algorithms Group. As +of September, 2002 it was withdrawn from the market and released +as free and open source code. + +Axiom is a recognized, world-class computer algebra system similar +in scope to Mathematica and Maple. The released system is still being +restructured but we expect to have an initial distribution, including +sources, by year end. The system is licensed under the Modified BSD. + +Axiom's primary audience is academic with a strong following by +researchers, teachers, and students. These groups tend to be early +users of technology such as Linux. + +We are planning to make Axiom run on all of the major operating +system distributions. Can you forward this mail to someone who can +provide technical requirements for working with your distribution? + +We look forward to a mutually cooperative effort that will enhance +your distribution's value to your customers and provide Axiom with +a wider audience. + +Please feel free to contact me at your convenience. + +Thank you. + +\start +Date: Mon, 11 Aug 2003 21:58:00 +0200 +From: "Weiss, Juergen" +To: "Camm Maguire" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] compiling the algebra files with gcl + +Did you install the new database files (share/algebra) as +well and generated a fresh interpsys with that database? +The old database contains definitions, which conflict +with the distributed algebra sources. + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com] +> Sent: Monday, August 11, 2003 9:51 PM +> To: Weiss, Juergen +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> +> +> Hello again! Just an update, I replace src/algebra with Juergen's +> tree, installed and edited his Makefile.inc, and then attempted a +> clean build. +> +> Fails at this point: +> +> = +========================== +========================== +============ +> =============== +> 0 making +> /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB +> from /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.spad +> +> (AXIOM Sockets) The AXIOM server number is undefined. +> -------------------------------------------------------------- +> --------------- +> Issue )copyright to view copyright notices. +> Issue )summary for a summary of useful system commands. +> Issue )quit to leave AXIOM and return to shell. +> Monday July 28, 2003 at 18:57:13 +> -------------------------------------------------------------- +> --------------- +> +> (1) -> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/apply. +> Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/c-doc. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/c-util. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/profile. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/category. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/compiler. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/define. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/functor. +> Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/info. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/iterator. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/modemap. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/nruncomp. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/package. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/htcheck. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/xruncomp. +> Compiling AXIOM source code from file +> /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.spad using +> old system compiler. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/parsing. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/bootlex. +> Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/def. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/fnewmeta. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/metalex. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/metameta. +> Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/parse. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/postpar. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/postprop. +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/preparse. +> 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) +> (1) -> Please enter y or yes if you really want to leave +> the interactive +> environment and return to the operating system: +> 0 making +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/algebra/LODO1.o +> from /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB +> cp: cannot stat +> `/fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB/cod +> e.o': No such file or directory + +> +> > Hi Camm, +> > +> > the set issue does not occur anymore. I have put a tgz file +> > under http://www.uni-mainz.de/~weiss/axiom.algebra.jw.20030810.tgz +> > It contains the src/algebra (I did not include a diff, because I'm +> > uncertain about the base), the share/algebra database files, +> > and a Makefile.inc for the axiom root and a Makefile in the +> > src/algebra directory. You must fix the axiom root in Makefile.inc, +> > then you should be able to compile the algebra in src/algebra +> > directly. Sorry, but I do not have pamphlet files for the +> > Makefiles. +> > +> > The interval.spad file (translated from interval.as) is incomplete +> > (and some parts are incorrect due to the incompletion), but it +> > compiles and it lets you compile the rest as well. + +> > > -----Original Message----- +> > > From: Camm Maguire [mailto:camm@enhanced.com] +> > > Sent: Sunday, August 10, 2003 3:49 AM +> > > To: Weiss, Juergen +> > > Cc: axiom-developer@nongnu.org +> > > Subject: Re: [Axiom-developer] compiling the algebra +> files with gcl +> > > +> > > +> > > Greetings! +> > > +> > > Great Juergen! I'd especially be interested in the steps you've +> > > taken, and in whether the duplicate set issue remains in +> your final +> > > build. Please drop me a line if you have the time. +> > > +> > > Take care, +> > > +> > > "Weiss, Juergen" writes: +> > > +> > > > Hi, +> > > > +> > > > I finally managed to get gcl compiled on a debian linux +> system. So +> > > > I tried to compile axiom with gcl as well. +> > > > +> > > > I used the makefile and the small modifications to the algebra +> > > > files, which sucessfully compiled with cmu lisp. I ran +> into similar +> > > > problems as with the cmu build of the algebra, namely that the +> > > > database files distributed do not exactly fit the algebra +> > > > (especially with linear ordinary differential equations, +> > > but some others +> > > > as well). Compiling some files with some others manually +> > > > preloaded and rebuilding the database files and the interpsys +> > > > image several times, I was finally able to compile all algebra +> > > > files. Right now, I try to compile all the algebra files from +> > > > scratch with the new database files. This will take a while +> > > > and I will report success or failure as soon as the compilation +> > > > will have finished. + +\start +Date: Mon, 11 Aug 2003 16:00:40 -0400 +From: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Camm, + +lodo.spad fails to compile. I think it is listed in the known bugs file. + +Tim + +\start +Date: Mon, 11 Aug 2003 20:13:08 -0400 +From: root +To: weiss@uni-mainz.de, axiom-developer@nongnu.org +Cc: daly@idsi.net +Subject: [Axiom-developer] make to ${MAKE} + +Done. I forgot to fix the field that says "Won't fix". +perhaps I was in a bad mood :-) +or perhaps I need training on how to fix bug reports. sigh. + +\start +Date: 12 Aug 2003 10:13:34 -0400 +From: Camm Maguire +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Greetings! + +"Weiss, Juergen" writes: + +> Did you install the new database files (share/algebra) as +> well and generated a fresh interpsys with that database? +> The old database contains definitions, which conflict +> with the distributed algebra sources. +> + +I hadn't -- thanks for pointing this out. However, after moving +share/algebra over too, make clean, and then make, lodo1 still fails +to compile, as separately noted by Tim. Do your changes resolve the +lodo1 compilation issue? + +Take care, +> +> > -----Original Message----- +> > From: Camm Maguire [mailto:camm@enhanced.com] +> > Sent: Monday, August 11, 2003 9:51 PM +> > To: Weiss, Juergen +> > Cc: axiom-developer@nongnu.org +> > Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> > +> > +> > Hello again! Just an update, I replace src/algebra with Juergen's +> > tree, installed and edited his Makefile.inc, and then attempted a +> > clean build. +> > +> > Fails at this point: +> > +> > ============================================================== +> > =============== +> > 0 making +> > /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB +> > from /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.spad +> > +> > (AXIOM Sockets) The AXIOM server number is undefined. +> > -------------------------------------------------------------- +> > --------------- +> > Issue )copyright to view copyright notices. +> > Issue )summary for a summary of useful system commands. +> > Issue )quit to leave AXIOM and return to shell. +> > Monday July 28, 2003 at 18:57:13 +> > -------------------------------------------------------------- +> > --------------- +> > +> > (1) -> Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/apply. +> > Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/c-doc. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/c-util. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/profile. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/category. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/compiler. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/define. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/functor. +> > Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/info. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/iterator. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/modemap. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/nruncomp. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/package. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/htcheck. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/xruncomp. +> > Compiling AXIOM source code from file +> > /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.spad using +> > old system compiler. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/parsing. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/bootlex. +> > Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/def. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/fnewmeta. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/metalex. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/metameta. +> > Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/parse. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/postpar. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/postprop. +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/preparse. +> > 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) +> > (1) -> Please enter y or yes if you really want to leave +> > the interactive +> > environment and return to the operating system: +> > 0 making +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/algebra/LODO1.o +> > from /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB +> > cp: cannot stat +> > `/fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB/cod +> > e.o': No such file or directory +> > ============================================================== +> > =============== +> > +> > Take care, +> > +> > "Weiss, Juergen" writes: +> > +> > > Hi Camm, +> > > +> > > the set issue does not occur anymore. I have put a tgz file +> > > under http://www.uni-mainz.de/~weiss/axiom.algebra.jw.20030810.tgz +> > > It contains the src/algebra (I did not include a diff, because I'm +> > > uncertain about the base), the share/algebra database files, +> > > and a Makefile.inc for the axiom root and a Makefile in the +> > > src/algebra directory. You must fix the axiom root in Makefile.inc, +> > > then you should be able to compile the algebra in src/algebra +> > > directly. Sorry, but I do not have pamphlet files for the +> > > Makefiles. +> > > +> > > The interval.spad file (translated from interval.as) is incomplete +> > > (and some parts are incorrect due to the incompletion), but it +> > > compiles and it lets you compile the rest as well. +> > > +> > > > -----Original Message----- +> > > > From: Camm Maguire [mailto:camm@enhanced.com] +> > > > Sent: Sunday, August 10, 2003 3:49 AM +> > > > To: Weiss, Juergen +> > > > Cc: axiom-developer@nongnu.org +> > > > Subject: Re: [Axiom-developer] compiling the algebra +> > files with gcl +> > > > +> > > > +> > > > Greetings! +> > > > +> > > > Great Juergen! I'd especially be interested in the steps you've +> > > > taken, and in whether the duplicate set issue remains in +> > your final +> > > > build. Please drop me a line if you have the time. +> > > > +> > > > Take care, +> > > > +> > > > "Weiss, Juergen" writes: +> > > > +> > > > > Hi, +> > > > > +> > > > > I finally managed to get gcl compiled on a debian linux +> > system. So +> > > > > I tried to compile axiom with gcl as well. +> > > > > +> > > > > I used the makefile and the small modifications to the algebra +> > > > > files, which sucessfully compiled with cmu lisp. I ran +> > into similar +> > > > > problems as with the cmu build of the algebra, namely that the +> > > > > database files distributed do not exactly fit the algebra +> > > > > (especially with linear ordinary differential equations, +> > > > but some others +> > > > > as well). Compiling some files with some others manually +> > > > > preloaded and rebuilding the database files and the interpsys +> > > > > image several times, I was finally able to compile all algebra +> > > > > files. Right now, I try to compile all the algebra files from +> > > > > scratch with the new database files. This will take a while +> > > > > and I will report success or failure as soon as the compilation +> > > > > will have finished. + +\start +Date: Tue, 12 Aug 2003 17:44:56 +0200 +From: "Weiss, Juergen" +To: "Camm Maguire" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] compiling the algebra files with gcl + +Hi, + +yes, with the changes to the algebra files and the +new database files I was able to compile all the +algebra files (with just a call to make in src/algebra). + +Did you do a make clean in the toplevel directory? + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com] +> Sent: Tuesday, August 12, 2003 4:14 PM +> To: Weiss, Juergen +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> +> Greetings! +> +> "Weiss, Juergen" writes: +> +> > Did you install the new database files (share/algebra) as +> > well and generated a fresh interpsys with that database? +> > The old database contains definitions, which conflict +> > with the distributed algebra sources. +> > +> +> I hadn't -- thanks for pointing this out. However, after moving +> share/algebra over too, make clean, and then make, lodo1 still fails +> to compile, as separately noted by Tim. Do your changes resolve the +> lodo1 compilation issue? +> +> Take care, +> +> > Juergen +> + +\start +Date: Tue, 12 Aug 2003 12:03:09 -0400 +From: root +To: weiss@uni-mainz.de +Cc: camm@enhanced.com, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +GCL still seems to have a remaining issue. The following 5 domains +won't compile: CPIMA COMBF D01AGNT d01WGTS INBFF + +I'm still finishing the remaining 231 domains which should take another +30 hours or so. After that I'll look into the compile issue with these +domains. + +\start +Date: Tue, 12 Aug 2003 18:21:18 +0200 +From: "Weiss, Juergen" +To: +Cc: camm@enhanced.com, axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] compiling the algebra files with gcl + +I was able to compile these files as well (with cmu and with gcl). + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Tuesday, August 12, 2003 6:03 PM +> To: Weiss, Juergen +> Cc: camm@enhanced.com; axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> +> GCL still seems to have a remaining issue. The following 5 domains +> won't compile: CPIMA COMBF D01AGNT d01WGTS INBFF +> +> I'm still finishing the remaining 231 domains which should +> take another +> 30 hours or so. After that I'll look into the compile issue with these +> domains. + +\start +Date: Tue, 12 Aug 2003 19:03:58 +0200 +From: David MENTRE +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] make to ${MAKE} + +Hi Tim, + +Glad to see you on board again. I hope we will see a new CVS snapshot +soon. It seems that we are close to a 0.1 release. :) + +root writes: + +> Done. I forgot to fix the field that says "Won't fix". +> perhaps I was in a bad mood :-) +> or perhaps I need training on how to fix bug reports. sigh. + +By the way, could you next time say something like "changed 'make' in +'${MAKE}' in all Makefile.pamphlet" instead of "fixed" in your Follow-up +Comments to the bug? It's much easier for mere mortal to follow bug +fixing. Or maybe we should promote a literate bug report system. :) + +\start +Date: Tue, 12 Aug 2003 13:18:44 -0400 +From: root +To: david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] make to ${MAKE} + +actually, there were 2 "fixed" messages for that make bug report. +the first one had a comment attached that said changed make to ${MAKE} +but was classified as "won't fix". + +the second one updated the first to change the "won't fix" to "fixed" status. + +the usual "luser" error as i hadn't used savannah's bug tracker before. + +the CVS for savannah is frightenly close. i have to finish the algebra +lattice (estimate 30 hours given the current rate of 8 per hour) and +automate the database build (est 8 hours). i'd also like to automate +the regression testing but that can wait. + +there are a few domains that still won't compile but getting a version +up on savannah is more important. besides, then i can get you guys to +help debug :-) + +version numbers, by the way, are going to be in "*yearweek*" format +which is printed (badly) at the initial command prompt. i don't find +the usual v3.1.4.1.5.9.2.6 version numbers useful. yearweek at least +tells you when the build was done. + +if i can figure out the magic command to add tags to CVS files i plan +to tag each release so we can regress to the correct level for bug +testing. i'll have to try out tagging on tenkan's cvs as i've never +done it before and cvs has a way of persisting my mistakes :-) + +\start +Date: Tue, 12 Aug 2003 19:38:16 +0200 +From: David MENTRE +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Tagging in CVS (was: Re: [Axiom-developer] make to ${MAKE}) + +Tim, + +It seems that your comment was lost at some point. Anyway, it doesn't +matter. + +root writes: + +> if i can figure out the magic command to add tags to CVS files i plan + +Use the CVS 'rtag' command. + +See section 3. in following documentation: + + CVS Branch and Tag Primer + http://cepa.fnal.gov/CPD/CPD/cvs_branches.html + + 3.1 Creating a Tag + + In order to name the current end of the main trunk of a module, use the command + cvs rtag Tagname my_module + + In order to name the current end of a branch of a module, use the command + cvs rtag -r Branchname Tagname my_module + + +Otherwise, here is the official documentation: + + 4.4 Tags--Symbolic revisions + http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_4.html#SEC48 + +\start +Date: Tue, 12 Aug 2003 15:21:49 -0400 +From: root +To: amundson@fnal.gov +Cc: axiom-developer@nongnu.org, maxima@www.ma.utexas.edu, daly@idsi.net, gcl-devel@gnu.org, acl2@lists.cc.utexas.edu +Subject: [Axiom-developer] Axiom and Maxima + +Jim, + +I had an interesting discussion with Richard Fateman about testing. +It appears that we can combine Axiom and Maxima in a single image. +It would then be possible to run a function in Axiom at the +command prompt and also run the same function in Maxima from Axiom's +command prompt: + +-> 2+2 => 4 <== execute in Axiom +-> )lisp (maxima) <== the )lisp runs a lisp command +# 2+2 => 4 <== execute in Maxima +# quit <== leave Maxima +-> + +This will greatly facilitate testing and also help the CATS effort along. +I'm not sure of the namespace collision issues but it seems like they +could all be worked out. + +Camm, + +Do you know if Maxima will load into an Axiom workspace? +What issues arise? + +If this works we could easily make "cover domains" for Maxima's +functionality in Axiom. + +I already have plans "in place" (see the +savannah website) to merge ACL2 in a similar way. + +\start +Date: 13 Aug 2003 11:38:10 -0400 +From: Camm Maguire +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Greetings! Just a status update -- I tried again, rechecking +that Juergen's files were in place, make clean, and I do get much +further. At first I was confused by messages of this type: + +============================================================================= + /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB/code + +(1) -> Please enter y or yes if you really want to leave the interactive + environment and return to the operating system: + + >> System error: + %.EOF is not of type SEQUENCE. + +protected-symbol-warn called with (NIL) +============================================================================= + +but this seems to only be a missing 'y' in the input. Now I get to +the following when comiling SFRTCAT.spad: + +============================================================================= + Loading /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/preparse. + SFRTCAT abbreviates category SquareFreeRegularTriangularSetCategory +------------------------------------------------------------------------ + initializing NRLIB SFRTCAT for SquareFreeRegularTriangularSetCategory + compiling into NRLIB SFRTCAT + +;;; *** |SquareFreeRegularTriangularSetCategory| REDEFINED +Time: 0.01 SEC. + + + >> System error: + The function |RegularTriangularSetCategory| is undefined. +============================================================================= + +Juergen, do you get past this point? (I'm assuming yes). If so, I'll +do some more checking. + + +"Weiss, Juergen" writes: + +> Hi, +> +> yes, with the changes to the algebra files and the +> new database files I was able to compile all the +> algebra files (with just a call to make in src/algebra). +> +> Did you do a make clean in the toplevel directory? +> +> > -----Original Message----- +> > From: Camm Maguire [mailto:camm@enhanced.com] +> > Sent: Tuesday, August 12, 2003 4:14 PM +> > To: Weiss, Juergen +> > Cc: axiom-developer@nongnu.org +> > Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> > +> > Greetings! +> > +> > "Weiss, Juergen" writes: +> > +> > > Did you install the new database files (share/algebra) as +> > > well and generated a fresh interpsys with that database? +> > > The old database contains definitions, which conflict +> > > with the distributed algebra sources. +> > > +> > +> > I hadn't -- thanks for pointing this out. However, after moving +> > share/algebra over too, make clean, and then make, lodo1 still fails +> > to compile, as separately noted by Tim. Do your changes resolve the +> > lodo1 compilation issue? + +\start +Date: Wed, 13 Aug 2003 13:08:38 -0400 +From: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] LODO* files won't compile + +It appears, as Juergen points out, that the LODO* issue is due to a +broken database. The databases were originally copied from the NAG +version but need to be updated. The NAG version appears to be broken. +Once I finish the lattice I'll be automating the rebuild of the +databases so this problem should go away. + +\start +Date: Wed, 13 Aug 2003 19:10:52 +0200 +From: "Weiss, Juergen" +To: "Camm Maguire" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] compiling the algebra files with gcl + +Hi, + +yes, I have a axiom.input file in my home directory with +)set quit unprotected + +I had problems with that domain as well, but I thought +I fixed them already with the current database. I will +have a look at it in more detail. + +What you can do is a make -k, there should be only +a very few files where compilation will fail. + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com] +> Sent: Wednesday, August 13, 2003 5:38 PM +> To: Weiss, Juergen +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> +> +> Greetings! Just a status update -- I tried again, rechecking +> that Juergen's files were in place, make clean, and I do get much +> further. At first I was confused by messages of this type: + +> /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB/code +> +> (1) -> Please enter y or yes if you really want to leave +> the interactive +> environment and return to the operating system: +> +> >> System error: +> %.EOF is not of type SEQUENCE. +> +> protected-symbol-warn called with (NIL) + +> +> but this seems to only be a missing 'y' in the input. Now I get to +> the following when comiling SFRTCAT.spad: +> + +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/preparse. +> SFRTCAT abbreviates category +> SquareFreeRegularTriangularSetCategory +> -------------------------------------------------------------- +> ---------- +> initializing NRLIB SFRTCAT for +> SquareFreeRegularTriangularSetCategory +> compiling into NRLIB SFRTCAT +> +> ;;; *** |SquareFreeRegularTriangularSetCategory| REDEFINED +> Time: 0.01 SEC. +> +> +> >> System error: +> The function |RegularTriangularSetCategory| is undefined. +> +> Juergen, do you get past this point? (I'm assuming yes). If so, I'll +> do some more checking. +> +> Take care, +> +> "Weiss, Juergen" writes: +> +> > Hi, +> > +> > yes, with the changes to the algebra files and the +> > new database files I was able to compile all the +> > algebra files (with just a call to make in src/algebra). +> > +> > Did you do a make clean in the toplevel directory? +> > +> > > -----Original Message----- +> > > From: Camm Maguire [mailto:camm@enhanced.com] +> > > Sent: Tuesday, August 12, 2003 4:14 PM +> > > To: Weiss, Juergen +> > > Cc: axiom-developer@nongnu.org +> > > Subject: Re: [Axiom-developer] compiling the algebra +> files with gcl +> > > +> > > Greetings! +> > > +> > > "Weiss, Juergen" writes: +> > > +> > > > Did you install the new database files (share/algebra) as +> > > > well and generated a fresh interpsys with that database? +> > > > The old database contains definitions, which conflict +> > > > with the distributed algebra sources. +> > > > +> > > +> > > I hadn't -- thanks for pointing this out. However, after moving +> > > share/algebra over too, make clean, and then make, lodo1 +> still fails +> > > to compile, as separately noted by Tim. Do your changes +> resolve the +> > > lodo1 compilation issue? + +\start +Date: Wed, 13 Aug 2003 19:14:10 +0200 +From: "Weiss, Juergen" +To: , +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] RE: LODO* files won't compile + +There is actually a target in my Makefile. But the generation +of the database fails, because of a missing file. I just +TOUCHed the file, then the build did work. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Wednesday, August 13, 2003 7:09 PM +> To: camm@enhanced.com +> Cc: Weiss, Juergen; axiom-developer@nongnu.org +> Subject: LODO* files won't compile +> +> +> It appears, as Juergen points out, that the LODO* issue is due to a +> broken database. The databases were originally copied from the NAG +> version but need to be updated. The NAG version appears to be broken. +> Once I finish the lattice I'll be automating the rebuild of the +> databases so this problem should go away. +> + +\start +Date: Wed, 13 Aug 2003 13:30:22 -0400 +From: "Page, Bill" +To: "'Camm Maguire'" , "Weiss, Juergen" , "'root'" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] compiling the algebra files with gcl + +Camm, Tim, Juergen, et al. + +I have just completed compiling the algebra source +provided by Juergen Weiss with no significant errors. +I now have a new running version of Axiom under +RedHat 8.0 that no longer fails the following test + +> pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer) +> p:pgr := 1 +> q:pgr := 1 +> set [p,q] + +What I did was: + + 1) start with the old tenkan.org CVS version + 2) apply all the patches discussed to date on this list + including the patch to bootsys discovered by Camm + 3) untar Juergen Weiss's version of the algebra files + into the new axiom root directory + 4) modify the first line of the Makefile.inc to refer + to the new root. + 5) issue a make from the root to build the whole system + 6) 11 hours later I have a new system. + +I can send the log file containing the output of the make +if anyone is interested. The only errors that occured +were "%.EOF is not of type SEQUENCE" as noted below plus +numerous errors of the form "Unexpected HT command: \spad" +Apparently these are generated by the contents of some +comment lines like + + ++ \\spad{asinh(x)} returns the hyperbolic arc-sine ... + +I will continue to test this new version against some +of the bugs that have been reported. + +-------- + +I noticed that some of the floating bugs that I reported +a few weeks ago using the axiom.tenkan.org version are not +yet included at Savannah so I think I will start these. + +--------- + +Tim, could you please send a few minutes and explain to +us the difference between what you are doing with the +new algebra makefile compared to what Juergen has done? + +Thanks. + +Bill Page. + +> -----Original Message----- +> From: Camm Maguire [mailto:camm@enhanced.com] +> Sent: Wednesday, August 13, 2003 11:38 AM +> To: Weiss, Juergen +> Cc: axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> +> +> Greetings! Just a status update -- I tried again, rechecking +> that Juergen's files were in place, make clean, and I do get much +> further. At first I was confused by messages of this type: +> +> ============================================================== +> =============== +> /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB/code +> +> (1) -> Please enter y or yes if you really want to leave +> the interactive +> environment and return to the operating system: +> +> >> System error: +> %.EOF is not of type SEQUENCE. +> +> protected-symbol-warn called with (NIL) +> ============================================================== +> =============== +> +> but this seems to only be a missing 'y' in the input. Now I get to +> the following when comiling SFRTCAT.spad: +> +> ============================================================== +> =============== +> Loading +> /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/preparse. +> SFRTCAT abbreviates category +> SquareFreeRegularTriangularSetCategory +> -------------------------------------------------------------- +> ---------- +> initializing NRLIB SFRTCAT for +> SquareFreeRegularTriangularSetCategory +> compiling into NRLIB SFRTCAT +> +> ;;; *** |SquareFreeRegularTriangularSetCategory| REDEFINED +> Time: 0.01 SEC. +> +> +> >> System error: +> The function |RegularTriangularSetCategory| is undefined. +> ============================================================== +> =============== +> +> Juergen, do you get past this point? (I'm assuming yes). If so, I'll +> do some more checking. +> +> +> "Weiss, Juergen" writes: +> +> > Hi, +> > +> > yes, with the changes to the algebra files and the +> > new database files I was able to compile all the +> > algebra files (with just a call to make in src/algebra). +> > +> > Did you do a make clean in the toplevel directory? +> > +> > Regards, +> > +> > +> > Juergen Weiss +> > +> > Juergen Weiss | Universitaet Mainz, Zentrum fuer +> Datenverarbeitung, +> > weiss@uni-mainz.de| 55099 Mainz, Tel: +49(6131)39-26361, FAX: +> > +49(6131)39-26407 +> > +> > +> > > -----Original Message----- +> > > From: Camm Maguire [mailto:camm@enhanced.com] +> > > Sent: Tuesday, August 12, 2003 4:14 PM +> > > To: Weiss, Juergen +> > > Cc: axiom-developer@nongnu.org +> > > Subject: Re: [Axiom-developer] compiling the algebra +> files with gcl +> > > +> > > Greetings! +> > > +> > > "Weiss, Juergen" writes: +> > > +> > > > Did you install the new database files (share/algebra) as +> > > > well and generated a fresh interpsys with that database? +> > > > The old database contains definitions, which conflict +> > > > with the distributed algebra sources. +> > > > +> > > +> > > I hadn't -- thanks for pointing this out. However, after moving +> > > share/algebra over too, make clean, and then make, lodo1 +> still fails +> > > to compile, as separately noted by Tim. Do your changes +> resolve the +> > > lodo1 compilation issue? + +\start +Date: Wed, 13 Aug 2003 13:34:20 -0400 +From: root +To: weiss@uni-mainz.de +Cc: camm@enhanced.com, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Re: LODO* files won't compile + +Yes, there is a database rebuild target already in the makefile +but it needs review. I have implemented routines that rebuild the +algebra, rebuild the database, etc (see the code in util.lisp.pamphlet). +Once the system is built from scratch then parts of it can be remade +without trouble. + +\start +Date: 13 Aug 2003 13:56:34 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, maxima@www.ma.utexas.edu, amundson@fnal.gov, gcl-devel@gnu.org, acl2@lists.cc.utexas.edu +Subject: [Axiom-developer] Re: [Gcl-devel] Axiom and Maxima + +Greetings! + +root writes: + +> Jim, +> +> I had an interesting discussion with Richard Fateman about testing. +> It appears that we can combine Axiom and Maxima in a single image. +> It would then be possible to run a function in Axiom at the +> command prompt and also run the same function in Maxima from Axiom's +> command prompt: +> +> -> 2+2 => 4 <== execute in Axiom +> -> )lisp (maxima) <== the )lisp runs a lisp command +> # 2+2 => 4 <== execute in Maxima +> # quit <== leave Maxima +> -> +> +> This will greatly facilitate testing and also help the CATS effort along. +> I'm not sure of the namespace collision issues but it seems like they +> could all be worked out. +> + +An ambitious idea! + +> Camm, +> +> Do you know if Maxima will load into an Axiom workspace? +> What issues arise? +> + +I must confess I do not know much about Axiom workspaces. If they are +like lisp packages, there should not be too much problem. + +> If this works we could easily make "cover domains" for Maxima's +> functionality in Axiom. +> +> I already have plans "in place" (see the +> savannah website) to merge ACL2 in a similar way. +> + +I was looking for this on the site, but could not see anything +pertinent. What am I missing? + +\start +Date: Wed, 13 Aug 2003 19:58:10 +0200 +From: David MENTRE +To: "Bill. Page1 (E-mail)" +Cc: 'Camm Maguire' , axiom-developer@nongnu.org, 'root' +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +"Page, Bill" writes: + +> I noticed that some of the floating bugs that I reported +> a few weeks ago using the axiom.tenkan.org version are not +> yet included at Savannah so I think I will start these. + +Oops. I'm sorry. I did my best to report all bugs but apparently I +missed some. Please do the report on savannah or send to me the emails +where you reported them. + +\start +Date: Wed, 13 Aug 2003 20:05:28 +0200 +From: David MENTRE +To: Camm Maguire +Cc: amundson@fnal.gov, axiom-developer@nongnu.org, maxima@www.ma.utexas.edu, acl2@lists.cc.utexas.edu, gcl-devel@gnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] Re: [Gcl-devel] Axiom and Maxima + +Hi Camm, + +Camm Maguire writes: + +> Tim: +>> I already have plans "in place" (see the +>> savannah website) to merge ACL2 in a similar way. +>> +> +> I was looking for this on the site, but could not see anything +> pertinent. What am I missing? + +I think Tim is refering to the following: + +In http://www.nongnu.org/axiom/ + + BOYER-MOORE THEOREM PROVER INTEGRATION + Motivation: Computational logic is a branch of computer mathematics + that is not currently available in Axiom. The Boyer-Moore + theorem prover, written in common lisp, provides a good + general purpose platform to study the interaction of the + theorem proving systems with Axiom +- Contact Boyer & Moore +- Contact Chandy & Misra +- Download ACL2 + Build ACL2 + Invoke ACL2 from Axiom + Integrate ACL2 into Axiom + Use Dijkstra's methods against SetCategory + Draft research paper + +\start +Date: Wed, 13 Aug 2003 14:36:13 -0400 +From: "Page, Bill" +To: "'David MENTRE'" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] compiling the algebra files with gcl + +David, + +Ok, I've submitted the floating point bug as + + https://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4733&group_id=2938 + +I hope I did it right. This is the first time I've used +Savannah this way. I was a little confused about the +used of some of the fields on the bug report form. Let +me know if you think I could have / should have done it +a little differently. Thanks. + +> -----Original Message----- +> From: David MENTRE [mailto:david.mentre@wanadoo.fr] +> Sent: Wednesday, August 13, 2003 1:58 PM +> To: Bill. Page1 (E-mail) +> Cc: 'Camm Maguire'; Weiss, Juergen; 'root'; axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> +> +> "Page, Bill" writes: +> +> > I noticed that some of the floating bugs that I reported +> > a few weeks ago using the axiom.tenkan.org version are not +> > yet included at Savannah so I think I will start these. +> +> Oops. I'm sorry. I did my best to report all bugs but apparently I +> missed some. Please do the report on savannah or send to me the emails +> where you reported them. + +\start +Date: Wed, 13 Aug 2003 14:43:42 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: camm@enhanced.com, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Juergen's makefile + +re: explaining the difference between Juergen's work and mine... + +I've been continuing the build of the system and have only glanced at +Juergen's work so this is (a) not intended as criticism and (b) not +well founded and open to discussion. + +First, there are dependencies beyond the 19 layers (I'm up to 21 so far) +but the compiles may be insensitive to these. I'm laying out the lattice +because without knowing these dependencies you can't build a system from +scratch. It is possible that after 19 layers there is no point in +continuing but (a) I haven't proven that and (b) I'm nearly finished. +It would be good to figure out how many layers form the minimal set. + +Second, remember that this Makefile is only really used to build the +system from scratch. Once the algebra code exists it is reasonably +insenstive to changes. In particular, changes to these original algebra +files will have to be reviewed carefully before being made so once there +is a running version of the algebra all of this work is basically +documenation. If you need to build the system from scratch on, say a 64 +bit architecture, you really need to understand why it is built that way. + +Third, Juergen's makefile looks a lot simpler as it is shorter and +less verbose. This is, in fact, the trend I'm trying hard to correct. +I'm simply unable to decode: + +@ ( echo '1.$$s,${IN}/\(.*\)/.spad\.pamphlet:<<\(.*\)\.lsp ....... + +well, that's not strictly true but you get the idea. It is important +to remember that I have Makefiles that look like this from long ago. +I like the apparent brevity of the rules. However the machine doesn't care +if there are 3 or 300 rules but humans do and I need to work with Juergen +to reach some compromise. At the moment I'm just using very simple rule +forms rather than GNU make extensions. Dirt simple rules, in fact. + +My main problem with the brief approach goes to the heart of the "new +Axiom". Juergen's makefile includes less than a dozen comment +lines. But think carefully about what this Makefile is doing. It +bridges the gap between the algebra world (where the files are +organized into logical piles of categories, domains, and packages) and +the method of constructing the world from scratch. It contains an +ordering which is required but documented nowhere else. Why does this +ordering exist? What does it imply about the algebra? How will someone +30 years from now figure out what to change, what it affects, and why +it has that effect when the need to change the core algebra files? + +Makefiles document how to build the system. One reason that it has +taken so long to get a running system from the NAG sources is that the +expertise of how to build the system (and it's associated makefiles) +was lost. (Another reason is that you used to need an Axiom to build +an Axiom.) That is partially my fault from the past. I built +Makefiles just like Juergen (and everybody else) does. I wrote +Makefiles for the machine to read. But that is misguided. I can build +a system (witness the downloadable version). But I'm trying to build +it so you guys can understand it, modify it, and maintain it. If we +don't document it then nobody will be able to do these things and +Axiom will die. + +Juergen's makefile is basically a condensed version of mine and is +correct (modulo the other layers). Use it to build and test the algebra. +However, the CVS version is going to end up as a pamphlet file that +leans heavily on explanation. The current version you see has a great +deal of "scaffolding" as I'm keeping build notes in the same file. +These build notes are unnecessary and will be elided eventually. +I need them to form the lattice. + +Again, this isn't a criticism of Juergen's great work. + +\start +Date: Wed, 13 Aug 2003 15:13:39 -0400 +From: root +To: daly@idsi.net, axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: ACL2 list + +(journaling ACL2 note) + +Matt, + +The referenced web page item is mine, not David's. (I'm the lead +developer on Axiom.) I worked with Nqthm years ago (trying to prove a +rule based program written in OPS5) and have recently tried to spin up +on ACL2. The misunderstandings are mine. We've emailed each other a +long time ago but the whole discussion died because I'm still buried +under making Axiom open source. The use and support of ACL2 in Axiom +is, as you can see, still on the todo list. + +Axiom lacks two fundamental things. First, Axiom does not support +proofs. I believe I can correct this issue in the next few years and +ACL2 seems like a well-founded system to use as a basis. Exactly how +this should be done is an open research question. I have some ideas +but I need a running Axiom system to do the research work. + +Second, Axiom's algorithms are unproven. It is going to take +considerable research to figure out how to match ACL2's model to +Axiom's model. I spent a fair amount of time reading ACL2 documents +and Dijkstra's work last summer (shortly after his death) and +pondering this question. At the moment it's all "on the shelf". If you +look at Axiom with a 30 year timeframe it is unacceptable that the +algorithms are unproven. The answers given will still be valid 30 +years from now but how can we trust a system without at least +attempting to prove it correct? + +It is true that Chandy and Misra have nothing to do with ACL2 but they +formed part of my background research on the subject. The latest piece +of background reading (unmentioned on the webpage) is on MetaPRL. + +My apologies for spamming the ACL2 list. + +===================================================================== +Date: Wed, 13 Aug 2003 13:26:04 -0500 +From: Matt Kaufmann +To: david.mentre@wanadoo.fr +Cc: camm@enhanced.com, moore@cs.utexas.edu, daly@idsi.net +Subject: ACL2 list + +Hi -- + +I notice that you just joined the ACL2 list. Welcome! + +I have probably been remiss in waiting to point something about about the ACL2 +list. I believe that most ACL2 users, while very interested in using GCL, are +not likely to be interested in GCL implementation/development issues. It's +completely up to you (and Camm, and other GCL people) what to email to the ACL2 +list, but I thought I should mention this. + +On another note, you mention the following, and I have some comments below. + + In http://www.nongnu.org/axiom/ + + BOYER-MOORE THEOREM PROVER INTEGRATION + Motivation: Computational logic is a branch of computer mathematics + that is not currently available in Axiom. The Boyer-Moore + theorem prover, written in common lisp, provides a good + general purpose platform to study the interaction of the + theorem proving systems with Axiom + - Contact Boyer & Moore + - Contact Chandy & Misra + - Download ACL2 + Build ACL2 + Invoke ACL2 from Axiom + Integrate ACL2 into Axiom + Use Dijkstra's methods against SetCategory + Draft research paper + +The Boyer-Moore theorem prover, also called Nqthm, is indeed a product of Bob +Boyer and J Moore. ACL2 is authored by me (Matt Kaufmann) and J Moore, albeit +with significant early contributions from Boyer, who however is no longer +involved (by his choice). + +I believe that integrating ACL2 into Axiom could be an interesting project, and +if you succeed I (and others on the ACL2 list, I believe) would like to know +about it. It would be especially interesting if Axiom could somehow contribute +to ACL2's proofs, but that may be a difficult problem (if for no other reason +than that their logics are presumably different). + +By the way, I'm not aware of any connection that Chandy or Misra have to this +stuff. + +\start +Date: Wed, 13 Aug 2003 21:46:20 +0200 +From: "Weiss, Juergen" +To: , +Cc: camm@enhanced.com, axiom-developer@nongnu.org +Subject: [Axiom-developer] RE: Juergen's makefile + +Actually, as I already noted, the ordering is mainly due +to Tim. I just went on with the missing files in alphabetical +order, tried to compile the files and if it failed, +I added the files after Tim's explicit list as layer 19. So +what's in the makefile is an explicit list and the rest alphabetically +ordered. There may be dependencies between the alphabetically +listed files. If you know the dependencies, just extend +the explicit list. Not further changes necessary. + +My idea was to explicitly state the nontrival and let make +care for the rest. And I wanted the command to compile an +algebra file to be in one place, so that it is easy to +change. It's very difficult to understand a system, +were some nontrivial build information is found after +some thousand lines of ``trivial=B4=B4 commands. In my framework, +if you add a new algebra file, you just have to add +the file to the list of .spad files and the modules +it defines at the right place in the modules list. + +You can explicitly define groups of +files and dependencies between them in my framework as +well. I wonder if this is really necessary. Make generates +the dependencies of a target sequentially and that's all +I used. Especially if as you suggest, the make file is +used only to build the system from scratch. Other +dependencies are necessary, if you change one file and +want to rebuild as few files as necessary. + +I know that my makefile needs some explanation. It was +just a first version. Though I'm proud of the ed +hack :-), I know it is quite cryptic. But I did not +wanted to put any time in the makefiles, if they would +not pass peer review ;-). + +Juergen + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Wednesday, August 13, 2003 8:44 PM +> To: bill.page1@sympatico.ca +> Cc: camm@enhanced.com; Weiss, Juergen; daly@idsi.net; +> axiom-developer@nongnu.org +> Subject: Juergen's makefile +> +> +> re: explaining the difference between Juergen's work and mine... +> +> I've been continuing the build of the system and have only glanced at +> Juergen's work so this is (a) not intended as criticism and (b) not +> well founded and open to discussion. +> +> First, there are dependencies beyond the 19 layers (I'm up to +> 21 so far) +> but the compiles may be insensitive to these. I'm laying out +> the lattice +> because without knowing these dependencies you can't build a +> system from +> scratch. It is possible that after 19 layers there is no point in +> continuing but (a) I haven't proven that and (b) I'm nearly finished. +> It would be good to figure out how many layers form the minimal set. +> +> Second, remember that this Makefile is only really used to build the +> system from scratch. Once the algebra code exists it is reasonably +> insenstive to changes. In particular, changes to these +> original algebra +> files will have to be reviewed carefully before being made so +> once there +> is a running version of the algebra all of this work is basically +> documenation. If you need to build the system from scratch +> on, say a 64 +> bit architecture, you really need to understand why it is +> built that way. +> +> Third, Juergen's makefile looks a lot simpler as it is shorter and +> less verbose. This is, in fact, the trend I'm trying hard to correct. +> I'm simply unable to decode: +> +> @ ( echo '1.$$s,${IN}/\(.*\)/.spad\.pamphlet:<<\(.*\)\.lsp ....... +> +> well, that's not strictly true but you get the idea. It is important +> to remember that I have Makefiles that look like this from long ago. +> I like the apparent brevity of the rules. However the machine +> doesn't care +> if there are 3 or 300 rules but humans do and I need to work +> with Juergen +> to reach some compromise. At the moment I'm just using very +> simple rule +> forms rather than GNU make extensions. Dirt simple rules, in fact. +> +> My main problem with the brief approach goes to the heart of the "new +> Axiom". Juergen's makefile includes less than a dozen comment +> lines. But think carefully about what this Makefile is doing. It +> bridges the gap between the algebra world (where the files are +> organized into logical piles of categories, domains, and packages) and +> the method of constructing the world from scratch. It contains an +> ordering which is required but documented nowhere else. Why does this +> ordering exist? What does it imply about the algebra? How will someone +> 30 years from now figure out what to change, what it affects, and why +> it has that effect when the need to change the core algebra files? +> +> Makefiles document how to build the system. One reason that it has +> taken so long to get a running system from the NAG sources is that the +> expertise of how to build the system (and it's associated makefiles) +> was lost. (Another reason is that you used to need an Axiom to build +> an Axiom.) That is partially my fault from the past. I built +> Makefiles just like Juergen (and everybody else) does. I wrote +> Makefiles for the machine to read. But that is misguided. I can build +> a system (witness the downloadable version). But I'm trying to build +> it so you guys can understand it, modify it, and maintain it. If we +> don't document it then nobody will be able to do these things and +> Axiom will die. +> +> Juergen's makefile is basically a condensed version of mine and is +> correct (modulo the other layers). Use it to build and test +> the algebra. +> However, the CVS version is going to end up as a pamphlet file that +> leans heavily on explanation. The current version you see has a great +> deal of "scaffolding" as I'm keeping build notes in the same file. +> These build notes are unnecessary and will be elided eventually. +> I need them to form the lattice. +> +> Again, this isn't a criticism of Juergen's great work. +> + +\start +Date: Wed, 13 Aug 2003 17:04:11 -0400 +From: root +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] testing axiom + +*, + +Assuming you use Juergen's makefile and get the world running +it would be valuable to run each of the input files and hand-check +the results for failures. Any bugs should be opened on the axiom +website so we can track them. Perhaps you can claim a*.input, b*.input, +etc so the work isn't duplicated. + +\start +Date: Thu, 14 Aug 2003 18:47:53 +0200 +From: David MENTRE +To: sal@kachinatech.com +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] Update for AXIOM web page on SAL + +Hello, + +While browsing SAL, I noticed your page on Axiom is not up-to-date: + http://sal.kachinatech.com/A/1/AXIOM.html + +Axiom is now a free software, under a BSD-like licence. Could you update +your page with following information? Thanks. + + +--The SAL fields-- + + +Axiom + +AXIOM is a powerful computer algebra system which provides a complete +environment for anyone needing to manipulate and solve mathematical +formulae. Its application is wide-ranging, from pure mathematics +research through branches of physics, chemistry, biology and engineering +to financial modelling and cryptography. + +Current Version: unknown (no stable release yet) + +License Type: Free Software (BSD-like) + + Home Site: http://savannah.nongnu.org/projects/axiom/ + +Source Code Availability: + Yes + + Available Binary Packages: + + * Debian Package: No + * RedHat RPM Package: No + * Other Packages: ?? + +Targeted Platforms: + Unix, Windows + +Software/Hardware Requirements: + None + + Other Links: None + +Mailing Lists/USENET News Groups: + http://savannah.nongnu.org/mail/?group=axiom + + - axiom-mail@nongnu.org General purpose conversation list + - axiom-developer@nongnu.org Discuss developer questions + - axiom-legal@nongnu.org License discussions + + + User Comments: + + * None + +See A Screen Shot? (Not Yet) + +\start +Date: Thu, 14 Aug 2003 19:29:59 +0200 +From: David MENTRE +To: "Bill. Page1 (E-mail)" +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Hello Bill, + +"Page, Bill" writes: + +> I was a little confused about the used of some of the fields on the +> bug report form. + +I tried to follow Tim examples. It wasn't clear to me. :) + +> Let me know if you think I could have / should have done it a little +> differently. + +It seems mostly correct to me. Some further clarification: + +The "Example:" is intended to contain runnable Axiom code that would +serve as showing the bug or (once fixed) non-regression testing. In +other words, it is intended to construct bugs.pamphlet and +fixed.pamphlet that Tim wants. I do not know Axiom's language yet but it +would be nice to have some code like "if round(-3.77623) = -4 then print +'ok' else print 'error'" (or raise an exception or wathever the +non-regression infrastructure would need). + +The "Explanation:" field is intended to contain the explanation of the +bug (i.e. the real cause of the bug), once the bug is fixed. + +I recognized that some fields are overlaping. + +I hope I am more clear. I'll try to refine savannah's bug report fields. + +\start +Date: Thu, 14 Aug 2003 13:39:06 -0400 +From: root +To: david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +David + +Feel free to "fix" the bug report fields as you see fit. + +\start +Date: Thu, 14 Aug 2003 14:37:36 -0400 +From: root +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] generalized makefile rules + +Juergen, + +You're clearly much better at makefile syntax than I am. I want to +generalize the following pattern so that FOO matches each file: + +${OUT}/FOO.o: ${MID}/FOO.NRLIB + echo making ${OUT}/FOO.o from ${MID}/FOO.NRLIB + cp ${MID}/FOO.NRLIB/code.o ${OUT}/FOO.o + +${MID}/FOO.NRLIB: ${MID}/FOO.spad + echo making ${MID}/FOO.NRLIB from ${MID}/FOO.spad + (cd ${MID} ; echo ')co FOO.spad' | ${INTERPSYS} + +I remember that there is a generalized replacement variable that +matches the name of the expanding file but I don't know what it is. + +\start +Date: Thu, 14 Aug 2003 21:09:01 +0200 +From: David MENTRE +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] generalized makefile rules + +Hello Tim, + +I've not checked (i.e. executed) but I would write: + +root writes: + +> ${OUT}/FOO.o: ${MID}/FOO.NRLIB +> echo making ${OUT}/FOO.o from ${MID}/FOO.NRLIB +> cp ${MID}/FOO.NRLIB/code.o ${OUT}/FOO.o + +${OUT}/%.o: ${MID}/%.NRLIB + echo making ${OUT}/$*.o from ${MID}/$*.NRLIB + cp ${MID}/$*.NRLIB/code.o ${OUT}/$*.o + + +or (shorter version): + +${OUT}/%.o: ${MID}/%.NRLIB + echo making $@ from $< + cp ${MID}/$*.NRLIB/code.o $@ + + +> ${MID}/FOO.NRLIB: ${MID}/FOO.spad +> echo making ${MID}/FOO.NRLIB from ${MID}/FOO.spad +> (cd ${MID} ; echo ')co FOO.spad' | ${INTERPSYS} + +${MID}/%.NRLIB: ${MID}/%.spad + echo making ${MID}/$*.NRLIB from ${MID}/$*.spad + (cd ${MID} ; echo ")co $*.spad" | ${INTERPSYS} + +Note: Beware of quotes, I've changed above ' by ". + +Or shorter version: + +${MID}/%.NRLIB: ${MID}/%.spad + echo making $@ from $< + (cd ${MID} ; echo ")co $*.spad" | ${INTERPSYS} + + +> I remember that there is a generalized replacement variable that +> matches the name of the expanding file but I don't know what it is. + +\start +Date: Thu, 14 Aug 2003 22:03:20 +0200 +From: "Weiss, Juergen" +To: +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] RE: generalized makefile rules + +Hi Tim, + +David's suggestions should do what you want. In my makefile +I used "static pattern rules", that is the rules are +applied only to the files mentioned before the first :. +If you omit the first part, you get normal rules which +may get applied to matching targets. This may be even +more elegant. If you have serveral rules, which match +the same target, make tries to find out, which prerequisites +exists or which can be generated by other rules. That is for +specific targets, you can have a general rule and a target specific +rule. The specific target specific. With static pattern rules +you get at least a warning. Details in the info file for +gnu make. I'm not really an expert in gnu make. I just +experimented a bit and read parts of the documentation. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Thursday, August 14, 2003 8:38 PM +> To: Weiss, Juergen +> Cc: daly@idsi.net; axiom-developer@nongnu.org +> Subject: generalized makefile rules +> +> +> Juergen, +> +> You're clearly much better at makefile syntax than I am. I want to +> generalize the following pattern so that FOO matches each file: +> +> ${OUT}/FOO.o: ${MID}/FOO.NRLIB +> echo making ${OUT}/FOO.o from ${MID}/FOO.NRLIB +> cp ${MID}/FOO.NRLIB/code.o ${OUT}/FOO.o +> +> ${MID}/FOO.NRLIB: ${MID}/FOO.spad +> echo making ${MID}/FOO.NRLIB from ${MID}/FOO.spad +> (cd ${MID} ; echo ')co FOO.spad' | ${INTERPSYS} +> +> I remember that there is a generalized replacement variable that +> matches the name of the expanding file but I don't know what it is. +> + +\start +Date: Sun, 17 Aug 2003 12:48:51 -0400 +From: root +To: weiss@uni-mainz.de +Cc: camm@enhanced.com, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Re: generalized makefile rules + +Juergen, + +Well, except for a few domains I've finished the lattice. +I've diffed your algebra versions with mine and I'm applying +your patches. I've found them quite useful as they fixed some +bugs I intended to chase. Excellent work on your part. + +I see that you have rewritten interval.as to interval.spad. +I've rewritten the \author tags on all of the files to indicate +the actual authors wherever I know the authors. Did you write +interval.spad.pamphlet? + +I also have algebra that has been recently written that I'm +working on merging. + +I'm trying at the moment to rebuild the database but I'm getting +a value stack overflow in GCL while loading the domains. (Daly's +law: there is no such thing as a simple job.) Other than that +problem and a few remaining domains that I need to fix, the whole +Axiom world builds from scratch. I never thought I'd see the day +that would happen. + +Once I fix the value stack overflow I'll concentrate on getting +the world imported onto Savannah. + +\start +Date: Sun, 17 Aug 2003 19:28:00 +0200 +From: "Weiss, Juergen" +To: +Cc: camm@enhanced.com, axiom-developer@nongnu.org +Subject: [Axiom-developer] RE: generalized makefile rules + +Tim, + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Sunday, August 17, 2003 6:49 PM +> To: Weiss, Juergen +> Cc: daly@idsi.net; axiom-developer@nongnu.org; camm@enhanced.com +> Subject: Re: generalized makefile rules +> +> +> Juergen, +> +> Well, except for a few domains I've finished the lattice. +> I've diffed your algebra versions with mine and I'm applying +> your patches. I've found them quite useful as they fixed some +> bugs I intended to chase. Excellent work on your part. + +About 10 years ago I tried to figure out the algebra lattice +myself. I logged the files loaded by each compile and later +on tried to use tsort or something similar. It did not work +out and I gave up (too many circular dependencies). So I +can at least partially appreciate what you have achieved. + +I got the impression, that in certain circumstances, the +content of the databases is enough to compile references +to some modules. In most cases the modules have to be +loaded. But I did not figure out, what the difference was. + +> I see that you have rewritten interval.as to interval.spad. +> I've rewritten the \author tags on all of the files to indicate +> the actual authors wherever I know the authors. Did you write +> interval.spad.pamphlet? + +I actually just changed the syntax of the original .as file. +So I would not call me the author. I have a newer version +of the file (two changes), which I will send you tonight. +With current database files, two function calls, which did +not compile, finally do. + +> I also have algebra that has been recently written that I'm +> working on merging. +> +> I'm trying at the moment to rebuild the database but I'm getting +> a value stack overflow in GCL while loading the domains. (Daly's +> law: there is no such thing as a simple job.) Other than that +> problem and a few remaining domains that I need to fix, the whole +> Axiom world builds from scratch. I never thought I'd see the day +> that would happen. + +This is strange indeed. I used the most recent cvs files and +compiled under Debian (with the supplied gcl). I think I only +fixed the category vector copying. Have you rebuild interpsys +without any algebra files preloaded or with more recent ones? + +> Once I fix the value stack overflow I'll concentrate on getting +> the world imported onto Savannah + +\start +Date: Sun, 17 Aug 2003 15:05:28 -0400 +From: root +To: weiss@uni-mainz.de +Cc: camm@enhanced.com, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] lattice + +re: lattice + +The lattice is quite subtle in places. The hardest part is the size +of the thing. ~1100 domains in ~375 files. Every time I set out to +do anything like change the authors which takes less than 1 minute +per file it turns into a several hour task. Some of the tasks took +over an hour per domain. I've been at this task since January. +I have much "back-checking" to do but I can do that after upload. +(e.g. I have to check that the bootstrap code is current, a painfully +slow process). + +I did a partial analysis years ago. It helped me find the most +frequently loaded domains which are now preloaded at build time. +I wish I had kept the data from that analysis because it +would have come in handy now. I've separated out the scaffolding +data into a file called Lattice.pamphlet. This contains information +that allows us to compute several interesting answers to questions +like: what's the "thickness" of the "main trunk" of the tree of +files holding up the lattice. I observed over the last few months +that there are only a few key files that hold the whole lattice up. +I'm also thinking of writing a lattice domain as I can think of +several operations that might be interesting to compute. Also of +interest is that the lattice data tells us where optimizations will +have the most effect. + +As a side-effect the Makefile.pamphlet has shrunk. Once I add in +David's change it should shrink again. You still won't be happy +with it though :-) + +re: interval.spad.pamphlet + +Your interval.spad.pamphlet file is not a trivial rewrite as far +as I can see. The file diffs are almost nowhere the same. My general +rule for "authorship" is to include the names of people who make +"intellectual changes" (that is, not just typos but rewrites or +handling special cases, etc) as authors. Credit is easy to share. +Once the file has more than 5 authors it'll switch over to the +generic "The Axiom Team". Currently 5 authors is the longest list. + +I'm also looking to rewrite the .as files. It simplifies things +if the basic algebra is all .spad rather than a mixture. I've +ignored the .as files in the build for this reason. If you're +feeling ambitious you could look at the other few .as files. + +re: value stack overflow + +Yes, it is very strange that I get a value stack overflow because +I used to build the databases. Indeed, I rebuilt the databases for +the hand-built version. I'm going to back down a level in the GCL +build and see if that fixes it. If so I'll upload the world using +the backlevel lisp until we get a chance to debug it. + +re savannah + +I'm working hard to get the savannah site set up so everybody is +working from the same set of mistakes :-) However, there is no +point in uploading mistakes I can easily fix. It is a tradeoff +but I'm leaning heavily toward the upload side now that the world +can be built from scratch. + +\start +Date: Sun, 17 Aug 2003 17:52:20 -0400 +From: root +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] subtle issue with generic rules + +Using generic rules in Makefiles fail in a subtle way. +The rules that I've created go to great lengths to ensure +that only the minimum amount of work is done. So if you erase +a file from the INT directory (e.g. DLAGG.o) then only that +file and ones that depend on it (e.g. the mnt/algebra version) +will be rebuilt. Caching the work is vital as Axiom can take +a LONG time to build. + +If you use generic rules and touch the original source.spad.pamphlet +file the generic rules work fine. However if you remove the cached +files from the INT directory without touching the source pamphlet the +generic rules fail. They fail trying to remove the NRLIB directories +that are generated by INTERPSYS. My specific rules don't do this. +I've documented this behavior in the Makefile.pamphlet so nobody tries +to repeat the mistake. + +\start +Date: Sun, 17 Aug 2003 17:52:39 -0400 +From: root +To: "Weiss, Juergen" +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] subtle issue with generic rules + +Thanks for the new version of interval.spad.pamphlet + +\start +Date: Sun, 17 Aug 2003 22:33:42 +0200 +From: "Weiss, Juergen" +To: +Cc: camm@enhanced.com, axiom-developer@nongnu.org +Subject: [Axiom-developer] RE: interval.spad + +> +> re: interval.spad.pamphlet +> +> Your interval.spad.pamphlet file is not a trivial rewrite as far +> as I can see. The file diffs are almost nowhere the same. My general +> rule for "authorship" is to include the names of people who make +> "intellectual changes" (that is, not just typos but rewrites or +> handling special cases, etc) as authors. Credit is easy to share. +> Once the file has more than 5 authors it'll switch over to the +> generic "The Axiom Team". Currently 5 authors is the longest list. + +Most lines differ only by a semicolon. + +\start +Date: Mon, 18 Aug 2003 18:54:10 +0200 +From: David MENTRE +To: "Weiss, Juergen" +Cc: camm@enhanced.com, Tim Daly , axiom-developer@nongnu.org, daly@idsi.net +Subject: About stack overflow in GCL (was: Re: [Axiom-developer] RE: generalized makefile rules) + +Hello Juergen and Tim, + +"Weiss, Juergen" writes: + +>> I'm trying at the moment to rebuild the database but I'm getting +>> a value stack overflow in GCL while loading the domains. (Daly's +>> law: there is no such thing as a simple job.) Other than that +>> problem and a few remaining domains that I need to fix, the whole +>> Axiom world builds from scratch. I never thought I'd see the day +>> that would happen. +> +> This is strange indeed. I used the most recent cvs files and +> compiled under Debian (with the supplied gcl). + +Are you using woody or sid? If sid, then maybe Camm has uploaded an +updated version of GCL? + + +Anyway, for the value stack overflow, Camm proposed a patch to GCL which +is the bug database: +http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4584&group_id=2938 + +The proposed patch of Camm: +The C stack size is to limited. Apply following patch: + +--- /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); + + +I also suppose that you, Tim, have increased the VSSIZE. + +The sources in a public CVS would definitely help track down bugs. ;) + +\start +Date: Mon, 18 Aug 2003 13:15:06 -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] About stack overflow in GCL + +I've already applied the suggested patch. I don't believe the problem +is in GCL. I've built databases successfully before. I've tried to +build the system using GCL 2.4 and GCL 2.5.2. Neither one works. + +I believe the problem is isolated to the domains STRING and STRICAT +which I'm working to isolate. I'm not quite sure of the details of +the cause so I can't say how I'll fix it. + +\start +Date: Mon, 18 Aug 2003 19:15:39 +0200 +From: David MENTRE +To: daly@idsi.net, Tim Daly +Cc: axiom-developer@nongnu.org +Subject: Automation & algebra lattice (was: Re: [Axiom-developer] lattice) + +Hi Tim, + +root writes: + +> The lattice is quite subtle in places. The hardest part is the size +> of the thing. ~1100 domains in ~375 files. Every time I set out to +> do anything like change the authors which takes less than 1 minute +> per file it turns into a several hour task. Some of the tasks took + +I hope you use Perl to do such things like: + + perl -pi -e 's/Old Author/New Author/g' *.spad.pamphlet + + +> over an hour per domain. I've been at this task since January. +> I have much "back-checking" to do but I can do that after upload. +> (e.g. I have to check that the bootstrap code is current, a painfully +> slow process). + +For such task (i.e. checking that bootstrap code is up-do-date regarding +generated .spad file), we could probably write some Perl scripts that +would automate it. I'm not saying it's easy, but it would be worth it +considering the size of the algebra. + + +BTW, regarding the algebra lattice, I have considered automatically +parsing .spad files to write dependencies in a file and then generate +the (currently cyclic) graph using free software tools like VCG +(Visualization of Compiler Graphs, [1]). The hairy +space-indentation-determines-code-blocks of SPAD files has stopped me +(and also my lack of knowledge in SPAD grammar) but, with a working +Axiom, it might be possible to hack the SPAD parser to output +dependencies. Producing the graph is then very easy. + + +[1] http://www.cs.uni-sb.de/RW/users/sander/html/gsvcg1.html + +\start +Date: Mon, 18 Aug 2003 13:31:00 -0400 +From: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Re: Automation & algebra lattice + +re: author automation + +I previously used an automated script to change "Nicolas Bourbaki" +to "The Axiom Team" in all of the Axiom files. However the algebra +files contain real authors names and, where I was sure of the author, +I changed the \author line. This is somewhat bogus because I know that +other people have worked on the various files and never put their names +in the file while others did. That was the original motivation for the +"Bourbaki" name, a group of anonymous mathematicians. We'll try to track +this a little better in the future. Once a file exceeds 5 authors it will +revert to "The Axiom Team" again. Finding the real author's names required +a hand review of each of the 375 algebra files. I didn't see any reliable +way to automate it and I would have to hand-check it anyway. + +re: automating algebra bootstrap + +I will eventually automate the bootstrap rebuild but I'm trying to get +the system buildable as a first priority. I need to hand check the code +just to ensure that I didn't make a major mistake. No doubt I've made +several but a bootstrap mistake would be very hard to find. + +re: lattice + +I looked for tools that could compute and draw the lattice but found +none. I have a partial lattice as a DIA file but I haven't touched it +since april. Now that I have the dependency data there are several +things I can compute from it and I plan to write a lattice domain in +Axiom when time permits. + +\start +Date: Mon, 18 Aug 2003 13:45:55 -0400 +From: "Bill Page" +To: "'David MENTRE'" , , "'Tim Daly'" +Cc: axiom-developer@nongnu.org +Subject: RE: Automation & algebra lattice (was: Re: [Axiom-developer] lattice) + +David, Tim, + +About "parsing .spad files to write dependencies". I wrote +a Perl script that does this last week. Unfortunately the +code is sitting on a machine that is still in the black-out +zone following last week's power failure. I do have a print +out and it is quite short, so if you are interested I can +re-key it and send it. The parsing is a bit "heuristic" in +places because of the macro flexibility in spad, but I +think that it is at least 95% accurate. + +The sorted list of dependencies is over 600 pages in length! +But maybe it might be of some use to Tim in verifying the +new make file? + +Also, it occurs to me that this information aught to be +presented in an easier to obtain form, perhaps as ++ +comments in the spad.pamphlet source. It seems perhaps +a design flaw of the spad language that these references +do not have to be declared explicitly. No? + +Anyway, One thing I did try was to use the list with tsort +to find the cycles. And I found lots of cycles! + +Another thing I noted was that there seemed to be a lot +of (possibly) duplicated code in files with the same name +but one in all upper case and one in all lower case. I am +not sure what is the cause of this yet. In some cases the +differences in the files seem obvious and both seem +required. In other cases I am not so sure. + +Chhers + +> -----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 David MENTRE +> Sent: Monday, August 18, 2003 1:16 PM +> To: daly@idsi.net; Tim Daly +> Cc: axiom-developer@nongnu.org +> Subject: Automation & algebra lattice (was: Re: +> [Axiom-developer] lattice) +> +> +> Hi Tim, +> +> root writes: +> +> > The lattice is quite subtle in places. The hardest part is +> the size of +> > the thing. ~1100 domains in ~375 files. Every time I set out to do +> > anything like change the authors which takes less than 1 minute per +> > file it turns into a several hour task. Some of the tasks took +> +> I hope you use Perl to do such things like: +> +> perl -pi -e 's/Old Author/New Author/g' *.spad.pamphlet +> +> +> > over an hour per domain. I've been at this task since +> January. I have +> > much "back-checking" to do but I can do that after upload. (e.g. I +> > have to check that the bootstrap code is current, a painfully slow +> > process). +> +> For such task (i.e. checking that bootstrap code is +> up-do-date regarding generated .spad file), we could probably +> write some Perl scripts that would automate it. I'm not +> saying it's easy, but it would be worth it considering the +> size of the algebra. +> +> +> BTW, regarding the algebra lattice, I have considered +> automatically parsing .spad files to write dependencies in a +> file and then generate the (currently cyclic) graph using +> free software tools like VCG (Visualization of Compiler +> Graphs, [1]). The hairy +> space-indentation-determines-code-blocks of SPAD files has +> stopped me (and also my lack of knowledge in SPAD grammar) +> but, with a working Axiom, it might be possible to hack the +> SPAD parser to output dependencies. Producing the graph is +> then very easy. +> +> [1] http://www.cs.uni-sb.de/RW/users/sander/html/gsvcg1.html +> -- + +\start +Date: 18 Aug 2003 15:17:17 -0400 +From: Camm Maguire +To: David MENTRE +Cc: axiom-developer@nongnu.org, daly@idsi.net, Tim Daly +Subject: Re: About stack overflow in GCL (was: Re: [Axiom-developer] RE: generalized makefile rules) + +Greetings, David, and thanks! I believe the patch you refer to below +was for a different situation, and is likely not relevant here. +Thanks for keeping such good track! + +Take care, + +David MENTRE writes: + +> Hello Juergen and Tim, +> +> "Weiss, Juergen" writes: +> +> >> I'm trying at the moment to rebuild the database but I'm getting +> >> a value stack overflow in GCL while loading the domains. (Daly's +> >> law: there is no such thing as a simple job.) Other than that +> >> problem and a few remaining domains that I need to fix, the whole +> >> Axiom world builds from scratch. I never thought I'd see the day +> >> that would happen. +> > +> > This is strange indeed. I used the most recent cvs files and +> > compiled under Debian (with the supplied gcl). +> +> Are you using woody or sid? If sid, then maybe Camm has uploaded an +> updated version of GCL? +> +> +> Anyway, for the value stack overflow, Camm proposed a patch to GCL which +> is the bug database: +> http://savannah.nongnu.org/bugs/?func=detailbug&bug_id=4584&group_id=2938 +> +> The proposed patch of Camm: +> The C stack size is to limited. Apply following patch: +> +> --- /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); +> +> +> I also suppose that you, Tim, have increased the VSSIZE. +> +> The sources in a public CVS would definitely help track down bugs. ;) + +\start +Date: Mon, 18 Aug 2003 17:35:10 -0400 +From: root +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] [suse@suse.de: Ticket [20030811900000240]] + +Well, I got the first response from a vendor. + +------- Start of forwarded message ------- +From: SuSE Linux AG +To: daly@idsi.net +Subject: Ticket [20030811900000240] +Date: Mon, 18 Aug 2003 23:12:49 +0200 (CEST) + +Dear Mr. Daly, + + +> +> We are planning to make Axiom run on all of the major operating +> system distributions. Can you forward this mail to someone who can +> provide technical requirements for working with your distribution? +> +> We look forward to a mutually cooperative effort that will enhance +> your distribution's value to your customers and provide Axiom with +> a wider audience. +> + +The first step to becoming an Independent Software Vendor for SUSE Linux is to sign up with our Technology Partner program. Please take a look at the website below and especially hte .pdf brochure: + +http://www.suse.com/us/partner/become_partner/index.html + +Once you have become a Technology Partner with SUSE, our development team will work with you on what is necessary to include your software with our distrobution. + + +> Please feel free to contact me at your convenience. +> + +Thanks for your interest in SUSE Linux! + +Best Regards, + + your SuSE Linux-Team! +Marissa Krupa + +- --------------------------------------------------------------- +SuSE, Inc. Phone : 510 628 3380 Mo-Fr 9:00-17:00 +318 Harrison Ave Fax : 510 628 3381 (PST) +Oakland, CA 94607 Email : suse@suse.com +USA WWW : http://www.suse.com/ +- --------------------------------------------------------------- +------- End of forwarded message ------- + +\start +Date: Tue, 19 Aug 2003 03:11:11 -0400 +From: root +To: advi@pauillac.inria.fr +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] ADVI browser + +I saw a presentation of ADVI at the Libre Software Meeting (Metz, France). + +I'm the lead developer on the Axiom project. Axiom is an open source +computer algebra system that was originally a commercial product from +the Numerical Algorithms Group (NAG). One of the key changes between +the NAG version of Axiom and the free version of Axiom is that I've +recoded the whole system into a literate programming style. So each +source file, rather than being C, Lisp, Boot, or Spad code is now a +"pamphlet" file which is basically Latex with 2 additional tags. The +source code and the documentation are both extracted from these pamphlet +files automatically. + +The documentation files are .dvi files. I've been trying to decide on +a long term strategy that will allow people to organize these hundreds +of dvi files into a reasonable hierarchy. Basically what I need is a +dvi "browser", similar to mozilla, that will allow me to create a +hyperlink from one dvi file to another and open the linked file either +in a "tabbed window" or as a separate window. It appears that ADVI +"almost" has this ability. + +Is it possible to create html-style navigation among DVI files using +ADVI? If so, could you show me a trivial 2-file example? I have tried +and don't see how to do this. If not, how hard would it be to modify +ADVI to allow hyperlinks, tabbed panes, and a "back" button? + +ADVI seems to be an ideal starting place for an Axiom documentation +viewer. I'm impressed with its abilities so far. + +\start +Date: Wed, 20 Aug 2003 15:29:49 +0200 +From: David MENTRE +To: daly@idsi.net +Cc: advi@pauillac.inria.fr, axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] ADVI browser + +Hello Tim and ADVI developers (Pierre Weis I suppose), + +root writes: + +> If not, how hard would it be to modify +> ADVI to allow hyperlinks, tabbed panes, and a "back" button? + +I would like to add that I know O'Caml and I would be pleased to code +this capability if needed, provided necessary pointer in ADVI code. + +\start +Date: Wed, 20 Aug 2003 15:18:25 +0200 +From: David MENTRE +To: "Bill Page" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: Automation & algebra lattice + +Hello Bill, + +"Bill Page" writes: + +> About "parsing .spad files to write dependencies". I wrote +> a Perl script that does this last week. Unfortunately the +> code is sitting on a machine that is still in the black-out +> zone following last week's power failure. I do have a print +> out and it is quite short, so if you are interested I can +> re-key it and send it. The parsing is a bit "heuristic" in +> places because of the macro flexibility in spad, but I +> think that it is at least 95% accurate. + +Yes, I would be very interested in such a script (or the dependencies in +a file). There's no hurry however, I can wait a few days that the +machine reboots. :) + +\start +Date: Wed, 20 Aug 2003 10:01:28 -0400 +From: "Bill Page" +To: =?iso-8859-1?Q?'David_Mentr=E9'?= +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] RE: Automation & algebra lattice + +This is a multi-part message in MIME format. + +------=_NextPart_000_0001_01C36702.088C16E0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: quoted-printable + +David, + +Here are the Perl and Bash scripts. Their usage should be +fairly obvious but if anything is unclear, please ask. + +I put all of these scripts in the mnt/linux/bin directory. +Then I run them with the axiom root as the current directory, +specifying the set of spad files I want to analyzed like +this + + [axiom]% depends int/algebra/*.spad + +The output goes to standard out. Because it takes a +while to execute (several hours unless you have a very +fast machine) you might prefer to do something like +the following; + + [axiom]% depends int/algebra/a*.spad int/algebra/A*.spad | tee a.dep + [axiom]% depends int/algebra/b*.spad int/algebra/B*.spad | tee b.dep + ... + [axiom]% sort -u *.dep | unique + [axiom]% cat *.spad | awk '{print $1" " $7;}' | sort -u | tsort 2>&1 | +tac + +The "heuristic" algorithm that I used to find the dependecies +takes the list of exported functions from each domain in the +specified list of spad files and searches for these names +and the associated domains in all of the available spad and +pamphlet source files. I did it this way (sort of backwards) +in order to avoid having to really parse the spad source. I +think it produces fairly reliable results but perhaps not +100%. + +Would you like me also to send you the complete dependency +file? + +I am thinking of uploading these files to the savannah site +(not CVS, just auxillary related files) but I am not too +familiar how to do this. Your help and suggestions would be +appreciated. + +Cheers, +Bill Page. + +> -----Original Message----- +> From: David Mentr=E9 [mailto:david.mentre@wanadoo.fr] +> Sent: Wednesday, August 20, 2003 9:18 AM +> To: Bill Page +> Cc: axiom-developer@nongnu.org +> Subject: Re: Automation & algebra lattice +> +> +> Hello Bill, +> +> "Bill Page" writes: +> +> > About "parsing .spad files to write dependencies". I wrote +> > a Perl script that does this last week. Unfortunately the code is +> > sitting on a machine that is still in the black-out zone following +> > last week's power failure. I do have a print out and it is quite +> > short, so if you are interested I can re-key it and send it. The +> > parsing is a bit "heuristic" in places because of the macro +> > flexibility in spad, but I think that it is at least 95% accurate. +> +> Yes, I would be very interested in such a script (or the +> dependencies in a file). There's no hurry however, I can wait +> a few days that the machine reboots. :) +> +> Yours, +> d. +> -- +> david.mentre@wanadoo.fr +> + +------=_NextPart_000_0001_01C36702.088C16E0 +Content-Type: application/octet-stream; + name="unique" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: attachment; + filename="unique" + +#! /usr/bin/perl +# unique +# - suppress indentical initial fields in input +# - assumes input is sorted +# - repeated lines contain initial blanks where +# - duplicate +# Bill Page 14 August 2003 +# +while (<>) { + $new = $_; + $b = 0; + for ($i=0;$i) { + chop; + $spad = $_; +# Only include those cross-references that contain the same module name +# except if they are inside comments + $spad =~ s/int\/algebra\///; + $target =~ s/int\/algebra\///; + if ($spad ne $target) { + print "$spad uses $name from $module in $target ($pamphlet)\n"; + }; + }; + close(IN); + }; + }; +}; + +------=_NextPart_000_0001_01C36702.088C16E0 +Content-Type: application/octet-stream; + name="index" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: attachment; + filename="index" + +#! /bin/bash +# Display an index of Axiom dependencies +# Bill Page +# 14 August 2003 +# +export LC_ALL=C +depends int/algebra/*.spad | sort -u | unique + +------=_NextPart_000_0001_01C36702.088C16E0 +Content-Type: application/octet-stream; + name="order" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: attachment; + filename="order" + +#! /bin/bash +# Use topological sort to determine a feasible order of +# compilation. Loops are indicated by +# tsort: x +# tsort: y +# tsort: loop +# Bill Page +# 14 August 2003 + +export LC_ALL=C +depends int/algebra/*.spad | awk '{print $1" " $7;}' | sort -u | tsort = +2>&1 | tac + +------=_NextPart_000_0001_01C36702.088C16E0-- + +\start +Date: Wed, 20 Aug 2003 12:21:51 -0400 +From: root +To: tim@tenkan.org +Cc: Jun.Furuse@inria.fr, advi@pauillac.inria.fr, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] ADVI/Axiom connection + +Tim, + +I believe, if memory serves, that you had common lisp bindings for the +GTK. Is that correct? If so, how difficult would it be to make these +work in GCL? What's the URL for this work? + +------- Start of forwarded message ------- +Date: Wed, 20 Aug 2003 18:09:07 +0200 +From: Jun.Furuse@inria.fr +To: daly@idsi.net +Cc: advi@pauillac.inria.fr, axiom-developer@nongnu.org +Subject: Re: ADVI browser +In-Reply-To: <200308190711.h7J7BBa16359@localhost.localdomain> +User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 13) (Rational FORTRAN) (i386-debian-linux) +Content-Type: text/plain; charset=US-ASCII + +Hi, + +> The documentation files are .dvi files. I've been trying to decide on +> a long term strategy that will allow people to organize these hundreds +> of dvi files into a reasonable hierarchy. Basically what I need is a +> dvi "browser", similar to mozilla, that will allow me to create a +> hyperlink from one dvi file to another and open the linked file either +> in a "tabbed window" or as a separate window. It appears that ADVI +> "almost" has this ability. + +Currently ADvi is built over the O'Caml's graphics library, which is +for simple bitmap based graphics. It lacks any gui-toolkit capability +such as menus, tabs... And also, ADvi only handles one dvi document +at a time. This makes difficult to have a tabbed browser which you +have mentioned. + +However, I think it is still possible to achieve your goal: with +rather smaller modifications, ADvi may work as an embeded dvi viewer +for existing web browsers such as mozilla. + +Personally, I am now porting ADvi over gtk, so that it can have more +gui functionality. Maybe it can have tabs as you have mentioned. + +- -- +Jun +------- End of forwarded message ------- + +\start +Date: Wed, 20 Aug 2003 10:30:09 -0400 +From: root +To: david.mentre@wanadoo.fr +Cc: axiom-developer@nongnu.org, advi@pauillac.inria.fr, daly@idsi.net, axiom-mail@nongnu.org +Subject: Re: [Axiom-developer] ADVI browser + +David, + +I might as well bore you with my long-term thoughts about pamphlets. + +If you do the ADVI browser think of it as the front end to a new kind +of automated book. The browser is intended as a viewer for the dvi +files generated from pamphlets. (Ideally the browser would handle the +dvi generation from the pamphlets but you can assume that's been done) +But the pile of pamphlets will eventually provide an N-dimensional +matrix of information. We want to support at least 7 different views +off the same data in this big pamphlet matrix: + +View 1 is a top-to-bottom path. At the top you start with a technical +paper that provides the mathematical description. For example, looking +at the area of integration starting with Barry Trager's Ph.D. thesis. +>From there you eventually work your way down to executable code. Thus +you move from theory to practice. + +View 2 is a side-to-side path. Here you are staying at the same level +of abstraction. You would be exploring, for example, all of the matrix +capabilities provided by Axiom by looking at the mathematics of each one. +Or looking at the implementation of each one. + +View 3, unlike View 1 and 2 which remain within the text area of the +pamphlet files, would wander among the code area of the files, say, +finding the pamphlet which contains the source code of a function +called from the current pamphlet. + +View 4 is a "threaded walk". ADVI allows embedded graphics and active +terminals. View 4 is intended to allow professors to develop course-related +paths thru the pamphlets. A particular course, say commutative algebra, +could develop a "textbook" which visits subsections of pamphlet files +in a particular order. This would also be used to construct further +pamphlet files. These will also contain embeded active graphics for +explaining things in class. + +View 5 is a "slide show" kind of presentation intended for classroom +or lecture use. This would visit code, pop up graphics and active +windows (hence use ADVI), etc so you could give a lecture using Axiom +within the slides. + +View 6 follows "document structure" information such as following +bibligraphic references to other pamphlets or combining index information +for cross-reference purposes. In general the browser will end up doing +searches (e.g. looking for the pamphlet containing a function for View 3) +and caching the results (e.g. building a file-based hashtable of +function->pamphlet cross-references). + +View 7 is a "concept map" form. This is the hardest to do as it +requires input from the user to construct. There is technology +available from the early 90s called KREP (Eric Mays's Knowledge +Representation) which, combined with OPS5 (Charles Forgy's thesis work +on rule based programming) forms a system called KROPS (my research +work at IBM). KROPS is a ( concept graph / rule graph ) that +automatically classifies "concepts" based on subsumption. It "learns" +as you add concepts to the graph. The long term use of this in Axiom +is intended to support the ability to "shape" the pamphlet files matrix +based on the understanding of the user of the system. + +There will be a large amount of mathematics in the pamphlet pile. We +need to control the complexity. So the idea is to watch what the user +visits and "learn" what he already knows. This gets added to a +"concept graph". The "concept graph" of a linear algebra professor +would differ greatly from the concept graph of a group theory +professor. This learned information feeds rules to drive the +presentation of information. Note that this functionality is "a long +way off". However you can see that the "30 year view" of Axiom's +mathematics is somewhat beyond what is available today (but barely +uses the technology available in the 1990s. sigh). + +So, in general, the pamphlet file is not intended to be a monolithic object. +It is rather a sequence of chunks, subsections, and references that can be +visited and recombined at will. + +There needs to be some sort of a "construction" support which will record +visited or needed links into some sort of a tree structure. Think of it as +a method of dynamically constructing a book by ripping out sections of +other books, adding your own notes, and combining them to form another +booklet. It's the "big staple" method of construction. Take a bunch of +existing subsections and chunks and "staple" them together. This is +different from the standard "back button history" trace because you +indicate things you want to keep and re-arrange. Ideally this would "save" +as a booklet file format for later hand-editing. Using this mechanism +authors can build on previous work and professors can construct class +notes from existing work. + +Initially I don't expect any of these views to be supported. All we need +in the beginning is some sort of a book-like front end. The "top level" +file will just be a pamphlet file that is a table-of-contents containing +"pamphlet" chunks using the "booklet" function you created: + +This is the first chapter +<> +This is the second chapter +<> +... + +I laid out the various views to give you some idea of the needed +generality in the long term. + +\start +Date: Wed, 20 Aug 2003 15:23:32 +0200 +From: David MENTRE +To: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: Automation & algebra lattice + +Hello Tim, + +root writes: + +> re: automating algebra bootstrap +> +> I will eventually automate the bootstrap rebuild but I'm trying to get +> the system buildable as a first priority. I need to hand check the code +> just to ensure that I didn't make a major mistake. No doubt I've made +> several but a bootstrap mistake would be very hard to find. + +At one point, we will probably have to write a bootstrap process close +to the one used in compilers: from the source, make a compiler C1 which +is used to build a compiler C2, then compare the produced binaries (or +the generated clisp in Axiom's case). + +> re: lattice +> +> I looked for tools that could compute and draw the lattice but found +> none. I have a partial lattice as a DIA file but I haven't touched it +> since april. Now that I have the dependency data there are several +> things I can compute from it and I plan to write a lattice domain in +> Axiom when time permits. + +VCG is definitely the tool you want to automate graph (and tree) +drawing. And it is free as in free software (GPL license). + + +I would be very interested in the lattice you have. + + +\start +Date: Fri, 22 Aug 2003 04:46:21 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: Automation & algebra lattice + +Bill, David, + +Axiom will tell you the exact dependencies of a domain. +Start a fresh Axiom, compile the domain (not the whole file), +save the console, look for the "Loading " messages and parse +out the domains. There is a file called exposed.lsp that +contains an association list of abbreviations and full domain +names. + +fyi, I'm down to about 5 files that need compiling (down from 265). +The issues are a harder with these 5 files but I understand how to +fix them. 5 clean compiles and a database build and the system +should be ready for alpha. you'll notice it is 4:45 a.m. here so +they probably won't get finished this morning :-) + +\start +Date: Fri, 22 Aug 2003 14:56:10 +0200 (CEST) +From: Bertfried Fauser +To: root +Cc: axiom-developer@nongnu.org, advi@pauillac.inria.fr +Subject: Re: [Axiom-developer] ADVI browser + +Hi, + +I have not yet seen the ADVI browser / viewer, but reading the 7 views, I +would kindly like to add a few more meta remarks. + +Regarding my current view on mathematics, ist far from beeing a static +sort of things. Many people do belife that methamatics is given as-is and +has only to be 'described' or 'explained'. However, I personally expect a +great reworking of many areas of mathematics in a more 'categorial' way. +Any documentation of a project like AXIOM should be capabal of such +reorganization, and you do indeed think about this. + +QUESTION: How can descriptions be separated into an algorithmic part which +most likely does not change (unless the code is replaced) and the more +meta-mathematical aspects, like the decision what is 'basic' math and what +is derived. + +Might there be a couple of mandatory tags for any AXIOM (algebra).spad +file which sepatates such information, perhaps by a new 'protocoll' like +<> +<> +However one would need such a thing as a math level, which may be +numbered, say "meta-mathNN", where NN is a number and 00--99 indicates the +increasing intricacy of the involved math. Such a 'rating' has to be +discussed, but would allow to extract a description of the AXIOM +capabilities on the user level. E.g. Maple has in undergraduate teaching +the problem that students don't know enough mathematics to appreciate that +Maple does not symilify an expression (say typically x^2=2) for such a +reason (e.g. x may be rational). Indeed one could even think about a +'named' or 'prohfiled' such numbering, specifying the needs of say +linear algebra, group theory, category theory, set theory to provide +specific views on the involved math. + +Regarding the HTML protocoll, one does use currently sxearch engines like +google (ht-dig, for local purpose) It would be possibleto index all of +AXIOMS pamthlet files and even .spad files etc. However, it is quite +difficult to reate such hits and if you ask for ay quite common term you +will have too much hits to be able to retrieve the desired information. +Therefore the HTML protocoll shall be enlaged in future by the W3C to have +meta tags which describe the content. Such a thing woudl be very helpful +in reworking the wast amount of documentation needed for AXIOM. Such meta +tags might describe things like +definition, theorem, algorithm, but also a sophistication level, say once +more from 00--99 + +My own experience shows, that documentation of code takes away 2/3 of the +total amount of work needed and only 1/3 goes into codeing and testing. +Waht is clear to oneself has to be described very precicely in a +documentation and there has to be a mechanism guaranteeing that code and +documentation are recent and mutually related. Perhaps this is already +guaranteed by using literate programming. However, there is a notorious +tendency to make small hacks and 'forget' about documenting them, since +one thinks about doing this in the next major realeas.... which never +happens. + +If someone of you invests work on extending / customizing ADVI such things +may be worth to be considered first. + +\start +Date: Wed, 20 Aug 2003 16:42:26 -0400 +From: "Bill Page" +To: =?iso-8859-1?Q?'David_Mentr=E9'?= +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] RE: Automation & algebra lattice + +David, + +Ok, now I guess I am a Savannah file upload expert ... + +After a lot of trouble trying to do things via Msys under +Windows, I finally gave up and went to Cygwin where these +sort of Unix things seem to work much better. As a result +I uploaded several files in the wrong place. So, after +learning to use scp in both Msys and Cygwin and then finding +that it is a well known problem that sftp doesn't always work +with Savannah, I had to learn to use rsync to delete the +stuff that I miss placed. I found the documentation on Savannah +confusing, insufficient and even wrong in some places. + +Phew! + +Anyway, the spad dependency Perl script and associated +files has (finally) been uploaded as you suggested below. + +You can find the file here: + + http://savannah.nongnu.org/files/?group=axiom + +Thanks for your suggestion to use the FileList system. + +Cheers, +Bill Page. + +> -----Original Message----- +> From: David Mentr=E9 [mailto:david.mentre@wanadoo.fr] +> Sent: Wednesday, August 20, 2003 1:24 PM +> To: Bill Page +> Cc: axiom-developer@nongnu.org +> Subject: Re: Automation & algebra lattice +> +> +> Hi Bill, +> +> Thanks for the script. I have no time to test it this week +> neither week-end but I will try it next week. +> +> "Bill Page" writes: +> +> > I am thinking of uploading these files to the savannah site +> (not CVS, +> > just auxillary related files) but I am not too familiar how to do +> > this. Your help and suggestions would be appreciated. +> +> I have no more experience that you in that regard. If I where +> you, I would follow the savannah FAQ[1]. As the savannah part +> is not used a lot by a wide public, this is the right time to +> make mistakes. :) +> +> I think you should use the FileList system, with something +> like: +> /upload/axiom/algebra_depends.pkg/1.0.0/algebra_depends-1.0.0.tar.gz +> +> Thus we will have proper sub-directories and nicely ordered versions. +> +> +> Yours, +> d. +> +> [1] +> http://savannah.gnu.org/faq/?group_id=11&question=How_do_I_add +_files_in_the_download_area.txt + + +\start +Date: 22 Aug 2003 08:16:21 +0200 +From: tim@tenkan.org (Tim Daly, Jr.) +To: daly@idsi.net +Cc: Jun.Furuse@inria.fr, advi@pauillac.inria.fr, axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: ADVI/Axiom connection + +root writes: + +> Tim, +> +> I believe, if memory serves, that you had common lisp bindings for the +> GTK. Is that correct? If so, how difficult would it be to make these +> work in GCL? What's the URL for this work? + +The URL is http://tenkan.org/clgtk/ , where you can find the last +beta. There's a cleaner version hanging around on my disk. + +It's designed so that all any Lisp needs to provide is some way to +start a process and communicate with it via a pipe or socket. So +porting is trivial. In fact, it used to work on GCL, but I've never +tried it since then. + +There has been no official release. The code needs a good week's work +before I would use it in a production environment. + +\start +Date: Wed, 20 Aug 2003 21:37:50 -0400 +From: root +To: axiom-developer@nongnu.org +Subject: [Axiom-developer] string.spad + +One of the steps I took to break cycles in the algebra involved +creating a separate file for each domain. Some spad files +contain several domains. + +Developers of algebra code have many styles. Some created macros +that only exist at the top of a spad file while others placed +macros at the start of each domain. + +The scope of a macro such as: + +MINSTRINGINDEX ==> 1 + +is the whole file. When I broke the domains into separate files +I was careful to ensure that each "small" domain got a copy of +the macros included in the DOMAIN.spad file. That is the correct +behavior. + +However, the side-effect of that copy changed the original source +code of the "big" spad file. So, for example, string.spad contains +5 domains (CHAR, CCLASS, ISTRING, STRICAT, and STRING). In the +original file the macro + +MINSTRINGINDEX ==> 1 + +appears once. This was copied so it appears in each chunk and thus +in each domain. Compiling CHAR.spad, or STRING.spad sees only one +copy. However, when the whole string.spad file is extracted it +contains 5 copies of the macro. + +The spad compiler gets a value stack overflow if you try to compile +string.spad. I don't yet know the cure. + +\start +Date: Fri, 22 Aug 2003 14:15:46 -0400 +From: root +To: Bertfried.Fauser@uni-konstanz.de +Cc: advi@pauillac.inria.fr, axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] ADVI browser + +Bertfried, + +I like your idea of "synopsys" and "algorithm" tags. Clearly the +pamphlet files need structure. However I'm not sure that the chunk +tags are the right place for the structure. The chunk tags are +intended to quote and embed code in a tex document. The booklet +extension allows the code to be in files which are "included" but +still has the idea that they embed code. We're beginning to evolve +the noweb idea. David Mentre took the first step with the booklet +code. + +> Regarding my current view on mathematics, ist far from beeing a static +> sort of things. Many people do belife that methamatics is given as-is and +> has only to be 'described' or 'explained'. However, I personally expect a +> great reworking of many areas of mathematics in a more 'categorial' way. +> Any documentation of a project like AXIOM should be capabal of such +> reorganization, and you do indeed think about this. + +Actually, Axiom's math evolves. Bill Sit has given me a newer version +of the PLEQN domain that includes later work. Several other people +have indicated that they also have later, improved work. I'm +struggling with the idea that Axiom should have an embedded CVS so you +can add new work while still referencing the old. And CVS solves the +problem of authors taking different directions with the same +mathematics. But I'd have to change the build structure to take this +into account so this idea is a long way off yet. + +What you appear to suggest is that portions of the document might contain +tags, lists, or markers (TLM) that indicate the intended use of the +material. The machinery for this would be easy to add. We simply need +to have a parameter on various tex tags (e.g. \section[synopsys]{The +Section}) What isn't clear, as you point out, is the meaning +associated with the TLMs. Perhaps a standard portion of the pamphlet +could exist (similar to an index) to carry this information. I have +a "concept index" for commutative algebra which I plan to use to +structure the booklet files once they come into existence. + +My thoughts on the subject, clearly open to debate, are that the +pamphlet files contain information that the author can structure +to explain a particular point. Think of these files as "technical +papers" which potentially contain code. A technical paper has a +certain assumed, but not required, structure by convention. It has +an abstract, background, new results, summary, and bibliography. +I think the pamphlet files will evolve structure by convention also. + +This raw information can be used and viewed in many different ways. +My thought was that "booklet" files would be the organizers of information. +So to address your example of sophistication level I'd expect an author +to write a booklet file that includes portions of pamphlet files. Simple +booklets such as an intro to linear algebra would only include text from +the examples portions of pamphlets. Complex booklets about lie algebras +might include portions of the theory sections containing theorems. So +booklets are intended to organize the pamphlet information for a particular +purpose. Pamphlet files are for organizing raw information about the code +and its supporting mathematics. I'm not sure if this is (a) a clear division +of responsibility or (b) a workable solution to your issue. It needs more +discussion. + +> My own experience shows, that documentation of code takes away 2/3 of the +> total amount of work needed and only 1/3 goes into codeing and testing. +> Waht is clear to oneself has to be described very precicely in a +> documentation and there has to be a mechanism guaranteeing that code and +> documentation are recent and mutually related. Perhaps this is already +> guaranteed by using literate programming. However, there is a notorious +> tendency to make small hacks and 'forget' about documenting them, since +> one thinks about doing this in the next major realeas.... which never +> happens. + +Knuth and Dijkstra both made this observation and both decided that +literate programming was the technique most likely to attack the issue +of documenting the code. It is ultimately up to the programmer to document. +I'm hoping, by force of convention, to convince Axiom programmers that it +is worthwhile spending 2/3 of their time documenting. The saving grace +is that, at least in mathematics, you get professional recognition for +writing up your results so you can, at minimum, attach the technical +paper to the code and call it a "pamphlet". That allows later authors to +better structure the mixture. If we succeed in keeping the theory with +the code it will be a major improvement over the current situation. Of +course, I'm not satisfied with just mixing the two. I want to exploit +the collection and make it useful for broader purposes. + +When the alpha version gets uploaded look at +src/algebra/dhmatrix.spad.pamphlet. I've combined the theory with the +code. Denavit-Hartenburg Matricies (DH Matricies) are 4x4 matricies +with special structure that enable them to describe rotations, +translations, scale, perspective, and skew operations. This domain was +used to create the graphics in the glossy pages of the Axiom book. I +wrote the original spad code essentially without comments. The theory +comes from Richard Paul's Ph.D. thesis (which he gave me permission +to use). I'm now trying to atone for my sins and document the domain +properly. Since this code will support graphics I'm hoping to use it +as an example domain to exploit ADVI's ability to embed active graphics. + +ADVI seems like worthwhile technology as they have found a mechanism +that allows authors of tex documents to embed information into the +dvi file that ADVI can use. This allows Axiom to perform all kinds of +interesting magic which opens up new ways to construct "books", booklets, +pamphlets, slides, technical papers, etc. And it uses "standard technology" +(since Knuth anticipated this in the dvi file format). + +The alpha release of Axiom will use an axiom.sty file that will eventually +allow us to embed ADVI information. ADVI has shown what's possible but we +need to do much more. + +\start +Date: 22 Aug 2003 16:17:01 -0400 +From: Camm Maguire +To: "Bill. Page1 (E-mail)" +Cc: axiom-developer@nongnu.org, 'root' +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Greetings! Is anyone interested in me releasing an experimental +Debian package for the unstable distribution only, presuming I can +reproduce the below, or is this still premature? + +Take care, + +"Page, Bill" writes: + +> Camm, Tim, Juergen, et al. +> +> I have just completed compiling the algebra source +> provided by Juergen Weiss with no significant errors. +> I now have a new running version of Axiom under +> RedHat 8.0 that no longer fails the following test +> +> > pgr := MonoidRing(Polynomial PrimeField 5, Permutation Integer) +> > p:pgr := 1 +> > q:pgr := 1 +> > set [p,q] +> +> What I did was: +> +> 1) start with the old tenkan.org CVS version +> 2) apply all the patches discussed to date on this list +> including the patch to bootsys discovered by Camm +> 3) untar Juergen Weiss's version of the algebra files +> into the new axiom root directory +> 4) modify the first line of the Makefile.inc to refer +> to the new root. +> 5) issue a make from the root to build the whole system +> 6) 11 hours later I have a new system. +> +> I can send the log file containing the output of the make +> if anyone is interested. The only errors that occured +> were "%.EOF is not of type SEQUENCE" as noted below plus +> numerous errors of the form "Unexpected HT command: \spad" +> Apparently these are generated by the contents of some +> comment lines like +> +> ++ \\spad{asinh(x)} returns the hyperbolic arc-sine ... +> +> I will continue to test this new version against some +> of the bugs that have been reported. +> +> -------- +> +> I noticed that some of the floating bugs that I reported +> a few weeks ago using the axiom.tenkan.org version are not +> yet included at Savannah so I think I will start these. +> +> --------- +> +> Tim, could you please send a few minutes and explain to +> us the difference between what you are doing with the +> new algebra makefile compared to what Juergen has done? +> +> Thanks. +> +> Bill Page. +> +> > -----Original Message----- +> > From: Camm Maguire [mailto:camm@enhanced.com] +> > Sent: Wednesday, August 13, 2003 11:38 AM +> > To: Weiss, Juergen +> > Cc: axiom-developer@nongnu.org +> > Subject: Re: [Axiom-developer] compiling the algebra files with gcl +> > +> > +> > Greetings! Just a status update -- I tried again, rechecking +> > that Juergen's files were in place, make clean, and I do get much +> > further. At first I was confused by messages of this type: +> > +> > ============================================================== +> > =============== +> > /fix/t1/camm/axiom/axiom2/new/new/int/algebra/LODO1.NRLIB/code +> > +> > (1) -> Please enter y or yes if you really want to leave +> > the interactive +> > environment and return to the operating system: +> > +> > >> System error: +> > %.EOF is not of type SEQUENCE. +> > +> > protected-symbol-warn called with (NIL) +> > ============================================================== +> > =============== +> > +> > but this seems to only be a missing 'y' in the input. Now I get to +> > the following when comiling SFRTCAT.spad: +> > +> > ============================================================== +> > =============== +> > Loading +> > /fix/t1/camm/axiom/axiom2/new/new/mnt/linux/autoload/preparse. +> > SFRTCAT abbreviates category +> > SquareFreeRegularTriangularSetCategory +> > -------------------------------------------------------------- +> > ---------- +> > initializing NRLIB SFRTCAT for +> > SquareFreeRegularTriangularSetCategory +> > compiling into NRLIB SFRTCAT +> > +> > ;;; *** |SquareFreeRegularTriangularSetCategory| REDEFINED +> > Time: 0.01 SEC. +> > +> > +> > >> System error: +> > The function |RegularTriangularSetCategory| is undefined. +> > ============================================================== +> > =============== +> > +> > Juergen, do you get past this point? (I'm assuming yes). If so, I'll +> > do some more checking. +> > +> > Take care, +> > +> > +> > +> > +> > "Weiss, Juergen" writes: +> > +> > > Hi, +> > > +> > > yes, with the changes to the algebra files and the +> > > new database files I was able to compile all the +> > > algebra files (with just a call to make in src/algebra). +> > > +> > > Did you do a make clean in the toplevel directory? +> > > +> > > Juergen Weiss +> > > +> > > > -----Original Message----- +> > > > From: Camm Maguire [mailto:camm@enhanced.com] +> > > > Sent: Tuesday, August 12, 2003 4:14 PM +> > > > To: Weiss, Juergen +> > > > Cc: axiom-developer@nongnu.org +> > > > Subject: Re: [Axiom-developer] compiling the algebra +> > files with gcl +> > > > +> > > > Greetings! +> > > > +> > > > "Weiss, Juergen" writes: +> > > > +> > > > > Did you install the new database files (share/algebra) as +> > > > > well and generated a fresh interpsys with that database? +> > > > > The old database contains definitions, which conflict +> > > > > with the distributed algebra sources. +> > > > > +> > > > +> > > > I hadn't -- thanks for pointing this out. However, after moving +> > > > share/algebra over too, make clean, and then make, lodo1 +> > still fails +> > > > to compile, as separately noted by Tim. Do your changes +> > resolve the +> > > > lodo1 compilation issue? + +\start +Date: 22 Aug 2003 16:06:11 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Re: generalized makefile rules + +Greetings! Please forgive if this is a repost -- having some email +troubles. If my help is needed with the value stack overflow, would +someone kindly let me know how to reproduce. No need to reply if its +under control. + +Take care, + +root writes: + +> Juergen, +> +> Well, except for a few domains I've finished the lattice. +> I've diffed your algebra versions with mine and I'm applying +> your patches. I've found them quite useful as they fixed some +> bugs I intended to chase. Excellent work on your part. +> +> I see that you have rewritten interval.as to interval.spad. +> I've rewritten the \author tags on all of the files to indicate +> the actual authors wherever I know the authors. Did you write +> interval.spad.pamphlet? +> +> I also have algebra that has been recently written that I'm +> working on merging. +> +> I'm trying at the moment to rebuild the database but I'm getting +> a value stack overflow in GCL while loading the domains. (Daly's +> law: there is no such thing as a simple job.) Other than that +> problem and a few remaining domains that I need to fix, the whole +> Axiom world builds from scratch. I never thought I'd see the day +> that would happen. +> +> Once I fix the value stack overflow I'll concentrate on getting +> the world imported onto Savannah. + +\start +Date: Fri, 22 Aug 2003 21:03:11 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: Automation & algebra lattice + +Bill, + +I have a computer running XP and I've installed cygwin. +Can you give me some idea of what tools you've set up to +compile Axiom? + +\start +Date: Fri, 22 Aug 2003 21:38:52 -0400 +From: "Bill Page" +To: +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: Automation & algebra lattice + +Tim, + +I don't use cygwin for Axiom anymore. I started out that way and +did manage to get CCL to compile some months back and then +I used it to compile (most of?) interpsys. But at that point you +decided to proceed first with GCL instead. Building GCL is +not supported under Cygwin. It should be fairly easy to do but +at this time there is no one who wants to take on the job of +debugging the build process. At this point I only use cygwin +when I need to talk directly with the Linux world, e.g. CVS, +ssh, rsync etc. + +Instead, on the Windows platform the preferred build +environment for GCL is MinGW with MSYS. See + + http://www.mingw.org/ + +MSYS provides a build environment rather like Linux/cygwin +with most of the same tools. But MSYS does not depend on +the cygwin dll to emulate unix and the programs built this way +run as true native windows applications instead of like unix +applications with an windows interface layer. + +Anyway, the 2.5.2 and later versions of GCL compile in the +usual manner under MinGW/MSYS to produce a windows +executable. The current Axiom Makefile system "almost" +works except that the extra C language extensions for file and +path management need to be re-written to work with Windows. +I think these can be ignored for now. The other problem with +the Windows version of GCL is the XDR. This was not +supported under windows until the most recent build candidate +GCL 2.5.4 which is supposed to compile under Windows with +the ONC version of rpc/XDR library. With Mike's help I did +manage to link the ONC rpc libraries to the earlier version +GCL 2.5.2 that is included in the Axiom CVS. I was just playing +with this when it *suddenly* became possible to actually build +a full Axiom system unded Linux and that has distracted me +for the last few weeks - so no more progress under windows. + +Good luck with Windows. Please let me know how +I can help. + +Bill Page. + +----- Original Message ----- +From: "root" +To: +Cc: ; +Sent: Friday, August 22, 2003 9:03 PM +Subject: Re: [Axiom-developer] RE: Automation & algebra lattice + + +> Bill, +> +> I have a computer running XP and I've installed cygwin. +> Can you give me some idea of what tools you've set up to +> compile Axiom? + +\start +Date: Fri, 22 Aug 2003 22:03:47 -0400 +From: "Bill Page" +To: , "David MENTRE" +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] dependency visualization with VCG + +David, + +About VCG. I downloaded an old Linux version of VCG which +shows + + xvcg -v + + VCG/XVCG - USAAR Visualization Tool V.1.3 + Revision 3.17 Date: 1995/02/08 11:11:14 + +(Where can I get a newer one??) I am running this on a fast +system with a lot of memory and Red Hat 9.0 Linux. + +I played with VCG it to understand the graph input language +(gdl) and then I wrote a short Perl script (based on what I did +last week to find the spad file dependencies) to generate a gdl +file for Axiom. + +Unfortunately when I tried to view it with xvcg, after a lot of grinding +of CPU, Linux finally crashed! (Hey, that's the first time I've crashed +Linux in a long time.) Anyway, the documentation did warn me that +the graph layout algorthm scaled exponentially with the size of the +graph... + +The Axiom dependency graph that I tried to use with xvcg has +over 1040 nodes and more than 17,000 edges (dependencies). + +Do you have any ideas about the size of graphs that can be +successfully manipulated with VCG? Do you have any suggestions +on where to go from here? Do you think of any way to segment +the Axiom dependency graph into smaller more managable +sub-graphs? + +Cheers, +Bill Page. + + +----- Original Message ----- +>From: "David MENTRE" +>To: +>Cc: ; +>Sent: Wednesday, August 20, 2003 9:23 AM +>Subject: [Axiom-developer] Re: Automation & algebra lattice + + +> ... +> > re: lattice +> > +> > I looked for tools that could compute and draw the lattice but found +> > none. I have a partial lattice as a DIA file but I haven't touched it +> > since april. Now that I have the dependency data there are several +> > things I can compute from it and I plan to write a lattice domain in +> > Axiom when time permits. +> +> VCG is definitely the tool you want to automate graph (and tree) +> drawing. And it is free as in free software (GPL license). +> +> +> I would be very interested in the lattice you have. + +\start +Date: Sat, 23 Aug 2003 04:50:26 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] mingw + +re: mingw. thanks. + +man, there are a lot of talented people out there. i kicked off a huge +download and now the sun is about to rise. We vampires must not be +caught out in the sun :-) + +\start +Date: Sat, 23 Aug 2003 10:35:35 +0200 +From: "Weiss, Juergen" +To: , +Subject: RE: [Axiom-developer] string.spad + +I think I had the same problem at the beginning with the compiler. +There must be an email in the mail archive. Problem is that the parser +macro expands the "left hand side" of macro definitions. One could +consider this a bug. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Thursday, August 21, 2003 3:38 AM +> To: axiom-developer@nongnu.org +> Subject: [Axiom-developer] string.spad +> +> +> One of the steps I took to break cycles in the algebra involved +> creating a separate file for each domain. Some spad files +> contain several domains. +> +> Developers of algebra code have many styles. Some created macros +> that only exist at the top of a spad file while others placed +> macros at the start of each domain. +> +> The scope of a macro such as: +> +> MINSTRINGINDEX ==> 1 +> +> is the whole file. When I broke the domains into separate files +> I was careful to ensure that each "small" domain got a copy of +> the macros included in the DOMAIN.spad file. That is the correct +> behavior. +> +> However, the side-effect of that copy changed the original source +> code of the "big" spad file. So, for example, string.spad contains +> 5 domains (CHAR, CCLASS, ISTRING, STRICAT, and STRING). In the +> original file the macro +> +> MINSTRINGINDEX ==> 1 +> +> appears once. This was copied so it appears in each chunk and thus +> in each domain. Compiling CHAR.spad, or STRING.spad sees only one +> copy. However, when the whole string.spad file is extracted it +> contains 5 copies of the macro. +> +> The spad compiler gets a value stack overflow if you try to compile +> string.spad. I don't yet know the cure. + +\start +Date: Sat, 23 Aug 2003 05:23:19 -0400 +From: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca, daly@idsi.net +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Camm, + +re: debian package. + +The algebra code has 5 files which will not yet compile properly +(due to mismaintained INTERP.EXPOSED). I'm working to solve this +problem which has yet another subtle catch-22. I should have it +done shortly and then there will be a "build from scratch" +version on savannah. + +Of course, we have to run tests against it, etc. + +You're welcome to build a debian package if you'd like. +We also have to discuss how we plan to support things like +apt and rpm files. I believe debian keeps them on their site +but we need to figure out how to keep binaries on the main +axiom site. Methinks Bill Page has already figured this out +so he's "the expert" :-) + +\start +Date: Sat, 23 Aug 2003 05:18:22 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net, axiom@tenkan.org +Subject: [Axiom-developer] Re: dependency visualization with VCG + +Bill, + +Crashed linux. damn. that's a HUGE bug in that program. Can't imagine how +they do that. + +I'd approach the problem somewhat differently. The lattice LEVEL order +is specified in the Makefile.pamphlet file. Given the first level as a +base you can graph the second level. Then iterate with the second level +as a base. The program should complain if it can find a file at level i +that can be pushed into level i-1 (which means I made a mistake). To find +the level of a file the steps were: + +1) collect the files it depends upon + this was the output of the compiler that I mentioned. + each file in the makefile has a long list of other files it uses. + call this the "depends on" list. +2) create a lisp association list that contains the bootstrap layer. +3) write a trivial lisp program (attached) that does: + for each file in the "depends on" list + look up the height of the file in the lattice + if the height doesn't exist + then we can't compile this file yet -- fail + else record the maximum of all the heights so far + print the (max height) + 1 + +I've attached the lattice information. + +Drawing this lattice involves taking an infinite 3-space of paper, +laying out the base level, adding the succeeding levels until done. +Next you have to project the 3-space to 2-space minimizing the +crossings. This is hard (possibly theoretically hard). Search the +web for papers about "embedding data structures into trees". Very +old "flowchart" programs used to do this. (Flowcharts were a technology +before your time I imagine :-) ). The hack introduced with flowcharts +was "the connector box" which was just a pair of numbered boxes. You +break any line into two, number the inner ends with number boxes that +have unique equal numbers (so you can find them) and lay them out. +Create a numbered box at every line crossing. + +(Theoretically a more interesting thing to do is to look upon the +cycle set as a "braid" structure and find the minimal cut). + +One last step that I have yet to perform is to re-cast the bootstrap +code to its proper level in the lattice. It isn't necessary for the +compile that I do but each bootstrap files is part of a cycle. The +choice of which file to choose to break the cycle is arbitrary. However +using an arbitrary choice could make the bootstrap set larger. Why? + +Consider two cycles A-B-C-D-E-A, F-G-A-F + +If we choose A from both cycles then we only have 1 bootstrap file. +If we choose B from the first we need 2 bootstrap files. +I failed to do the complete analysis of this and we ought to. + +In any case, it would make a nice algebra problem to solve using +Axiom. We could create a lattice domain which we use to construct +Axiom (creating yet one MORE instance of cyclic building behavior). +We can't be the first person to visit this problem so there must +be some general theory worth encoding. (Due next week. Show all +work. Use literate programming. Use #2 pencils :-) ). + +Tim +axiom@tenkan.org +daly@idsi.net + + +(defun height (dependson) + (let ((h -2)) + (dolist (dep dependson) + (setq num (assoc dep lattice)) + (if (null num) + (progn + (format t "~a does not exist yet" dep) + (break)) + (progn + (setq h (max h (cdr (assoc dep lattice)))) + (format t "height=~a based on ~a~%" h dep)))) + (format t "put into layer ~a~%" (+ h 1)))) + +(setq lattice + '( +( ABELGRP . -1 ) +( ABELGRP- . -1 ) +( ABELMON . -1 ) +( ABELMON- . -1 ) +( ABELSG . -1 ) +( ABELSG- . -1 ) +( ALAGG . -1 ) +( BOOLEAN . -1 ) +( CABMON . -1 ) +( CHAR . -1 ) +( CLAGG . -1 ) +( CLAGG- . -1 ) +( COMRING . -1 ) +( DFLOAT . -1 ) +( DIFRING . -1 ) +( DIFRING- . -1 ) +( DIVRING . -1 ) +( DIVRING- . -1 ) +( ENTIRER . -1 ) +( ES . -1 ) +( ES- . -1 ) +( EUCDOM . -1 ) +( EUCDOM- . -1 ) +( FFIELDC . -1 ) +( FFIELDC- . -1 ) +( FPS . -1 ) +( FPS- . -1 ) +( GCDDOM . -1 ) +( GCDDOM- . -1 ) +( HOAGG . -1 ) +( HOAGG- . -1 ) +( ILIST . -1 ) +( INS . -1 ) +( INS- . -1 ) +( INT . -1 ) +( INTDOM . -1 ) +( INTDOM- . -1 ) +( ISTRING . -1 ) +( LIST . -1 ) +( LNAGG . -1 ) +( LNAGG- . -1 ) +( LSAGG . -1 ) +( LSAGG- . -1 ) +( MONOID . -1 ) +( MONOID- . -1 ) +( MTSCAT . -1 ) +( NNI . -1 ) +( OINTDOM . -1 ) +( ORDRING . -1 ) +( ORDRING- . -1 ) +( OUTFORM . -1 ) +( PI . -1 ) +( PRIMARR . -1 ) +( POLYCAT . -1 ) +( POLYCAT- . -1 ) +( PSETCAT . -1 ) +( PSETCAT- . -1 ) +( QFCAT . -1 ) +( QFCAT- . -1 ) +( RCAGG . -1 ) +( RCAGG- . -1 ) +( REF . -1 ) +( RING . -1 ) +( RING- . -1 ) +( RNG . -1 ) +( RNS . -1 ) +( RNS- . -1 ) +( SETAGG . -1 ) +( SETAGG- . -1 ) +( SETCAT . -1 ) +( SETCAT- . -1 ) +( SINT . -1 ) +( STAGG . -1 ) +( STAGG- . -1 ) +( SYMBOL . -1 ) +( TSETCAT . -1 ) +( TSETCAT- . -1 ) +( UFD . -1 ) +( UFD- . -1 ) +( ULSCAT . -1 ) +( UPOLYC . -1 ) +( UPOLYC- . -1 ) +( URAGG . -1 ) +( URAGG- . -1 ) +( VECTOR . -1 ) +( AHYP . 0 ) +( ATTREG . 0 ) +( CFCAT . 0 ) +( ELTAB . 0 ) +( KOERCE . 0 ) +( KONVERT . 0 ) +( MSYSCMD . 0 ) +( ODEIFTBL . 0 ) +( OM . 0 ) +( OMCONN . 0 ) +( OMDEV . 0 ) +( OUT . 0 ) +( PRIMCAT . 0 ) +( PRINT . 0 ) +( PTRANFN . 0 ) +( SPFCAT . 0 ) +( TYPE . 0 ) +( ANY1 . 1 ) +( COMBOPC . 1 ) +( DROPT1 . 1 ) +( EQ2 . 1 ) +( FORTCAT . 1 ) +( ITFUN2 . 1 ) +( ITFUN3 . 1 ) +( ITUPLE . 1 ) +( MKBCFUNC . 1 ) +( MKRECORD . 1 ) +( MKUCFUNC . 1 ) +( NONE1 . 1 ) +( PATAB . 1 ) +( PLOT1 . 1 ) +( PPCURVE . 1 ) +( PSCURVE . 1 ) +( REAL . 1 ) +( RESLATC . 1 ) +( RETRACT . 1 ) +( RETRACT- . 1 ) +( SEGBIND2 . 1 ) +( SEGCAT . 1 ) +( STREAM1 . 1 ) +( STREAM2 . 1 ) +( STREAM3 . 1 ) +( FMC . 2 ) +( FMFUN . 2 ) +( FORTFN . 2 ) +( FVC . 2 ) +( FVFUN . 2 ) +( INTRET . 2 ) +( SEGXCAT . 2 ) +( AGG . 3 ) +( AGG- . 3 ) +( BASTYPE . 3 ) +( BASTYPE- . 3 ) +( GRDEF . 3 ) +( LIST3 . 3 ) +( MKFUNC . 3 ) +( ANON . 4 ) +( COLOR . 4 ) +( COMM . 4 ) +( COMPPROP . 4 ) +( ELTAGG . 4 ) +( ELTAGG- . 4 ) +( ESCONT1 . 4 ) +( EXIT . 4 ) +( FAMONC . 4 ) +( FILECAT . 4 ) +( FINITE . 4 ) +( FNCAT . 4 ) +( FORMULA1 . 4 ) +( IDPC . 4 ) +( IEVALAB . 4 ) +( IEVALAB- . 4 ) +( INTBIT . 4 ) +( LMODULE . 4 ) +( LOGIC . 4 ) +( LOGIC- . 4 ) +( MAPHACK1 . 4 ) +( MAPHACK2 . 4 ) +( MAPHACK3 . 4 ) +( MAPPKG1 . 4 ) +( MAPPKG2 . 4 ) +( MAPPKG3 . 4 ) +( MONAD . 4 ) +( MONAD- . 4 ) +( NIPROB . 4 ) +( NONE . 4 ) +( NUMINT . 4 ) +( ODECAT . 4 ) +( ODEPROB . 4 ) +( OMENC . 4 ) +( ONECOMP2 . 4 ) +( OPTCAT . 4 ) +( OPTPROB . 4 ) +( ORDSET . 4 ) +( ORDSET- . 4 ) +( PALETTE . 4 ) +( PARPCURV . 4 ) +( PARPC2 . 4 ) +( PARSCURV . 4 ) +( PARSC2 . 4 ) +( PARSURF . 4 ) +( PARSU2 . 4 ) +( PATMAB . 4 ) +( PATRES2 . 4 ) +( PATTERN1 . 4 ) +( PDECAT . 4 ) +( PDEPROB . 4 ) +( REPSQ . 4 ) +( REPDB . 4 ) +( RFDIST . 4 ) +( RIDIST . 4 ) +( RMODULE . 4 ) +( SEXCAT . 4 ) +( SGROUP . 4 ) +( SGROUP- . 4 ) +( SPACEC . 4 ) +( SPLNODE . 4 ) +( STEP . 4 ) +( SUCH . 4 ) +( TEX1 . 4 ) +( UDVO . 4 ) +( YSTREAM . 4 ) +( ATRIG . 5 ) +( ATRIG- . 5 ) +( BMODULE . 5 ) +( CACHSET . 5 ) +( CHARNZ . 5 ) +( CHARZ . 5 ) +( DVARCAT . 5 ) +( DVARCAT- . 5 ) +( ELEMFUN . 5 ) +( ELEMFUN- . 5 ) +( ESTOOLS2 . 5 ) +( EVALAB . 5 ) +( EVALAB- . 5 ) +( FCOMP . 5 ) +( FEVALAB . 5 ) +( FEVALAB- . 5 ) +( FPATMAB . 5 ) +( GROUP . 5 ) +( GROUP- . 5 ) +( IDPAM . 5 ) +( IDPO . 5 ) +( INCRMAPS . 5 ) +( IXAGG . 5 ) +( IXAGG- . 5 ) +( KERNEL2 . 5 ) +( LALG . 5 ) +( LALG- . 5 ) +( LINEXP . 5 ) +( MODMONOM . 5 ) +( MONADWU . 5 ) +( MONADWU- . 5 ) +( MRF2 . 5 ) +( NARNG . 5 ) +( NARNG- . 5 ) +( NSUP2 . 5 ) +( OASGP . 5 ) +( ODVAR . 5 ) +( OPQUERY . 5 ) +( ORDFIN . 5 ) +( ORDMON . 5 ) +( PATMATCH . 5 ) +( PERMCAT . 5 ) +( PDRING . 5 ) +( PDRING- . 5 ) +( SDVAR . 5 ) +( SUP2 . 5 ) +( TRIGCAT . 5 ) +( TRIGCAT- . 5 ) +( ULS2 . 5 ) +( UP2 . 5 ) +( AUTOMOR . 6 ) +( BGAGG . 6 ) +( BRAGG . 6 ) +( BRAGG- . 6 ) +( CARTEN2 . 6 ) +( CHARPOL . 6 ) +( COMPLEX2 . 6 ) +( DIFEXT . 6 ) +( DIFEXT- . 6 ) +( DLAGG . 6 ) +( ELAGG . 6 ) +( ELAGG- . 6 ) +( ES1 . 6 ) +( ES2 . 6 ) +( GRMOD . 6 ) +( GRMOD- . 6 ) +( HYPCAT . 6 ) +( HYPCAT- . 6 ) +( MKCHSET . 6 ) +( MODRING . 6 ) +( MODULE . 6 ) +( MODULE- . 6 ) +( NASRING . 6 ) +( NASRING- . 6 ) +( OAMON . 6 ) +( SORTPAK . 6 ) +( ZMOD . 6 ) +( ALGEBRA . 7 ) +( BTCAT . 7 ) +( FMCAT . 7 ) +( IDPOAM . 7 ) +( IFAMON . 7 ) +( GRALG . 7 ) +( GRALG- . 7 ) +( OCAMON . 7 ) +( PRQAGG . 7 ) +( QUAGG . 7 ) +( SKAGG . 7 ) +( BSTREE . 8 ) +( BTOURN . 8 ) +( CARD . 8 ) +( DRAWHACK . 8 ) +( DQAGG . 8 ) +( FACTFUNC . 8 ) +( FMTC . 8 ) +( FR2 . 8 ) +( FRAC2 . 8 ) +( FRUTIL . 8 ) +( ITAYLOR . 8 ) +( MLO . 8 ) +( NAALG . 8 ) +( NAALG- . 8 ) +( OAGROUP . 8 ) +( OAMONS . 8 ) +( OP . 8 ) +( ORDCOMP2 . 8 ) +( PID . 8 ) +( RANDSRC . 8 ) +( UNISEG2 . 8 ) +( XALG . 8 ) +( AMR . 9 ) +( AMR- . 9 ) +( DEGRED . 9 ) +( DLP . 9 ) +( EAB . 9 ) +( ESTOOLS1 . 9 ) +( FAGROUP . 9 ) +( FAMONOID . 9 ) +( FIELD . 9 ) +( FIELD- . 9 ) +( FLAGG . 9 ) +( FLAGG- . 9 ) +( FLINEXP . 9 ) +( FLINEXP- . 9 ) +( FRETRCT . 9 ) +( FRETRCT- . 9 ) +( FSERIES . 9 ) +( FT . 9 ) +( IDPAG . 9 ) +( IDPOAMS . 9 ) +( INFINITY . 9 ) +( LA . 9 ) +( OMLO . 9 ) +( ORTHPOL . 9 ) +( PRODUCT . 9 ) +( PADICCT . 9 ) +( PMPRED . 9 ) +( PMASS . 9 ) +( PTFUNC2 . 9 ) +( RADCAT . 9 ) +( RADCAT- . 9 ) +( RATRET . 9 ) +( RADUTIL . 9 ) +( UPXS2 . 9 ) +( XFALG . 9 ) +( ZLINDEP . 9 ) +( A1AGG . 10 ) +( A1AGG- . 10 ) +( ARR2CAT . 10 ) +( ARR2CAT- . 10 ) +( ASP34 . 10 ) +( BBTREE . 10 ) +( BFUNCT . 10 ) +( BPADIC . 10 ) +( BTREE . 10 ) +( CRAPACK . 10 ) +( DEQUEUE . 10 ) +( DLIST . 10 ) +( DRAWCX . 10 ) +( D01GBFA . 10 ) +( D02EJFA . 10 ) +( D03FAFA . 10 ) +( DRAWPT . 10 ) +( FAMR . 10 ) +( FAMR- . 10 ) +( FLASORT . 10 ) +( FLAGG2 . 10 ) +( FGROUP . 10 ) +( FM . 10 ) +( FM1 . 10 ) +( FPC . 10 ) +( FPC- . 10 ) +( FMONOID . 10 ) +( INDE . 10 ) +( IPADIC . 10 ) +( IROOT . 10 ) +( IR2 . 10 ) +( LEXP . 10 ) +( LIECAT . 10 ) +( LIECAT- . 10 ) +( LIST2 . 10 ) +( LIST2MAP . 10 ) +( LMOPS . 10 ) +( LZSTAGG . 10 ) +( LZSTAGG- . 10 ) +( MAGMA . 10 ) +( MESH . 10 ) +( MOEBIUS . 10 ) +( MODFIELD . 10 ) +( MODOP . 10 ) +( MRING . 10 ) +( MTHING . 10 ) +( NCNTFRAC . 10 ) +( NCODIV . 10 ) +( NUMTUBE . 10 ) +( ODR . 10 ) +( OFMONOID . 10 ) +( ONECOMP . 10 ) +( ORDCOMP . 10 ) +( OREPCAT . 10 ) +( OREPCAT- . 10 ) +( OWP . 10 ) +( PADIC . 10 ) +( PATTERN2 . 10 ) +( PATLRES . 10 ) +( PARTPERM . 10 ) +( PBWLB . 10 ) +( PENDTREE . 10 ) +( PGE . 10 ) +( PGROEB . 10 ) +( PINTERP . 10 ) +( PLOTTOOL . 10 ) +( PFR . 10 ) +( PMDOWN . 10 ) +( PRTITION . 10 ) +( PMINS . 10 ) +( PMLSAGG . 10 ) +( PMTOOLS . 10 ) +( PSCAT . 10 ) +( PSCAT- . 10 ) +( QFORM . 10 ) +( QUEUE . 10 ) +( SCACHE . 10 ) +( SEG . 10 ) +( SEG2 . 10 ) +( SEXOF . 10 ) +( STACK . 10 ) +( STTAYLOR . 10 ) +( TABLBUMP . 10 ) +( TABLEAU . 10 ) +( TOPSP . 10 ) +( TRANFUN . 10 ) +( TRANFUN- . 10 ) +( TUBE . 10 ) +( UDPO . 10 ) +( UNISEG . 10 ) +( VIEW . 10 ) +( VSPACE . 10 ) +( VSPACE- . 10 ) +( XPOLYC . 10 ) +( APPLYORE . 11 ) +( ARRAY1 . 11 ) +( ARRAY12 . 11 ) +( ARRAY2 . 11 ) +( ASTACK . 11 ) +( BTAGG . 11 ) +( COMBINAT . 11 ) +( CSTTOOLS . 11 ) +( D01FCFA . 11 ) +( E04MBFA . 11 ) +( FARRAY . 11 ) +( FLALG . 11 ) +( GALUTIL . 11 ) +( HEAP . 11 ) +( IARRAY1 . 11 ) +( IARRAY2 . 11 ) +( IFARRAY . 11 ) +( INTCAT . 11 ) +( INTHEORY . 11 ) +( IRREDFFX . 11 ) +( LFCAT . 11 ) +( LODOCAT . 11 ) +( LODOCAT- . 11 ) +( LWORD . 11 ) +( MATCAT . 11 ) +( MATCAT- . 11 ) +( MATSTOR . 11 ) +( ORESUP . 11 ) +( OREPCTO . 11 ) +( OREUP . 11 ) +( PLOT3D . 11 ) +( PR . 11 ) +( PREASSOC . 11 ) +( PRIMARR2 . 11 ) +( REDORDER . 11 ) +( SRAGG . 11 ) +( SRAGG- . 11 ) +( STREAM . 11 ) +( SYMPOLY . 11 ) +( TS . 11 ) +( TUPLE . 11 ) +( UPSCAT . 11 ) +( UPSCAT- . 11 ) +( VECTCAT . 11 ) +( VECTCAT- . 11 ) +( XDPOLY . 11 ) +( XEXPPKG . 11 ) +( XF . 11 ) +( XF- . 11 ) +( XPBWPOLY . 11 ) +( XPOLY . 11 ) +( XRPOLY . 11 ) +( BITS . 12 ) +( DIRPROD2 . 12 ) +( IMATRIX . 12 ) +( IVECTOR . 12 ) +( LPOLY . 12 ) +( LSMP . 12 ) +( LSMP1 . 12 ) +( MATCAT2 . 12 ) +( PTCAT . 12 ) +( STRICAT . 12 ) +( TRIMAT . 12 ) +( ASSOCEQ . 13 ) +( CARTEN . 13 ) +( CLIF . 13 ) +( CLIP . 13 ) +( COORDSYS . 13 ) +( DBASE . 13 ) +( DHMATRIX . 13 ) +( DIOSP . 13 ) +( DIRPCAT . 13 ) +( DIRPCAT- . 13 ) +( D02BBFA . 13 ) +( D02BHFA . 13 ) +( D02CJFA . 13 ) +( FAXF . 13 ) +( FFPOLY2 . 13 ) +( FNLA . 13 ) +( GRAY . 13 ) +( HB . 13 ) +( IRSN . 13 ) +( MCALCFN . 13 ) +( MHROWRED . 13 ) +( NUMODE . 13 ) +( NUMQUAD . 13 ) +( ODESYS . 13 ) +( ODETOOLS . 13 ) +( ORDFUNS . 13 ) +( PERMAN . 13 ) +( PFECAT . 13 ) +( PFECAT- . 13 ) +( POINT . 13 ) +( PSEUDLIN . 13 ) +( PTPACK . 13 ) +( REP2 . 13 ) +( SETMN . 13 ) +( SEX . 13 ) +( STRING . 13 ) +( SYMFUNC . 13 ) +( VECTOR2 . 13 ) +( ASP1 . 14 ) +( ASP10 . 14 ) +( ASP24 . 14 ) +( ASP4 . 14 ) +( ASP50 . 14 ) +( ASP6 . 14 ) +( ASP73 . 14 ) +( BALFACT . 14 ) +( BEZOUT . 14 ) +( BINARY . 14 ) +( BINFILE . 14 ) +( BOUNDZRO . 14 ) +( BPADICRT . 14 ) +( BRILL . 14 ) +( CDEN . 14 ) +( CHVAR . 14 ) +( COMMUPC . 14 ) +( CONTFRAC . 14 ) +( CVMP . 14 ) +( CYCLOTOM . 14 ) +( CYCLES . 14 ) +( DDFACT . 14 ) +( DECIMAL . 14 ) +( DIOPS . 14 ) +( DIOPS- . 14 ) +( DIRPROD . 14 ) +( DISPLAY . 14 ) +( DMP . 14 ) +( DPMO . 14 ) +( DPOLCAT . 14 ) +( DPOLCAT- . 14 ) +( D01AJFA . 14 ) +( D01AKFA . 14 ) +( D01ALFA . 14 ) +( D01AMFA . 14 ) +( D01APFA . 14 ) +( D01AQFA . 14 ) +( EMR . 14 ) +( EQ . 14 ) +( ERROR . 14 ) +( EVALCYC . 14 ) +( E04DGFA . 14 ) +( E04FDFA . 14 ) +( E04GCFA . 14 ) +( E04JAFA . 14 ) +( FACUTIL . 14 ) +( FF . 14 ) +( FFCG . 14 ) +( FFCGX . 14 ) +( FFF . 14 ) +( FFHOM . 14 ) +( FFNB . 14 ) +( FFNBX . 14 ) +( FFPOLY . 14 ) +( FFSLPE . 14 ) +( FFX . 14 ) +( FGLMICPK . 14 ) +( FILE . 14 ) +( FINAALG . 14 ) +( FINRALG . 14 ) +( FLOATRP . 14 ) +( FNAME . 14 ) +( FOP . 14 ) +( FORMULA . 14 ) +( FORT . 14 ) +( FRAC . 14 ) +( FTEM . 14 ) +( GALFACTU . 14 ) +( GALPOLYU . 14 ) +( GB . 14 ) +( GBEUCLID . 14 ) +( GBF . 14 ) +( GBINTERN . 14 ) +( GENEEZ . 14 ) +( GENMFACT . 14 ) +( GENPGCD . 14 ) +( GHENSEL . 14 ) +( GMODPOL . 14 ) +( GOSPER . 14 ) +( GRIMAGE . 14 ) +( GROEBSOL . 14 ) +( HDMP . 14 ) +( HDP . 14 ) +( HEXADEC . 14 ) +( HEUGCD . 14 ) +( IBPTOOLS . 14 ) +( IBITS . 14 ) +( ICARD . 14 ) +( ICDEN . 14 ) +( IDECOMP . 14 ) +( IFF . 14 ) +( IIARRAY2 . 14 ) +( IMATLIN . 14 ) +( IMATQF . 14 ) +( INMODGCD . 14 ) +( INNMFACT . 14 ) +( INPSIGN . 14 ) +( INTHERTR . 14 ) +( INTRAT . 14 ) +( INTRF . 14 ) +( INTSLPE . 14 ) +( INTTR . 14 ) +( ISUMP . 14 ) +( LAUPOL . 14 ) +( LEADCDET . 14 ) +( LGROBP . 14 ) +( LIMITRF . 14 ) +( LINDEP . 14 ) +( LO . 14 ) +( LPEFRAC . 14 ) +( LSPP . 14 ) +( MATLIN . 14 ) +( MCDEN . 14 ) +( MDDFACT . 14 ) +( MFINFACT . 14 ) +( MFLOAT . 14 ) +( MINT . 14 ) +( MLIFT . 14 ) +( MMAP . 14 ) +( MODMON . 14 ) +( MONOTOOL . 14 ) +( MPCPF . 14 ) +( MPC2 . 14 ) +( MPC3 . 14 ) +( MPOLY . 14 ) +( MPRFF . 14 ) +( MRATFAC . 14 ) +( MULTSQFR . 14 ) +( NORMRETR . 14 ) +( NPCOEF . 14 ) +( NSUP . 14 ) +( NTPOLFN . 14 ) +( ODP . 14 ) +( ODEPRIM . 14 ) +( ODEPRRIC . 14 ) +( OMPKG . 14 ) +( OMSERVER . 14 ) +( PADEPAC . 14 ) +( PADICRAT . 14 ) +( PADICRC . 14 ) +( PCOMP . 14 ) +( PDECOMP . 14 ) +( PF . 14 ) +( PFBR . 14 ) +( PFBRU . 14 ) +( PFOTOOLS . 14 ) +( PFRPAC . 14 ) +( PGCD . 14 ) +( PINTERPA . 14 ) +( PLEQN . 14 ) +( PMPLCAT . 14 ) +( PMQFCAT . 14 ) +( PNTHEORY . 14 ) +( POLUTIL . 14 ) +( POLTOPOL . 14 ) +( POLYCATQ . 14 ) +( POLYLIFT . 14 ) +( POLYROOT . 14 ) +( POLY2 . 14 ) +( POLY2UP . 14 ) +( PRS . 14 ) +( PSQFR . 14 ) +( PUSHVAR . 14 ) +( QALGSET . 14 ) +( QFCAT2 . 14 ) +( RADIX . 14 ) +( RATFACT . 14 ) +( RCFIELD . 14 ) +( RDETR . 14 ) +( RDETRS . 14 ) +( REAL0 . 14 ) +( REAL0Q . 14 ) +( REALSOLV . 14 ) +( RESRING . 14 ) +( RETSOL . 14 ) +( RF . 14 ) +( RFFACTOR . 14 ) +( RMATCAT . 14 ) +( RRCC . 14 ) +( SCPKG . 14 ) +( SHDP . 14 ) +( SHP . 14 ) +( SIGNRF . 14 ) +( SMITH . 14 ) +( SMP . 14 ) +( SMTS . 14 ) +( SOLVEFOR . 14 ) +( SPLTREE . 14 ) +( STINPROD . 14 ) +( STTFNC . 14 ) +( SUBRESP . 14 ) +( SUMRF . 14 ) +( SUP . 14 ) +( SUPFRACF . 14 ) +( TANEXP . 14 ) +( TEMUTL . 14 ) +( TEX . 14 ) +( TEXTFILE . 14 ) +( TREE . 14 ) +( TWOFACT . 14 ) +( UNIFACT . 14 ) +( UP . 14 ) +( UPCDEN . 14 ) +( UPDECOMP . 14 ) +( UPDIVP . 14 ) +( UPMP . 14 ) +( UPOLYC2 . 14 ) +( UPXSCAT . 14 ) +( VIEWDEF . 14 ) +( UPSQFREE . 14 ) +( VIEW2D . 14 ) +( VOID . 14 ) +( WEIER . 14 ) +( WP . 14 ) +( DIAGG . 15 ) +( DIAGG- . 15 ) +( DSMP . 15 ) +( EXPUPXS . 15 ) +( FRAMALG . 15 ) +( FRAMALG- . 15 ) +( MDAGG . 15 ) +( ODPOL . 15 ) +( PLOT . 15 ) +( RMCAT2 . 15 ) +( ROIRC . 15 ) +( SDPOL . 15 ) +( SMATCAT . 15 ) +( SMATCAT- . 15 ) +( TUBETOOL . 15 ) +( UPXSCCA . 15 ) +( DPMM . 16 ) +( EFUPXS . 16 ) +( FFINTBAS . 16 ) +( FRIDEAL . 16 ) +( FRIDEAL2 . 16 ) +( FRMOD . 16 ) +( FSAGG . 16 ) +( IBATOOL . 16 ) +( INTFACT . 16 ) +( KDAGG . 16 ) +( KDAGG- . 16 ) +( MSETAGG . 16 ) +( MONOGEN . 16 ) +( MONOGEN- . 16 ) +( NFINTBAS . 16 ) +( SPACE3 . 16 ) +( CCLASS . 17 ) +( FSAGG2 . 17 ) +( GALFACT . 17 ) +( IALGFACT . 17 ) +( IBACHIN . 17 ) +( NORMMA . 17 ) +( ODERED . 17 ) +( OMSAGG . 17 ) +( PERM . 17 ) +( PERMGRP . 17 ) +( PRIMES . 17 ) +( PWFFINTB . 17 ) +( RDIST . 17 ) +( SAE . 17 ) +( SAEFACT . 17 ) +( SAERFFC . 17 ) +( SGCF . 17 ) +( TBAGG . 17 ) +( VIEW3D . 17 ) +( ALIST . 18 ) +( EQTBL . 18 ) +( GSTBL . 18 ) +( HASHTBL . 18 ) +( INTABL . 18 ) +( INTFTBL . 18 ) +( INTPACK . 18 ) +( IPF . 18 ) +( KAFILE . 18 ) +( PATRES . 18 ) +( STBL . 18 ) +( STRTBL . 18 ) +( TABLE . 18 ) +( TBCMPPK . 18 ) +( ACF . 19 ) +( ACF- . 19 ) +( ACPLOT . 19 ) +( ANTISYM . 19 ) +( ANY . 19 ) +( ASP12 . 19 ) +( ASP27 . 19 ) +( ASP28 . 19 ) +( ASP33 . 19 ) +( ASP49 . 19 ) +( ASP55 . 19 ) +( ASP7 . 19 ) +( ASP78 . 19 ) +( ASP8 . 19 ) +( ASP9 . 19 ) +( ATTRBUT . 19 ) +( BOP . 19 ) +( BOP1 . 19 ) +( COMMONOP . 19 ) +( COMPCAT . 19 ) +( COMPCAT- . 19 ) +( DRAW . 19 ) +( DRAWCFUN . 19 ) +( DROPT . 19 ) +( DROPT0 . 19 ) +( D01ANFA . 19 ) +( D01ASFA . 19 ) +( D03AGNT . 19 ) +( EP . 19 ) +( E04AGNT . 19 ) +( FCPAK1 . 19 ) +( FEXPR . 19 ) +( FFCAT . 19 ) +( FFCGP . 19 ) +( FFNBP . 19 ) +( FFP . 19 ) +( FLOAT . 19 ) +( FPARFRAC . 19 ) +( FR . 19 ) +( FRNAALG . 19 ) +( FS . 19 ) +( FST . 19 ) +( FUNCTION . 19 ) +( GDMP . 19 ) +( HACKPI . 19 ) +( IDEAL . 19 ) +( INFORM . 19 ) +( INFORM1 . 19 ) +( IPRNTPK . 19 ) +( IR . 19 ) +( ISUPS . 19 ) +( KERNEL . 19 ) +( LIB . 19 ) +( LMDICT . 19 ) +( LODOOPS . 19 ) +( MATRIX . 19 ) +( MKFLCFN . 19 ) +( MSET . 19 ) +( M3D . 19 ) +( NAGC02 . 19 ) +( NAGC05 . 19 ) +( NAGC06 . 19 ) +( NAGD03 . 19 ) +( NAGE01 . 19 ) +( NAGE02 . 19 ) +( NAGE04 . 19 ) +( NAGF07 . 19 ) +( NAGS . 19 ) +( NAGSP . 19 ) +( NREP . 19 ) +( NUMFMT . 19 ) +( OC . 19 ) +( ODEPACK . 19 ) +( ODERAT . 19 ) +( OMERR . 19 ) +( OMERRK . 19 ) +( OPTPACK . 19 ) +( OSI . 19 ) +( OVAR . 19 ) +( PATTERN . 19 ) +( PMKERNEL . 19 ) +( PMSYM . 19 ) +( POLY . 19 ) +( PRIMELT . 19 ) +( QALGSET2 . 19 ) +( QEQUAT . 19 ) +( QUATCAT . 19 ) +( RECLOS . 19 ) +( REP1 . 19 ) +( RESULT . 19 ) +( RFFACT . 19 ) +( RMATRIX . 19 ) +( ROMAN . 19 ) +( ROUTINE . 19 ) +( RPOLCAT . 19 ) +( RULECOLD . 19 ) +( SAOS . 19 ) +( SEGBIND . 19 ) +( SET . 19 ) +( SPECOUT . 19 ) +( SQMATRIX . 19 ) +( SWITCH . 19 ) +( SYMS . 19 ) +( SYMTAB . 19 ) +( SYSSOLP . 19 ) +( UTSCAT . 19 ) +( VARIABLE . 19 ) +( WFFINTBS . 19 ) +( ACFS . 20 ) +( AF . 20 ) +( ALGFACT . 20 ) +( ALGFF . 20 ) +( ALGMANIP . 20 ) +( ALGMFACT . 20 ) +( ALGPKG . 20 ) +( ALGSC . 20 ) +( AN . 20 ) +( APPRULE . 20 ) +( ASP19 . 20 ) +( ASP20 . 20 ) +( ASP30 . 20 ) +( ASP31 . 20 ) +( ASP35 . 20 ) +( ASP41 . 20 ) +( ASP42 . 20 ) +( ASP74 . 20 ) +( ASP77 . 20 ) +( ASP80 . 20 ) +( ASP9 . 20 ) +( CINTSLPE . 20 ) +( COMPFACT . 20 ) +( COMPLEX . 20 ) +( COMPLPAT . 20 ) +( CMPLXRT . 20 ) +( CPMATCH . 20 ) +( CRFP . 20 ) +( CTRIGMNP . 20 ) +( D02AGNT . 20 ) +( D03EEFA . 20 ) +( DBLRESP . 20 ) +( DERHAM . 20 ) +( DFSFUN . 20 ) +( DRAWCURV . 20 ) +( E04NAFA . 20 ) +( E04UCFA . 20 ) +( EF . 20 ) +( EFSTRUC . 20 ) +( ELFUTS . 20 ) +( ESTOOLS . 20 ) +( EXPEXPAN . 20 ) +( EXPRODE . 20 ) +( EXPRTUBE . 20 ) +( EXPR2 . 20 ) +( FC . 20 ) +( FDIVCAT . 20 ) +( FDIV2 . 20 ) +( FFCAT2 . 20 ) +( FLOATCP . 20 ) +( FORDER . 20 ) +( FORTRAN . 20 ) +( FRNAAF2 . 20 ) +( FSPECF . 20 ) +( FSRED . 20 ) +( FSUPFACT . 20 ) +( FS2 . 20 ) +( FS2UPS . 20 ) +( GAUSSFAC . 20 ) +( GCNAALG . 20 ) +( GENUFACT . 20 ) +( GENUPS . 20 ) +( GTSET . 20 ) +( GPOLSET . 20 ) +( IAN . 20 ) +( INEP . 20 ) +( INFPROD0 . 20 ) +( INFSP . 20 ) +( INPRODFF . 20 ) +( INPRODPF . 20 ) +( INTAF . 20 ) +( INTALG . 20 ) +( INTEF . 20 ) +( INTG0 . 20 ) +( INTHERAL . 20 ) +( INTPAF . 20 ) +( INTPM . 20 ) +( INTTOOLS . 20 ) +( ITRIGMNP . 20 ) +( JORDAN . 20 ) +( KOVACIC . 20 ) +( LF . 20 ) +( LIE . 20 ) +( LODOF . 20 ) +( LSQM . 20 ) +( OMEXPR . 20 ) +( MCMPLX . 20 ) +( MULTFACT . 20 ) +( NAGD01 . 20 ) +( NAGD02 . 20 ) +( NAGF01 . 20 ) +( NAGF02 . 20 ) +( NAGF04 . 20 ) +( NCEP . 20 ) +( NLINSOL . 20 ) +( NSMP . 20 ) +( NUMERIC . 20 ) +( OCT . 20 ) +( OCTCT2 . 20 ) +( ODEPAL . 20 ) +( ODERTRIC . 20 ) +( PADE . 20 ) +( PAN2EXPR . 20 ) +( PDEPACK . 20 ) +( PFO . 20 ) +( PFOQ . 20 ) +( PICOERCE . 20 ) +( PMASSFS . 20 ) +( PMFS . 20 ) +( PMPREDFS . 20 ) +( PRIMELT . 20 ) +( PSETPK . 20 ) +( QUAT . 20 ) +( QUATCT2 . 20 ) +( RADFF . 20 ) +( RDEEF . 20 ) +( RDEEFS . 20 ) +( RDIV . 20 ) +( RSETCAT . 20 ) +( RULE . 20 ) +( RULESET . 20 ) +( SIMPAN . 20 ) +( SFORT . 20 ) +( SOLVESER . 20 ) +( SUMFS . 20 ) +( SUTS . 20 ) +( TOOLSIGN . 20 ) +( TRIGMNIP . 20 ) +( TRMANIP . 20 ) +( ULSCCAT . 20 ) +( UPXSSING . 20 ) +( UTSODE . 20 ) +( UTSODETL . 20 ) +( UTS2 . 20 ) +( WUTSET . 20 ) +( DEFINTEF . 21 ) +( DFINTTLS . 21 ) +( DEFINTRF . 21 ) +( D01TRNS . 21 ) +( EFULS . 21 ) +( ESCONT . 21 ) +( EXPR . 21 ) +( EXPR2UPS . 21 ) +( FDIV . 21 ) +( FSCINT . 21 ) +( FSINT . 21 ) +( FS2EXPXP . 21 ) +( GSERIES . 21 ) +( HELLFDIV . 21 ) +( INVLAPLA . 21 ) +( IR2F . 21 ) +( LAPLACE . 21 ) +( LIMITPS . 21 ) +( LODEEF . 21 ) +( NODE1 . 21 ) +( ODECONST . 21 ) +( ODEINT . 21 ) +( REP . 21 ) +( SOLVERAD . 21 ) +( SULS . 21 ) +( SUPXS . 21 ) +( ULS . 21 ) +( ULSCONS . 21 ) +( UPXS . 21 ) +( UPXSCONS . 21 ) +( UTS . 21 ) +)) + +\start +Date: Sat, 23 Aug 2003 10:49:54 +0200 +From: =?iso-8859-1?Q?Fr=E9d=E9ric_Lehobey?= +To: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Dear Camm, + +> Greetings! Is anyone interested in me releasing an experimental +> Debian package for the unstable distribution only, presuming I can +> reproduce the below, or is this still premature? + + Yes. I would test it. David Mentré and I can even try to help to the +powerpc and sparc ports. + +Best regards, +Frédéric Lehobey + +\start +Date: Sat, 23 Aug 2003 04:48:12 -0400 +From: root +To: weiss@uni-mainz.de +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] string.spad + +Yes, I see that the parser expands left hand sides and *I* do consider it +a bug. I'll fix it some other time as it isn't on the critical path. I added +it to the bug list to make sure it gets remembered. The failure causes a +stack overflow which is not a reasonable failure mode of a compiler. + +\start +Date: Sat, 23 Aug 2003 05:28:10 -0400 +From: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca, daly@idsi.net +Subject: [Axiom-developer] Stack overflow problem + +Camm, + +The stack overflow problem is caused by the Axiom preparser. It +scans for macros and expands BOTH sides of the macros based on +previous macros. The failure occcurs if there are 2 macros with +the same name in the same file. The expansion becomes: + +env: () +macro: MAX ==> 1 +env: (MAX ==> 1) +macro: MAX ==> 1 +env (1 ==> 1, MAX ==> 1) +macro 1 + 1 + crash + +It is considered (by me) a bug to expand the left hand side of the macro. +I don't know where this is done but it needs to be fixed. I fear the +"correct" fix will take me into the meta code using the meta compiler. + +This is not a GCL failure (although GCL is particularly unhelpful +when debugging stack overflows as :bt will crash GCL). + +\start +Date: Sat, 23 Aug 2003 06:07:29 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] graphing the lattice + +More thought about this subject after closing my eyes for the evening: + +You don't need a general 3-space layout. You can do it as a set of +parallel 2-space planes. Consider the following: + +create a plane[0] +layout the bootstrap layer along the x axis. +layout the 0th layer above the bootstrap layer. +if a 0th layer item cannot be laid out without crossings + then create a new plane, say plane[1] + insert the new item into plane[1] connected with "lines" + drawn back to plane[0] +layout the 1st layer above the 0th layer +if a 1st layer item cannot be laid out without crossings + then create a new plane, say plane[2] + insert the new item into plane[2] connected with "lines" + drawn back to plane[0] +In general this may require quite a few planes. Only lines that +connect planes need connectors. + +An optimization would be to lay out items in a "greedy" manner so +that you only create plane[2] when a crossing occurs in plane[1]. + +\start +Date: Sat, 23 Aug 2003 11:43:52 +0200 +From: "Weiss, Juergen" +To: , +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca +Subject: [Axiom-developer] RE: Stack overflow problem + +I have not really checked it, only looked at the code. +In compiler.boot the function compMacro calls the +function macroExpand with the complete form as an +argument. This seems to be wrong. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Saturday, August 23, 2003 11:28 AM +> To: camm@enhanced.com +> Cc: bill.page1@sympatico.ca; Weiss, Juergen; daly@idsi.net; +> axiom-developer@nongnu.org +> Subject: Stack overflow problem +> +> +> Camm, +> +> The stack overflow problem is caused by the Axiom preparser. It +> scans for macros and expands BOTH sides of the macros based on +> previous macros. The failure occcurs if there are 2 macros with +> the same name in the same file. The expansion becomes: +> +> env: () +> macro: MAX ==> 1 +> env: (MAX ==> 1) +> macro: MAX ==> 1 +> env (1 ==> 1, MAX ==> 1) +> macro 1 + 1 +> crash +> +> It is considered (by me) a bug to expand the left hand side +> of the macro. +> I don't know where this is done but it needs to be fixed. I fear the +> "correct" fix will take me into the meta code using the meta compiler. +> +> This is not a GCL failure (although GCL is particularly unhelpful +> when debugging stack overflows as :bt will crash GCL). +> +> Tim +> axiom@tenkan.org +> daly@idsi.net +> + +\start +Date: 24 Aug 2003 21:29:45 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: Automation & algebra lattice + +Tim, + +Well, it turns out that the newest version of VCG is called aiSee. + + http://www.aisee.com/ + + [wspage@asus axiom2]$ aisee -- + aiSee V.2.1 AbsInt Angewandte Informatik GmbH + Revision: 1.88 Date: 2003/06/23 15:24:52 + Usage: /usr/local/bin/aisee.bin [options] [filename] + Enter /usr/local/bin/aisee.bin -h for help information. + +This version seems to no longer be GPL but the binary is still +available at no cost for personal, academic and/or research use. +So I downloaded it to see if the newer version would fair any +better with the Axiom dependency graph. + + [wspage@asus axiom2]$ aisee -f all.gdl + Wait....lSegmentation fault + +Well, at least it didn't crash Linux this time! + +There are lots of options to play with (-f above means use the +fastest layout option), so maybe I will find one that will work. +There is even an "automatic clustering" option. But perhaps +I will eventually be forced to use the more intellegent approach +that you suggest below. + +I guess I could start by selecting from the whole dependency list +only those nodes in that are in layer 1 and add the "bootstrap" +nodes without their dependencies. The layer 1 nodes should not +depend on any spad files outside of layer 1 and the bootstrap, +right? + +But really I would like to draw the *graph* including it's +cycles, not just the lattice that is implemented in the make +file. Hmmm.... + +Cheers, +Bill Page. + +----- Original Message ----- +>From: "root" +>To: +>Cc: ; ; +>Sent: Saturday, August 23, 2003 5:18 AM +>Subject: [Axiom-developer] Re: dependency visualization with VCG + + +> Bill, +> +> Crashed linux. damn. that's a HUGE bug in that program. Can't imagine +> how they do that. +> +> I'd approach the problem somewhat differently. The lattice LEVEL order +> is specified in the Makefile.pamphlet file. Given the first level as a +> base you can graph the second level. Then iterate with the second +> level as a base. The program should complain if it can find a file +> at level i that can be pushed into level i-1 (which means I made a +> mistake). +> ... + +\start +Date: Sun, 24 Aug 2003 21:57:28 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] RE: Automation & algebra lattice + +well, several comments. + +perhaps if they made aisee open source we could fix the bugs. + +the difference between the makefile lattice and the full graph +can be discovered by compiling the bootstrap domains as spad +files (use notangle to extract the spad code, not the bootstrap +code). Since you already have a running axiom with running algebra +the bootstrap domains should compile cleanly. Save the console +file from each compile, collect all of the Loading messages, +strip out their domains, and find out where the bootstrap files +occur in the lattice. In particular, find out where they occur +without the bootstrap files. Once you've successfully classified +the bootstrap domains you no longer need the bootstrap layer of +the lattice (and, in fact, it shouldn't be there any longer since +each domain in the bootstrap appears elsewhere in the graph). + +as to the "two paper lattice layout algorithm" I mentioned earlier: +there is a subtle case that happens when you try to place two files +at the same lattice level in the plane. don't know if I can explain +this without pictures. suppose C depends on A and B. supposed D +depends on A and B. if you start the process and put A and B on the +bottom line at the same level you see: + + + A B + +then you add C + + C -- layer 1 line + / \ + / \ + / \ + A B -- layer 0 line + +Now if you add D at the same "height" as C it can appear to the left +of C or the right of C. + + D C -- layer 1 line + / \ + / \ + / \ + A B -- layer 0 line + + +In either case when you try to link D with A and B you are forced to +have a pair of lines that cross. However, if the same "height" is an +area rather than a line you can add "slightly" above C: + + + D -- + > layer 1 "area" + C -- + / \ + / \ + / \ + A B -- layer 0 line + +and now it is possible to draw non-intersecting lines from D to A and B. +So the problem gets more complex if you allow an "area" for laying out +a single lattice level. + +\start +Date: Sun, 24 Aug 2003 23:11:39 -0400 +From: root +To: Daniel.Lazard@lip6.fr +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Axiom and the Lazard-Moreno Solving Package + +Daniel, + +I'm Tim Daly, the lead developer for Axiom which is now open source. +I'm not sure if you remember me from the past. I used to work on +Axiom at IBM Research and am now working to make it publicly +available. I'm cleaning up the last details of the algebra before +publishing the sources and I notice that there is a domain called +LazardMorenoSolvingPackage. This domain doesn't appear to exist +anywhere. Do you have a copy of the source and would you allow us to +add it to the open source version of the system? + +\start +Date: 24 Aug 2003 22:00:33 -0400 +From: Bill Page +To: daly@idsi.net, Juergen Weiss +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] Patch to Juergen's Makefile + +Here is a patch to Juergen's Makefile to eliminate unnecessary +.spad files with lower case names in the int/algebra directory. +If not eliminated, these files end up as extra nodes and edges +in the dependency graph. + +---------- + + +--- weiss/axiom2/src/algebra/Makefile 2003-08-20 22:23:37.000000000 +-0400 ++++ wspage/axiom2/src/algebra/Makefile 2003-08-22 20:08:04.000000000 +-0400 +@@ -631,8 +631,11 @@ + + # original algebra source files combining several related modules + +-SOURCE_FILES= $(addprefix ${MID}/, $(SPADFILES:%=%.spad)) \ +- ${MID}/INTERP.EXPOSED ${MID}/exposed.lsp ++#SOURCE_FILES= $(addprefix ${MID}/, $(SPADFILES:%=%.spad)) \ ++# ${MID}/INTERP.EXPOSED ${MID}/exposed.lsp ++ ++SOURCE_FILES= ${MID}/INTERP.EXPOSED ${MID}/exposed.lsp ++ + + # object files in build order + +-------- + +\start +Date: Mon, 25 Aug 2003 10:46:46 +0200 +From: "Weiss, Juergen" +To: , +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] RE: Automation & algebra lattice + +Some domains may be preloaded at compile time of +the interpsys executable. To get reliable dependencies, +you should generate an interpsys without preloaded +algebra modules. + + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Monday, August 25, 2003 3:57 AM +> To: bill.page1@sympatico.ca +> Cc: axiom-developer@nongnu.org; daly@idsi.net +> Subject: Re: [Axiom-developer] RE: Automation & algebra lattice +> +> +> well, several comments. +> +> perhaps if they made aisee open source we could fix the bugs. +> +> the difference between the makefile lattice and the full graph +> can be discovered by compiling the bootstrap domains as spad +> files (use notangle to extract the spad code, not the bootstrap +> code). Since you already have a running axiom with running algebra +> the bootstrap domains should compile cleanly. Save the console +> file from each compile, collect all of the Loading messages, +> strip out their domains, and find out where the bootstrap files +> occur in the lattice. In particular, find out where they occur +> without the bootstrap files. Once you've successfully classified +> the bootstrap domains you no longer need the bootstrap layer of +> the lattice (and, in fact, it shouldn't be there any longer since +> each domain in the bootstrap appears elsewhere in the graph). +> +> as to the "two paper lattice layout algorithm" I mentioned earlier: +> there is a subtle case that happens when you try to place two files +> at the same lattice level in the plane. don't know if I can explain +> this without pictures. suppose C depends on A and B. supposed D +> depends on A and B. if you start the process and put A and B on the +> bottom line at the same level you see: +> +> +> A B +> +> then you add C +> +> C -- layer 1 line +> / \ +> / \ +> / \ +> A B -- layer 0 line +> +> Now if you add D at the same "height" as C it can appear to the left +> of C or the right of C. +> +> D C -- layer 1 line +> / \ +> / \ +> / \ +> A B -- layer 0 line +> +> +> In either case when you try to link D with A and B you are forced to +> have a pair of lines that cross. However, if the same "height" is an +> area rather than a line you can add "slightly" above C: +> +> +> D -- +> > layer 1 "area" +> C -- +> / \ +> / \ +> / \ +> A B -- layer 0 line +> +> and now it is possible to draw non-intersecting lines from D +> to A and B. +> So the problem gets more complex if you allow an "area" for laying out +> a single lattice level. +> + +\start +Date: Tue, 26 Aug 2003 12:39:51 -0400 +From: root +To: kortenkamp@inf.fu-berlin.de +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, tim@tenkan.org +Subject: [Axiom-developer] Re: axiom letter + +Ulli, + +The Axiom homepage is at savannah.nongnu.org/projects/axiom. +There is currently nothing there at the moment but I expect to upload +the alpha versions of the sources tonight or tomorrow (depending on +whether the alpha particle emits). Long term plans are on the link +marked "Homepage". + +The prior homepage contains a hand-built downloadable version which +runs on Redhat Linux 9 (my build platform). It is available at +axiom.tenkan.org. + +The current state is that Axiom will build from scratch from the +sources, at least on my platform. The build has not yet been tested. +The testing process itself is undergoing rebuilding and generalization. +The build consists of the algebra/interpreter/compiler. It does not +yet contain the graphics or hyperdoc. + +\start +Date: Tue, 26 Aug 2003 13:08:06 -0400 +From: root +To: Juergen Weiss , axiom-developer@nongnu.org +Subject: [Axiom-developer] interval.spad + +Juergen, + +Let me know if this succeeds or fails in your version: + +start interpsys and type: + +)co interval.spad )con INTRVL + +\start +Date: Tue, 26 Aug 2003 20:31:51 +0200 +From: David MENTRE +To: "Bill Page" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: dependency visualization with VCG + +Hi Bill, + +Sorry for the late reply. My real life is interfering with my hacking +activities. ;-) + +"Bill Page" writes: + +> The Axiom dependency graph that I tried to use with xvcg has +> over 1040 nodes and more than 17,000 edges (dependencies). + +I'm currently trying with a smaller graph (just dependencies between +spad file generated by your script). + +> Do you have any ideas about the size of graphs that can be +> successfully manipulated with VCG? Do you have any suggestions +> on where to go from here? Do you think of any way to segment +> the Axiom dependency graph into smaller more managable +> sub-graphs? + +Sorry, I have no answer to all of your questions. I'm just a occasional +VCG user. + +By the way, I think your script would be a good candidate for literate +programming. The conciseness of Perl makes some parts of your script +quite obscure. :) + +In fact, the most missing part is an example that would explain what the +code is doing. + +In your perl script, how have you handle the case of macros? + +\start +Date: Tue, 26 Aug 2003 21:25:06 +0200 (CEST) +From: Martin RUBEY +To: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Re: dependency visualization with VCG + +I don't know whether that could help, but tulip is designed to process +*very* large graphs. (and it is GPL) + +http://www.tulip-software.org/ + +\start +Date: Tue, 26 Aug 2003 15:55:27 -0400 +From: "Page, Bill" +To: "'daly@idsi.net'" , Juergen Weiss +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] interval.spad + +The compile of interval.spad seems to work on my +incarnation of Juergen's version. The axiom output +file is attached. + +Cheers, +Bill Page. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Tuesday, August 26, 2003 1:08 PM +> To: Juergen Weiss; axiom-developer@nongnu.org +> Subject: [Axiom-developer] interval.spad +> +> +> Juergen, +> +> Let me know if this succeeds or fails in your version: +> +> start interpsys and type: +> +> )co interval.spad )con INTRVL +> +> Tim + +------_=_NextPart_000_01C36C0B.FEBB1760 +Content-Type: application/octet-stream; + name="interval.log" +Content-Transfer-Encoding: quoted-printable +Content-Disposition: attachment; + filename="interval.log" + +AXIOM=/home/bpage/axiom2/mnt/linux +DAASE=/home/bpage/axiom2/mnt/linux/../../share + +(AXIOM Sockets) The AXIOM server number is undefined. +------------------------------------------------------------------------= +----- + Issue )copyright to view copyright notices. + Issue )summary for a summary of useful system commands. + Issue )quit to leave AXIOM and return to shell. +Wednesday August 13, 2003 at 02:07:33 +------------------------------------------------------------------------= +----- + + Using local database = +/home/bpage/axiom2/mnt/linux/../../share/algebra/compress.daase.. = +Using local database = +/home/bpage/axiom2/mnt/linux/../../share/algebra/interp.daase.. + Using local database = +/home/bpage/axiom2/mnt/linux/../../share/algebra/operation.daase.. + Using local database = +/home/bpage/axiom2/mnt/linux/../../share/algebra/category.daase.. + Using local database = +/home/bpage/axiom2/mnt/linux/../../share/algebra/browse.daase.. +(1) -> )co interval )con INTRVL + Loading /home/bpage/axiom2/mnt/linux/autoload/apply. + Loading /home/bpage/axiom2/mnt/linux/autoload/c-doc. + Loading /home/bpage/axiom2/mnt/linux/autoload/c-util. + Loading /home/bpage/axiom2/mnt/linux/autoload/profile. + Loading /home/bpage/axiom2/mnt/linux/autoload/category. + Loading /home/bpage/axiom2/mnt/linux/autoload/compiler. + Loading /home/bpage/axiom2/mnt/linux/autoload/define. + Loading /home/bpage/axiom2/mnt/linux/autoload/functor. + Loading /home/bpage/axiom2/mnt/linux/autoload/info. + Loading /home/bpage/axiom2/mnt/linux/autoload/iterator. + Loading /home/bpage/axiom2/mnt/linux/autoload/modemap. + Loading /home/bpage/axiom2/mnt/linux/autoload/nruncomp. + Loading /home/bpage/axiom2/mnt/linux/autoload/package. + Loading /home/bpage/axiom2/mnt/linux/autoload/htcheck. + Loading /home/bpage/axiom2/mnt/linux/autoload/xruncomp. + Compiling AXIOM source code from file + /home/bpage/axiom2/int/algebra/interval.spad using old system + compiler. + Loading /home/bpage/axiom2/mnt/linux/autoload/parsing. + Loading /home/bpage/axiom2/mnt/linux/autoload/bootlex. + Loading /home/bpage/axiom2/mnt/linux/autoload/def. + Loading /home/bpage/axiom2/mnt/linux/autoload/fnewmeta. + Loading /home/bpage/axiom2/mnt/linux/autoload/metalex. + Loading /home/bpage/axiom2/mnt/linux/autoload/metameta. + Loading /home/bpage/axiom2/mnt/linux/autoload/parse. + Loading /home/bpage/axiom2/mnt/linux/autoload/postpar. + Loading /home/bpage/axiom2/mnt/linux/autoload/postprop. + Loading /home/bpage/axiom2/mnt/linux/autoload/preparse. + INTCAT abbreviates category IntervalCategory + INTRVL abbreviates domain Interval +------------------------------------------------------------------------= + + initializing NRLIB INTRVL for Interval + compiling into NRLIB INTRVL + Loading /home/bpage/axiom2/mnt/linux/algebra/INTCAT.o for = +category + IntervalCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/GCDDOM.o for = +category + GcdDomain + Loading /home/bpage/axiom2/mnt/linux/algebra/INTDOM.o for = +category + IntegralDomain + Loading /home/bpage/axiom2/mnt/linux/algebra/COMRING.o for = +category + CommutativeRing + Loading /home/bpage/axiom2/mnt/linux/algebra/RING.o for category + Ring + Loading /home/bpage/axiom2/mnt/linux/algebra/RNG.o for category = +Rng + Loading /home/bpage/axiom2/mnt/linux/algebra/ABELGRP.o for = +category + AbelianGroup + Loading /home/bpage/axiom2/mnt/linux/algebra/CABMON.o for = +category + CancellationAbelianMonoid + Loading /home/bpage/axiom2/mnt/linux/algebra/ABELMON.o for = +category + AbelianMonoid + Loading /home/bpage/axiom2/mnt/linux/algebra/ABELSG.o for = +category + AbelianSemiGroup + Loading /home/bpage/axiom2/mnt/linux/algebra/SETCAT.o for = +category + SetCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/BASTYPE.o for = +category + BasicType + Loading /home/bpage/axiom2/mnt/linux/algebra/KOERCE.o for = +category + CoercibleTo + Loading /home/bpage/axiom2/mnt/linux/algebra/SGROUP.o for = +category + SemiGroup + Loading /home/bpage/axiom2/mnt/linux/algebra/MONOID.o for = +category + Monoid + Loading /home/bpage/axiom2/mnt/linux/algebra/LMODULE.o for = +category + LeftModule + Loading /home/bpage/axiom2/mnt/linux/algebra/BMODULE.o for = +category + BiModule + Loading /home/bpage/axiom2/mnt/linux/algebra/RMODULE.o for = +category + RightModule + Loading /home/bpage/axiom2/mnt/linux/algebra/ALGEBRA.o for = +category + Algebra + Loading /home/bpage/axiom2/mnt/linux/algebra/MODULE.o for = +category + Module + Loading /home/bpage/axiom2/mnt/linux/algebra/ENTIRER.o for = +category + EntireRing + Loading /home/bpage/axiom2/mnt/linux/algebra/ORDSET.o for = +category + OrderedSet + Loading /home/bpage/axiom2/mnt/linux/algebra/TRANFUN.o for = +category + TranscendentalFunctionCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/TRIGCAT.o for = +category + TrigonometricFunctionCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/ATRIG.o for category + ArcTrigonometricFunctionCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/HYPCAT.o for = +category + HyperbolicFunctionCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/AHYP.o for category + ArcHyperbolicFunctionCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/ELEMFUN.o for = +category + ElementaryFunctionCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/RADCAT.o for = +category + RadicalCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/RETRACT.o for = +category + RetractableTo + Loading /home/bpage/axiom2/mnt/linux/algebra/FPS.o for category + FloatingPointSystem + Loading /home/bpage/axiom2/mnt/linux/algebra/RNS.o for category + RealNumberSystem + Loading /home/bpage/axiom2/mnt/linux/algebra/FIELD.o for category + Field + Loading /home/bpage/axiom2/mnt/linux/algebra/EUCDOM.o for = +category + EuclideanDomain + Loading /home/bpage/axiom2/mnt/linux/algebra/PID.o for category + PrincipalIdealDomain + Loading /home/bpage/axiom2/mnt/linux/algebra/UFD.o for category + UniqueFactorizationDomain + Loading /home/bpage/axiom2/mnt/linux/algebra/DIVRING.o for = +category + DivisionRing + Loading /home/bpage/axiom2/mnt/linux/algebra/ORDRING.o for = +category + OrderedRing + Loading /home/bpage/axiom2/mnt/linux/algebra/OAGROUP.o for = +category + OrderedAbelianGroup + Loading /home/bpage/axiom2/mnt/linux/algebra/OCAMON.o for = +category + OrderedCancellationAbelianMonoid + Loading /home/bpage/axiom2/mnt/linux/algebra/OAMON.o for category + OrderedAbelianMonoid + Loading /home/bpage/axiom2/mnt/linux/algebra/OASGP.o for category + OrderedAbelianSemiGroup + Loading /home/bpage/axiom2/mnt/linux/algebra/REAL.o for category + RealConstant + Loading /home/bpage/axiom2/mnt/linux/algebra/KONVERT.o for = +category + ConvertibleTo + Loading /home/bpage/axiom2/mnt/linux/algebra/PATMAB.o for = +category + PatternMatchable + Loading /home/bpage/axiom2/mnt/linux/algebra/CHARZ.o for category + CharacteristicZero +****** Domain: R already in scope + importing Integer + compiling local roundDown : R -> R + Loading /home/bpage/axiom2/mnt/linux/algebra/INT.o for domain + Integer +Time: 0.45 SEC. + + compiling local roundUp : R -> R +Time: 0.01 SEC. + + compiling local normaliseFloat : R -> R +Time: 0.05 SEC. + + compiling exported interval : (R,R) -> $ +Time: 0 SEC. + + compiling exported interval : R -> $ +Time: 0.03 SEC. + + compiling exported qinterval : (R,R) -> $ +Time: 0.01 SEC. + + compiling local exactInterval : (R,R) -> $ + INTRVL;exactInterval is replaced by CONS +Time: 0 SEC. + + compiling local exactSupInterval : (R,R) -> $ +Time: 0 SEC. + + compiling local exactInfInterval : (R,R) -> $ +Time: 0.01 SEC. + + compiling exported inf : $ -> R + INTRVL;inf;$R;10 is replaced by QCAR +Time: 0 SEC. + + compiling exported sup : $ -> R + INTRVL;sup;$R;11 is replaced by QCDR +Time: 0 SEC. + + compiling exported width : $ -> R +Time: 0.01 SEC. + + compiling exported contains? : ($,R) -> Boolean + Loading /home/bpage/axiom2/mnt/linux/algebra/BOOLEAN.o for domain + Boolean +Time: 0.02 SEC. + + compiling exported positive? : $ -> Boolean +Time: 0.02 SEC. + + compiling exported negative? : $ -> Boolean +Time: 0.01 SEC. + + compiling exported < : ($,$) -> Boolean +Time: 0.04 SEC. + + compiling exported + : ($,$) -> $ +Time: 0.17 SEC. + + compiling exported - : ($,$) -> $ +Time: 0.01 SEC. + + compiling exported * : ($,$) -> $ + Loading /home/bpage/axiom2/mnt/linux/algebra/LIST.o for domain = +List + Loading /home/bpage/axiom2/mnt/linux/algebra/ILIST.o for domain + IndexedList + Loading /home/bpage/axiom2/mnt/linux/algebra/LSAGG-.o for domain + ListAggregate& + Loading /home/bpage/axiom2/mnt/linux/algebra/STAGG-.o for domain + StreamAggregate& + Loading /home/bpage/axiom2/mnt/linux/algebra/ELAGG-.o for domain + ExtensibleLinearAggregate& + Loading /home/bpage/axiom2/mnt/linux/algebra/FLAGG-.o for domain + FiniteLinearAggregate& + Loading /home/bpage/axiom2/mnt/linux/algebra/URAGG-.o for domain + UnaryRecursiveAggregate& +Time: 0.26 SEC. + + compiling exported * : (Integer,$) -> $ +Time: 0.02 SEC. + + compiling exported * : (PositiveInteger,$) -> $ +Time: 0.03 SEC. + + compiling exported ** : ($,PositiveInteger) -> $ +Time: 0.09 SEC. + + compiling exported ^ : ($,PositiveInteger) -> $ +Time: 0.18 SEC. + + compiling exported - : $ -> $ +Time: 0.01 SEC. + + compiling exported = : ($,$) -> Boolean +Time: 0.03 SEC. + + compiling exported ~= : ($,$) -> Boolean +Time: 0.02 SEC. + + compiling exported One : () -> $ +Time: 0 SEC. + + compiling exported Zero : () -> $ +Time: 0.01 SEC. + + compiling exported recip : $ -> Union($,failed) +Time: 0.05 SEC. + + compiling exported unit? : $ -> Boolean +Time: 0.12 SEC. + + compiling exported exquo : ($,$) -> Union($,failed) +Time: 0.06 SEC. + + compiling exported gcd : ($,$) -> $ +Time: 0.01 SEC. + + compiling exported coerce : Integer -> $ +Time: 0 SEC. + + compiling exported interval : Fraction Integer -> $ + Loading /home/bpage/axiom2/mnt/linux/algebra/INS.o for category + IntegerNumberSystem + Loading /home/bpage/axiom2/mnt/linux/algebra/OINTDOM.o for = +category + OrderedIntegralDomain + Loading /home/bpage/axiom2/mnt/linux/algebra/DIFRING.o for = +category + DifferentialRing + Loading /home/bpage/axiom2/mnt/linux/algebra/LINEXP.o for = +category + LinearlyExplicitRingOver + Loading /home/bpage/axiom2/mnt/linux/algebra/CFCAT.o for category + CombinatorialFunctionCategory + Loading /home/bpage/axiom2/mnt/linux/algebra/STEP.o for category + StepThrough +Time: 0.86 SEC. + + compiling exported retractIfCan : $ -> Union(Integer,failed) +Time: 0.02 SEC. + + compiling exported retract : $ -> Integer +Time: 0.03 SEC. + + compiling exported coerce : $ -> OutputForm +Time: 0.17 SEC. + + compiling exported characteristic : () -> NonNegativeInteger + Loading /home/bpage/axiom2/mnt/linux/algebra/NNI.o for domain + NonNegativeInteger + INTRVL;characteristic;Nni;38 is replaced by 0 +Time: 0.01 SEC. + + compiling exported pi : () -> $ +Time: 0 SEC. + + compiling exported log : $ -> $ +Time: 0.03 SEC. + + compiling exported exp : $ -> $ +Time: 0 SEC. + + compiling exported ** : ($,$) -> $ +Time: 0.21 SEC. + + compiling local hasTwoPiMultiple : (R,() -> R,$) -> Boolean + Loading /home/bpage/axiom2/mnt/linux/algebra/INS-.o for domain + IntegerNumberSystem& + Loading /home/bpage/axiom2/mnt/linux/algebra/EUCDOM-.o for domain + EuclideanDomain& + Loading /home/bpage/axiom2/mnt/linux/algebra/UFD-.o for domain + UniqueFactorizationDomain& + Loading /home/bpage/axiom2/mnt/linux/algebra/GCDDOM-.o for domain + GcdDomain& + Loading /home/bpage/axiom2/mnt/linux/algebra/INTDOM-.o for domain + IntegralDomain& + Loading /home/bpage/axiom2/mnt/linux/algebra/ALGEBRA-.o for = +domain + Algebra& + Loading /home/bpage/axiom2/mnt/linux/algebra/DIFRING-.o for = +domain + DifferentialRing& + Loading /home/bpage/axiom2/mnt/linux/algebra/ORDRING-.o for = +domain + OrderedRing& + Loading /home/bpage/axiom2/mnt/linux/algebra/MODULE-.o for domain + Module& + Loading /home/bpage/axiom2/mnt/linux/algebra/RING-.o for domain + Ring& + Loading /home/bpage/axiom2/mnt/linux/algebra/ABELGRP-.o for = +domain + AbelianGroup& + Loading /home/bpage/axiom2/mnt/linux/algebra/ABELMON-.o for = +domain + AbelianMonoid& +Time: 0.21 SEC. + + compiling local hasPiMultiple : (R,() -> R,$) -> Boolean +Time: 0.03 SEC. + + compiling exported sin : $ -> $ +Time: 0.18 SEC. + + compiling exported cos : $ -> $ +Time: 0.10 SEC. + + compiling exported tan : $ -> $ +Time: 0.15 SEC. + + compiling exported csc : $ -> $ +Time: 0.25 SEC. + + compiling exported sec : $ -> $ +Time: 0.23 SEC. + + compiling exported cot : $ -> $ +Time: 0.15 SEC. + + compiling exported asin : $ -> $ +Time: 0.06 SEC. + + compiling exported acos : $ -> $ +Time: 0.06 SEC. + + compiling exported atan : $ -> $ +Time: 0 SEC. + + compiling exported acot : $ -> $ +Time: 0.01 SEC. + + compiling exported acsc : $ -> $ +Time: 0.20 SEC. + + compiling exported asec : $ -> $ +Time: 0.09 SEC. + + compiling exported tanh : $ -> $ +Time: 0 SEC. + + compiling exported sinh : $ -> $ +Time: 0 SEC. + + compiling exported sech : $ -> $ +Time: 0.17 SEC. + + compiling exported cosh : $ -> $ +Time: 0.07 SEC. + + compiling exported csch : $ -> $ +Time: 0.15 SEC. + + compiling exported coth : $ -> $ +Time: 0.03 SEC. + + compiling exported acosh : $ -> $ +Time: 0.05 SEC. + + compiling exported acoth : $ -> $ +Time: 0.22 SEC. + + compiling exported acsch : $ -> $ +Time: 0.03 SEC. + + compiling exported asech : $ -> $ +Time: 0.05 SEC. + + compiling exported asinh : $ -> $ +Time: 0.02 SEC. + + compiling exported atanh : $ -> $ +Time: 0.05 SEC. + + compiling exported ** : ($,Fraction Integer) -> $ +Time: 0.22 SEC. + +(time taken in buildFunctor: 4) + +;;; *** |Interval| REDEFINED + +;;; *** |Interval| REDEFINED +Time: 0.16 SEC. + + + Warnings: + [1] roundDown: pretend(Integer) -- should replace by @ + [2] roundUp: pretend(Integer) -- should replace by @ + [3] normaliseFloat: pretend(Integer) -- should replace by @ + [4] **: pretend(Integer) -- should replace by @ + [5] ^: pretend(Integer) -- should replace by @ + [6] interval: pretend(Integer) -- should replace by @ + [7] sin: hasOne? has no value + [8] sin: hasMinusOne? has no value + + + Cumulative Statistics for Constructor Interval + Time: 6.00 seconds + + Loading /home/bpage/axiom2/mnt/linux/autoload/bc-matrix. + Loading /home/bpage/axiom2/mnt/linux/autoload/bc-misc. + Loading /home/bpage/axiom2/mnt/linux/autoload/bc-solve. + Loading /home/bpage/axiom2/mnt/linux/autoload/bc-util. + Loading /home/bpage/axiom2/mnt/linux/autoload/ht-util. + Loading /home/bpage/axiom2/mnt/linux/autoload/htsetvar. + Loading /home/bpage/axiom2/mnt/linux/autoload/ht-root. + Loading /home/bpage/axiom2/mnt/linux/autoload/br-con. + Loading /home/bpage/axiom2/mnt/linux/autoload/br-data. + Loading /home/bpage/axiom2/mnt/linux/autoload/showimp. + Loading /home/bpage/axiom2/mnt/linux/autoload/br-op1. + Loading /home/bpage/axiom2/mnt/linux/autoload/br-op2. + Loading /home/bpage/axiom2/mnt/linux/autoload/br-search. + Loading /home/bpage/axiom2/mnt/linux/autoload/br-util. + Loading /home/bpage/axiom2/mnt/linux/autoload/topics. + Loading /home/bpage/axiom2/mnt/linux/autoload/br-prof. + Loading /home/bpage/axiom2/mnt/linux/autoload/br-saturn. + finalizing NRLIB INTRVL + Processing Interval for Browser database: +--------constructor--------- +Compiling /home/bpage/axiom2/int/algebra/./INTRVL.NRLIB/code.lsp. +; (DEFUN |INTRVL;exactInterval| ...) is being compiled. +;; Warning: The variable $ is not used. +; (DEFUN |INTRVL;inf;$R;10| ...) is being compiled. +;; Warning: The variable $ is not used. +; (DEFUN |INTRVL;sup;$R;11| ...) is being compiled. +;; Warning: The variable $ is not used. +; (DEFUN |INTRVL;gcd;3$;32| ...) is being compiled. +;; Warning: The variable |u| is not used. +;; Warning: The variable |v| is not used. +; (DEFUN |INTRVL;characteristic;Nni;38| ...) is being compiled. +;; Warning: The variable $ is not used. +; (DEFUN |INTRVL;sin;2$;45| ...) is being compiled. +;; The variable |hasOne?| is undefined. +;; The compiler will assume this variable is a global. +;; The variable |hasMinusOne?| is undefined. +;; The compiler will assume this variable is a global. +End of Pass 1. +; (DEFUN |INTRVL;hasTwoPiMultiple| ...) is being compiled. +;; Warning: INTRVL;hasTwoPiMultiple is proclaimed but not in = +*inline-functions* +T1defun could not assure suitability of args for C call +; (DEFUN |INTRVL;hasPiMultiple| ...) is being compiled. +;; Warning: INTRVL;hasPiMultiple is proclaimed but not in = +*inline-functions* +T1defun could not assure suitability of args for C call +; (DEFUN |INTRVL;cos;2$;46|) is being compiled. +;; Warning: INTRVL;hasTwoPiMultiple called with 4 args, expected 0 +;; Warning: INTRVL;hasTwoPiMultiple called with 4 args, expected 0 +; (DEFUN |INTRVL;csc;2$;48|) is being compiled. +;; Warning: INTRVL;hasPiMultiple called with 4 args, expected 0 +;; Warning: INTRVL;hasTwoPiMultiple called with 4 args, expected 0 +;; Warning: INTRVL;hasTwoPiMultiple called with 4 args, expected 0 +; (DEFUN |INTRVL;sec;2$;49|) is being compiled. +;; Warning: INTRVL;hasPiMultiple called with 4 args, expected 0 +;; Warning: INTRVL;hasTwoPiMultiple called with 4 args, expected 0 +;; Warning: INTRVL;hasTwoPiMultiple called with 4 args, expected 0 +End of Pass 2. +OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, = +Speed=3 +Finished compiling = +/home/bpage/axiom2/int/algebra/./INTRVL.NRLIB/code.lsp. +------------------------------------------------------------------------= + + Interval is now explicitly exposed in frame initial + Interval will be automatically loaded when needed from + /home/bpage/axiom2/int/algebra/INTRVL.NRLIB/code + +(1) -> + +------_=_NextPart_000_01C36C0B.FEBB1760-- + +\start +Date: Tue, 26 Aug 2003 23:08:35 +0200 +From: "Weiss, Juergen" +To: "Bill. Page1 (E-mail)" , +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] interval.spad + +There is that strange error message of the C compiler in the log file... + +> -----Original Message----- +> From: Page, Bill [mailto:Bill.Page@drdc-rddc.gc.ca] +> Sent: Tuesday, August 26, 2003 9:55 PM +> To: 'daly@idsi.net'; Weiss, Juergen +> Cc: axiom-developer@nongnu.org +> Subject: RE: [Axiom-developer] interval.spad +> +> +> Tim, +> +> The compile of interval.spad seems to work on my +> incarnation of Juergen's version. The axiom output +> file is attached. +> +> Cheers, +> Bill Page. +> +> > -----Original Message----- +> > From: root [mailto:daly@idsi.net] +> > Sent: Tuesday, August 26, 2003 1:08 PM +> > To: Juergen Weiss; axiom-developer@nongnu.org +> > Subject: [Axiom-developer] interval.spad +> > +> > +> > Juergen, +> > +> > Let me know if this succeeds or fails in your version: +> > +> > start interpsys and type: +> > +> > )co interval.spad )con INTRVL +> > +> > Tim + +\start +Date: Tue, 26 Aug 2003 17:43:48 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] interval.spad + +Bill, + +Try clipping the domain out of the interval.spad file +and storing it in INTRVL.spad. Then type (in a fresh +interpsys (this is important)): + +)co INTRVL.spad + +Tim + +\start +Date: Tue, 26 Aug 2003 18:07:01 -0400 +From: "Page, Bill" +To: "'daly@idsi.net'" +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] interval.spad + +Tim, + +I already have a file called INTRVL.spad that contains the +code for the domain. I also have a file called INTCAT.spad +that contains the code for the category. Together they +constitute the contents of the file interval.spad. They +both had been compiled before as part of the algebra/Makefile. + +As far as I can tell, the file interval.spad is generated +by a small over sight in Juergen's algebra/Makefile that +runs notangle without the -R option on all the named +(lowercase) spad files. This is not necessary for the +build of Axiom. I sent a patch the other day to eliminate +this extra .spad files with lowercase names. + +The output of axiom is nearly the same as before (except +of course minus the output generated by compiling the +INTCAT code, but including the unusally warning messages: + +------- + +; (DEFUN |INTRVL;hasTwoPiMultiple| ...) is being compiled. +;; Warning: INTRVL;hasTwoPiMultiple is proclaimed but not in +*inline-functions* +T1defun could not assure suitability of args for C call +; (DEFUN |INTRVL;hasPiMultiple| ...) is being compiled. +;; Warning: INTRVL;hasPiMultiple is proclaimed but not in +*inline-functions* +T1defun could not assure suitability of args for C call + +-------- + +which is perhaps what Juergen calls the "strange error +message of the C compiler"? (It is not clear to me that +it is generated by the gcc...) + +Cheers, +Bill Page. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Tuesday, August 26, 2003 5:44 PM +> To: bill.page1@sympatico.ca +> Cc: daly@idsi.net; weiss@uni-mainz.de; axiom-developer@nongnu.org +> Subject: Re: [Axiom-developer] interval.spad +> +> +> Bill, +> +> Try clipping the domain out of the interval.spad file +> and storing it in INTRVL.spad. Then type (in a fresh +> interpsys (this is important)): +> +> )co INTRVL.spad +> +> Tim +> + +\start +Date: Tue, 26 Aug 2003 18:52:18 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] interval.spad + +Yeah, this strangeness is something I'm chasing. +At the moment I've just put it "ont the shelf" to look at later. +Trying to get the final cleanup stages (whatever that means) done. +As usual there are a million little things to change. + +Thanks for the trials. +Tim + +\start +Date: Wed, 27 Aug 2003 03:17:06 -0400 +From: "Page, Bill" +To: "'David MENTRE'" +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] RE: dependency visualization with VCG + +David, + +About Perl hacking and literate programming. You are +right of course that I should have provided more +documentation with the Perl scripts. There is never +enough time! But I promise that I will move some of +the following description into a pamphlet file at +some point in the future if the scripts appear to +have any long term value. + +The algorithm that I used in the 'depends' script is +as follows: + +1) First depends is given a list of spad files as an +argument list. E.g. all the files beginning with +the letter X: + + % mnt/linux/bin/depends int/algebra/X*.spad + +The contents of each file, in turn, is loaded into the +work space name $buf for further processing. Let's +denote a specific spad file by 'A'. + +2) Within the $buf work space, a search is made +for the )ABBREV command that marks the beginning +of a module (domain, category or package). The names +from this command are saved. Let's denote the name +of a specific module by 'M'. Anything in the buffer +prior to this command is discarded. Each input spad +file 'A' may contains more than one module 'M'. + +3) For each of these modules, we also look for the +pamphlet file that contains the module. Denote the +pamphlet file by 'P'. + +4) After locating the )ABBREV command, another +pattern search is done to find the actual start of +the module definition continuing up to the 'with' +clause (which often appears as part of a macro). +Here we will find a list of all the functions which +this module "exports", i.e. potentially makes +available to other modules. Let's denote a specify +function by 'F'. There are usually many 'F' for +each 'M'. + +5) For each of the functions 'F' in the with clause, +a search is done (using grep) for all other spad files +which contain a reference to the function name. Some +of these names will be "overloaded" so we also check +that the files we located also contain the name of +the module itself. Let's denote each of the spad files +that contains an 'M' qualified reference to 'F' by +the symbol 'B'. + +6) For each of the spad files found by the above +search, we generate a line of output indicating an +edge in the dependency graph. I.e. + + 'B' uses 'F' from 'M' in 'A' ('P') + +7) Now this process is repeated with the next +module 'M' found within spad file 'A', starting +again at step 2) above. And so on with each file +in the argument list. + +8) The resulting list of dependencies is in ordered +on the target spad files rather than the source +files, but this is easily remedied by use of the +Linux sort command. Also, there is the possibility +that the same dependency could be generated more +than once, so the sort option -u (unique) is also +useful. + +9) A script called 'unique' is provided which after +sorting, suppresses the repeated source module names +to produce a more readable dependency list in the +usual format 'index' format. + +--------- + +About handling macros. That is where the "heuristic" +comes into the algorithm. In fact, there is no attempt +to make use of the actual macro definitions per se. +The assumption is made that *if* a spad file contains +*both* a specific function name 'F' and the module +name 'M' anywhere in the same file, then there (very +probably) exists a reference to that function. All +such references are assumed to constitute dependencies. +Very often in the coding of the spad file, the module +name will be contained in the definition of a shorter +macro (say 'm') and it is that macro 'm' that appears +together with the function name 'F' as in F$m or in a +domain expression. It is possible however for the +algorithm to make mistakes, especially in the case of +short, multiply overloaded function names which some +times occur together in a module. This will sometimes +result in "extra" bogus dependencies, but it should +not miss any really existing dependencies. + +Please let me know how you make out with your trails +with the VCG / aiSee graphics package. aiSee apparently +includes an experimental "clustering" algorithm that might +be interesting for finding "tight" cyclical dependencies. +But even if an automatic layout determination is not +possible, perhaps some manual effort will produce a useful +graphical representation. + +But I am starting to think perhaps some other approach +might be desirable for producing the kind of "optimized" +layered structure that Tim has described. In that regard, +counting the number of cycles in which each module appears +in the simple output of the topological sort done in the +script I called 'order' might be of some interest. The +counts might be treated as "weights" assigned to each +module in terms of their value as bootstrap candidates. + +Cheers, +Bill Page. + + +> -----Original Message----- +> From: David MENTRE [mailto:david.mentre@wanadoo.fr] +> Sent: Tuesday, August 26, 2003 2:32 PM +> To: Bill Page +> Cc: axiom-developer@nongnu.org +> Subject: Re: dependency visualization with VCG +> +> +> Hi Bill, +> +> Sorry for the late reply. My real life is interfering with my hacking +> activities. ;-) +> +> "Bill Page" writes: +> +> > The Axiom dependency graph that I tried to use with xvcg has +> > over 1040 nodes and more than 17,000 edges (dependencies). +> +> I'm currently trying with a smaller graph (just dependencies between +> spad file generated by your script). +> +> > Do you have any ideas about the size of graphs that can be +> > successfully manipulated with VCG? Do you have any suggestions +> > on where to go from here? Do you think of any way to segment +> > the Axiom dependency graph into smaller more manageable +> > sub-graphs? +> +> Sorry, I have no answer to all of your questions. I'm just a +> occasional +> VCG user. +> +> By the way, I think your script would be a good candidate for literate +> programming. The conciseness of Perl makes some parts of your script +> quite obscure. :) +> +> In fact, the most missing part is an example that would +> explain what the +> code is doing. +> +> In your perl script, how have you handle the case of macros? +> + +\start +Date: Wed, 27 Aug 2003 03:34:08 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: dependency visualization with VCG + +With respect to the notion of optimizing the domain we choose for +the bootstrap list: + +Consider that we have, say 30 loops, each between 1 (some files +self-refer) and 20 long. If we write each loop as a list then the goal +is to choose domains out of the lists so we minimize the total number +of bootstrap domains. Clearly the best first choice is "the most +frequent" domain mentioned across all of the lists. We can then +eliminate all of those lists since we now have a bootstrap file. Next +we choose the most frequent domain from the remaining lists. This may +not be optimal but it would be a better algorithm than the one I used +which was to just choose any domain. + +I'm sure there is a wonderful mathematical name for the bootstrap +list (e.g. the "kernel"?) but I haven't yet cast it into either +graph theory or any other theory yet. + +\start +Date: 27 Aug 2003 17:19:07 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca, gcl-devel@gnu.org +Subject: [Axiom-developer] Re: Stack overflow problem + +Greetings! + +root writes: + +> Camm, +> +> The stack overflow problem is caused by the Axiom preparser. It +> scans for macros and expands BOTH sides of the macros based on +> previous macros. The failure occcurs if there are 2 macros with +> the same name in the same file. The expansion becomes: +> +> env: () +> macro: MAX ==> 1 +> env: (MAX ==> 1) +> macro: MAX ==> 1 +> env (1 ==> 1, MAX ==> 1) +> macro 1 + 1 +> crash +> +> It is considered (by me) a bug to expand the left hand side of the macro. +> I don't know where this is done but it needs to be fixed. I fear the +> "correct" fix will take me into the meta code using the meta compiler. +> +> This is not a GCL failure (although GCL is particularly unhelpful +> when debugging stack overflows as :bt will crash GCL). +> + +OK, then this is what I need to look at, which I'll try to get to +soon. + +Take care, + +\start +Date: 27 Aug 2003 17:29:38 -0400 +From: Camm Maguire +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca, gcl-devel@gnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Greetings! + +root writes: + +> Camm, +> +> re: debian package. +> +> The algebra code has 5 files which will not yet compile properly +> (due to mismaintained INTERP.EXPOSED). I'm working to solve this +> problem which has yet another subtle catch-22. I should have it +> done shortly and then there will be a "build from scratch" +> version on savannah. +> +> Of course, we have to run tests against it, etc. +> + +Great! I'd like it if possible if axiom can be built with an external +unpatched gcl-2.5.4, which I'm trying to release shortly. When the +build from scratch is in place, I'd like to fold all necessary axiom +patches into gcl upstream. + +> You're welcome to build a debian package if you'd like. +> We also have to discuss how we plan to support things like +> apt and rpm files. I believe debian keeps them on their site +> but we need to figure out how to keep binaries on the main +> axiom site. Methinks Bill Page has already figured this out +> so he's "the expert" :-) +> + +I have a little cron which installs the latest from the Debian site +onto ftp.gnu.org, then runs alien to make an rpm. (ftp.gnu.org still +isn't back up after the security compromise :-(). The cron also pulls +a automatically generated solaris build on a machine at utexas. Maybe +something similar would work? + +I don't know if you think this is a good idea, but we could put a +debian subdir into the axiom source tree if you'd like. Every Debian +package has one with the scripts and makefiles necessary to install +the package according to policy. Normally this is maintained by the +Debian developer as a patch to the upstream source, but as you've +granted me rights on savannah, we could maintain this there via CVS. +Whatever you think is best of course. + +\start +Date: Thu, 28 Aug 2003 05:24:21 -0400 +From: root +To: camm@enhanced.com +Cc: axiom-developer@nongnu.org, daly@idsi.net, gcl-devel@gnu.org, bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Camm, + +re: gcl-2.5.4 +I'd be happy to try the unpatched version. +Let me know when it is released and I'll download it. + +re: debian package +The "standard" way to handle the various opsys/platform builds +is to change the AXIOM variable. The AXIOM variable's last +value (basename) selects the appropriate Makefile. Thus setting +AXIOM=/axiom/mnt/linux creates Makefile.linux. + +Since we plan to run on all of the linux distribs we can you +raise an interesting point. The basename should be more specific +than linux. If you look in Makefile.pamphlet you'll find a +dozen or so potential basenames already. The top level Makefile.pamphlet +selects the appropriate one and makes a specific Makefile. + +As to creating a debian subdir I'm a little reluctant. If it is +required than we can but I'd rather keep the system-specific +information in the Makefiles. What would go into the debian +subdir? If you consider the question in general rather than +specifically for debian is there a requirement for a new +subdir to contain platform-build specific stuff? There is a +src/scripts subdir intended for this already. The +src/scripts/Makefile.pamphlet could be customized for debian +and a debian subdir could occur there. + +In any case, a new subdir should live under src, not at the root. +The idea of the src subdir is that you can clip off src and the +top level Makefile and have the whole distribution. You can clip +off mnt, move it anywhere, and have a working Axiom image. + +\start +Date: Thu, 28 Aug 2003 20:18:19 +0200 +From: David MENTRE +To: Tim Daly , daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] compiling the algebra files with gcl + +Hello Tim, + +root writes: + +> Since we plan to run on all of the linux distribs we can you +> raise an interesting point. The basename should be more specific +> than linux. + +I would suggest using a name along one used for building gnu packages, +something like : + + i686-linux + + or sparc64-sunos-5.8 + +In other terms : hardware_platform-OS[-OS_version] + +[ In fact, GNU packages and more specifically configure script are using + linux-gnu-i686, i.e. OS-vendor-hardware. I think the vendor part is + not necessary. ] + +My .02 euros. + +\start +Date: 28 Aug 2003 19:28:13 -0400 +From: Bill Page +To: Martin RUBEY +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] Re: dependency visualization with VCG + +Martin, + +Thank you for your reference to the tulip package. I have downloaded +it (both as binary rpm and in source form) and tried to install in +under Linux RedHat 9.0, but I have run into problems in both cases. + +In trying to install the binary package after first installing the +required lib files, I have one remaining dependency which I don't +seem to be able to resolve. + + [wspage@asus wspage]$ rpm -i tulip-1.2.4-1.i386.rpm + error: Failed dependencies: + libOSMesa.so.3 is needed by tulip-1.2.4-1 + +I have also installed Mesa 5.0.1 and I *do* have a file named + + /usr/local/lib/libOSMesa.so.4 + +I tried compiling and installing various older versions of Mesa but +even the "recommended" version 4.0.1 did not produce the required +libOSMesa.so.3 file. + +So then I decided to try to resort to compiling Tulip from source. +>From the ./configure I discovered that I first had to recompile +qt from source because the version I got from the RedHat rpm did +not contain the header files. After getting qt to compile and +install, configure completed but way down in the make I got an +error during the compile: + +... +source='PropertyDialogData.cpp' object='Tulip-PropertyDialogData.o' +libtool=no \depfile='.deps/Tulip-PropertyDialogData.Po' +tmpdepfile='.deps/Tulip-PropertyDialogData.TPo' \ +depmode=gcc3 /bin/sh ../../../depcomp \ +g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I./../include -I../include +-I../../../thirdparty/gzstream -I/usr/local/qt/include +-I../../../library/tulip/include -I../../../library/tulip-geo/include +-I../../../library/tulip-ogl/include +-I../../../library/tulip-qt/include -DQT_THREAD_SUPPORT -D_REENTRANT +-DNDEBUG -O2 -pipe +-c -o Tulip-PropertyDialogData.o `test -f 'PropertyDialogData.cpp' || +echo './'`PropertyDialogData.cpp +PropertyDialogData.cpp: In constructor + `PropertyDialogData::PropertyDialogData(QWidget*, const char*, +unsigned + int)': +PropertyDialogData.cpp:84: invalid use of undefined type `struct + TulipPropertyTable' +../include/PropertyDialogData.h:24: forward declaration of `struct + TulipPropertyTable' +PropertyDialogData.cpp:85: incomplete type `TulipPropertyTable' does not +have + member `AlwaysOn' +PropertyDialogData.cpp:86: invalid use of undefined type `struct + TulipPropertyTable' +../include/PropertyDialogData.h:24: forward declaration of `struct + TulipPropertyTable' +PropertyDialogData.cpp:87: invalid use of undefined type `struct + TulipPropertyTable' +../include/PropertyDialogData.h:24: forward declaration of `struct + TulipPropertyTable' +PropertyDialogData.cpp:89: no matching function for call to +`QGridLayout:: + addWidget(TulipPropertyTable*&, int, int)' +/usr/local/qt/include/qlayout.h:331: candidates are: void + QGridLayout::addWidget(QWidget*, int, int, int = 0) +PropertyDialogData.cpp:95: invalid use of undefined type `struct + TulipPropertyTable' +../include/PropertyDialogData.h:24: forward declaration of `struct + TulipPropertyTable' +PropertyDialogData.cpp:96: incomplete type `TulipPropertyTable' does not +have + member `AlwaysOn' +PropertyDialogData.cpp:97: invalid use of undefined type `struct + TulipPropertyTable' +../include/PropertyDialogData.h:24: forward declaration of `struct + TulipPropertyTable' +PropertyDialogData.cpp:98: invalid use of undefined type `struct + TulipPropertyTable' +../include/PropertyDialogData.h:24: forward declaration of `struct + TulipPropertyTable' +PropertyDialogData.cpp:100: no matching function for call to +`QGridLayout:: + addWidget(TulipPropertyTable*&, int, int)' +/usr/local/qt/include/qlayout.h:331: candidates are: void + QGridLayout::addWidget(QWidget*, int, int, int = 0) +make[5]: *** [Tulip-PropertyDialogData.o] Error 1 +make[5]: Leaving directory `/home/wspage/tulip-1.2.4/software/Tulip/src' +make[4]: *** [all] Error 2 +make[4]: Leaving directory `/home/wspage/tulip-1.2.4/software/Tulip/src' +make[3]: *** [all-recursive] Error 1 +make[3]: Leaving directory `/home/wspage/tulip-1.2.4/software/Tulip' +make[2]: *** [all-recursive] Error 1 +make[2]: Leaving directory `/home/wspage/tulip-1.2.4/software' +make[1]: *** [all-recursive] Error 1 +make[1]: Leaving directory `/home/wspage/tulip-1.2.4' +make: *** [all] Error 2 + +----------- + +So finally, I decided to complete the original install using + + rpm --nodeps -i tulip-1.2.4-1.i386.rpm + +to ignore the dependency error. + +Now I have a version of Tulip that "sort of" runs. I can draw a +simple graph but some actions cause the program to abort. And I +find the controls rather confusing. Nor have I found an particularly +useful documentation or examples. For instance, I do not understand +how to import an externally defined graph (such as the axiom +dependency graph which I currently have in GDL - graph description +language - format). + +Anyway, if you have any suggestions on what to do to solve these +problems, I would really appreciate it. In spite of these problems +what I have seen so far looks very interesting. + +Cheers, +Bill Page. + +On Tue, 2003-08-26 at 15:25, Martin RUBEY wrote: +> I don't know whether that could help, but tulip is designed to process +> *very* large graphs. (and it is GPL) +> +> http://www.tulip-software.org/ +> + +\start +Date: Thu, 28 Aug 2003 21:49:33 -0400 +From: root +To: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Cc: axiom@tenkan.org, daly@idsi.net +Subject: [Axiom-developer] Axiom Availability Announcement + +*, + +Axiom exists as free and open source software. + +The first version of the Axiom sources has been uploaded to the CVS at +http://savannah.gnu.org/projects/axiom. Congrats to all involved. +Many thanks to the Numerical Algorithms Group, the CAISS Institute at +City College of New York and to the people of these mailing lists. + +This version contains (almost) all of the algebra, the interpreter, +and the spad compiler. This is the heart of Axiom. The graphics, +hyperdoc, documentation, numerical code, Axiom Journal papers, +openmath, and CATS test suite are in my source tree but are not ready +for distribution yet. I'll announce these parts as they become +available. + +A gzipped-tar file of the sources will be available soon. +Debian apt and Redhat rpm files are under discussion. + +The CVS version can be downloaded by anonymous CVS: + +cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/savannah login +cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/savannah co axiom + +NOTE: when prompted for a password for anoncvs simply press the Enter key + +The primary documentation is in the Makefile.dvi file. + +To build the system in a directory (e.g. /SPAD) you do: + +cd /SPAD +export AXIOM=/SPAD/mnt/linux +make + +The executable is (currently) found by doing: + +export PATH=/SPAD/obj/linux/bin:/SPAD/mnt/linux/bin:$PATH +interpsys + +The build takes about 2 hours and 15 minutes on a 2Ghz/1Gb machine. +You might want to do the build in an emacs shell buffer so you can +save the console output in case of trouble. + +So far the build works properly on Redhat GNU/Linux 9. If you build it +on another system please let us know. A port to Windows is in process. + +This is an alpha version of the system so expect (and report) bugs. +The savannah website has a bug reporting tool. + +The algebra runs but has not yet been tested. This version has been +uploaded so we can all test from the same base. When reporting bugs +please use this version number printed at the top of your Axiom session. +It will look something like: + Thursday, August 28, 2003, 2:31am + +This version is a complete rebuild of Axiom. Many changes have been made. + +First, the system has been rewritten using literate programming. +Each file is in "pamphlet" format (which is basically Latex with +two extra tags). The reason for this is explained in the top-level +Makefile.dvi file. + +Second, the system has been ported to GCL. This is the first of many +common lisp ports where Axiom will exist. + +Third, the makefile tree has been rewritten. Most of the documentation +that exists at the moment is in the various Makefile.dvi files. + +Fourth, the algebra is built from scratch rather than pre-existing files. + +The tenkan.org website and CVS is now obsolete and will be removed. +Please use savannah for future development. + +Much work needs to be done. Click on the homepage link to see some of +the future tasks. + +Questions, comments, and snide remarks can be sent to me at: + +\start +Date: Thu, 28 Aug 2003 20:46:40 -0700 (PDT) +From: C Y +To: daly@idsi.net, axiom-developer@nongnu.org, axiom-mail@nongnu.org +Cc: axiom@tenkan.org +Subject: [Axiom-developer] Re: [Axiom-mail] Axiom Availability Announcement + +--- root wrote: + +> This is an alpha version of the system so expect (and report) bugs. +> The savannah website has a bug reporting tool. + +Congrats on the release! A very impressive achievement. + +One question - is the file axiom/zips/XFree86-devel-4.2.0-72.i386.rpm +needed in the cvs tree? Wouldn't that be something the distro would +provide? + +Thanks much for all your tremendous work. + +CY + +\start +Date: Fri, 29 Aug 2003 05:06:47 -0400 +From: root +To: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] sigh + +Well, it appears that the CVS commands that I copied from the +documentation on Savannah do not work. I'll figure it out and +post new instructions. There is no such thing as a simple job. + +\start +Date: Fri, 29 Aug 2003 05:11:36 -0400 +From: root +To: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] sigh + +These are the corrected instructions for downloading Axiom from CVS: + + +The CVS version can be downloaded by anonymous CVS: + +cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom login +cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom co axiom + +NOTE: when prompted for a password for anoncvs simply press the Enter key + +\start +From: Jason White +Date: Fri, 29 Aug 2003 19:26:13 +1000 +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: Re: [Axiom-developer] sigh + +Tim Daly writes: + > Well, it appears that the CVS commands that I copied from the + > documentation on Savannah do not work. I'll figure it out and + > post new instructions. There is no such thing as a simple job. + > +Only the CVSROOT was wrong. It should be: +:pserver:anoncvs@subversions.gnu.org:/cvsroot/axiom + +\start +Date: Fri, 29 Aug 2003 05:29:39 -0400 +From: root +To: david.mentre@wanadoo.fr +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] AXIOM platform naming conventions + +David, + +Schelter had a scheme for naming systems also. +It was part of the add-defs function. +Since the name is arbitrary perhaps the string used to +designate the name should also be arbitrary. It is only +a way to select a chunk out of the Makefile anyway. + +I need to add the name to the yearweek variable so it +becomes part of the version information. Axiom used to +have a )bug command that would format email and sent it +to me. I'll have to write (or exhume) that code again. + +re: advi +I included advi in the zips directory because one of the +tasks is to generate documentation files, which the current +build skips. I'm muttering to myself about ways to organize +the documentation library. I'd especially like to combine +the top level structure of Axiom's booklet library (this +needs a new name also since 'library' means so many things +to programmers). + +I'd like to rip-and-tear the old Hypertex machinery and +redo it in terms of an ADVI based machine. We have to think +carefully about the long term with such issues as platform +porting (e.g. does ADVI run on windows?). + +\start +Date: Fri, 29 Aug 2003 19:06:54 +0200 +From: David MENTRE +To: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: AXIOM platform naming conventions + +Hello Tim, + +root writes: + +> Schelter had a scheme for naming systems also. +> It was part of the add-defs function. +> Since the name is arbitrary perhaps the string used to +> designate the name should also be arbitrary. It is only +> a way to select a chunk out of the Makefile anyway. + +I think the name is not so arbitrary: it should help us to determined +quickly the platform on which the bug is occurring: + + - hardware + + - OS + + - common lisp used + + - version number when relevant + + - anything I have forget + +So it would be "i686-linux-gcl" or "i686-linux-gcl/2.5.4" for +example. + + +> I need to add the name to the yearweek variable so it +> becomes part of the version information. Axiom used to +> have a )bug command that would format email and sent it +> to me. I'll have to write (or exhume) that code again. + +About the )bug command, please provide the option to format the bug +report and print it somewhere, instead of sending it +directly. Sometimes, the mail system is not configured (laptop) or has a +different API (windows platform). + +\start +Date: 29 Aug 2003 13:26:46 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: Re: [Axiom-developer] Axiom Availability Announcement + +Tim, + +On my first attempt to compile the new Axiom source from Savannah +I got the following error message: + + +------- +0 making /home/wspage/projects/axiom/int/algebra/AHYP.spad from +/home/wspage/projects/axiom/src/algebra/trigcat.spad.pamphlet +0 making /home/wspage/projects/axiom/int/algebra/AHYP.NRLIB from +/home/wspage/projects/axiom/int/algebra/AHYP.spad + +(AXIOM Sockets) The AXIOM server number is undefined. +----------------------------------------------------------------------------- + Issue )copyright to view copyright notices. + Issue )summary for a summary of useful system commands. + Issue )quit to leave AXIOM and return to shell. +Friday August 29, 2003 at 13:14:01 +----------------------------------------------------------------------------- + + Using local database +/home/wspage/projects/axiom/src/share/algebra/compress.daase.. Using +local database +/home/wspage/projects/axiom/src/share/algebra/interp.daase.. + Using local database +/home/wspage/projects/axiom/src/share/algebra/operation.daase.. + Using local database +/home/wspage/projects/axiom/src/share/algebra/category.daase.. + Using local database +/home/wspage/projects/axiom/src/share/algebra/browse.daase.. +(1) -> Loading /projects/axiom/mnt/linux/autoload/apply. + + >> System error: + Cannot open the file /projects/axiom/mnt/linux/autoload/apply. + +protected-symbol-warn called with (NIL) +(1) -> 0 making /home/wspage/projects/axiom/mnt/linux/algebra/AHYP.o +from /home/wspage/projects/axiom/int/algebra/AHYP.NRLIB +cp: cannot stat +`/home/wspage/projects/axiom/int/algebra/AHYP.NRLIB/code.o': No +such file or directory +make[3]: *** [/home/wspage/projects/axiom/mnt/linux/algebra/AHYP.o] +Error 1 +make[3]: Leaving directory `/home/wspage/projects/axiom/src/algebra' +make[2]: *** [algebradir] Error 2 +make[2]: Leaving directory `/home/wspage/projects/axiom/src' +make[1]: *** [srcdir] Error 2 +make[1]: Leaving directory `/home/wspage/projects/axiom' +make: *** [all] Error 2 +[wspage@asus axiom]$ + + +------- + +Is there a problem with 'autoload/apply'?? + +Cheers, +Bill Page. + + +On Thu, 2003-08-28 at 21:49, root wrote: +> *, +> +> Axiom exists as free and open source software. +> +> The first version of the Axiom sources has been uploaded to the CVS at +> http://savannah.gnu.org/projects/axiom. Congrats to all involved. +> Many thanks to the Numerical Algorithms Group, the CAISS Institute at +> City College of New York and to the people of these mailing lists. + +... + + +\start +Date: Fri, 29 Aug 2003 17:02:34 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, axiom-mail@nongnu.org +Subject: [Axiom-developer] apply.boot autoload + +Bill, + +The autoload path is correct so that isn't the problem. +The AHYP compile is the first .spad compile so this is the first +time that the new Axiom started. +So it seems that apply.boot did not compile. +Check your console output for the apply.boot compile and see why it failed. + +\start +Date: Fri, 29 Aug 2003 17:20:50 -0400 +From: "Bill Page" +To: +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] RE: apply.boot autoload + +Tim, + +Here is what I see for apply.boot in the build log. It +seems to have compiled normally. Any other ideas? Are +there any environment variables besides AXIOM that might +affect this? + +---------- +11 making /home/wspage/projects/axiom/int/interp/apply.clisp from +/home/wspage/projects/axiom/src/interp/apply.boot.pamphlet + +>10 making /home/wspage/projects/axiom/obj/linux/interp/apply.o from +/home/wspage/projects/axiom/int/interp/apply.clisp + +> +Compiling /home/wspage/projects/axiom/int/interp/apply.clisp. +; (DEFUN |compApplication| ...) is being compiled. +;; The variable |$op| is undefined. +;; The compiler will assume this variable is a global. +; (DEFUN |compApplyModemap| ...) is being compiled. +;; The variable |$bindings| is undefined. +;; The compiler will assume this variable is a global. +; (DEFUN |compMapCondFun| ...) is being compiled. +;; Warning: The variable |op| is not used. +;; Warning: The variable |dc| is not used. +End of Pass 1. +End of Pass 2. +OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 +Finished compiling /home/wspage/projects/axiom/obj/linux/interp/apply.o. +9 making /home/wspage/projects/axiom/mnt/linux/autoload/apply.o from +/home/wspage/projects/axiom/obj/linux/interp/apply.o +--------- + +Cheers, +Bill Page. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Friday, August 29, 2003 5:03 PM +> To: bill.page1@sympatico.ca +> Cc: daly@idsi.net; axiom-developer@nongnu.org; +> axiom-mail@nongnu.org; axiom@tenkan.org +> Subject: apply.boot autoload +> +> +> Bill, +> +> The autoload path is correct so that isn't the problem. +> The AHYP compile is the first .spad compile so this is the +> first time that the new Axiom started. So it seems that +> apply.boot did not compile. Check your console output for the +> apply.boot compile and see why it failed. +> + +\start +Date: 29 Aug 2003 17:58:14 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: Re: [Axiom-developer] RE: apply.boot autoload + +Tim, + +The odd thing is this: I just returned to my 'projects/axiom' +directory and typed 'make' again. Now it seems to be able to +find apply and the compile continues... + +Right now I can't explain this. I haven't changed anything +since the first attempt. I did not start from 'make clean' +however. I just tried to reproduce the error by having make +carrying on where it left off. But it didn't work - or rather +it *is* now working, unexpectedly. + +Anyway, I let you know in a couple of hours if it completes +properly. + +Cheers, +Bill page. + + +On Fri, 2003-08-29 at 17:20, Bill Page wrote: +> Tim, +> +> Here is what I see for apply.boot in the build log. It +> seems to have compiled normally. Any other ideas? Are +> there any environment variables besides AXIOM that might +> affect this? +> ... + +\start +Date: Fri, 29 Aug 2003 18:26:37 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom@tenkan.org, axiom-developer@nongnu.org, daly@idsi.net, axiom-mail@nongnu.org +Subject: Re: [Axiom-developer] RE: apply.boot autoload + +Bill, + +I'm unable to figure this one out. Perhaps we should talk on the phone and +we can look over the details. + +\start +Date: Sat, 30 Aug 2003 00:17:05 -0400 +From: William Sit +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] RE: dependency visualization with VCG + +Tim: + +As I understand this, the problem is to find a linear ordering (for +compilation) on the set of Axiom "domains" (here in this paragraph, +"domain" means either a category or domain constructor, or a package) +such that if domain A precedes domain B in the linear order, then the +compiling of A does not depend on B and only on what precedes A. You +propose a heuristic method to generate this linear order using the +idea of a kernel (set of bootstrap domains) and then the most +frequently depended-on domain among the rest of the domains. + +To formulate the problem in terms of graph theory, a few +clarifications are needed. Here (in first paragraph), the set V of +vertices are the set of category constructors, domain constructors and +packages. It is not at all clear one should just limit vertices to +these three objects; it can also be argued that the set of vertices +include the set of functions as defined in these three objects; but +from your email, I'll assume the above is your intention. For +simplicity, let's refer to elements of V as a vertex rather than a +domain so as not to cause confusion; and at the same time, if the +meaning of vertex changes, the discussion below remains valid when +suitably interpreted. + +First, let's specify precisely the binary relation "depend on", that +is, the set E of directed edges (also called arcs). When we say there +is a directed edge from vertex A to vertex B if B "depends on" A +(note: a more intuitive term would be A "comes before" B, with the +understanding that cycles are allowed), do we mean some function or +reference (such as using the "with" clause) in B calls, with some +appropriate set C of parameters for A, either the construction of A +(if A is a category or domain constructor) and/or, in all cases, calls +a function from A? This seems to Bill Page's working definition. +If so, by this definition, it should be true that +B also "depends on" any vertex in the set C AND the vertices to which +any member of C belongs (that is, a parameter in C need not be a +vertex; for example, it could be an integer). + +I believe that Bill Page's algorithm may miss such a dependence as +well as adding dependences that are not real dependences (of course, +there is no harm in the latter case; but it may affect the solution to +the graph-theoretic problem). But I have to study this more to be +sure. Bill himself is aware of a number of problems. In general, I +do not agree with ONLY using the source file with text matching to +decide dependencies (even though that may be a good first +approximation). One should rely on the compiler itself (assuming it +has no bugs) to discover the dependencies. But this creates a +catch-22 situation. An example of a function that the compiler will +catch, but not easily caught by simple pattern matching from the spad +source is something like a + b. With all the notation embeded in a +pamphlet file, signs like + or - appear everywhere in all sorts of +context. Even in pure spad files, one cannot easily decide the +meaning of say the minus sign without understanding the context +where it appears. Observe that the appearance of a declaration for +ELEMENTS in a domain, or DOMAIN in a category is enough to decide a +dependence because operations, functions, or domain constructor must +all involve operands or parameters that belong to domains or +categories. As far as the problem of is dependence among vertices in +V, exactly which function demonstrates the dependence is not +important. Thus, it may be reasonable to revise the "depends on" to +mean: a vertex B depends on a vertex A if an element of A is declared +in the code for B. Here a category is considered as the set of +domains belonging to the category; a domain is the mathematical set +defined by the construction, and a package is the set of its exported +AND private functions. + +At this point, this discussion is a digression but related to how the +multi-digraph of the "depends on" relation is computed and the +subsequent efficiency. With that in mind, let me continue with the +theoretical version. + +Once this multi-digraph G = (V, E) is defined, because of possible +cycles (the word "loop" in digraph is reserved to mean +"self-dependency" in our context, that is, a directed edge from a +vertex to itself), it need not be anti-symmetric and so it is not a +partial ordering. One needs to "break" the cycles. We can easily +simplify the multi-digraph to just a di-graph (that is, we can +eliminate multiple directed edges from A to B for all pairs of +vertices (A, B). (Bill Page used sorting to accomplish this). +We may put weights on the parallel arcs to reflect some measure of +dependency, so that we can choose the one with the least weight. + +Now let's ease up a bit and consider only undirected graphs. To break +the cycles means finding a spanning forest (a forest is a disjoint +union of trees). The depth-first search algorithm accomplishes this as +well as decomposing the graph into its connected components. If the +graph is weighted, then we can even find minimum spanning forests by +finding a minimum spanning tree for each component. For example +Kruskal's or Prim's algorithm will do that. Here, a minimum spanning +tree is one that minimizes the sum of all weights in the tree. + +Now the depth-first search algorithm can be modified for digraphs. +The definitions for a few terms will be recalled. A digraph is +asymmetric if there is at most one arc between any two vertices. A +directed tree is an asymmetric digraph whose underlying graph (where +arcs become edges) is a tree. A directed tree that contains exactly +one vertex with indegree 0 is called an out-tree. A directed forest +is a digraph each of whose components is a directed tree. A theorem +then states that an out-tree is a rooted-tree whose root is the unique +vertex with indegree 0. Using an adjacency list for vertices, the +depth-first search produces a spanning directed forest each of whose +components is an out-tree. It is easy to draw the graphs of out-trees and then +to add in the remaining arcs of the digraph. + +Once we have the out-trees forming components of the digraph, it is an +easy matter to embed each out-tree (as a relation on vertices) into +a linear order (say list the vertices by the distances from the root, +starting with the root (distance 0); vertices the same distances from +the root may be listed in any order.) + +The bootstrap set of vertices are then the roots of the out-trees. +Note that this bootstrap set may change if the digraph grows as Axiom +adds more vertices. However, most of the original structure should +remain unless a very fundamental domain or category is created. + +All the algorithms as well as concepts on digraphs may be found in: +Gary Chartrand and Ortrud R. Oellermann, "Applied and Algorithmic +Graph Theory", McGraw Hill, 1993, New York. The depth-first search for digraph +is Algorithm 11.1 on pp. 317-318. + +William + + +root wrote: +> +> With respect to the notion of optimizing the domain we choose for +> the bootstrap list: +> +> Consider that we have, say 30 loops, each between 1 (some files +> self-refer) and 20 long. If we write each loop as a list then the goal +> is to choose domains out of the lists so we minimize the total number +> of bootstrap domains. Clearly the best first choice is "the most +> frequent" domain mentioned across all of the lists. We can then +> eliminate all of those lists since we now have a bootstrap file. Next +> we choose the most frequent domain from the remaining lists. This may +> not be optimal but it would be a better algorithm than the one I used +> which was to just choose any domain. +> +> I'm sure there is a wonderful mathematical name for the bootstrap +> list (e.g. the "kernel"?) but I haven't yet cast it into either +> graph theory or any other theory yet. +> + +\start +Date: Sat, 30 Aug 2003 00:20:34 -0400 +From: root +To: bill.page1@sympatico.ca, axiom-developer@nongnu.org +Subject: [Axiom-developer] mingw + +Bill, + +Well, Windows XP lives. +MinGW lives. +Hello, World works. +Any advice? + +\start +Date: Sat, 30 Aug 2003 00:34:08 -0400 +From: root +To: axiom-developer@nongnu.org +Cc: daly@idsi.net +Subject: [Axiom-developer] running? + +If anyone gets the system to compile and run please let me know. + +\start +Date: Sat, 30 Aug 2003 00:33:04 -0400 +From: root +To: wyscc@cunyvm.cuny.edu +Cc: axiom-developer@nongnu.org, daly@idsi.net, bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] RE: dependency visualization with VCG + +Bill Sit, + +The linear order exists and is documented in the file +src/algebra/Lattice.pamphlet. The compiler will tell +you all of the dependencies at compile time. The subtle +part is to find the bootstrap set since, in the beginning, +nothing will compile. That's part of what took so long. +The other part is that computing the correct location in +the lattice for all 1100 categories, domains, and packages +was tedious and time consuming. But it's done. + +I believe the lattice can be further optimized but that's +just an academic exercise. The reason the lattice has to +exist in any form is that you need to compile from scratch. +Once that happens the lattice is worthless. + +I'd like to see it graphed just so I can stare at the beast +that ate 8 months of my life. + +\start +Date: 30 Aug 2003 02:38:13 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] running? + +Tim, + +In spite of the "hick-up" that we discussed earlier regarding +apply.boot, I have now compiled a running system from your +Savannah source files. It has passed a few simple tests and +seems to be fully functional. Great work! + +I noticed, one thing during the compile. Your make file (like +Juergen's) produces extra unnecessary intermediate algebra files +(lowercase.spad files) by running notangle on the *.spad.pamphlet +files without specifying a root chunk (-R). So there are about +400+ extra unnecessary files in the int/algebra directory. This +has no effect on the actual result of the build but it is quite +easily eliminated and it does simplify the algebra/Makefile a +little. I will send you a patch sometime tomorrow to fix this. + +Cheers, +Bill Page. + + +On Sat, 2003-08-30 at 00:34, root wrote: +> If anyone gets the system to compile and run please let me know. +> +> Tim + +\start +Date: 30 Aug 2003 04:09:01 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] RE: dependency visualization with VCG + +Tim, William; + +I think an accurate algebra dependency di-graph has more than +just a curiosity value. + +William, I think the analysis and formalism in your previous +message is relevant, however the problem is somewhat simplier +than you suggest. The vertices of the di-graph are just the +*.spad files themselves. These are a subset of the files +contained in the int/algebra and are derived (many to one) +from the *.spad.pamphlet files in src/algebra. The directed +edges between vertices represent pre-conditions for compilation. +Specifically, an edge directed from vertex A to vertex B states +that file B.spad contains some element (function) that is +needed in the compilation of A.spad. (Of course the opposite +convention for the orientation of the edges is also possible.) + +Although I admit that you do correctly point out that my +current method of finding these dependencies is deficient in +some respects. I agree with you and Tim that the most accurate +way to obtain this dependency di-graph would be to analyze +the output of the compilation process itself. Now that we +have a full compilation of Axiom that runs to completion, +this is easily achievable. + +It is one of the unusual properties of Axiom that the algebra +dependency di-graph may contain cycles. This means that it +is not possible to compile Axiom in the way that most complex +computer systems are compiled. The presence of cycles means that +no linear order of compilation exists. Instead, one must find a +way to *solve* (satisfy) the set of cyclically dependent vertices, +separately from those that follow in a linear manner. We call +a cycle "satisfied" if all of the spad files in the cycle can +be compiled in a self-consistent manner, that is, in such a +way that all the dependencies in the cycle are satisfied. +Operationally, this means that given such a solution for a +cycle, we could repeatedly compile each spad file in turn going +around the cycle with no change in the internal code that is +produced. In other words, the solution is a "fixed-point" for +the cycle. + +In this respect the Axiom code is not strictly "imperative" but +rather it is a specification of a system that may or may not +have a solution. And if a solution exists, it may not be unique. + +Bertfried Fauser has pointed out that there is good reason to +suppose that this sort of cyclical dependency is inherent in +the underlying mathematics that Axiom attempts to represent. I +think this has a rather large importance in the philosophy of +mathematics. But that is subject that is beyond the scope of +the current discussion + +The solution algorthm that Tim has employed in the new open +source version of Axiom starts with a choice of "bootstrap" +vertices. The compiled code for these vertices is given "out +of the blue", that is through some external process (in this +case it is derived from the intermediate LISP code of a previous +version of Axiom). The dependency di-graph is *cut* by +temporarily ignoring all the outward directed edges of these +vertices. The choice of bootstrap vertices is made in such +a way as to produce an acyclic di-graph (lattice) that covers +the orginal dependency di-graph. + +Tim is right that *any* viable selection (quite possiblity +sub-optimal) of "bootstrap" vertices together with a linear +ordering is sufficient to build a working version of Axiom - +and this is hard enough. But really we are not done when we +have just produced a runnable program. We really need to +complete the bootstrap cycles and compile each of the +previously choosen bootstrap spad files as well. Then we will +compare the newly generated internal code (LISP) for each +bootstrap file to the bootstrap code with which that we +started. If there is a semantic difference between the orginal +and the new bootstrap code, then we need to repeat the build +process again, using the new bootstrap code. In principle we +have to iterate until we reach the desired fixed point for +all of the bootstrap vertices. Achieving this fixed point +means that our internal code for Axiom no longer depends on +the particular starting bootstrap code and it does not +depend on how many times we have repeated the iterations +after the fixed point is achieved. + +I say "in principle" because in actual fact, change in the +bootstrap code with each iteration may not be that significant. +On the other hand, it is not clear to me what are the pre- +onditions on the initial bootstrap code might have to be in +order to guarrantee the existence of a fixed point solution +by iteration. It is also not clear that such a solution is +necessarily unique. So perhaps it is not really possible to +completely eliminate the dependence of Axiom on the initial +choice of bootstrap code. + +But in preparing the algebra makefile for Axiom, I think we +should be even more ambitious. I think it is very desirable to +design a makefile script that directly incorporates the specific +dependencies and not just a viable linear ordering. The make +program is designed to perform a "lazy evaluation" on a lattice +of such specific dependencies. If I make a change to coding in +one spad file (by editing a spad.pamphlet file), I want the +make program to use the information in the Makefile to re-compile +only those spad files which are affected (both directly and +indirectly) by my change. This would (usually) be a very short +process compared to recompiling the whole set of well over +1000 files. + +The second problem to which Tim has referred, namely attempting +to find an optimal set of bootstrap files also deserves some +attention. Presumably a smaller set of bootstrap files will +converge to a fixed point more quickly that a larger set. And +it is also desirable to have a smaller set in order to reduce +the effort reguired to evaluate the correctness of the initial +bootstrap code. + +I hope I have not taken us too far afield in this discussion. + +Cheers, +Bill Page. + + +On Sat, 2003-08-30 at 00:33, root wrote: +> Bill Sit, +> +> The linear order exists and is documented in the file +> src/algebra/Lattice.pamphlet. The compiler will tell +> you all of the dependencies at compile time. The subtle +> part is to find the bootstrap set since, in the beginning, +> nothing will compile. That's part of what took so long. +> The other part is that computing the correct location in +> the lattice for all 1100 categories, domains, and packages +> was tedious and time consuming. But it's done. +> +> I believe the lattice can be further optimized but that's +> just an academic exercise. The reason the lattice has to +> exist in any form is that you need to compile from scratch. +> Once that happens the lattice is worthless. +> +> I'd like to see it graphed just so I can stare at the beast +> that ate 8 months of my life. +> + +\start +Date: Sat, 30 Aug 2003 10:12:11 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] RE: dependency visualization with VCG + +> In this respect the Axiom code is not strictly "imperative" but +> rather it is a specification of a system that may or may not +> have a solution. And if a solution exists, it may not be unique. +> +> Bertfried Fauser has pointed out that there is good reason to +> suppose that this sort of cyclical dependency is inherent in +> the underlying mathematics that Axiom attempts to represent. I +> think this has a rather large importance in the philosophy of +> mathematics. But that is subject that is beyond the scope of +> the current discussion + +I've added a new mailing list, axiom-math@nongnu.org, because +such discussions of math theory and philosophy of Axiom's math +are important and need a proper forum. It should be available +today and I'll announce it to the lists once it exists. Once it +exists lets move the discussion over there. + +Philosophically speaking, I'm beginning to think that computational +mathematics (as opposed to pencil mathematics) will begin to uncover +new "axioms" that further refine the mathematical theory. So, for +instance, we might discover that the category division of RNG and RING +exists because there is a logical requirement that has never been +formally stated. The Axiom book contains an algebra hierarchy on the +front flyleaf. Somebody needs to write the corresponding axioms that +underlie each domain. It would be very interesting to see the RNG vs +RING axioms. + +(On a side note: I once saw a Venn diagram that showed the relationship +between groups, rings, integral domains, fields, etc. in a book. I'm +unable to find that again. If anyone ever sees it please send me the +name of the book. I want to use that diagram to explain the algebra +hierarchy and I can't find it again.) + + +> Tim is right that *any* viable selection (quite possiblity +> sub-optimal) of "bootstrap" vertices together with a linear +> ordering is sufficient to build a working version of Axiom - +> and this is hard enough. But really we are not done when we +> have just produced a runnable program. We really need to +> complete the bootstrap cycles and compile each of the +> previously choosen bootstrap spad files as well. + +Actually, if you look at the <> chunk in the makefile you'll +see that a chunk exists after all of the levels. This chunk recompiles +the bootstrap layer code using the compiler. + +This should cover the case where the bootstrap lisp code is not +semantically the same. This will not work in general as significant +changes to the files containing the bootstrap code (e.g. deleting +functions) will break everything. However, the pamphlet files for the +bootstrap code contain warnings that you have to regenerate and +re-embed the lisp code if you change the algebra. + +> Then we will +> compare the newly generated internal code (LISP) for each +> bootstrap file to the bootstrap code with which that we +> started. If there is a semantic difference between the orginal +> and the new bootstrap code, then we need to repeat the build +> process again, using the new bootstrap code. In principle we +> have to iterate until we reach the desired fixed point for +> all of the bootstrap vertices. Achieving this fixed point +> means that our internal code for Axiom no longer depends on +> the particular starting bootstrap code and it does not +> depend on how many times we have repeated the iterations +> after the fixed point is achieved. + +The recompile hack mentioned above will recover from "small" errors +but does not cover the "fixed point" case you mention. However if +the fixed point is not achieved within the one iteration within the +makefile I'd consider the build badly broken. + +> But in preparing the algebra makefile for Axiom, I think we +> should be even more ambitious. I think it is very desirable to +> design a makefile script that directly incorporates the specific +> dependencies and not just a viable linear ordering. The make + +I originally agreed with you on this and, if you look in the previous +Makefile.pamphlet you'll see that the layer0 files were being added to +each file they depended on. That is, if foo.spad depended on int.spad +I wrote: + +foo.NRLIB: int.o foo.spad + +This is very fragile as modifications to the lattice had to be propagated +into all of the rule stanzas. So the next "hack" was to generalize the +dependence to the layer thus: + +foo.NRLIB: ${LAYER0} foo.spad + +Thus any change in the layer 0 files would cause foo to be rebuilt. +This is more robust but causes a HUGE increase in the number of +recompiles. + +Axiom's algebra is reasonably stable in the face of changes. I don't +expect that people will be making many changes to the "standard library" +that is shipped with Axiom. Code that IS changed or added will have to +be reviewed. In particular the "standard library" code will have to +build from scratch anyway so changes that break the algebra will show +up (well, mumble, mumble, mutter, mumble) in the build. + +> I hope I have not taken us too far afield in this discussion. + +It's very relevant discussion but perhaps not of interest to all of +the developers. The lattice solution has caused me to "circle the coffee +table" quite a few times as it was not clear how to solve the bootstrap +problem. Discussions like this would have helped. + +There are still more problems that need this kind of discussion such as: + +generalization of simplification, +making simplification "domain controlled", +adding provisos (e.g. saying 1/x provided x != 0), +proving the algorithms correct, +adding ACL2 or MetaPRL style computation to the standard library, +mathematically justifying the computational mathematics (e.g. why RNG and RING?) +taxonomiically ordering the algebra by subject, +... + +Indeed, each of these topics and more should eventually become Axiom Journal +articles. Once we figure out the correct way to represent the lattice we +should consider writing up a paper for submission to the Axiom Journal. +Then we can argue over what the "rules" for submission are (e.g. what +is required in a "literate paper", who reviews these things, how to +get such a Journal recognized by ACM or Springer, etc). + +In any case, sometime this afternoon there will be an "axiom-math" +mailing list. I'll forward these mailings to it. Lets continue the +discussion there. I'm very interested in the result. + +\start +Date: Sat, 30 Aug 2003 11:21:22 -0400 +From: William Sit +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] RE: dependency visualization with VCG + +Tim and Bill: + +I just got Bill's comments, which I think agrees with my comments below (written +before I read Bill's comments), and are also more practical than the abstract +version I present. My original analysis was an attempt (I am no graph theory +expert) to relate the practical to if you will a mathematical model using known +algorithms from graph theory. This in no way diminishes the accomplishment Tim +and other great hackers have achieved. + +William +---------- + +root wrote: +> +> The linear order exists and is documented in the file +> src/algebra/Lattice.pamphlet. The compiler will tell +> you all of the dependencies at compile time. The subtle +> part is to find the bootstrap set since, in the beginning, +> nothing will compile. That's part of what took so long. +> The other part is that computing the correct location in +> the lattice for all 1100 categories, domains, and packages +> was tedious and time consuming. + +But this is a catch-22 situation. Your problem, however, is to be able to +compile from scratch, even if in order to find the linear order, you have to do +some "test" compiling (or rely on "information" from the NAG compilation -- this +is NOT equivalent to relying on the "compiled object files"). One can use ANY +means to obtain the dependency adjacent list on vertices, including manually +analysing all spad sources, which you probably did. From that, one can identify +the bootstrap set (the set of roots of out-trees in the components of the +digraphs). I think they are just those vertices with indegree 0. + + +> But it's done. + +> I believe the lattice can be further optimized but that's +> just an academic exercise. The reason the lattice has to +> exist in any form is that you need to compile from scratch. +> Once that happens the lattice is worthless. + +I agree that the lattice can be, and should be, further optimized. It's not just +an academic exercise. Further, I do not agree the lattice is worthless. I know +that "it's done", but each time a full (or even partial) compilation is done, a +more accurate (or up-to-date) dependency adjacent list is found that can feed +the next compilation from scratch. Right now, you have a static library of spad +sources. This is going to become dynamic as more spad sources are added. + +> I'd like to see it graphed just so I can stare at the beast +> that ate 8 months of my life. + +Your initial great effort is much appreciated. It is part of the "collection of +data" for the dependency digraph. However you did it, you did a fantastic job. +What I was pointing out was that when Bill Page wrote the routine to graph the +dependency digraph, it seems to me he started afresh from the spad sources to +derive the dependency digraph. Isn't it true that you already have the digraph +and you only need to display it visually? I am probably missing something +subtle. + +Actually, I just note that the analysis I gave has a small mistake. That is, +even though we obtain a directed forest of out-trees for the digraph, and a +linear order extending each out-tree, it is not the case that the compilation of +any vertex A just depend on what precedes it. (In other words, this property +cannot be satisfied if there are cycles). + +There is a further extension of the depth-first search algorithm that computes +what is called the condensation of a digraph. Roughly speaking, the condensation +is an acyclic digraph whose vertices are the strong components of the digraph (a +strong component is a maximally strongly connected sub-digraph where there is a +directed path between any two vertices) and whose arcs reflect the arcs between +strong components. + +It seems the graph you want to see is the condensation and the strong components +of the dependency digraph. + +William + +\start +Date: Sat, 30 Aug 2003 15:57:34 -0400 +From: root +To: axiom-mail@nongnu.org, axiom-developer@nongnu.org +Subject: [Axiom-developer] new mailing list + +I've set up a new mailing list, axiom-math@nongnu.org, for the purpose +of discussing mathematical and philosophical issues with Axiom. The +developer's mailing list is intended for more specific coding and +debugging tasks. + +\start +Date: 30 Aug 2003 16:34:56 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: mingw + +Tim, + +I would suggest that you obtain GCL 2.5.4 from the CVS and next +attempt to compile and install it under Windows using MinGW and +MSYS. Although it is still pre-release, it should compile with +no problems. 2.5.4 is supposed to include support for the XDR +extensions under windows (which is needed for Axiom) but you +must first install the ONC version of XDR. I can send this to +you. I successfully installed XDR under 2.5.3 on Windows, but +it was a little involved. + +Once you have a running version of GCL with XDR under Windows, +you will be almost ready to attempt to build Axiom. But you +most add the GCL dir so that the Axiom Makefile does not +attempt to build a new version of GCL from the older sources +and also arrange that GCL can be run from the place that +the Axiom Makefile expects to find it. + +All this isn't particulary hard, but if you really are new +to Windows you will no doubt find the transition to this +environment a little frustrating. Let me know if you have +questions. + +Bill Page. + + +On Sat, 2003-08-30 at 00:20, root wrote: +> Bill, +> +> Well, Windows XP lives. +> MinGW lives. +> Hello, World works. +> Any advice? +> +> Tim +> axiom@tenkan.org +> daly@idsi.net + +\start +Date: 30 Aug 2003 16:50:51 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] Re: [Axiom-mail] new mailing list + +Tim, + +The url + + http://mail.gnu.org/archive/html/axiom-math + +Gives the message: + +Not Found +The requested URL /archive/html/axiom-math was not found on this server. + +Perhsps the list is not yet fully set up? + +I think your idea of creating this list is a good one! + +Cheers, +Bill Page. + + +On Sat, 2003-08-30 at 15:57, root wrote: +> I've set up a new mailing list, axiom-math@nongnu.org, for the purpose +> of discussing mathematical and philosophical issues with Axiom. The +> developer's mailing list is intended for more specific coding and +> debugging tasks. + +\start +Date: Sat, 30 Aug 2003 16:55:03 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net, axiom-mail@nongnu.org +Subject: [Axiom-developer] Re: [Axiom-mail] new mailing list + +I was able to subscribe to the list without a problem. +Try once more and let me know if you succeed or fail. + +\start +Date: 30 Aug 2003 17:06:18 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org, axiom-mail@nongnu.org +Subject: [Axiom-developer] Re: [Axiom-mail] new mailing list + +Tim, + +I sucessfully subscribed, I am just not yet able to access the +archives for the new list. It should be at + + http://mail.gnu.org/archive/html/axiom-math + +but I get an error message. + +Bill. + +On Sat, 2003-08-30 at 16:55, root wrote: +> I was able to subscribe to the list without a problem. +> Try once more and let me know if you succeed or fail. +> + +\start +Date: Sat, 30 Aug 2003 23:08:49 +0200 +From: "Weiss, Juergen" +To: , +Subject: RE: [Axiom-developer] running? + +I compiled the system under debian woody. Because I did not have +binutils installed I configured gcl with the locally supplied bdf +library. It was not possible to compile the system without latex +installed. With latex every thing seemed to work as expected. + +Good job. + +> -----Original Message----- +> From: root [mailto:daly@idsi.net] +> Sent: Saturday, August 30, 2003 6:34 AM +> To: axiom-developer@nongnu.org +> Cc: daly@idsi.net +> Subject: [Axiom-developer] running? +> +> +> If anyone gets the system to compile and run please let me know. +> + +\start +Date: Sat, 30 Aug 2003 17:16:51 -0400 +From: root +To: weiss@uni-mainz.de +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] running? + +Juergen, + +Try the following experiment: + +Clip out the domain INTRVL from interval.spad and call it INTRVL.spad +Start the system and try: + +)co INTRVL.spad + +Let me know the results. + +\start +Date: Sat, 30 Aug 2003 22:49:56 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] interval.spad INTRVL + +re: lowercase spad files. + +These were put there for the purpose of testing. They are in the +int directory and would not be part of a "shipped" image (which +all resides under the mnt directory). It is convenient to be able +to )co foo.spad or )co foo.spad )con bar without having to do the +notangle. One thing I need to do is try to recompile all of the +lowercase.spad files to ensure I haven't broken the original code. +I did that earlier but it needs to be redone for the latest changes. + +Additionally the long term will have the interpreter do the notangle +under the covers directly from the pamphlet file. At that time we +can eliminate the lowercase.spad files. I didn't have time to write +this before shipping the Thursday system. + +re: INTRVL + +The reason it works in Juergen's version is that the interval.spad +file is compiled as one file rather than as a category and a domain. + +If you start the Thursday version and do: + +)co INTCAT +)co INTRVL + +then the compiles succeed. This is the same behavior as compiling +all of interval.spad. The compile of INTCAT implicitly makes the +|IntervalCategory| function available. However, if you compile +the two files in separate interpsys sessions then the compile of +INTRVL fails because it cannot find INTCAT. + +The databases are indeed bent. There is a another layer of cycle +in the game as follows: + +In order to build the first interpsys you need the database files. +These are gotten from the src/share/algebra/*.daase files which are +the original NAG databases. This magic occurs because there is a +shell variable ($DAASE) that is asserted during the build (see the +./Makefile.pamphlet file). + +Once the build is complete (which also builds new databases) the +databases are fetched from mnt/linux/algebra/*.daase. (You can +change which databases it uses by setting or unsetting the DAASE +shell variable. Note that the shell variable has /algebra automatically +appended so DAASE=/foo/bar becomes /foo/bar/algebra) + +The interval.spad file was rewritten by Juergen and is not part +of the NAG database but interval.as is. Somehow building INTRVL +with the NAG databases causes the compile to fail. I'm chasing it +now but I don't understand it fully yet. + +re: SIGNEF + +The nature of that problem is that SIGNEF uses INTRVL. + +================================================================== + +Tim, + +I am now in the middle of third re-compile with a modified +Makefile.pamphlet that eliminates the extra lowercase.spad +files and adds a few of the modules which were not yet +included in your make file, including INTRVL. I found that +when a attempted to evaluate + + + -> integrate(exp(sin(x)),x) + +that Axiom complained that it could not load COMBF.o and +then SIGNEF.o. When I tried to compile SIGNEF.o, I got an +error saying that it couldn't find Interval. + +The interesting thing is that this works under Juergen's +version. (It loads all of the required algebra, but Axiom +returns the expression unevaluated.) + +Could it be that there is still a problem with the databases? +Are these being re-built in your newest version of the +Makefile? + +Cheers, +Bill Page. + +On Sat, 2003-08-30 at 21:00, root wrote: +> The INTCAT category is not being autoloaded. I'm not sure why. + +\start +Date: Sun, 31 Aug 2003 01:50:55 -0400 +From: dpt@exoskeleton.math.harvard.edu (Dylan Thurston) +To: axiom-developer@nongnu.org +Subject: Re: [Axiom-developer] running? + +--LZvS9be/3tNcYl/X +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline + +On Sat, Aug 30, 2003 at 12:34:08AM -0400, root wrote: +> If anyone gets the system to compile and run please let me know. + +It compiled for me with no problems. + +(However, there are several files, particularly in the 'zips' directory, +that don't seem like they belong under CVS control.) + +\start +Date: 31 Aug 2003 03:10:36 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: interval.spad INTRVL + +Tim, + +On Sat, 2003-08-30 at 22:49, you wrote: +> re: lowercase spad files. +> +> These were put there for the purpose of testing. They are in the +> int directory and would not be part of a "shipped" image (which +> all resides under the mnt directory). It is convenient to be able +> to )co foo.spad or )co foo.spad )con bar without having to do the +> notangle. + +Perhaps. But I understood that your goal was one category, domain +or package per spad file, presumably so that the dependencies +could be more "fine grained". Otherwise you could just build +with the lowercase files and throw away the upper case ones. No? + +In any case, as you say the duplication does no harm. + +> One thing I need to do is try to recompile all of the +> lowercase.spad files to ensure I haven't broken the original +> code. I did that earlier but it needs to be redone for the +> latest changes. +> +> Additionally the long term will have the interpreter do the +> notangle under the covers directly from the pamphlet file. At +> that time we can eliminate the lowercase.spad files. I didn't +> have time to write this before shipping the Thursday system. + +It seems you would be eliminating the upper case ones as well +and would depend directly on the pamphlet files. I can see the +advantage of this in other circumstances, e.g. user application +files. + +> +> re: INTRVL +> +> The reason it works in Juergen's version is that the interval.spad +> file is compiled as one file rather than as a category and a domain. + +No, look again. That is not what happens in Juergen's makefile. +All of the pamphlet files including interval.spad.pamphlet are +split into upper case name files containing individual modules +with named by their abbreviations and also as a combined module +file with a lower case name the same as the pamphlet. *Only* +the upper case files are compiled. In fact, in my variant of +Juergen's makefile I have eliminated all of the files with +lowercase names. + +There must be some other explanation. + +> If you start the Thursday version and do: +> +> )co INTCAT +> )co INTRVL +> +> then the compiles succeed. This is the same behavior as compiling +> all of interval.spad. The compile of INTCAT implicitly makes the +> |IntervalCategory| function available. However, if you compile +> the two files in separate interpsys sessions then the compile of +> INTRVL fails because it cannot find INTCAT. +> + +These two files are compiled separately in Juergen's version. + +> The databases are indeed bent. There is a another layer of cycle +> in the game as follows: +> +> In order to build the first interpsys you need the database files. +> These are gotten from the src/share/algebra/*.daase files which are +> the original NAG databases. + +Juergen re-built the src/share/algebra/*.daase files. These +re-built files are used to build the first version. + + +> This magic occurs because there is a +> shell variable ($DAASE) that is asserted during the build +> (see the /Makefile.pamphlet file). +> +> Once the build is complete (which also builds new databases) +> the databases are fetched from mnt/linux/algebra/*.daase. + +Juergen's version does not build new database files. It +continues to use the ones from share. + +> (You can +> change which databases it uses by setting or unsetting the +> DAASE shell variable. Note that the shell variable has /algebra +> automatically appended so DAASE=/foo/bar becomes /foo/bar/algebra) +> +> The interval.spad file was rewritten by Juergen and is not part +> of the NAG database but interval.as is. Somehow building INTRVL +> with the NAG databases causes the compile to fail. I'm chasing it +> now but I don't understand it fully yet. +> + +Me neither! But I don't trust those database files! + +This reminds me to ask about the other ALDOR files that are +included in the build but apparently not compiled. Are you +planning that these will at some point be compiled by ALDOR? +(which is now a separate non-BSD licensed? package) How +difficult is it for a user to encorporate ALDOR if they so +wished? There would likely be a considerable speed and memory +advantage for certain routines. Right? + +Another thing that has happened since Aldor separated from +Axiom is that a very large part of the algegbra has been +re-written and apparently improved. Do you think that in +the medium to long term the Axiom and Aldor algebra libraries +should be made compatible? How practical (and legal?) would +it be for Axiom (at least as a option) to implement the +same library. Is it difficult to convert to spad. Or is +there any advantage if ALDOR can be easily linked with +Axiom? + +> re: SIGNEF +> +> The nature of that problem is that SIGNEF uses INTRVL. +> + +With the Thursday version if I compile INTCAT, INTRVL and +SIGNEF in the same session (and in that order), I get an +error + +--------constructor--------- +Compiling /home/wspage/projects/axiom2/./SIGNEF.NRLIB/code.lsp. +End of Pass 1. +End of Pass 2. +OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 +Finished compiling /home/wspage/projects/axiom2/./SIGNEF.NRLIB/code.lsp. +------------------------------------------------------------------------ + + >> System error: + Caught fatal error [memory may be damaged] + +protected-symbol-warn called with (NIL) + +-------- + +Ho hum ... time to get a little sleep. + +Cheers, +Bill Page. + + +> ================================================================== +> +> Tim, +> +> I am now in the middle of third re-compile with a modified +> Makefile.pamphlet that eliminates the extra lowercase.spad +> files and adds a few of the modules which were not yet +> included in your make file, including INTRVL. I found that +> when a attempted to evaluate +> +> +> -> integrate(exp(sin(x)),x) +> +> that Axiom complained that it could not load COMBF.o and +> then SIGNEF.o. When I tried to compile SIGNEF.o, I got an +> error saying that it couldn't find Interval. +> +> The interesting thing is that this works under Juergen's +> version. (It loads all of the required algebra, but Axiom +> returns the expression unevaluated.) +> +> Could it be that there is still a problem with the databases? +> Are these being re-built in your newest version of the +> Makefile? +> +> Cheers, +> Bill Page. +> +> On Sat, 2003-08-30 at 21:00, root wrote: +> > The INTCAT category is not being autoloaded. I'm not sure why. + +\start +Date: Sun, 31 Aug 2003 03:38:02 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Re: interval.spad INTRVL + +> > re: lowercase spad files. +> > +> > These were put there for the purpose of testing. They are in the +> > int directory and would not be part of a "shipped" image (which +> > all resides under the mnt directory). It is convenient to be able +> > to )co foo.spad or )co foo.spad )con bar without having to do the +> > notangle. +> +> Perhaps. But I understood that your goal was one category, domain +> or package per spad file, presumably so that the dependencies +> could be more "fine grained". Otherwise you could just build +> with the lowercase files and throw away the upper case ones. No? +> +> In any case, as you say the duplication does no harm. + +Actually the organization of a pamphlet file is likely to have +several category/domain/packages (CDP) in it. In fact, most newly +contributed algebra is likely to be packaged that way. It is +not a problem because newly contributed algebra does not need +to be bootstrapped. I prefer the single-CDP per file style but +others do not. + +However, in the bootstrap situation you need to have much finer +grain control of which CDP you are building. I found that there +was no possible order that could build the "lowercase" spad files +so I needed to break them apart. + +In any case the "user level" presentation of the algebra will be +the "lowercase" spad file pamphlets. This is too ingrained to change. +So consider the "uppercase" spad files to be part of the internal +machinery of the build. + + +> It seems you would be eliminating the upper case ones as well +> and would depend directly on the pamphlet files. I can see the +> advantage of this in other circumstances, e.g. user application +> files. + +Remember that the user will see nothing from the int and obj +directories. These are purely compiler and makefile caches. They +contain no useful information for the user. However they seriously +reduce the rebuild time and allow optimization to occur (watch for the +warning messages about duplicate functions. that comes from the +special second-pass optimizer based on the .fn files in the int +directory). + +The user will see the "lowercase" spad.pamphlet files +(hopefully with better documentation). In particular, the user should +be able to type: + +)co interval + +and have the interval.spad file extracted, compiled, and installed. +In the longer term the compiler will be hidden and the user will just type: + +)add interval + +which will rip the pamphlet into code, compile it, rip out the test cases, +test them, rip out the documentation and integrate it into the system, +chase biblio references and include them, run included proofs, install +examples, and shine your sneakers. This will take a few weeks to implement +so the scaffolding is still showing thru. + +> > +> > re: INTRVL +> > +> > The reason it works in Juergen's version is that the interval.spad +> > file is compiled as one file rather than as a category and a domain. +> +> No, look again. That is not what happens in Juergen's makefile. +> All of the pamphlet files including interval.spad.pamphlet are +> split into upper case name files containing individual modules +> with named by their abbreviations and also as a combined module +> file with a lower case name the same as the pamphlet. *Only* +> the upper case files are compiled. In fact, in my variant of +> Juergen's makefile I have eliminated all of the files with +> lowercase names. +> +> There must be some other explanation. + +Interesting. That's another clue. I missed that. + +> > In order to build the first interpsys you need the database files. +> > These are gotten from the src/share/algebra/*.daase files which are +> > the original NAG databases. +> +> Juergen re-built the src/share/algebra/*.daase files. These +> re-built files are used to build the first version. + +Hmmm, yet another clue. I'll look into that also. + + +> This reminds me to ask about the other ALDOR files that are +> included in the build but apparently not compiled. Are you +> planning that these will at some point be compiled by ALDOR? +> (which is now a separate non-BSD licensed? package) How +> difficult is it for a user to encorporate ALDOR if they so +> wished? There would likely be a considerable speed and memory +> advantage for certain routines. Right? +> +> Another thing that has happened since Aldor separated from +> Axiom is that a very large part of the algegbra has been +> re-written and apparently improved. Do you think that in +> the medium to long term the Axiom and Aldor algebra libraries +> should be made compatible? How practical (and legal?) would +> it be for Axiom (at least as a option) to implement the +> same library. Is it difficult to convert to spad. Or is +> there any advantage if ALDOR can be easily linked with +> Axiom? + +mumble + +> > The nature of that problem is that SIGNEF uses INTRVL. +> > +> +> With the Thursday version if I compile INTCAT, INTRVL and +> SIGNEF in the same session (and in that order), I get an +> error +> +> --------constructor--------- +> Compiling /home/wspage/projects/axiom2/./SIGNEF.NRLIB/code.lsp. +> End of Pass 1. +> End of Pass 2. +> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 +> Finished compiling /home/wspage/projects/axiom2/./SIGNEF.NRLIB/code.lsp. +> ------------------------------------------------------------------------ +> +> >> System error: +> Caught fatal error [memory may be damaged] +> +> protected-symbol-warn called with (NIL) +> +> -------- +> +> Ho hum ... time to get a little sleep. +> + +sleep? at a time like this? where's your dedication, man! Why it's only +3:30am. Sleep. cheese. you'll have time to sleep after you die. + +\start +Date: Sun, 31 Aug 2003 10:07:29 +0200 +From: "Weiss, Juergen" +To: , +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] Re: interval.spad INTRVL + +Axiom remembers in the database files, if the source was an aldor +or spad file and behaves differently. So if you distributed the old +database, it does not work. Did not work for me either ;-). + +> > > re: INTRVL +> > > +> > > The reason it works in Juergen's version is that the interval.spad +> > > file is compiled as one file rather than as a category +> and a domain. +> > +> > No, look again. That is not what happens in Juergen's makefile. +> > All of the pamphlet files including interval.spad.pamphlet are +> > split into upper case name files containing individual modules +> > with named by their abbreviations and also as a combined module +> > file with a lower case name the same as the pamphlet. *Only* +> > the upper case files are compiled. In fact, in my variant of +> > Juergen's makefile I have eliminated all of the files with +> > lowercase names. +> > +> > There must be some other explanation. +> +> Interesting. That's another clue. I missed that. +> +> > > In order to build the first interpsys you need the database files. +> > > These are gotten from the src/share/algebra/*.daase files +> which are +> > > the original NAG databases. +> > +> > Juergen re-built the src/share/algebra/*.daase files. These +> > re-built files are used to build the first version. +> +> Hmmm, yet another clue. I'll look into that also. +> +> +> > This reminds me to ask about the other ALDOR files that are +> > included in the build but apparently not compiled. Are you +> > planning that these will at some point be compiled by ALDOR? +> > (which is now a separate non-BSD licensed? package) How +> > difficult is it for a user to encorporate ALDOR if they so +> > wished? There would likely be a considerable speed and memory +> > advantage for certain routines. Right? +> > +> > Another thing that has happened since Aldor separated from +> > Axiom is that a very large part of the algegbra has been +> > re-written and apparently improved. Do you think that in +> > the medium to long term the Axiom and Aldor algebra libraries +> > should be made compatible? How practical (and legal?) would +> > it be for Axiom (at least as a option) to implement the +> > same library. Is it difficult to convert to spad. Or is +> > there any advantage if ALDOR can be easily linked with +> > Axiom? +> +> mumble +> +> > > The nature of that problem is that SIGNEF uses INTRVL. +> > > +> > +> > With the Thursday version if I compile INTCAT, INTRVL and +> > SIGNEF in the same session (and in that order), I get an +> > error +> > +> > --------constructor--------- +> > Compiling /home/wspage/projects/axiom2/./SIGNEF.NRLIB/code.lsp. +> > End of Pass 1. +> > End of Pass 2. +> > OPTIMIZE levels: Safety=0 (No runtime error checking), +> Space=0, Speed=3 +> > Finished compiling +> /home/wspage/projects/axiom2/./SIGNEF.NRLIB/code.lsp. +> > +> -------------------------------------------------------------- +> ---------- +> > +> > >> System error: +> > Caught fatal error [memory may be damaged] +> > +> > protected-symbol-warn called with (NIL) +> > +> > -------- +> > +> > Ho hum ... time to get a little sleep. +> > +> +> sleep? at a time like this? where's your dedication, man! Why +> it's only +> 3:30am. Sleep. cheese. you'll have time to sleep after you die. +> + +\start +Date: Sun, 31 Aug 2003 04:14:33 -0400 +From: root +To: weiss@uni-mainz.de +Cc: axiom-developer@nongnu.org, daly@idsi.net, bill.page1@sympatico.ca +Subject: Re: [Axiom-developer] Re: interval.spad INTRVL + +> Axiom remembers in the database files, if the source was an aldor +> or spad file and behaves differently. So if you distributed the old +> database, it does not work. Did not work for me either ;-). +> + +yaknow i wrote that code. sure wish i'd have commented it. sigh. +at least i get to re-document it. poetic justice, eh? :-) + +\start +Date: Sun, 31 Aug 2003 11:07:49 +0200 +From: "Weiss, Juergen" +To: "Bill Page" , +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] Aldor files -- was: interval.spad INTRVL + +> This reminds me to ask about the other ALDOR files that are +> included in the build but apparently not compiled. Are you +> planning that these will at some point be compiled by ALDOR? +> (which is now a separate non-BSD licensed? package) How +> difficult is it for a user to encorporate ALDOR if they so +> wished? There would likely be a considerable speed and memory +> advantage for certain routines. Right? + +The ALDOR files besides interval.spad seem to be interesting +only to users of the link to the NAG mathematical library. At +least there are no SPAD files, which depend on them. + +ALDOR was able to genereate LISP or C code. I don't know if this +is still the case. You could load the LISP code into AXIOM. +This should still be possible, though probably untested. I would not +expect any performance difference. + +I was never directly connected to the AXIOM project, but from +hearsay I concluded, that at the beginning of the '90s, +there was an old algebra compiler (the compiler which is still +used) and a new one, which was buggy, largely undocumented +and kind of unfixable. Stephen Watt and Knut Wolf and maybe +others started to write a new algebra compiler from scatch +in C -- ALDOR. The ALDOR compiler has slightly different +syntax and semantic. I think the algebra (SPAD) files where never +ported to the ALDOR compiler. + +> Another thing that has happened since Aldor separated from +> Axiom is that a very large part of the algegbra has been +> re-written and apparently improved. Do you think that in +> the medium to long term the Axiom and Aldor algebra libraries +> should be made compatible? How practical (and legal?) would +> it be for Axiom (at least as a option) to implement the +> same library. Is it difficult to convert to spad. Or is +> there any advantage if ALDOR can be easily linked with +> Axiom? + +Manuel Bronstein, at that time a main contributor to the +algebra (integration, ODE) told me once, that he prefered +a noninteractive system for the implementation +of his algorithms. So I think he adopted ALDOR and +developped quite a bit of algebra in that language. I never +had a look at the algebra, which is available for ALDOR. +So I do not really know of which parts of mathematics +it consists and who contributed them. + +At that time the machines where much slower and since then +there were some optimizations in AXIOM as well. So the +development cycle of algebra code on AXIOM was quite time +consuming. The old compiler has its weaknesses too -- +this was the reason the write the new compiler and the +ALDOR compiler in the first place. + +I think the compiler history is kind of symptomatic of +AXIOM as a whole. We have two parsers, the old one +still used with the old compiler, and a new one now +used for the interpreter with some extended features +(parsing of rules for example). And I think this is +similar in other parts of the system. + +After some history we should have a look at the future. +In which direction are we going? + +A few thoughts: + +Though the system should be open (that is modular) so that +it allows the addition or the replacement of parts by developpers +who want AXIOM as a testbed for new ideas, the core +system should contain only one parser, one compiler etc... +Having everything at least twice increases comlexity beyond +the point where we are able to manage the sources. + +There are parts of the AXIOM interpreter (graphics, hypertext, etc) +which I would consider optional components. The core system +should run on any common lisp system without any additional +functionality which is now provided by C code. For example +the core system does not need xdr functions. This would make +initial porting to for example Windows much easier. + +\start +Date: Sun, 31 Aug 2003 11:49:42 +0200 +From: "Weiss, Juergen" +To: "Weiss, Juergen" , "Bill Page" , +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] Aldor files -- was: interval.spad INTRVL + +> A few thoughts: +> +> Though the system should be open (that is modular) so that +> it allows the addition or the replacement of parts by developpers +> who want AXIOM as a testbed for new ideas, the core +> system should contain only one parser, one compiler etc... +> Having everything at least twice increases comlexity beyond +> the point where we are able to manage the sources. +> +> There are parts of the AXIOM interpreter (graphics, hypertext, etc) +> which I would consider optional components. The core system +> should run on any common lisp system without any additional +> functionality which is now provided by C code. For example +> the core system does not need xdr functions. This would make +> initial porting to for example Windows much easier. + +Some other thoughts: + +Axiom is written in boot and lisp. The original lisp seems +to be a lisp on an IBM mainframe. There is a glue layer for +common lisp -- sometimes only renaming functions. Where do +we go from here? Use common lisp as the lisp language and elimiate +most of the glue? Write in common lisp or in boot? It seems +that some more recent files have been written in common lisp. + +\start +Date: 31 Aug 2003 08:35:30 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] INTCAT INTRVL and SIGNEH + +Tim, + +Overnight I set my computer to re-build Axiom from the +Thursday sources modified to include the INTRVL and +SIGNEH but overwriting the databases in src/share/algebra +with the same files from Juergin Weiss' version. I was +pleasantly surprized this morning that it completed without +errors and successfully evaluates + + integrate(exp(sin(x)),x) + +SO ... I would definitely conclude that there is something +wrong with the databases in the share directory of the +Thursay version. It seems likely that this is the cause +of many of the problems you have seen. + +Now I don't know exactly what magic Juergen included in +his version of the database files, but a diff shows that +they are very different than the ones in share. I did +find however to have a completely functional version +I still had to run database rebuild. I tried first without +doing that by just setting DAASE to the share directory. +But some things fails, e.g. certain commands did not +produce any output such as the test integration above. +After running the database rebuild and unset DAASE, this +work properly. + +Perhaps it would be sufficient to replace the contents +of src/share/algebra with the result of the database +rebuild and then re-compile Axiom? Or perhaps Juergen +can explain in more detail to us his database rebuild +procedure. + +By the way, not counting any of the lowercase.spad files, +Juergen's version has 1040 spad files while the Thursday +version with INTRVL and SIGNEH has only 1011. Here are +the differences + ++ASP29.spad ++CPIMA.spad ++D01AGNT.spad +-DHMATRIX.spad ++FSPRMELT.spad ++INBFF.spad ++IRURPK.spad ++LAZM3PK.spad ++LEXTRIPK.spad ++LODO.spad ++LODO1.spad ++LODO2.spad ++NORMPK.spad ++NTSCAT.spad ++ODEEF.spad ++QCMPACK.spad ++REGSET.spad ++RGCHAIN.spad ++RSDCMPK.spad ++RSETGCD.spad ++RURPK.spad ++SFQCMPK.spad ++SFRGCD.spad ++SFRTCAT.spad ++SNTSCAT.spad ++SOLVETRA.spad ++SRDCMPK.spad ++SREGSET.spad ++STTF.spad ++SUBSPACE.spad ++ZDSOLVE.spad + +where + means the file is missing from the Thursday version +and - means missing from Juergen's version. + +Are there really 29 files which are not yet compiled or does +Juergen's list include some that are obsolete? + +\start +Date: 31 Aug 2003 10:30:52 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] No lower case files patch + +Tim, + +I have attached to this message a patch to modify + + src/algebra/Makefile.pamphlet + +which removes the lowercase.spad files and adds COMBF, +INTRV and SIGNEH. It was a lot of work to take the +lowercase stuff out so I am passing this on to you +although I know that you might still find the lowercase +files useful and so may choose not to use this patch. + +For the things that I am doing with the dependency graph, +the lower case files tend to get in the way since they +duplicate all of the algebra code. Of course there are +other things that I could use to avoid these files instead +of not generating them, e.g. a grep filter etc. So I can +cope... . + +\start +Date: Sun, 31 Aug 2003 13:41:55 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: Re: [Axiom-developer] INTCAT INTRVL and SIGNEH + +Bill, + +Use cvs to check in your .daase files over the files that exist in +src/share/algebra. + +\start +Date: Sun, 31 Aug 2003 19:59:33 +0200 +From: "Weiss, Juergen" +To: "Bill Page" , +Cc: axiom-developer@nongnu.org +Subject: RE: [Axiom-developer] INTCAT INTRVL and SIGNEH + +Actually there was no magic involved. If you have +let's say module A and B where B depends on A and +the database entries of A and B are wrong, just +compile A and B in the same AXIOM process and +rebuild the database afterwards. That's all. Of +course you could rebuild the database after +every file compiled, but that would take too long. +Information about loaded modules has precedence +over information in the databases. + +The structure of pamphlet file for DHMATRIX is +different from the rest, so the instructions to +generate some parts of the Makefile automatically +did not generate anything. + +> -----Original Message----- +> From: Bill Page [mailto:bill.page1@sympatico.ca] +> Sent: Sunday, August 31, 2003 2:36 PM +> To: daly@idsi.net +> Cc: axiom-developer@nongnu.org +> Subject: [Axiom-developer] INTCAT INTRVL and SIGNEH +> +> +> Tim, +> +> Overnight I set my computer to re-build Axiom from the +> Thursday sources modified to include the INTRVL and +> SIGNEH but overwriting the databases in src/share/algebra +> with the same files from Juergin Weiss' version. I was +> pleasantly surprized this morning that it completed without +> errors and successfully evaluates +> +> integrate(exp(sin(x)),x) +> +> SO ... I would definitely conclude that there is something +> wrong with the databases in the share directory of the +> Thursay version. It seems likely that this is the cause +> of many of the problems you have seen. +> +> Now I don't know exactly what magic Juergen included in +> his version of the database files, but a diff shows that +> they are very different than the ones in share. I did +> find however to have a completely functional version +> I still had to run database rebuild. I tried first without +> doing that by just setting DAASE to the share directory. +> But some things fails, e.g. certain commands did not +> produce any output such as the test integration above. +> After running the database rebuild and unset DAASE, this +> work properly. +> +> Perhaps it would be sufficient to replace the contents +> of src/share/algebra with the result of the database +> rebuild and then re-compile Axiom? Or perhaps Juergen +> can explain in more detail to us his database rebuild +> procedure. +> +> By the way, not counting any of the lowercase.spad files, +> Juergen's version has 1040 spad files while the Thursday +> version with INTRVL and SIGNEH has only 1011. Here are +> the differences +> +> +ASP29.spad +> +CPIMA.spad +> +D01AGNT.spad +> -DHMATRIX.spad +> +FSPRMELT.spad +> +INBFF.spad +> +IRURPK.spad +> +LAZM3PK.spad +> +LEXTRIPK.spad +> +LODO.spad +> +LODO1.spad +> +LODO2.spad +> +NORMPK.spad +> +NTSCAT.spad +> +ODEEF.spad +> +QCMPACK.spad +> +REGSET.spad +> +RGCHAIN.spad +> +RSDCMPK.spad +> +RSETGCD.spad +> +RURPK.spad +> +SFQCMPK.spad +> +SFRGCD.spad +> +SFRTCAT.spad +> +SNTSCAT.spad +> +SOLVETRA.spad +> +SRDCMPK.spad +> +SREGSET.spad +> +STTF.spad +> +SUBSPACE.spad +> +ZDSOLVE.spad +> +> where + means the file is missing from the Thursday version +> and - means missing from Juergen's version. +> +> Are there really 29 files which are not yet compiled or does +> Juergen's list include some that are obsolete? + +\start +Date: Sun, 31 Aug 2003 15:55:34 -0400 +From: root +To: weiss@uni-mainz.de +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Axiom Language and History tidbits. + +Juergen, + +Yes, Axiom is written in boot and common lisp. I wrote most, if not all, +of the common lisp. I found the boot syntax (which is basically lisp +except that parens are replaced by indentation) was impossible for me +to use. However other people on the project hate parens. It was a +religious difference that never got solved. + +Boot has some nice features. It was basically Python before Python existed. +The key flaw in Boot (and Python) is that programs are not data. That is, +(print (eval (read "sourcefile"))) is broken. And there is no documentation +as it is a perfectly obvious language (sarcasm optional). + +But, being a religious debate, the issue can never be resolved. If +I'm not mistaken (but memory fails) Bill Burge added a "feature" to +boot to allow "nopile" (indented code was called "piled" code). that +relied on syntax rather than spaces. It caused quite a stir about like +having the Pope decide to require all catholic females to wear a burka. +(Or Lisp programmers to code in Boot, which is far worse :-) ) + +There is a third language used in the system called Meta. (Which is why +meta.tar exists in zips). This code is not part of the bootstrap but +needs to be at some point. Changing the meta parser (see metameta.lisp, +fnewmeta.lisp, and metalex.lisp) would surely cause havoc. In the +distributed system I replaced the Meta code with common lisp. + +There is a fourth language called CHARYBDIS used in the printing subsystem. +This was a project at MIT around the time that IBM was working on MODLisp. +I'm not sure how they got co-mingled but I believe Dave Barton and Joel +Moses (MIT) worked with Dick Jenks, Jim Griesmer, and Fred Blair (IBM). + +There is a fifth unnamed language, a psuedo-tex-html language (see +src/share/doc/hypertex/pages/util.ht) that is used by the hypertex +system (which is a browser before browser existed). You can see this +language stick up into the world in the comments section of the algebra +files. Notice the \axiom{}. That's the TeX-used-as-HTML language. +Scott Morrison invented this language to drive Hypertex, also his work. + +In fact, if you do ")set output script on " you'll find support for +IBM's internal TeX-like language called Script. Technical papers +were written in Script before Knuth's TeX caught on. This isn't a +new language within the system but it is another language that is still +supported by the system. )set output fortran also works. + +There is a sixth language, called spad, which is used to implement the +.spad algebra files. There were several spad languages. Each time we +redesigned the language we renamed the old language "old spad". We were +talking about old-old-old-spad at one point in the project. These +languages are now dead but you can still find code to support them +Look for "old" and "new" in the sources. Bill Burge, our parser guy, +used "old" and "new" as the spad and boot languages evolved. It caused +no confusion in any given week but caused massive confusion in the code. + +You can still see the confusion. Build Axiom then rebuild Axiom. + +(digression: I have a second-build function-calling optimizer that +Bill Schelter and I worked on. We needed to make function calling +faster. There isn't enough information on the first compile. So if you +look in src/interp/util.lisp in the function make-depsys you'll see +the load of "/cmpnew/collectfn". This is code Schelter and I worked +on. When you compile a lisp file for the first time (say foo.lisp) it +spits out a file (foo.fn). If foo.fn exists and you recompile the +foo.lisp file it will optimize the function calling code (fast-pathing +the code) since it has "perfect information" about how many arguments +and what type the arguments are. This is a significant improvement. +So Axiom is much faster after the second build. I have to automate this +in the build but haven't yet. It works if you hand-build Axiom twice). + +On the second build of Axiom the function-optimizer has the .fn files. +It will complain that duplicate code exists. The reason for this duplicate +code is that some of it is "old^N" code (where N is ambiguous) and the +duplicate code is "layered" on top of the old code. I have to go thru +the system and decide which code is correct and elide the "old" code. +I have marked all of the duplicates in the sources (look for "---->") +but stopped that effort in order to get the code uploaded. + +In any case this is an example of the "confusion" as we frequently +needed to run "old" BOOT and spad code until I rewrote it into the +"new" BOOT and spad code. Shortly before Axiom was given to NAG I +spent several weeks rewriting all of the algebra files into the +"new" A# (AxiomXL, Aldor) compatible language so that the spad compiler +and the Aldor compiler used the same language. + +There is a seventh language, originally A#, then AxiomXL, now Aldor +which is a minor variant of spad. It allows the use of { } pairs +instead of indentation making it a philosophical cross between the +lisp and boot religions. (Bill Burge's "nopile" option exists in Aldor). +(It also uses ";" which is an abmonination but that might be a religious +opinion :-) ) + +There is an 8th language called SHOE (search for SHOE) which was a +replacement for BOOT. Bill Burge liked puns. SHOE was a "more refined" +BOOT. BOOT was a bootstrap language written in BOOT. Once Burge got +a language "in the air" he was quite fond of losing the scaffolding +that got it there. As a consequence BOOT and spad could not be built +from scratch and required a running BOOT and spad compiler. This is +fixed in the released version. This fix took the bulk of the last +8 months which is why it took so long to deliver an open-source +version of a product (NAG already had a running Axiom and didn't need +to build from scratch but I'm not allowed to distribute a runnable +Axiom so I had to fix this fundamental problem). The fix is horrible +and I'll rewrite it all from scratch eventually. However if you had +to wait for me to "clean up" all the issues you'd have to wait a +few years. Release early, release often is going to be my mantra. + +There are even languages within languages. If you look at the common +lisp you'll find such things as (from g-opt.boot.pamphlet): +EVALANDFILEACTQ which is VMLisp/370 (nee LispVM, nee Lisp/360) +a product of Fred Blair, Cyril Alberga, and Mark Wegman (which, by +the way I need to add to the kudos list since Fred, Cyril, and Mark +were heavily consulted during the translation from VMLisp). Most of +the MACLisp and VMLisp rewrites are in vmlisp.spad.pamphlet. + +Looking even deeper into the common lisp you'll find MODLisp, which +was an effort by Dick Jenks, Dave Barton, and a few others. Bits of +it still survive. It predated and fathered Scratchpad/Scratchpad II. + +And there are even MACLisp primitives still around like subrp (see +src/interp/vmlisp.lisp.pamphlet). + +I rewrote large portions of old code trying hard to eliminate these +old languages but found that the newer languages didn't have a name +for all of the old concepts (e.g. EVALANDFILEACTQ) or the new name +didn't match the meaning of the old name (e.g. subrp vs compiled-function-p) +exactly so I had to write cover macros/functions. Over time I eliminated +the semantic differences and some of the cover functions/macros are now +simply renames (e.g. subrp is now just a rename and should be removed). +We sold Axiom before I could completely clean up the system. Now I get +a second chance (of course I wish the filmy bastard (i.e. me) had DOCUMENTED +some of this code :-( ) + +When dealing with languages it is very hard to do a rewrite. Usually the +original programmer was an expert in his language (e.g. MACLisp) and the +rewrite-programmer is not. When the rewrite happens subtle things break. +My special talent on the project was deep expertise in anything lispish +as I worked in MACLisp, VMLisp, Common Lisp, SpiceLisp ZetaLisp, PSL, +Scheme, Standard Lisp, NIL, and my own implementation (living quietly +under code that runs IBM's and Unimation's industrial robots) and every +other variant that I could find. I even have a lisp implemented in fortran. +Thus you will hear me say (and not realize the religious nature of the +comment) that "Axiom is just Lisp". + +Clearly there is much more to do. + +Anyway, this history lesson is brought to you by the letters Alpha and +Omega, and the numbers pi and e. + +Tim, the wizard (from Monty Python) + +\start +Date: Sun, 31 Aug 2003 22:55:16 -0400 +From: root +To: bill.page1@sympatico.ca +Cc: axiom-developer@nongnu.org, daly@idsi.net +Subject: [Axiom-developer] Re: No lower case files patch + +Thanks for the patch file. +Did you get a chance to CVS the *.daase files? + +\start +Date: 31 Aug 2003 22:37:07 -0400 +From: Bill Page +To: daly@idsi.net +Cc: axiom-developer@nongnu.org +Subject: [Axiom-developer] Re: No lower case files patch + +--=-60OPaxFfLcp8qTKvunBC +Content-Type: text/plain +Content-Transfer-Encoding: 7bit + +Oops. Here's the file. + +--=-60OPaxFfLcp8qTKvunBC +Content-Disposition: attachment; filename=nolowercase.patch +Content-Type: text/plain; name=nolowercase.patch; charset=UTF-8 +Content-Transfer-Encoding: 7bit + +--- axiom/src/algebra/Makefile.pamphlet 2003-08-30 15:21:16.000000000 -0400 ++++ axiom2/src/algebra/Makefile.pamphlet 2003-08-31 10:12:23.000000000 -0400 +@@ -9,6 +9,13 @@ + \eject + \tableofcontents + \eject ++\section{Change Notes} ++August 31, 2003 Bill Page ++\begin{enumerate} ++\item removed lowercase.spad files ++\item added COMBF, INTRVL and SIGNEH ++\item removed note about INTRVL compile problem ++\end{enumerate} + \section{Adding new algebra} + This is a complex process by its very nature. Developers and Maintainers + who undertake the process need to understand quite a lot of detail. The +@@ -480,6 +487,7 @@ + <>= + LAYER12=\ + ${OUT}/BITS.o ${OUT}/DIRPROD2.o ${OUT}/IMATRIX.o ${OUT}/IVECTOR.o \ ++ ${OUT}/INTRVL.o \ + ${OUT}/LPOLY.o ${OUT}/LSMP.o ${OUT}/LSMP1.o ${OUT}/MATCAT2.o \ + ${OUT}/PTCAT.o ${OUT}/STRICAT.o ${OUT}/TRIMAT.o + +@@ -965,7 +973,8 @@ + ${OUT}/PMPREDFS.o ${OUT}/PRIMELT.o ${OUT}/PSETPK.o ${OUT}/QUAT.o \ + ${OUT}/QUATCT2.o ${OUT}/RADFF.o ${OUT}/RDEEF.o ${OUT}/RDEEFS.o \ + ${OUT}/RDIV.o ${OUT}/RSETCAT.o ${OUT}/RSETCAT-.o ${OUT}/RULE.o \ +- ${OUT}/RULESET.o ${OUT}/SIMPAN.o ${OUT}/SFORT.o ${OUT}/SOLVESER.o \ ++ ${OUT}/RULESET.o ${OUT}/SIGNEF.o \ ++ ${OUT}/SIMPAN.o ${OUT}/SFORT.o ${OUT}/SOLVESER.o \ + ${OUT}/SUMFS.o ${OUT}/SUTS.o ${OUT}/TOOLSIGN.o ${OUT}/TRIGMNIP.o \ + ${OUT}/TRMANIP.o ${OUT}/ULSCCAT.o ${OUT}/ULSCCAT-.o ${OUT}/UPXSSING.o \ + ${OUT}/UTSODE.o ${OUT}/UTSODETL.o ${OUT}/UTS2.o ${OUT}/WUTSET.o +@@ -1004,6 +1013,7 @@ + + <>= + LAYER21=\ ++ ${OUT}/COMBF.o \ + ${OUT}/DEFINTEF.o ${OUT}/DFINTTLS.o ${OUT}/DEFINTRF.o ${OUT}/D01TRNS.o \ + ${OUT}/EFULS.o ${OUT}/ESCONT.o ${OUT}/EXPR.o ${OUT}/EXPR2UPS.o \ + ${OUT}/FDIV.o ${OUT}/FSCINT.o ${OUT}/FSINT.o ${OUT}/FS2EXPXP.o \ +@@ -1030,7 +1040,6 @@ + These files need to be added. + \begin{verbatim} + +-limitps SIGNEF + primelt FSPRMELT + nsregset LAZM3PK + nregset NORMPK +@@ -1048,7 +1057,6 @@ + nregset NTSCAT + sregset SFRTCAT + algcat CPIMA +-combfunc COMBF + ffnb INBFF + lodo LODO + lodo LODO1 +@@ -1085,12 +1093,7 @@ + + These files won't compile yet + \begin{verbatim} +-${OUT}/INTRVL.o (from layer 12) +- cannot produce category object: +- (|IntervalCategory| R) +- finalizing NRLIB INTRVL +- Internal Error +- Unexpected error in call to system function getSlotFromFunctor ++ + \end{verbatim} + + \section{The Environment} +@@ -1186,7 +1189,7 @@ + ${MID}/ideal.spad ${MID}/idecomp.spad ${MID}/indexedp.spad \ + ${MID}/infprod.spad ${MID}/intaf.spad ${MID}/intalg.spad \ + ${MID}/intaux.spad ${MID}/intclos.spad ${MID}/intef.spad \ +- ${MID}/integer.spad ${MID}/integrat.spad ${MID}/INTERP.EXPOSED \ ++ ${MID}/integer.spad ${MID}/integrat.spad \ + ${MID}/interval.spad \ + ${MID}/intfact.spad ${MID}/intpm.spad \ + ${MID}/intrf.spad \ +@@ -1580,13 +1583,6 @@ + + + \subsection{acplot.spad \cite{1}} +-<>= +-${MID}/acplot.spad: ${IN}/acplot.spad.pamphlet +- @ echo 0 making ${MID}/acplot.spad from ${IN}/acplot.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/acplot.spad.pamphlet >acplot.spad ) +- +-@ + <>= + ${OUT}/ACPLOT.o: ${MID}/ACPLOT.NRLIB + @ echo 0 making ${OUT}/ACPLOT.o from ${MID}/ACPLOT.NRLIB +@@ -1639,13 +1635,6 @@ + + @ + \subsection{aggcat2.spad \cite{1}} +-<>= +-${MID}/aggcat2.spad: ${IN}/aggcat2.spad.pamphlet +- @ echo 0 making ${MID}/aggcat2.spad from ${IN}/aggcat2.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/aggcat2.spad.pamphlet >aggcat2.spad ) +- +-@ + <>= + ${OUT}/FLAGG2.o: ${MID}/FLAGG2.NRLIB + @ echo 0 making ${OUT}/FLAGG2.o from ${MID}/FLAGG2.NRLIB +@@ -1698,13 +1687,6 @@ + + @ + \subsection{aggcat.spad \cite{1}} +-<>= +-${MID}/aggcat.spad: ${IN}/aggcat.spad.pamphlet +- @ echo 0 making ${MID}/aggcat.spad from ${IN}/aggcat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/aggcat.spad.pamphlet >aggcat.spad ) +- +-@ + <>= + ${OUT}/ALAGG.o: ${MID}/ALAGG.NRLIB + @ echo 0 making ${OUT}/ALAGG.o from ${MID}/ALAGG.NRLIB +@@ -2942,13 +2924,6 @@ + + @ + \subsection{algcat.spad \cite{1}} +-<>= +-${MID}/algcat.spad: ${IN}/algcat.spad.pamphlet +- @ echo 0 making ${MID}/algcat.spad from ${IN}/algcat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/algcat.spad.pamphlet >algcat.spad ) +- +-@ + <>= + ${OUT}/CPIMA.o: ${MID}/CPIMA.NRLIB + @ echo 0 making ${OUT}/CPIMA.o from ${MID}/CPIMA.NRLIB +@@ -3097,13 +3072,6 @@ + + @ + \subsection{algext.spad \cite{1}} +-<>= +-${MID}/algext.spad: ${IN}/algext.spad.pamphlet +- @ echo 0 making ${MID}/algext.spad from ${IN}/algext.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/algext.spad.pamphlet >algext.spad ) +- +-@ + <>= + ${OUT}/SAE.o: ${MID}/SAE.NRLIB + @ echo 0 making ${OUT}/SAE.o from ${MID}/SAE.NRLIB +@@ -3136,13 +3104,6 @@ + + @ + \subsection{algfact.spad \cite{1}} +-<>= +-${MID}/algfact.spad: ${IN}/algfact.spad.pamphlet +- @ echo 0 making ${MID}/algfact.spad from ${IN}/algfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/algfact.spad.pamphlet >algfact.spad ) +- +-@ + <>= + ${OUT}/ALGFACT.o: ${MID}/ALGFACT.NRLIB + @ echo 0 making ${OUT}/ALGFACT.o from ${MID}/ALGFACT.NRLIB +@@ -3255,13 +3216,6 @@ + + @ + \subsection{algfunc.spad \cite{1}} +-<>= +-${MID}/algfunc.spad: ${IN}/algfunc.spad.pamphlet +- @ echo 0 making ${MID}/algfunc.spad from ${IN}/algfunc.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/algfunc.spad.pamphlet >algfunc.spad ) +- +-@ + <>= + ${OUT}/ACF-.o: ${MID}/ACF.NRLIB + @ echo 0 making ${OUT}/ACF-.o from ${MID}/ACF-.NRLIB +@@ -3358,13 +3312,6 @@ + + @ + \subsection{allfact.spad \cite{1}} +-<>= +-${MID}/allfact.spad: ${IN}/allfact.spad.pamphlet +- @ echo 0 making ${MID}/allfact.spad from ${IN}/allfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/allfact.spad.pamphlet >allfact.spad ) +- +-@ + <>= + ${OUT}/GENMFACT.o: ${MID}/GENMFACT.NRLIB + @ echo 0 making ${OUT}/GENMFACT.o from ${MID}/GENMFACT.NRLIB +@@ -3497,13 +3444,6 @@ + + @ + \subsection{alql.spad \cite{1}} +-<>= +-${MID}/alql.spad: ${IN}/alql.spad.pamphlet +- @ echo 0 making ${MID}/alql.spad from ${IN}/alql.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/alql.spad.pamphlet >alql.spad ) +- +-@ + <>= + ${OUT}/DBASE.o: ${MID}/DBASE.NRLIB + @ echo 0 making ${OUT}/DBASE.o from ${MID}/DBASE.NRLIB +@@ -3636,13 +3576,6 @@ + + @ + \subsection{annacat.spad \cite{1}} +-<>= +-${MID}/annacat.spad: ${IN}/annacat.spad.pamphlet +- @ echo 0 making ${MID}/annacat.spad from ${IN}/annacat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/annacat.spad.pamphlet >annacat.spad ) +- +-@ + <>= + ${OUT}/NIPROB.o: ${MID}/NIPROB.NRLIB + @ echo 0 making ${OUT}/NIPROB.o from ${MID}/NIPROB.NRLIB +@@ -3815,13 +3748,6 @@ + + @ + \subsection{any.spad \cite{1}} +-<>= +-${MID}/any.spad: ${IN}/any.spad.pamphlet +- @ echo 0 making ${MID}/any.spad from ${IN}/any.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/any.spad.pamphlet >any.spad ) +- +-@ + <>= + ${OUT}/ANY.o: ${MID}/ANY.NRLIB + @ echo 0 making ${OUT}/ANY.o from ${MID}/ANY.NRLIB +@@ -3914,13 +3840,6 @@ + + @ + \subsection{array1.spad \cite{1}} +-<>= +-${MID}/array1.spad: ${IN}/array1.spad.pamphlet +- @ echo 0 making ${MID}/array1.spad from ${IN}/array1.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/array1.spad.pamphlet >array1.spad ) +- +-@ + <>= + ${OUT}/ARRAY1.o: ${MID}/ARRAY1.NRLIB + @ echo 0 making ${OUT}/ARRAY1.o from ${MID}/ARRAY1.NRLIB +@@ -4110,13 +4029,6 @@ + + @ + \subsection{array2.spad \cite{1}} +-<>= +-${MID}/array2.spad: ${IN}/array2.spad.pamphlet +- @ echo 0 making ${MID}/array2.spad from ${IN}/array2.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/array2.spad.pamphlet >array2.spad ) +- +-@ + <>= + ${OUT}/ARRAY2.o: ${MID}/ARRAY2.NRLIB + @ echo 0 making ${OUT}/ARRAY2.o from ${MID}/ARRAY2.NRLIB +@@ -4221,13 +4133,6 @@ + + @ + \subsection{asp.spad \cite{1}} +-<>= +-${MID}/asp.spad: ${IN}/asp.spad.pamphlet +- @ echo 0 making ${MID}/asp.spad from ${IN}/asp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/asp.spad.pamphlet >asp.spad ) +- +-@ + <>= + ${OUT}/ASP1.o: ${MID}/ASP1.NRLIB + @ echo 0 making ${OUT}/ASP1.o from ${MID}/ASP1.NRLIB +@@ -4820,13 +4725,6 @@ + + @ + \subsection{attreg.spad \cite{1}} +-<>= +-${MID}/attreg.spad: ${IN}/attreg.spad.pamphlet +- @ echo 0 making ${MID}/attreg.spad from ${IN}/attreg.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/attreg.spad.pamphlet >attreg.spad ) +- +-@ + <>= + ${OUT}/ATTREG.o: ${MID}/ATTREG.NRLIB + @ echo 0 making ${OUT}/ATTREG.o from ${MID}/ATTREG.NRLIB +@@ -4866,6 +4764,7 @@ + ${SPADBIN}/notangle ${IN}/axtimer.as.pamphlet >axtimer.as ) + + @ ++ + <>= + ${DOC}/axtimer.as.dvi: ${IN}/axtimer.as.pamphlet + @ echo 0 making ${DOC}/axtimer.as.dvi from ${IN}/axtimer.as.pamphlet +@@ -4878,13 +4777,6 @@ + + @ + \subsection{bags.spad \cite{1}} +-<>= +-${MID}/bags.spad: ${IN}/bags.spad.pamphlet +- @ echo 0 making ${MID}/bags.spad from ${IN}/bags.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/bags.spad.pamphlet >bags.spad ) +- +-@ + <>= + ${OUT}/ASTACK.o: ${MID}/ASTACK.NRLIB + @ echo 0 making ${OUT}/ASTACK.o from ${MID}/ASTACK.NRLIB +@@ -4997,13 +4889,6 @@ + + @ + \subsection{bezout.spad \cite{1}} +-<>= +-${MID}/bezout.spad: ${IN}/bezout.spad.pamphlet +- @ echo 0 making ${MID}/bezout.spad from ${IN}/bezout.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/bezout.spad.pamphlet >bezout.spad ) +- +-@ + <>= + ${OUT}/BEZOUT.o: ${MID}/BEZOUT.NRLIB + @ echo 0 making ${OUT}/BEZOUT.o from ${MID}/BEZOUT.NRLIB +@@ -5036,13 +4921,6 @@ + + @ + \subsection{boolean.spad \cite{1}} +-<>= +-${MID}/boolean.spad: ${IN}/boolean.spad.pamphlet +- @ echo 0 making ${MID}/boolean.spad from ${IN}/boolean.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/boolean.spad.pamphlet >boolean.spad ) +- +-@ + <>= + ${OUT}/BITS.o: ${MID}/BITS.NRLIB + @ echo 0 making ${OUT}/BITS.o from ${MID}/BITS.NRLIB +@@ -5201,13 +5079,6 @@ + + @ + \subsection{brill.spad \cite{1}} +-<>= +-${MID}/brill.spad: ${IN}/brill.spad.pamphlet +- @ echo 0 making ${MID}/brill.spad from ${IN}/brill.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/brill.spad.pamphlet >brill.spad ) +- +-@ + <>= + ${OUT}/BRILL.o: ${MID}/BRILL.NRLIB + @ echo 0 making ${OUT}/BRILL.o from ${MID}/BRILL.NRLIB +@@ -5240,13 +5111,6 @@ + + @ + \subsection{c02.spad \cite{1}} +-<>= +-${MID}/c02.spad: ${IN}/c02.spad.pamphlet +- @ echo 0 making ${MID}/c02.spad from ${IN}/c02.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/c02.spad.pamphlet >c02.spad ) +- +-@ + <>= + ${OUT}/NAGC02.o: ${MID}/NAGC02.NRLIB + @ echo 0 making ${OUT}/NAGC02.o from ${MID}/NAGC02.NRLIB +@@ -5279,13 +5143,6 @@ + + @ + \subsection{c05.spad \cite{1}} +-<>= +-${MID}/c05.spad: ${IN}/c05.spad.pamphlet +- @ echo 0 making ${MID}/c05.spad from ${IN}/c05.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/c05.spad.pamphlet >c05.spad ) +- +-@ + <>= + ${OUT}/NAGC05.o: ${MID}/NAGC05.NRLIB + @ echo 0 making ${OUT}/NAGC05.o from ${MID}/NAGC05.NRLIB +@@ -5318,13 +5175,6 @@ + + @ + \subsection{c06.spad \cite{1}} +-<>= +-${MID}/c06.spad: ${IN}/c06.spad.pamphlet +- @ echo 0 making ${MID}/c06.spad from ${IN}/c06.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/c06.spad.pamphlet >c06.spad ) +- +-@ + <>= + ${OUT}/NAGC06.o: ${MID}/NAGC06.NRLIB + @ echo 0 making ${OUT}/NAGC06.o from ${MID}/NAGC06.NRLIB +@@ -5357,13 +5207,6 @@ + + @ + \subsection{card.spad \cite{1}} +-<>= +-${MID}/card.spad: ${IN}/card.spad.pamphlet +- @ echo 0 making ${MID}/card.spad from ${IN}/card.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/card.spad.pamphlet >card.spad ) +- +-@ + <>= + ${OUT}/CARD.o: ${MID}/CARD.NRLIB + @ echo 0 making ${OUT}/CARD.o from ${MID}/CARD.NRLIB +@@ -5396,13 +5239,6 @@ + + @ + \subsection{carten.spad \cite{1}} +-<>= +-${MID}/carten.spad: ${IN}/carten.spad.pamphlet +- @ echo 0 making ${MID}/carten.spad from ${IN}/carten.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/carten.spad.pamphlet >carten.spad ) +- +-@ + <>= + ${OUT}/CARTEN.o: ${MID}/CARTEN.NRLIB + @ echo 0 making ${OUT}/CARTEN.o from ${MID}/CARTEN.NRLIB +@@ -5519,13 +5355,6 @@ + + @ + \subsection{catdef.spad \cite{1}} +-<>= +-${MID}/catdef.spad: ${IN}/catdef.spad.pamphlet +- @ echo 0 making ${MID}/catdef.spad from ${IN}/catdef.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/catdef.spad.pamphlet >catdef.spad ) +- +-@ + <>= + ${OUT}/ABELGRP-.o: ${MID}/ABELGRP.NRLIB + @ echo 0 making ${OUT}/ABELGRP-.o from ${MID}/ABELGRP-.NRLIB +@@ -7285,13 +7114,6 @@ + + @ + \subsection{cden.spad \cite{1}} +-<>= +-${MID}/cden.spad: ${IN}/cden.spad.pamphlet +- @ echo 0 making ${MID}/cden.spad from ${IN}/cden.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/cden.spad.pamphlet >cden.spad ) +- +-@ + <>= + ${OUT}/CDEN.o: ${MID}/CDEN.NRLIB + @ echo 0 making ${OUT}/CDEN.o from ${MID}/CDEN.NRLIB +@@ -7384,13 +7206,6 @@ + + @ + \subsection{clifford.spad \cite{1}} +-<>= +-${MID}/clifford.spad: ${IN}/clifford.spad.pamphlet +- @ echo 0 making ${MID}/clifford.spad from ${IN}/clifford.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/clifford.spad.pamphlet >clifford.spad ) +- +-@ + <>= + ${OUT}/CLIF.o: ${MID}/CLIF.NRLIB + @ echo 0 making ${OUT}/CLIF.o from ${MID}/CLIF.NRLIB +@@ -7443,13 +7258,6 @@ + + @ + \subsection{clip.spad \cite{1}} +-<>= +-${MID}/clip.spad: ${IN}/clip.spad.pamphlet +- @ echo 0 making ${MID}/clip.spad from ${IN}/clip.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/clip.spad.pamphlet >clip.spad ) +- +-@ + <>= + ${OUT}/CLIP.o: ${MID}/CLIP.NRLIB + @ echo 0 making ${OUT}/CLIP.o from ${MID}/CLIP.NRLIB +@@ -7482,13 +7290,6 @@ + + @ + \subsection{cmplxrt.spad \cite{1}} +-<>= +-${MID}/cmplxrt.spad: ${IN}/cmplxrt.spad.pamphlet +- @ echo 0 making ${MID}/cmplxrt.spad from ${IN}/cmplxrt.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/cmplxrt.spad.pamphlet >cmplxrt.spad ) +- +-@ + <>= + ${OUT}/CMPLXRT.o: ${MID}/CMPLXRT.NRLIB + @ echo 0 making ${OUT}/CMPLXRT.o from ${MID}/CMPLXRT.NRLIB +@@ -7522,13 +7323,6 @@ + @ + \subsection{coerce.spad \cite{1}} + Builds KOERCE KONVERT RETRACT- RETRACT TYPE +-<>= +-${MID}/coerce.spad: ${IN}/coerce.spad.pamphlet +- @ echo 0 making ${MID}/coerce.spad from ${IN}/coerce.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/coerce.spad.pamphlet >coerce.spad ) +- +-@ + <>= + ${OUT}/KOERCE.o: ${MID}/KOERCE.NRLIB + @ echo 0 making ${OUT}/KOERCE.o from ${MID}/KOERCE.NRLIB +@@ -7630,13 +7424,6 @@ + + @ + \subsection{color.spad \cite{1}} +-<>= +-${MID}/color.spad: ${IN}/color.spad.pamphlet +- @ echo 0 making ${MID}/color.spad from ${IN}/color.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/color.spad.pamphlet >color.spad ) +- +-@ + <>= + ${OUT}/COLOR.o: ${MID}/COLOR.NRLIB + @ echo 0 making ${OUT}/COLOR.o from ${MID}/COLOR.NRLIB +@@ -7689,13 +7476,6 @@ + + @ + \subsection{combfunc.spad \cite{1}} +-<>= +-${MID}/combfunc.spad: ${IN}/combfunc.spad.pamphlet +- @ echo 0 making ${MID}/combfunc.spad from ${IN}/combfunc.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/combfunc.spad.pamphlet >combfunc.spad ) +- +-@ + <>= + ${OUT}/COMBF.o: ${MID}/COMBF.NRLIB + @ echo 0 making ${OUT}/COMBF.o from ${MID}/COMBF.NRLIB +@@ -7788,13 +7568,6 @@ + + @ + \subsection{combinat.spad \cite{1}} +-<>= +-${MID}/combinat.spad: ${IN}/combinat.spad.pamphlet +- @ echo 0 making ${MID}/combinat.spad from ${IN}/combinat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/combinat.spad.pamphlet >combinat.spad ) +- +-@ + <>= + ${OUT}/COMBINAT.o: ${MID}/COMBINAT.NRLIB + @ echo 0 making ${OUT}/COMBINAT.o from ${MID}/COMBINAT.NRLIB +@@ -7827,13 +7600,6 @@ + + @ + \subsection{complet.spad \cite{1}} +-<>= +-${MID}/complet.spad: ${IN}/complet.spad.pamphlet +- @ echo 0 making ${MID}/complet.spad from ${IN}/complet.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/complet.spad.pamphlet >complet.spad ) +- +-@ + <>= + ${OUT}/INFINITY.o: ${MID}/INFINITY.NRLIB + @ echo 0 making ${OUT}/INFINITY.o from ${MID}/INFINITY.NRLIB +@@ -7946,13 +7712,6 @@ + + @ + \subsection{constant.spad \cite{1}} +-<>= +-${MID}/constant.spad: ${IN}/constant.spad.pamphlet +- @ echo 0 making ${MID}/constant.spad from ${IN}/constant.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/constant.spad.pamphlet >constant.spad ) +- +-@ + <>= + ${OUT}/AN.o: ${MID}/AN.NRLIB + @ echo 0 making ${OUT}/AN.o from ${MID}/AN.NRLIB +@@ -8005,13 +7764,6 @@ + + @ + \subsection{contfrac.spad \cite{1}} +-<>= +-${MID}/contfrac.spad: ${IN}/contfrac.spad.pamphlet +- @ echo 0 making ${MID}/contfrac.spad from ${IN}/contfrac.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/contfrac.spad.pamphlet >contfrac.spad ) +- +-@ + <>= + ${OUT}/CONTFRAC.o: ${MID}/CONTFRAC.NRLIB + @ echo 0 making ${OUT}/CONTFRAC.o from ${MID}/CONTFRAC.NRLIB +@@ -8064,13 +7816,6 @@ + + @ + \subsection{cont.spad \cite{1}} +-<>= +-${MID}/cont.spad: ${IN}/cont.spad.pamphlet +- @ echo 0 making ${MID}/cont.spad from ${IN}/cont.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/cont.spad.pamphlet >cont.spad ) +- +-@ + <>= + ${OUT}/ESCONT.o: ${MID}/ESCONT.NRLIB + @ echo 0 making ${OUT}/ESCONT.o from ${MID}/ESCONT.NRLIB +@@ -8123,13 +7868,6 @@ + + @ + \subsection{coordsys.spad \cite{1}} +-<>= +-${MID}/coordsys.spad: ${IN}/coordsys.spad.pamphlet +- @ echo 0 making ${MID}/coordsys.spad from ${IN}/coordsys.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/coordsys.spad.pamphlet >coordsys.spad ) +- +-@ + <>= + ${OUT}/COORDSYS.o: ${MID}/COORDSYS.NRLIB + @ echo 0 making ${OUT}/COORDSYS.o from ${MID}/COORDSYS.NRLIB +@@ -8162,13 +7900,6 @@ + + @ + \subsection{cra.spad \cite{1}} +-<>= +-${MID}/cra.spad: ${IN}/cra.spad.pamphlet +- @ echo 0 making ${MID}/cra.spad from ${IN}/cra.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/cra.spad.pamphlet >cra.spad ) +- +-@ + <>= + ${OUT}/CRAPACK.o: ${MID}/CRAPACK.NRLIB + @ echo 0 making ${OUT}/CRAPACK.o from ${MID}/CRAPACK.NRLIB +@@ -8201,13 +7932,6 @@ + + @ + \subsection{crfp.spad \cite{1}} +-<>= +-${MID}/crfp.spad: ${IN}/crfp.spad.pamphlet +- @ echo 0 making ${MID}/crfp.spad from ${IN}/crfp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/crfp.spad.pamphlet >crfp.spad ) +- +-@ + <>= + ${OUT}/CRFP.o: ${MID}/CRFP.NRLIB + @ echo 0 making ${OUT}/CRFP.o from ${MID}/CRFP.NRLIB +@@ -8240,13 +7964,6 @@ + + @ + \subsection{curve.spad \cite{1}} +-<>= +-${MID}/curve.spad: ${IN}/curve.spad.pamphlet +- @ echo 0 making ${MID}/curve.spad from ${IN}/curve.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/curve.spad.pamphlet >curve.spad ) +- +-@ + <>= + ${OUT}/ALGFF.o: ${MID}/ALGFF.NRLIB + @ echo 0 making ${OUT}/ALGFF.o from ${MID}/ALGFF.NRLIB +@@ -8391,13 +8108,6 @@ + + @ + \subsection{cycles.spad \cite{1}} +-<>= +-${MID}/cycles.spad: ${IN}/cycles.spad.pamphlet +- @ echo 0 making ${MID}/cycles.spad from ${IN}/cycles.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/cycles.spad.pamphlet >cycles.spad ) +- +-@ + <>= + ${OUT}/CYCLES.o: ${MID}/CYCLES.NRLIB + @ echo 0 making ${OUT}/CYCLES.o from ${MID}/CYCLES.NRLIB +@@ -8450,13 +8160,6 @@ + + @ + \subsection{cyclotom.spad \cite{1}} +-<>= +-${MID}/cyclotom.spad: ${IN}/cyclotom.spad.pamphlet +- @ echo 0 making ${MID}/cyclotom.spad from ${IN}/cyclotom.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/cyclotom.spad.pamphlet >cyclotom.spad ) +- +-@ + <>= + ${OUT}/CYCLOTOM.o: ${MID}/CYCLOTOM.NRLIB + @ echo 0 making ${OUT}/CYCLOTOM.o from ${MID}/CYCLOTOM.NRLIB +@@ -8489,13 +8192,6 @@ + + @ + \subsection{d01agents.spad \cite{1}} +-<>= +-${MID}/d01agents.spad: ${IN}/d01agents.spad.pamphlet +- @ echo 0 making ${MID}/d01agents.spad from ${IN}/d01agents.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d01agents.spad.pamphlet >d01agents.spad ) +- +-@ + <>= + ${OUT}/D01AGNT.o: ${MID}/D01AGNT.NRLIB + @ echo 0 making ${OUT}/D01AGNT.o from ${MID}/D01AGNT.NRLIB +@@ -8548,13 +8244,6 @@ + + @ + \subsection{d01Package.spad \cite{1}} +-<>= +-${MID}/d01Package.spad: ${IN}/d01Package.spad.pamphlet +- @ echo 0 making ${MID}/d01Package.spad from ${IN}/d01Package.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d01Package.spad.pamphlet >d01Package.spad ) +- +-@ + <>= + ${OUT}/INTPACK.o: ${MID}/INTPACK.NRLIB + @ echo 0 making ${OUT}/INTPACK.o from ${MID}/INTPACK.NRLIB +@@ -8587,13 +8276,6 @@ + + @ + \subsection{d01routine.spad \cite{1}} +-<>= +-${MID}/d01routine.spad: ${IN}/d01routine.spad.pamphlet +- @ echo 0 making ${MID}/d01routine.spad from ${IN}/d01routine.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d01routine.spad.pamphlet >d01routine.spad ) +- +-@ + <>= + ${OUT}/D01AJFA.o: ${MID}/D01AJFA.NRLIB + @ echo 0 making ${OUT}/D01AJFA.o from ${MID}/D01AJFA.NRLIB +@@ -8806,13 +8488,6 @@ + + @ + \subsection{d01.spad \cite{1}} +-<>= +-${MID}/d01.spad: ${IN}/d01.spad.pamphlet +- @ echo 0 making ${MID}/d01.spad from ${IN}/d01.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d01.spad.pamphlet >d01.spad ) +- +-@ + <>= + ${OUT}/NAGD01.o: ${MID}/NAGD01.NRLIB + @ echo 0 making ${OUT}/NAGD01.o from ${MID}/NAGD01.NRLIB +@@ -8845,13 +8520,6 @@ + + @ + \subsection{d01transform.spad \cite{1}} +-<>= +-${MID}/d01transform.spad: ${IN}/d01transform.spad.pamphlet +- @ echo 0 making ${MID}/d01transform.spad from ${IN}/d01transform.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d01transform.spad.pamphlet >d01transform.spad ) +- +-@ + <>= + ${OUT}/D01TRNS.o: ${MID}/D01TRNS.NRLIB + @ echo 0 making ${OUT}/D01TRNS.o from ${MID}/D01TRNS.NRLIB +@@ -8884,13 +8552,6 @@ + + @ + \subsection{d01weights.spad \cite{1}} +-<>= +-${MID}/d01weights.spad: ${IN}/d01weights.spad.pamphlet +- @ echo 0 making ${MID}/d01weights.spad from ${IN}/d01weights.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d01weights.spad.pamphlet >d01weights.spad ) +- +-@ + <>= + ${OUT}/D01WGTS.o: ${MID}/D01WGTS.NRLIB + @ echo 0 making ${OUT}/D01WGTS.o from ${MID}/D01WGTS.NRLIB +@@ -8923,13 +8584,6 @@ + + @ + \subsection{d02agents.spad \cite{1}} +-<>= +-${MID}/d02agents.spad: ${IN}/d02agents.spad.pamphlet +- @ echo 0 making ${MID}/d02agents.spad from ${IN}/d02agents.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d02agents.spad.pamphlet >d02agents.spad ) +- +-@ + <>= + ${OUT}/D02AGNT.o: ${MID}/D02AGNT.NRLIB + @ echo 0 making ${OUT}/D02AGNT.o from ${MID}/D02AGNT.NRLIB +@@ -8982,13 +8636,6 @@ + + @ + \subsection{d02Package.spad \cite{1}} +-<>= +-${MID}/d02Package.spad: ${IN}/d02Package.spad.pamphlet +- @ echo 0 making ${MID}/d02Package.spad from ${IN}/d02Package.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d02Package.spad.pamphlet >d02Package.spad ) +- +-@ + <>= + ${OUT}/ODEPACK.o: ${MID}/ODEPACK.NRLIB + @ echo 0 making ${OUT}/ODEPACK.o from ${MID}/ODEPACK.NRLIB +@@ -9021,13 +8668,6 @@ + + @ + \subsection{d02routine.spad \cite{1}} +-<>= +-${MID}/d02routine.spad: ${IN}/d02routine.spad.pamphlet +- @ echo 0 making ${MID}/d02routine.spad from ${IN}/d02routine.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d02routine.spad.pamphlet >d02routine.spad ) +- +-@ + <>= + ${OUT}/D02BBFA.o: ${MID}/D02BBFA.NRLIB + @ echo 0 making ${OUT}/D02BBFA.o from ${MID}/D02BBFA.NRLIB +@@ -9120,13 +8760,6 @@ + + @ + \subsection{d02.spad \cite{1}} +-<>= +-${MID}/d02.spad: ${IN}/d02.spad.pamphlet +- @ echo 0 making ${MID}/d02.spad from ${IN}/d02.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d02.spad.pamphlet >d02.spad ) +- +-@ + <>= + ${OUT}/NAGD02.o: ${MID}/NAGD02.NRLIB + @ echo 0 making ${OUT}/NAGD02.o from ${MID}/NAGD02.NRLIB +@@ -9159,13 +8792,6 @@ + + @ + \subsection{d03agents.spad \cite{1}} +-<>= +-${MID}/d03agents.spad: ${IN}/d03agents.spad.pamphlet +- @ echo 0 making ${MID}/d03agents.spad from ${IN}/d03agents.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d03agents.spad.pamphlet >d03agents.spad ) +- +-@ + <>= + ${OUT}/D03AGNT.o: ${MID}/D03AGNT.NRLIB + @ echo 0 making ${OUT}/D03AGNT.o from ${MID}/D03AGNT.NRLIB +@@ -9198,13 +8824,6 @@ + + @ + \subsection{d03Package.spad \cite{1}} +-<>= +-${MID}/d03Package.spad: ${IN}/d03Package.spad.pamphlet +- @ echo 0 making ${MID}/d03Package.spad from ${IN}/d03Package.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d03Package.spad.pamphlet >d03Package.spad ) +- +-@ + <>= + ${OUT}/PDEPACK.o: ${MID}/PDEPACK.NRLIB + @ echo 0 making ${OUT}/PDEPACK.o from ${MID}/PDEPACK.NRLIB +@@ -9237,13 +8856,6 @@ + + @ + \subsection{d03routine.spad \cite{1}} +-<>= +-${MID}/d03routine.spad: ${IN}/d03routine.spad.pamphlet +- @ echo 0 making ${MID}/d03routine.spad from ${IN}/d03routine.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d03routine.spad.pamphlet >d03routine.spad ) +- +-@ + <>= + ${OUT}/D03EEFA.o: ${MID}/D03EEFA.NRLIB + @ echo 0 making ${OUT}/D03EEFA.o from ${MID}/D03EEFA.NRLIB +@@ -9296,13 +8908,6 @@ + + @ + \subsection{d03.spad \cite{1}} +-<>= +-${MID}/d03.spad: ${IN}/d03.spad.pamphlet +- @ echo 0 making ${MID}/d03.spad from ${IN}/d03.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/d03.spad.pamphlet >d03.spad ) +- +-@ + <>= + ${OUT}/NAGD03.o: ${MID}/NAGD03.NRLIB + @ echo 0 making ${OUT}/NAGD03.o from ${MID}/NAGD03.NRLIB +@@ -9335,13 +8940,6 @@ + + @ + \subsection{ddfact.spad \cite{1}} +-<>= +-${MID}/ddfact.spad: ${IN}/ddfact.spad.pamphlet +- @ echo 0 making ${MID}/ddfact.spad from ${IN}/ddfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ddfact.spad.pamphlet >ddfact.spad ) +- +-@ + <>= + ${OUT}/DDFACT.o: ${MID}/DDFACT.NRLIB + @ echo 0 making ${OUT}/DDFACT.o from ${MID}/DDFACT.NRLIB +@@ -9374,13 +8972,6 @@ + + @ + \subsection{defaults.spad \cite{1}} +-<>= +-${MID}/defaults.spad: ${IN}/defaults.spad.pamphlet +- @ echo 0 making ${MID}/defaults.spad from ${IN}/defaults.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/defaults.spad.pamphlet >defaults.spad ) +- +-@ + <>= + ${OUT}/FLASORT.o: ${MID}/FLASORT.NRLIB + @ echo 0 making ${OUT}/FLASORT.o from ${MID}/FLASORT.NRLIB +@@ -9453,13 +9044,6 @@ + + @ + \subsection{defintef.spad \cite{1}} +-<>= +-${MID}/defintef.spad: ${IN}/defintef.spad.pamphlet +- @ echo 0 making ${MID}/defintef.spad from ${IN}/defintef.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/defintef.spad.pamphlet >defintef.spad ) +- +-@ + <>= + ${OUT}/DEFINTEF.o: ${MID}/DEFINTEF.NRLIB + @ echo 0 making ${OUT}/DEFINTEF.o from ${MID}/DEFINTEF.NRLIB +@@ -9492,13 +9076,6 @@ + + @ + \subsection{defintrf.spad \cite{1}} +-<>= +-${MID}/defintrf.spad: ${IN}/defintrf.spad.pamphlet +- @ echo 0 making ${MID}/defintrf.spad from ${IN}/defintrf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/defintrf.spad.pamphlet >defintrf.spad ) +- +-@ + <>= + ${OUT}/DEFINTRF.o: ${MID}/DEFINTRF.NRLIB + @ echo 0 making ${OUT}/DEFINTRF.o from ${MID}/DEFINTRF.NRLIB +@@ -9551,13 +9128,6 @@ + + @ + \subsection{degred.spad \cite{1}} +-<>= +-${MID}/degred.spad: ${IN}/degred.spad.pamphlet +- @ echo 0 making ${MID}/degred.spad from ${IN}/degred.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/degred.spad.pamphlet >degred.spad ) +- +-@ + <>= + ${OUT}/DEGRED.o: ${MID}/DEGRED.NRLIB + @ echo 0 making ${OUT}/DEGRED.o from ${MID}/DEGRED.NRLIB +@@ -9590,13 +9160,6 @@ + + @ + \subsection{derham.spad \cite{1}} +-<>= +-${MID}/derham.spad: ${IN}/derham.spad.pamphlet +- @ echo 0 making ${MID}/derham.spad from ${IN}/derham.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/derham.spad.pamphlet >derham.spad ) +- +-@ + <>= + ${OUT}/ANTISYM.o: ${MID}/ANTISYM.NRLIB + @ echo 0 making ${OUT}/ANTISYM.o from ${MID}/ANTISYM.NRLIB +@@ -9701,13 +9264,6 @@ + + @ + \subsection{dhmatrix.spad \cite{1}} +-<>= +-${MID}/dhmatrix.spad: ${IN}/dhmatrix.spad.pamphlet +- @ echo 0 making ${MID}/dhmatrix.spad from ${IN}/dhmatrix.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/dhmatrix.spad.pamphlet >dhmatrix.spad ) +- +-@ + <>= + ${OUT}/DHMATRIX.o: ${MID}/DHMATRIX.NRLIB + @ echo 0 making ${OUT}/DHMATRIX.o from ${MID}/DHMATRIX.NRLIB +@@ -9740,13 +9296,6 @@ + + @ + \subsection{divisor.spad \cite{1}} +-<>= +-${MID}/divisor.spad: ${IN}/divisor.spad.pamphlet +- @ echo 0 making ${MID}/divisor.spad from ${IN}/divisor.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/divisor.spad.pamphlet >divisor.spad ) +- +-@ + <>= + ${OUT}/FDIV2.o: ${MID}/FDIV2.NRLIB + @ echo 0 making ${OUT}/FDIV2.o from ${MID}/FDIV2.NRLIB +@@ -9931,13 +9480,6 @@ + + @ + \subsection{dpolcat.spad \cite{1}} +-<>= +-${MID}/dpolcat.spad: ${IN}/dpolcat.spad.pamphlet +- @ echo 0 making ${MID}/dpolcat.spad from ${IN}/dpolcat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/dpolcat.spad.pamphlet >dpolcat.spad ) +- +-@ + <>= + ${OUT}/SDPOL.o: ${MID}/SDPOL.NRLIB + @ echo 0 making ${OUT}/SDPOL.o from ${MID}/SDPOL.NRLIB +@@ -10114,13 +9656,6 @@ + + @ + \subsection{drawopt.spad \cite{1}} +-<>= +-${MID}/drawopt.spad: ${IN}/drawopt.spad.pamphlet +- @ echo 0 making ${MID}/drawopt.spad from ${IN}/drawopt.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/drawopt.spad.pamphlet >drawopt.spad ) +- +-@ + <>= + ${OUT}/DROPT.o: ${MID}/DROPT.NRLIB + @ echo 0 making ${OUT}/DROPT.o from ${MID}/DROPT.NRLIB +@@ -10193,13 +9728,6 @@ + + @ + \subsection{drawpak.spad \cite{1}} +-<>= +-${MID}/drawpak.spad: ${IN}/drawpak.spad.pamphlet +- @ echo 0 making ${MID}/drawpak.spad from ${IN}/drawpak.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/drawpak.spad.pamphlet >drawpak.spad ) +- +-@ + <>= + ${OUT}/DRAWCX.o: ${MID}/DRAWCX.NRLIB + @ echo 0 making ${OUT}/DRAWCX.o from ${MID}/DRAWCX.NRLIB +@@ -10232,13 +9760,6 @@ + + @ + \subsection{draw.spad \cite{1}} +-<>= +-${MID}/draw.spad: ${IN}/draw.spad.pamphlet +- @ echo 0 making ${MID}/draw.spad from ${IN}/draw.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/draw.spad.pamphlet >draw.spad ) +- +-@ + <>= + ${OUT}/DRAW.o: ${MID}/DRAW.NRLIB + @ echo 0 making ${OUT}/DRAW.o from ${MID}/DRAW.NRLIB +@@ -10331,13 +9852,6 @@ + + @ + \subsection{e01.spad \cite{1}} +-<>= +-${MID}/e01.spad: ${IN}/e01.spad.pamphlet +- @ echo 0 making ${MID}/e01.spad from ${IN}/e01.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/e01.spad.pamphlet >e01.spad ) +- +-@ + <>= + ${OUT}/NAGE01.o: ${MID}/NAGE01.NRLIB + @ echo 0 making ${OUT}/NAGE01.o from ${MID}/NAGE01.NRLIB +@@ -10370,13 +9884,6 @@ + + @ + \subsection{e02.spad \cite{1}} +-<>= +-${MID}/e02.spad: ${IN}/e02.spad.pamphlet +- @ echo 0 making ${MID}/e02.spad from ${IN}/e02.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/e02.spad.pamphlet >e02.spad ) +- +-@ + <>= + ${OUT}/NAGE02.o: ${MID}/NAGE02.NRLIB + @ echo 0 making ${OUT}/NAGE02.o from ${MID}/NAGE02.NRLIB +@@ -10409,13 +9916,6 @@ + + @ + \subsection{e04agents.spad \cite{1}} +-<>= +-${MID}/e04agents.spad: ${IN}/e04agents.spad.pamphlet +- @ echo 0 making ${MID}/e04agents.spad from ${IN}/e04agents.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/e04agents.spad.pamphlet >e04agents.spad ) +- +-@ + <>= + ${OUT}/E04AGNT.o: ${MID}/E04AGNT.NRLIB + @ echo 0 making ${OUT}/E04AGNT.o from ${MID}/E04AGNT.NRLIB +@@ -10448,13 +9948,6 @@ + + @ + \subsection{e04Package.spad \cite{1}} +-<>= +-${MID}/e04Package.spad: ${IN}/e04Package.spad.pamphlet +- @ echo 0 making ${MID}/e04Package.spad from ${IN}/e04Package.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/e04Package.spad.pamphlet >e04Package.spad ) +- +-@ + <>= + ${OUT}/OPTPACK.o: ${MID}/OPTPACK.NRLIB + @ echo 0 making ${OUT}/OPTPACK.o from ${MID}/OPTPACK.NRLIB +@@ -10487,13 +9980,6 @@ + + @ + \subsection{e04routine.spad \cite{1}} +-<>= +-${MID}/e04routine.spad: ${IN}/e04routine.spad.pamphlet +- @ echo 0 making ${MID}/e04routine.spad from ${IN}/e04routine.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/e04routine.spad.pamphlet >e04routine.spad ) +- +-@ + <>= + ${OUT}/E04DGFA.o: ${MID}/E04DGFA.NRLIB + @ echo 0 making ${OUT}/E04DGFA.o from ${MID}/E04DGFA.NRLIB +@@ -10646,13 +10132,6 @@ + + @ + \subsection{e04.spad \cite{1}} +-<>= +-${MID}/e04.spad: ${IN}/e04.spad.pamphlet +- @ echo 0 making ${MID}/e04.spad from ${IN}/e04.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/e04.spad.pamphlet >e04.spad ) +- +-@ + <>= + ${OUT}/NAGE04.o: ${MID}/NAGE04.NRLIB + @ echo 0 making ${OUT}/NAGE04.o from ${MID}/NAGE04.NRLIB +@@ -10685,13 +10164,6 @@ + + @ + \subsection{efstruc.spad \cite{1}} +-<>= +-${MID}/efstruc.spad: ${IN}/efstruc.spad.pamphlet +- @ echo 0 making ${MID}/efstruc.spad from ${IN}/efstruc.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/efstruc.spad.pamphlet >efstruc.spad ) +- +-@ + <>= + ${OUT}/CTRIGMNP.o: ${MID}/CTRIGMNP.NRLIB + @ echo 0 making ${OUT}/CTRIGMNP.o from ${MID}/CTRIGMNP.NRLIB +@@ -10824,13 +10296,6 @@ + + @ + \subsection{efuls.spad \cite{1}} +-<>= +-${MID}/efuls.spad: ${IN}/efuls.spad.pamphlet +- @ echo 0 making ${MID}/efuls.spad from ${IN}/efuls.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/efuls.spad.pamphlet >efuls.spad ) +- +-@ + <>= + ${OUT}/EFULS.o: ${MID}/EFULS.NRLIB + @ echo 0 making ${OUT}/EFULS.o from ${MID}/EFULS.NRLIB +@@ -10863,13 +10328,6 @@ + + @ + \subsection{efupxs.spad \cite{1}} +-<>= +-${MID}/efupxs.spad: ${IN}/efupxs.spad.pamphlet +- @ echo 0 making ${MID}/efupxs.spad from ${IN}/efupxs.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/efupxs.spad.pamphlet >efupxs.spad ) +- +-@ + <>= + ${OUT}/EFUPXS.o: ${MID}/EFUPXS.NRLIB + @ echo 0 making ${OUT}/EFUPXS.o from ${MID}/EFUPXS.NRLIB +@@ -10902,13 +10360,6 @@ + + @ + \subsection{eigen.spad \cite{1}} +-<>= +-${MID}/eigen.spad: ${IN}/eigen.spad.pamphlet +- @ echo 0 making ${MID}/eigen.spad from ${IN}/eigen.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/eigen.spad.pamphlet >eigen.spad ) +- +-@ + <>= + ${OUT}/CHARPOL.o: ${MID}/CHARPOL.NRLIB + @ echo 0 making ${OUT}/CHARPOL.o from ${MID}/CHARPOL.NRLIB +@@ -10961,13 +10412,6 @@ + + @ + \subsection{elemntry.spad \cite{1}} +-<>= +-${MID}/elemntry.spad: ${IN}/elemntry.spad.pamphlet +- @ echo 0 making ${MID}/elemntry.spad from ${IN}/elemntry.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/elemntry.spad.pamphlet >elemntry.spad ) +- +-@ + <>= + ${OUT}/EF.o: ${MID}/EF.NRLIB + @ echo 0 making ${OUT}/EF.o from ${MID}/EF.NRLIB +@@ -11000,13 +10444,6 @@ + + @ + \subsection{elfuts.spad \cite{1}} +-<>= +-${MID}/elfuts.spad: ${IN}/elfuts.spad.pamphlet +- @ echo 0 making ${MID}/elfuts.spad from ${IN}/elfuts.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/elfuts.spad.pamphlet >elfuts.spad ) +- +-@ + <>= + ${OUT}/ELFUTS.o: ${MID}/ELFUTS.NRLIB + @ echo 0 making ${OUT}/ELFUTS.o from ${MID}/ELFUTS.NRLIB +@@ -11040,13 +10477,6 @@ + + @ + \subsection{equation1.spad \cite{1}} +-<>= +-${MID}/equation1.spad: ${IN}/equation1.spad.pamphlet +- @ echo 0 making ${MID}/equation1.spad from ${IN}/equation1.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/equation1.spad.pamphlet >equation1.spad ) +- +-@ + <>= + ${OUT}/EVALAB-.o: ${MID}/EVALAB.NRLIB + @ echo 0 making ${OUT}/EVALAB-.o from ${MID}/EVALAB-.NRLIB +@@ -11123,13 +10553,6 @@ + + @ + \subsection{equation2.spad \cite{1}} +-<>= +-${MID}/equation2.spad: ${IN}/equation2.spad.pamphlet +- @ echo 0 making ${MID}/equation2.spad from ${IN}/equation2.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/equation2.spad.pamphlet >equation2.spad ) +- +-@ + <>= + ${OUT}/EQ.o: ${MID}/EQ.NRLIB + @ echo 0 making ${OUT}/EQ.o from ${MID}/EQ.NRLIB +@@ -11214,13 +10637,6 @@ + + @ + \subsection{error.spad \cite{1}} +-<>= +-${MID}/error.spad: ${IN}/error.spad.pamphlet +- @ echo 0 making ${MID}/error.spad from ${IN}/error.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/error.spad.pamphlet >error.spad ) +- +-@ + <>= + ${OUT}/ERROR.o: ${MID}/ERROR.NRLIB + @ echo 0 making ${OUT}/ERROR.o from ${MID}/ERROR.NRLIB +@@ -11253,13 +10669,6 @@ + + @ + \subsection{expexpan.spad \cite{1}} +-<>= +-${MID}/expexpan.spad: ${IN}/expexpan.spad.pamphlet +- @ echo 0 making ${MID}/expexpan.spad from ${IN}/expexpan.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/expexpan.spad.pamphlet >expexpan.spad ) +- +-@ + <>= + ${OUT}/EXPEXPAN.o: ${MID}/EXPEXPAN.NRLIB + @ echo 0 making ${OUT}/EXPEXPAN.o from ${MID}/EXPEXPAN.NRLIB +@@ -11349,13 +10758,6 @@ + + @ + \subsection{expr2ups.spad \cite{1}} +-<>= +-${MID}/expr2ups.spad: ${IN}/expr2ups.spad.pamphlet +- @ echo 0 making ${MID}/expr2ups.spad from ${IN}/expr2ups.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/expr2ups.spad.pamphlet >expr2ups.spad ) +- +-@ + <>= + ${OUT}/EXPR2UPS.o: ${MID}/EXPR2UPS.NRLIB + @ echo 0 making ${OUT}/EXPR2UPS.o from ${MID}/EXPR2UPS.NRLIB +@@ -11388,13 +10790,6 @@ + + @ + \subsection{exprode.spad \cite{1}} +-<>= +-${MID}/exprode.spad: ${IN}/exprode.spad.pamphlet +- @ echo 0 making ${MID}/exprode.spad from ${IN}/exprode.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/exprode.spad.pamphlet >exprode.spad ) +- +-@ + <>= + ${OUT}/EXPRODE.o: ${MID}/EXPRODE.NRLIB + @ echo 0 making ${OUT}/EXPRODE.o from ${MID}/EXPRODE.NRLIB +@@ -11427,13 +10822,6 @@ + + @ + \subsection{expr.spad \cite{1}} +-<>= +-${MID}/expr.spad: ${IN}/expr.spad.pamphlet +- @ echo 0 making ${MID}/expr.spad from ${IN}/expr.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/expr.spad.pamphlet >expr.spad ) +- +-@ + <>= + ${OUT}/EXPR.o: ${MID}/EXPR.NRLIB + @ echo 0 making ${OUT}/EXPR.o from ${MID}/EXPR.NRLIB +@@ -11626,13 +11014,6 @@ + + @ + \subsection{f01.spad \cite{1}} +-<>= +-${MID}/f01.spad: ${IN}/f01.spad.pamphlet +- @ echo 0 making ${MID}/f01.spad from ${IN}/f01.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/f01.spad.pamphlet >f01.spad ) +- +-@ + <>= + ${OUT}/NAGF01.o: ${MID}/NAGF01.NRLIB + @ echo 0 making ${OUT}/NAGF01.o from ${MID}/NAGF01.NRLIB +@@ -11665,13 +11046,6 @@ + + @ + \subsection{f02.spad \cite{1}} +-<>= +-${MID}/f02.spad: ${IN}/f02.spad.pamphlet +- @ echo 0 making ${MID}/f02.spad from ${IN}/f02.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/f02.spad.pamphlet >f02.spad ) +- +-@ + <>= + ${OUT}/NAGF02.o: ${MID}/NAGF02.NRLIB + @ echo 0 making ${OUT}/NAGF02.o from ${MID}/NAGF02.NRLIB +@@ -11704,13 +11078,6 @@ + + @ + \subsection{f04.spad \cite{1}} +-<>= +-${MID}/f04.spad: ${IN}/f04.spad.pamphlet +- @ echo 0 making ${MID}/f04.spad from ${IN}/f04.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/f04.spad.pamphlet >f04.spad ) +- +-@ + <>= + ${OUT}/NAGF04.o: ${MID}/NAGF04.NRLIB + @ echo 0 making ${OUT}/NAGF04.o from ${MID}/NAGF04.NRLIB +@@ -11743,13 +11110,6 @@ + + @ + \subsection{f07.spad \cite{1}} +-<>= +-${MID}/f07.spad: ${IN}/f07.spad.pamphlet +- @ echo 0 making ${MID}/f07.spad from ${IN}/f07.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/f07.spad.pamphlet >f07.spad ) +- +-@ + <>= + ${OUT}/NAGF07.o: ${MID}/NAGF07.NRLIB + @ echo 0 making ${OUT}/NAGF07.o from ${MID}/NAGF07.NRLIB +@@ -11782,13 +11142,6 @@ + + @ + \subsection{facutil.spad \cite{1}} +-<>= +-${MID}/facutil.spad: ${IN}/facutil.spad.pamphlet +- @ echo 0 making ${MID}/facutil.spad from ${IN}/facutil.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/facutil.spad.pamphlet >facutil.spad ) +- +-@ + <>= + ${OUT}/FACUTIL.o: ${MID}/FACUTIL.NRLIB + @ echo 0 making ${OUT}/FACUTIL.o from ${MID}/FACUTIL.NRLIB +@@ -11841,13 +11194,6 @@ + + @ + \subsection{ffcat.spad \cite{1}} +-<>= +-${MID}/ffcat.spad: ${IN}/ffcat.spad.pamphlet +- @ echo 0 making ${MID}/ffcat.spad from ${IN}/ffcat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ffcat.spad.pamphlet >ffcat.spad ) +- +-@ + <>= + ${OUT}/DLP.o: ${MID}/DLP.NRLIB + @ echo 0 making ${OUT}/DLP.o from ${MID}/DLP.NRLIB +@@ -12062,13 +11408,6 @@ + + @ + \subsection{ffcg.spad \cite{1}} +-<>= +-${MID}/ffcg.spad: ${IN}/ffcg.spad.pamphlet +- @ echo 0 making ${MID}/ffcg.spad from ${IN}/ffcg.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ffcg.spad.pamphlet >ffcg.spad ) +- +-@ + <>= + ${OUT}/FFCG.o: ${MID}/FFCG.NRLIB + @ echo 0 making ${OUT}/FFCG.o from ${MID}/FFCG.NRLIB +@@ -12141,13 +11480,6 @@ + + @ + \subsection{fff.spad \cite{1}} +-<>= +-${MID}/fff.spad: ${IN}/fff.spad.pamphlet +- @ echo 0 making ${MID}/fff.spad from ${IN}/fff.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fff.spad.pamphlet >fff.spad ) +- +-@ + <>= + ${OUT}/FFF.o: ${MID}/FFF.NRLIB + @ echo 0 making ${OUT}/FFF.o from ${MID}/FFF.NRLIB +@@ -12180,13 +11512,6 @@ + + @ + \subsection{ffhom.spad \cite{1}} +-<>= +-${MID}/ffhom.spad: ${IN}/ffhom.spad.pamphlet +- @ echo 0 making ${MID}/ffhom.spad from ${IN}/ffhom.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ffhom.spad.pamphlet >ffhom.spad ) +- +-@ + <>= + ${OUT}/FFHOM.o: ${MID}/FFHOM.NRLIB + @ echo 0 making ${OUT}/FFHOM.o from ${MID}/FFHOM.NRLIB +@@ -12219,13 +11544,6 @@ + + @ + \subsection{ffnb.spad \cite{1}} +-<>= +-${MID}/ffnb.spad: ${IN}/ffnb.spad.pamphlet +- @ echo 0 making ${MID}/ffnb.spad from ${IN}/ffnb.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ffnb.spad.pamphlet >ffnb.spad ) +- +-@ + <>= + ${OUT}/FFNB.o: ${MID}/FFNB.NRLIB + @ echo 0 making ${OUT}/FFNB.o from ${MID}/FFNB.NRLIB +@@ -12318,13 +11636,6 @@ + + @ + \subsection{ffpoly2.spad \cite{1}} +-<>= +-${MID}/ffpoly2.spad: ${IN}/ffpoly2.spad.pamphlet +- @ echo 0 making ${MID}/ffpoly2.spad from ${IN}/ffpoly2.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ffpoly2.spad.pamphlet >ffpoly2.spad ) +- +-@ + <>= + ${OUT}/FFPOLY2.o: ${MID}/FFPOLY2.NRLIB + @ echo 0 making ${OUT}/FFPOLY2.o from ${MID}/FFPOLY2.NRLIB +@@ -12357,13 +11668,6 @@ + + @ + \subsection{ffpoly.spad \cite{1}} +-<>= +-${MID}/ffpoly.spad: ${IN}/ffpoly.spad.pamphlet +- @ echo 0 making ${MID}/ffpoly.spad from ${IN}/ffpoly.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ffpoly.spad.pamphlet >ffpoly.spad ) +- +-@ + <>= + ${OUT}/FFPOLY.o: ${MID}/FFPOLY.NRLIB + @ echo 0 making ${OUT}/FFPOLY.o from ${MID}/FFPOLY.NRLIB +@@ -12396,13 +11700,6 @@ + + @ + \subsection{ffp.spad \cite{1}} +-<>= +-${MID}/ffp.spad: ${IN}/ffp.spad.pamphlet +- @ echo 0 making ${MID}/ffp.spad from ${IN}/ffp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ffp.spad.pamphlet >ffp.spad ) +- +-@ + <>= + ${OUT}/IFF.o: ${MID}/IFF.NRLIB + @ echo 0 making ${OUT}/IFF.o from ${MID}/IFF.NRLIB +@@ -12514,13 +11811,6 @@ + + @ + \subsection{ffx.spad \cite{1}} +-<>= +-${MID}/ffx.spad: ${IN}/ffx.spad.pamphlet +- @ echo 0 making ${MID}/ffx.spad from ${IN}/ffx.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ffx.spad.pamphlet >ffx.spad ) +- +-@ + <>= + ${OUT}/IRREDFFX.o: ${MID}/IRREDFFX.NRLIB + @ echo 0 making ${OUT}/IRREDFFX.o from ${MID}/IRREDFFX.NRLIB +@@ -12553,13 +11843,6 @@ + + @ + \subsection{files.spad \cite{1}} +-<>= +-${MID}/files.spad: ${IN}/files.spad.pamphlet +- @ echo 0 making ${MID}/files.spad from ${IN}/files.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/files.spad.pamphlet >files.spad ) +- +-@ + <>= + ${OUT}/BINFILE.o: ${MID}/BINFILE.NRLIB + @ echo 0 making ${OUT}/BINFILE.o from ${MID}/BINFILE.NRLIB +@@ -12692,13 +11975,6 @@ + + @ + \subsection{float.spad \cite{1}} +-<>= +-${MID}/float.spad: ${IN}/float.spad.pamphlet +- @ echo 0 making ${MID}/float.spad from ${IN}/float.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/float.spad.pamphlet >float.spad ) +- +-@ + <>= + ${OUT}/FLOAT.o: ${MID}/FLOAT.NRLIB + @ echo 0 making ${OUT}/FLOAT.o from ${MID}/FLOAT.NRLIB +@@ -12731,13 +12007,6 @@ + + @ + \subsection{fmod.spad \cite{1}} +-<>= +-${MID}/fmod.spad: ${IN}/fmod.spad.pamphlet +- @ echo 0 making ${MID}/fmod.spad from ${IN}/fmod.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fmod.spad.pamphlet >fmod.spad ) +- +-@ + <>= + ${OUT}/ZMOD.o: ${MID}/ZMOD.NRLIB + @ echo 0 making ${OUT}/ZMOD.o from ${MID}/ZMOD.NRLIB +@@ -12770,13 +12039,6 @@ + + @ + \subsection{fname.spad \cite{1}} +-<>= +-${MID}/fname.spad: ${IN}/fname.spad.pamphlet +- @ echo 0 making ${MID}/fname.spad from ${IN}/fname.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fname.spad.pamphlet >fname.spad ) +- +-@ + <>= + ${OUT}/FNAME.o: ${MID}/FNAME.NRLIB + @ echo 0 making ${OUT}/FNAME.o from ${MID}/FNAME.NRLIB +@@ -12829,13 +12091,6 @@ + + @ + \subsection{fnla.spad \cite{1}} +-<>= +-${MID}/fnla.spad: ${IN}/fnla.spad.pamphlet +- @ echo 0 making ${MID}/fnla.spad from ${IN}/fnla.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fnla.spad.pamphlet >fnla.spad ) +- +-@ + <>= + ${OUT}/COMM.o: ${MID}/COMM.NRLIB + @ echo 0 making ${OUT}/COMM.o from ${MID}/COMM.NRLIB +@@ -12928,13 +12183,6 @@ + + @ + \subsection{formula.spad \cite{1}} +-<>= +-${MID}/formula.spad: ${IN}/formula.spad.pamphlet +- @ echo 0 making ${MID}/formula.spad from ${IN}/formula.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/formula.spad.pamphlet >formula.spad ) +- +-@ + <>= + ${OUT}/FORMULA.o: ${MID}/FORMULA.NRLIB + @ echo 0 making ${OUT}/FORMULA.o from ${MID}/FORMULA.NRLIB +@@ -12987,13 +12235,6 @@ + + @ + \subsection{fortcat.spad \cite{1}} +-<>= +-${MID}/fortcat.spad: ${IN}/fortcat.spad.pamphlet +- @ echo 0 making ${MID}/fortcat.spad from ${IN}/fortcat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fortcat.spad.pamphlet >fortcat.spad ) +- +-@ + <>= + ${OUT}/FMTC.o: ${MID}/FMTC.NRLIB + @ echo 0 making ${OUT}/FMTC.o from ${MID}/FMTC.NRLIB +@@ -13146,13 +12387,6 @@ + + @ + \subsection{fortmac.spad \cite{1}} +-<>= +-${MID}/fortmac.spad: ${IN}/fortmac.spad.pamphlet +- @ echo 0 making ${MID}/fortmac.spad from ${IN}/fortmac.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fortmac.spad.pamphlet >fortmac.spad ) +- +-@ + <>= + ${OUT}/MCMPLX.o: ${MID}/MCMPLX.NRLIB + @ echo 0 making ${OUT}/MCMPLX.o from ${MID}/MCMPLX.NRLIB +@@ -13225,13 +12459,6 @@ + + @ + \subsection{fortpak.spad \cite{1}} +-<>= +-${MID}/fortpak.spad: ${IN}/fortpak.spad.pamphlet +- @ echo 0 making ${MID}/fortpak.spad from ${IN}/fortpak.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fortpak.spad.pamphlet >fortpak.spad ) +- +-@ + <>= + ${OUT}/FCPAK1.o: ${MID}/FCPAK1.NRLIB + @ echo 0 making ${OUT}/FCPAK1.o from ${MID}/FCPAK1.NRLIB +@@ -13364,13 +12591,6 @@ + + @ + \subsection{fortran.spad \cite{1}} +-<>= +-${MID}/fortran.spad: ${IN}/fortran.spad.pamphlet +- @ echo 0 making ${MID}/fortran.spad from ${IN}/fortran.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fortran.spad.pamphlet >fortran.spad ) +- +-@ + <>= + ${OUT}/FC.o: ${MID}/FC.NRLIB + @ echo 0 making ${OUT}/FC.o from ${MID}/FC.NRLIB +@@ -13543,13 +12763,6 @@ + + @ + \subsection{forttyp.spad \cite{1}} +-<>= +-${MID}/forttyp.spad: ${IN}/forttyp.spad.pamphlet +- @ echo 0 making ${MID}/forttyp.spad from ${IN}/forttyp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/forttyp.spad.pamphlet >forttyp.spad ) +- +-@ + <>= + ${OUT}/FST.o: ${MID}/FST.NRLIB + @ echo 0 making ${OUT}/FST.o from ${MID}/FST.NRLIB +@@ -13642,13 +12855,6 @@ + + @ + \subsection{fourier.spad \cite{1}} +-<>= +-${MID}/fourier.spad: ${IN}/fourier.spad.pamphlet +- @ echo 0 making ${MID}/fourier.spad from ${IN}/fourier.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fourier.spad.pamphlet >fourier.spad ) +- +-@ + <>= + ${OUT}/FCOMP.o: ${MID}/FCOMP.NRLIB + @ echo 0 making ${OUT}/FCOMP.o from ${MID}/FCOMP.NRLIB +@@ -13701,13 +12907,6 @@ + + @ + \subsection{fparfrac.spad \cite{1}} +-<>= +-${MID}/fparfrac.spad: ${IN}/fparfrac.spad.pamphlet +- @ echo 0 making ${MID}/fparfrac.spad from ${IN}/fparfrac.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fparfrac.spad.pamphlet >fparfrac.spad ) +- +-@ + <>= + ${OUT}/FPARFRAC.o: ${MID}/FPARFRAC.NRLIB + @ echo 0 making ${OUT}/FPARFRAC.o from ${MID}/FPARFRAC.NRLIB +@@ -13740,13 +12939,6 @@ + + @ + \subsection{fraction.spad \cite{1}} +-<>= +-${MID}/fraction.spad: ${IN}/fraction.spad.pamphlet +- @ echo 0 making ${MID}/fraction.spad from ${IN}/fraction.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fraction.spad.pamphlet >fraction.spad ) +- +-@ + <>= + ${OUT}/FRAC.o: ${MID}/FRAC.NRLIB + @ echo 0 making ${OUT}/FRAC.o from ${MID}/FRAC.NRLIB +@@ -13945,13 +13137,6 @@ + + @ + \subsection{free.spad \cite{1}} +-<>= +-${MID}/free.spad: ${IN}/free.spad.pamphlet +- @ echo 0 making ${MID}/free.spad from ${IN}/free.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/free.spad.pamphlet >free.spad ) +- +-@ + <>= + ${OUT}/FAGROUP.o: ${MID}/FAGROUP.NRLIB + @ echo 0 making ${OUT}/FAGROUP.o from ${MID}/FAGROUP.NRLIB +@@ -14104,13 +13289,6 @@ + + @ + \subsection{fr.spad \cite{1}} +-<>= +-${MID}/fr.spad: ${IN}/fr.spad.pamphlet +- @ echo 0 making ${MID}/fr.spad from ${IN}/fr.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fr.spad.pamphlet >fr.spad ) +- +-@ + <>= + ${OUT}/FR.o: ${MID}/FR.NRLIB + @ echo 0 making ${OUT}/FR.o from ${MID}/FR.NRLIB +@@ -14183,13 +13361,6 @@ + + @ + \subsection{fs2expxp.spad \cite{1}} +-<>= +-${MID}/fs2expxp.spad: ${IN}/fs2expxp.spad.pamphlet +- @ echo 0 making ${MID}/fs2expxp.spad from ${IN}/fs2expxp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fs2expxp.spad.pamphlet >fs2expxp.spad ) +- +-@ + <>= + ${OUT}/FS2EXPXP.o: ${MID}/FS2EXPXP.NRLIB + @ echo 0 making ${OUT}/FS2EXPXP.o from ${MID}/FS2EXPXP.NRLIB +@@ -14222,13 +13393,6 @@ + + @ + \subsection{fs2ups.spad \cite{1}} +-<>= +-${MID}/fs2ups.spad: ${IN}/fs2ups.spad.pamphlet +- @ echo 0 making ${MID}/fs2ups.spad from ${IN}/fs2ups.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fs2ups.spad.pamphlet >fs2ups.spad ) +- +-@ + <>= + ${OUT}/FS2UPS.o: ${MID}/FS2UPS.NRLIB + @ echo 0 making ${OUT}/FS2UPS.o from ${MID}/FS2UPS.NRLIB +@@ -14261,13 +13425,6 @@ + + @ + \subsection{fspace.spad \cite{1}} +-<>= +-${MID}/fspace.spad: ${IN}/fspace.spad.pamphlet +- @ echo 0 making ${MID}/fspace.spad from ${IN}/fspace.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/fspace.spad.pamphlet >fspace.spad ) +- +-@ + <>= + ${OUT}/ES-.o: ${MID}/ES.NRLIB + @ echo 0 making ${OUT}/ES-.o from ${MID}/ES-.NRLIB +@@ -14438,13 +13595,6 @@ + + @ + \subsection{funcpkgs.spad \cite{1}} +-<>= +-${MID}/funcpkgs.spad: ${IN}/funcpkgs.spad.pamphlet +- @ echo 0 making ${MID}/funcpkgs.spad from ${IN}/funcpkgs.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/funcpkgs.spad.pamphlet >funcpkgs.spad ) +- +-@ + <>= + ${OUT}/FSUPFACT.o: ${MID}/FSUPFACT.NRLIB + @ echo 0 making ${OUT}/FSUPFACT.o from ${MID}/FSUPFACT.NRLIB +@@ -14477,13 +13627,6 @@ + + @ + \subsection{functions.spad \cite{1}} +-<>= +-${MID}/functions.spad: ${IN}/functions.spad.pamphlet +- @ echo 0 making ${MID}/functions.spad from ${IN}/functions.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/functions.spad.pamphlet >functions.spad ) +- +-@ + <>= + ${OUT}/BFUNCT.o: ${MID}/BFUNCT.NRLIB + @ echo 0 making ${OUT}/BFUNCT.o from ${MID}/BFUNCT.NRLIB +@@ -14516,13 +13659,6 @@ + + @ + \subsection{galfact.spad \cite{1}} +-<>= +-${MID}/galfact.spad: ${IN}/galfact.spad.pamphlet +- @ echo 0 making ${MID}/galfact.spad from ${IN}/galfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/galfact.spad.pamphlet >galfact.spad ) +- +-@ + <>= + ${OUT}/GALFACT.o: ${MID}/GALFACT.NRLIB + @ echo 0 making ${OUT}/GALFACT.o from ${MID}/GALFACT.NRLIB +@@ -14555,13 +13691,6 @@ + + @ + \subsection{galfactu.spad \cite{1}} +-<>= +-${MID}/galfactu.spad: ${IN}/galfactu.spad.pamphlet +- @ echo 0 making ${MID}/galfactu.spad from ${IN}/galfactu.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/galfactu.spad.pamphlet >galfactu.spad ) +- +-@ + <>= + ${OUT}/GALFACTU.o: ${MID}/GALFACTU.NRLIB + @ echo 0 making ${OUT}/GALFACTU.o from ${MID}/GALFACTU.NRLIB +@@ -14594,13 +13723,6 @@ + + @ + \subsection{galpolyu.spad \cite{1}} +-<>= +-${MID}/galpolyu.spad: ${IN}/galpolyu.spad.pamphlet +- @ echo 0 making ${MID}/galpolyu.spad from ${IN}/galpolyu.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/galpolyu.spad.pamphlet >galpolyu.spad ) +- +-@ + <>= + ${OUT}/GALPOLYU.o: ${MID}/GALPOLYU.NRLIB + @ echo 0 making ${OUT}/GALPOLYU.o from ${MID}/GALPOLYU.NRLIB +@@ -14633,13 +13755,6 @@ + + @ + \subsection{galutil.spad \cite{1}} +-<>= +-${MID}/galutil.spad: ${IN}/galutil.spad.pamphlet +- @ echo 0 making ${MID}/galutil.spad from ${IN}/galutil.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/galutil.spad.pamphlet >galutil.spad ) +- +-@ + <>= + ${OUT}/GALUTIL.o: ${MID}/GALUTIL.NRLIB + @ echo 0 making ${OUT}/GALUTIL.o from ${MID}/GALUTIL.NRLIB +@@ -14672,13 +13787,6 @@ + + @ + \subsection{gaussfac.spad \cite{1}} +-<>= +-${MID}/gaussfac.spad: ${IN}/gaussfac.spad.pamphlet +- @ echo 0 making ${MID}/gaussfac.spad from ${IN}/gaussfac.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gaussfac.spad.pamphlet >gaussfac.spad ) +- +-@ + <>= + ${OUT}/GAUSSFAC.o: ${MID}/GAUSSFAC.NRLIB + @ echo 0 making ${OUT}/GAUSSFAC.o from ${MID}/GAUSSFAC.NRLIB +@@ -14711,13 +13819,6 @@ + + @ + \subsection{gaussian.spad \cite{1}} +-<>= +-${MID}/gaussian.spad: ${IN}/gaussian.spad.pamphlet +- @ echo 0 making ${MID}/gaussian.spad from ${IN}/gaussian.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gaussian.spad.pamphlet >gaussian.spad ) +- +-@ + <>= + ${OUT}/CINTSLPE.o: ${MID}/CINTSLPE.NRLIB + @ echo 0 making ${OUT}/CINTSLPE.o from ${MID}/CINTSLPE.NRLIB +@@ -14882,13 +13983,6 @@ + + @ + \subsection{gbeuclid.spad \cite{1}} +-<>= +-${MID}/gbeuclid.spad: ${IN}/gbeuclid.spad.pamphlet +- @ echo 0 making ${MID}/gbeuclid.spad from ${IN}/gbeuclid.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gbeuclid.spad.pamphlet >gbeuclid.spad ) +- +-@ + <>= + ${OUT}/GBEUCLID.o: ${MID}/GBEUCLID.NRLIB + @ echo 0 making ${OUT}/GBEUCLID.o from ${MID}/GBEUCLID.NRLIB +@@ -14921,13 +14015,6 @@ + + @ + \subsection{gbintern.spad \cite{1}} +-<>= +-${MID}/gbintern.spad: ${IN}/gbintern.spad.pamphlet +- @ echo 0 making ${MID}/gbintern.spad from ${IN}/gbintern.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gbintern.spad.pamphlet >gbintern.spad ) +- +-@ + <>= + ${OUT}/GBINTERN.o: ${MID}/GBINTERN.NRLIB + @ echo 0 making ${OUT}/GBINTERN.o from ${MID}/GBINTERN.NRLIB +@@ -14960,13 +14047,6 @@ + + @ + \subsection{gb.spad \cite{1}} +-<>= +-${MID}/gb.spad: ${IN}/gb.spad.pamphlet +- @ echo 0 making ${MID}/gb.spad from ${IN}/gb.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gb.spad.pamphlet >gb.spad ) +- +-@ + <>= + ${OUT}/GB.o: ${MID}/GB.NRLIB + @ echo 0 making ${OUT}/GB.o from ${MID}/GB.NRLIB +@@ -14999,13 +14079,6 @@ + + @ + \subsection{gdirprod.spad \cite{1}} +-<>= +-${MID}/gdirprod.spad: ${IN}/gdirprod.spad.pamphlet +- @ echo 0 making ${MID}/gdirprod.spad from ${IN}/gdirprod.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gdirprod.spad.pamphlet >gdirprod.spad ) +- +-@ + <>= + ${OUT}/HDP.o: ${MID}/HDP.NRLIB + @ echo 0 making ${OUT}/HDP.o from ${MID}/HDP.NRLIB +@@ -15098,13 +14171,6 @@ + + @ + \subsection{gdpoly.spad \cite{1}} +-<>= +-${MID}/gdpoly.spad: ${IN}/gdpoly.spad.pamphlet +- @ echo 0 making ${MID}/gdpoly.spad from ${IN}/gdpoly.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gdpoly.spad.pamphlet >gdpoly.spad ) +- +-@ + <>= + ${OUT}/DMP.o: ${MID}/DMP.NRLIB + @ echo 0 making ${OUT}/DMP.o from ${MID}/DMP.NRLIB +@@ -15177,13 +14243,6 @@ + + @ + \subsection{geneez.spad \cite{1}} +-<>= +-${MID}/geneez.spad: ${IN}/geneez.spad.pamphlet +- @ echo 0 making ${MID}/geneez.spad from ${IN}/geneez.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/geneez.spad.pamphlet >geneez.spad ) +- +-@ + <>= + ${OUT}/GENEEZ.o: ${MID}/GENEEZ.NRLIB + @ echo 0 making ${OUT}/GENEEZ.o from ${MID}/GENEEZ.NRLIB +@@ -15216,13 +14275,6 @@ + + @ + \subsection{generic.spad \cite{1}} +-<>= +-${MID}/generic.spad: ${IN}/generic.spad.pamphlet +- @ echo 0 making ${MID}/generic.spad from ${IN}/generic.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/generic.spad.pamphlet >generic.spad ) +- +-@ + <>= + ${OUT}/CVMP.o: ${MID}/CVMP.NRLIB + @ echo 0 making ${OUT}/CVMP.o from ${MID}/CVMP.NRLIB +@@ -15275,13 +14327,6 @@ + + @ + \subsection{genufact.spad \cite{1}} +-<>= +-${MID}/genufact.spad: ${IN}/genufact.spad.pamphlet +- @ echo 0 making ${MID}/genufact.spad from ${IN}/genufact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/genufact.spad.pamphlet >genufact.spad ) +- +-@ + <>= + ${OUT}/GENUFACT.o: ${MID}/GENUFACT.NRLIB + @ echo 0 making ${OUT}/GENUFACT.o from ${MID}/GENUFACT.NRLIB +@@ -15314,13 +14359,6 @@ + + @ + \subsection{genups.spad \cite{1}} +-<>= +-${MID}/genups.spad: ${IN}/genups.spad.pamphlet +- @ echo 0 making ${MID}/genups.spad from ${IN}/genups.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/genups.spad.pamphlet >genups.spad ) +- +-@ + <>= + ${OUT}/GENUPS.o: ${MID}/GENUPS.NRLIB + @ echo 0 making ${OUT}/GENUPS.o from ${MID}/GENUPS.NRLIB +@@ -15353,13 +14391,6 @@ + + @ + \subsection{ghensel.spad \cite{1}} +-<>= +-${MID}/ghensel.spad: ${IN}/ghensel.spad.pamphlet +- @ echo 0 making ${MID}/ghensel.spad from ${IN}/ghensel.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ghensel.spad.pamphlet >ghensel.spad ) +- +-@ + <>= + ${OUT}/GHENSEL.o: ${MID}/GHENSEL.NRLIB + @ echo 0 making ${OUT}/GHENSEL.o from ${MID}/GHENSEL.NRLIB +@@ -15392,13 +14423,6 @@ + + @ + \subsection{gpgcd.spad \cite{1}} +-<>= +-${MID}/gpgcd.spad: ${IN}/gpgcd.spad.pamphlet +- @ echo 0 making ${MID}/gpgcd.spad from ${IN}/gpgcd.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gpgcd.spad.pamphlet >gpgcd.spad ) +- +-@ + <>= + ${OUT}/GENPGCD.o: ${MID}/GENPGCD.NRLIB + @ echo 0 making ${OUT}/GENPGCD.o from ${MID}/GENPGCD.NRLIB +@@ -15431,13 +14455,6 @@ + + @ + \subsection{gpol.spad \cite{1}} +-<>= +-${MID}/gpol.spad: ${IN}/gpol.spad.pamphlet +- @ echo 0 making ${MID}/gpol.spad from ${IN}/gpol.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gpol.spad.pamphlet >gpol.spad ) +- +-@ + <>= + ${OUT}/LAUPOL.o: ${MID}/LAUPOL.NRLIB + @ echo 0 making ${OUT}/LAUPOL.o from ${MID}/LAUPOL.NRLIB +@@ -15470,13 +14487,6 @@ + + @ + \subsection{grdef.spad \cite{1}} +-<>= +-${MID}/grdef.spad: ${IN}/grdef.spad.pamphlet +- @ echo 0 making ${MID}/grdef.spad from ${IN}/grdef.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/grdef.spad.pamphlet >grdef.spad ) +- +-@ + <>= + ${OUT}/GRDEF.o: ${MID}/GRDEF.NRLIB + @ echo 0 making ${OUT}/GRDEF.o from ${MID}/GRDEF.NRLIB +@@ -15509,13 +14519,6 @@ + + @ + \subsection{groebf.spad \cite{1}} +-<>= +-${MID}/groebf.spad: ${IN}/groebf.spad.pamphlet +- @ echo 0 making ${MID}/groebf.spad from ${IN}/groebf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/groebf.spad.pamphlet >groebf.spad ) +- +-@ + <>= + ${OUT}/GBF.o: ${MID}/GBF.NRLIB + @ echo 0 making ${OUT}/GBF.o from ${MID}/GBF.NRLIB +@@ -15548,13 +14551,6 @@ + + @ + \subsection{groebsol.spad \cite{1}} +-<>= +-${MID}/groebsol.spad: ${IN}/groebsol.spad.pamphlet +- @ echo 0 making ${MID}/groebsol.spad from ${IN}/groebsol.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/groebsol.spad.pamphlet >groebsol.spad ) +- +-@ + <>= + ${OUT}/GROEBSOL.o: ${MID}/GROEBSOL.NRLIB + @ echo 0 making ${OUT}/GROEBSOL.o from ${MID}/GROEBSOL.NRLIB +@@ -15587,13 +14583,6 @@ + + @ + \subsection{gseries.spad \cite{1}} +-<>= +-${MID}/gseries.spad: ${IN}/gseries.spad.pamphlet +- @ echo 0 making ${MID}/gseries.spad from ${IN}/gseries.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/gseries.spad.pamphlet >gseries.spad ) +- +-@ + <>= + ${OUT}/GSERIES.o: ${MID}/GSERIES.NRLIB + @ echo 0 making ${OUT}/GSERIES.o from ${MID}/GSERIES.NRLIB +@@ -15645,13 +14634,6 @@ + + @ + \subsection{ideal.spad \cite{1}} +-<>= +-${MID}/ideal.spad: ${IN}/ideal.spad.pamphlet +- @ echo 0 making ${MID}/ideal.spad from ${IN}/ideal.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ideal.spad.pamphlet >ideal.spad ) +- +-@ + <>= + ${OUT}/IDEAL.o: ${MID}/IDEAL.NRLIB + @ echo 0 making ${OUT}/IDEAL.o from ${MID}/IDEAL.NRLIB +@@ -15684,13 +14666,6 @@ + + @ + \subsection{idecomp.spad \cite{1}} +-<>= +-${MID}/idecomp.spad: ${IN}/idecomp.spad.pamphlet +- @ echo 0 making ${MID}/idecomp.spad from ${IN}/idecomp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/idecomp.spad.pamphlet >idecomp.spad ) +- +-@ + <>= + ${OUT}/IDECOMP.o: ${MID}/IDECOMP.NRLIB + @ echo 0 making ${OUT}/IDECOMP.o from ${MID}/IDECOMP.NRLIB +@@ -15723,13 +14698,6 @@ + + @ + \subsection{indexedp.spad \cite{1}} +-<>= +-${MID}/indexedp.spad: ${IN}/indexedp.spad.pamphlet +- @ echo 0 making ${MID}/indexedp.spad from ${IN}/indexedp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/indexedp.spad.pamphlet >indexedp.spad ) +- +-@ + <>= + ${OUT}/IDPAG.o: ${MID}/IDPAG.NRLIB + @ echo 0 making ${OUT}/IDPAG.o from ${MID}/IDPAG.NRLIB +@@ -15862,13 +14830,6 @@ + + @ + \subsection{infprod.spad \cite{1}} +-<>= +-${MID}/infprod.spad: ${IN}/infprod.spad.pamphlet +- @ echo 0 making ${MID}/infprod.spad from ${IN}/infprod.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/infprod.spad.pamphlet >infprod.spad ) +- +-@ + <>= + ${OUT}/INFPROD0.o: ${MID}/INFPROD0.NRLIB + @ echo 0 making ${OUT}/INFPROD0.o from ${MID}/INFPROD0.NRLIB +@@ -15961,13 +14922,6 @@ + + @ + \subsection{intaf.spad \cite{1}} +-<>= +-${MID}/intaf.spad: ${IN}/intaf.spad.pamphlet +- @ echo 0 making ${MID}/intaf.spad from ${IN}/intaf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/intaf.spad.pamphlet >intaf.spad ) +- +-@ + <>= + ${OUT}/INTAF.o: ${MID}/INTAF.NRLIB + @ echo 0 making ${OUT}/INTAF.o from ${MID}/INTAF.NRLIB +@@ -16040,13 +14994,6 @@ + + @ + \subsection{intalg.spad \cite{1}} +-<>= +-${MID}/intalg.spad: ${IN}/intalg.spad.pamphlet +- @ echo 0 making ${MID}/intalg.spad from ${IN}/intalg.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/intalg.spad.pamphlet >intalg.spad ) +- +-@ + <>= + ${OUT}/DBLRESP.o: ${MID}/DBLRESP.NRLIB + @ echo 0 making ${OUT}/DBLRESP.o from ${MID}/DBLRESP.NRLIB +@@ -16119,13 +15066,6 @@ + + @ + \subsection{intaux.spad \cite{1}} +-<>= +-${MID}/intaux.spad: ${IN}/intaux.spad.pamphlet +- @ echo 0 making ${MID}/intaux.spad from ${IN}/intaux.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/intaux.spad.pamphlet >intaux.spad ) +- +-@ + <>= + ${OUT}/IR.o: ${MID}/IR.NRLIB + @ echo 0 making ${OUT}/IR.o from ${MID}/IR.NRLIB +@@ -16178,13 +15118,6 @@ + + @ + \subsection{intclos.spad \cite{1}} +-<>= +-${MID}/intclos.spad: ${IN}/intclos.spad.pamphlet +- @ echo 0 making ${MID}/intclos.spad from ${IN}/intclos.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/intclos.spad.pamphlet >intclos.spad ) +- +-@ + <>= + ${OUT}/IBATOOL.o: ${MID}/IBATOOL.NRLIB + @ echo 0 making ${OUT}/IBATOOL.o from ${MID}/IBATOOL.NRLIB +@@ -16297,13 +15230,6 @@ + + @ + \subsection{intef.spad \cite{1}} +-<>= +-${MID}/intef.spad: ${IN}/intef.spad.pamphlet +- @ echo 0 making ${MID}/intef.spad from ${IN}/intef.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/intef.spad.pamphlet >intef.spad ) +- +-@ + <>= + ${OUT}/INTEF.o: ${MID}/INTEF.NRLIB + @ echo 0 making ${OUT}/INTEF.o from ${MID}/INTEF.NRLIB +@@ -16336,13 +15262,6 @@ + + @ + \subsection{integer.spad \cite{1}} +-<>= +-${MID}/integer.spad: ${IN}/integer.spad.pamphlet +- @ echo 0 making ${MID}/integer.spad from ${IN}/integer.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/integer.spad.pamphlet >integer.spad ) +- +-@ + <>= + ${OUT}/INT.o: ${MID}/INT.NRLIB + @ echo 0 making ${OUT}/INT.o from ${MID}/INT.NRLIB +@@ -16506,13 +15425,6 @@ + + @ + \subsection{integrat.spad \cite{1}} +-<>= +-${MID}/integrat.spad: ${IN}/integrat.spad.pamphlet +- @ echo 0 making ${MID}/integrat.spad from ${IN}/integrat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/integrat.spad.pamphlet >integrat.spad ) +- +-@ + <>= + ${OUT}/FSCINT.o: ${MID}/FSCINT.NRLIB + @ echo 0 making ${OUT}/FSCINT.o from ${MID}/FSCINT.NRLIB +@@ -16603,13 +15515,6 @@ + + @ + \subsection{interval.spad \cite{1}} +-<>= +-${MID}/interval.spad: ${IN}/interval.spad.pamphlet +- @ echo 0 making ${MID}/interval.spad from ${IN}/interval.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/interval.spad.pamphlet >interval.spad ) +- +-@ + <>= + ${OUT}/INTCAT.o: ${MID}/INTCAT.NRLIB + @ echo 0 making ${OUT}/INTCAT.o from ${MID}/INTCAT.NRLIB +@@ -16662,13 +15567,6 @@ + + @ + \subsection{intfact.spad \cite{1}} +-<>= +-${MID}/intfact.spad: ${IN}/intfact.spad.pamphlet +- @ echo 0 making ${MID}/intfact.spad from ${IN}/intfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/intfact.spad.pamphlet >intfact.spad ) +- +-@ + <>= + ${OUT}/INTFACT.o: ${MID}/INTFACT.NRLIB + @ echo 0 making ${OUT}/INTFACT.o from ${MID}/INTFACT.NRLIB +@@ -16741,13 +15639,6 @@ + + @ + \subsection{intpm.spad \cite{1}} +-<>= +-${MID}/intpm.spad: ${IN}/intpm.spad.pamphlet +- @ echo 0 making ${MID}/intpm.spad from ${IN}/intpm.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/intpm.spad.pamphlet >intpm.spad ) +- +-@ + <>= + ${OUT}/INTPM.o: ${MID}/INTPM.NRLIB + @ echo 0 making ${OUT}/INTPM.o from ${MID}/INTPM.NRLIB +@@ -16780,13 +15671,6 @@ + + @ + \subsection{intrf.spad \cite{1}} +-<>= +-${MID}/intrf.spad: ${IN}/intrf.spad.pamphlet +- @ echo 0 making ${MID}/intrf.spad from ${IN}/intrf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/intrf.spad.pamphlet >intrf.spad ) +- +-@ + <>= + ${OUT}/INTHERTR.o: ${MID}/INTHERTR.NRLIB + @ echo 0 making ${OUT}/INTHERTR.o from ${MID}/INTHERTR.NRLIB +@@ -16983,6 +15867,7 @@ + ${SPADBIN}/notangle ${IN}/invutils.as.pamphlet >invutils.as ) + + @ ++ + <>= + ${DOC}/invutils.as.dvi: ${IN}/invutils.as.pamphlet + @ echo 0 making ${DOC}/invutils.as.dvi from ${IN}/invutils.as.pamphlet +@@ -16995,13 +15880,6 @@ + + @ + \subsection{irexpand.spad \cite{1}} +-<>= +-${MID}/irexpand.spad: ${IN}/irexpand.spad.pamphlet +- @ echo 0 making ${MID}/irexpand.spad from ${IN}/irexpand.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/irexpand.spad.pamphlet >irexpand.spad ) +- +-@ + <>= + ${OUT}/IR2F.o: ${MID}/IR2F.NRLIB + @ echo 0 making ${OUT}/IR2F.o from ${MID}/IR2F.NRLIB +@@ -17054,13 +15932,6 @@ + + @ + \subsection{irsn.spad \cite{1}} +-<>= +-${MID}/irsn.spad: ${IN}/irsn.spad.pamphlet +- @ echo 0 making ${MID}/irsn.spad from ${IN}/irsn.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/irsn.spad.pamphlet >irsn.spad ) +- +-@ + <>= + ${OUT}/IRSN.o: ${MID}/IRSN.NRLIB + @ echo 0 making ${OUT}/IRSN.o from ${MID}/IRSN.NRLIB +@@ -17093,13 +15964,6 @@ + + @ + \subsection{ituple.spad \cite{1}} +-<>= +-${MID}/ituple.spad: ${IN}/ituple.spad.pamphlet +- @ echo 0 making ${MID}/ituple.spad from ${IN}/ituple.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ituple.spad.pamphlet >ituple.spad ) +- +-@ + <>= + ${OUT}/ITFUN2.o: ${MID}/ITFUN2.NRLIB + @ echo 0 making ${OUT}/ITFUN2.o from ${MID}/ITFUN2.NRLIB +@@ -17191,13 +16055,6 @@ + + @ + \subsection{kl.spad \cite{1}} +-<>= +-${MID}/kl.spad: ${IN}/kl.spad.pamphlet +- @ echo 0 making ${MID}/kl.spad from ${IN}/kl.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/kl.spad.pamphlet >kl.spad ) +- +-@ + <>= + ${OUT}/CACHSET.o: ${MID}/CACHSET.NRLIB + @ echo 0 making ${OUT}/CACHSET.o from ${MID}/CACHSET.NRLIB +@@ -17310,13 +16167,6 @@ + + @ + \subsection{kovacic.spad \cite{1}} +-<>= +-${MID}/kovacic.spad: ${IN}/kovacic.spad.pamphlet +- @ echo 0 making ${MID}/kovacic.spad from ${IN}/kovacic.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/kovacic.spad.pamphlet >kovacic.spad ) +- +-@ + <>= + ${OUT}/KOVACIC.o: ${MID}/KOVACIC.NRLIB + @ echo 0 making ${OUT}/KOVACIC.o from ${MID}/KOVACIC.NRLIB +@@ -17349,13 +16199,6 @@ + + @ + \subsection{laplace.spad \cite{1}} +-<>= +-${MID}/laplace.spad: ${IN}/laplace.spad.pamphlet +- @ echo 0 making ${MID}/laplace.spad from ${IN}/laplace.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/laplace.spad.pamphlet >laplace.spad ) +- +-@ + <>= + ${OUT}/INVLAPLA.o: ${MID}/INVLAPLA.NRLIB + @ echo 0 making ${OUT}/INVLAPLA.o from ${MID}/INVLAPLA.NRLIB +@@ -17408,13 +16251,6 @@ + + @ + \subsection{laurent.spad \cite{1}} +-<>= +-${MID}/laurent.spad: ${IN}/laurent.spad.pamphlet +- @ echo 0 making ${MID}/laurent.spad from ${IN}/laurent.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/laurent.spad.pamphlet >laurent.spad ) +- +-@ + <>= + ${OUT}/ULS.o: ${MID}/ULS.NRLIB + @ echo 0 making ${OUT}/ULS.o from ${MID}/ULS.NRLIB +@@ -17519,13 +16355,6 @@ + + @ + \subsection{leadcdet.spad \cite{1}} +-<>= +-${MID}/leadcdet.spad: ${IN}/leadcdet.spad.pamphlet +- @ echo 0 making ${MID}/leadcdet.spad from ${IN}/leadcdet.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/leadcdet.spad.pamphlet >leadcdet.spad ) +- +-@ + <>= + ${OUT}/LEADCDET.o: ${MID}/LEADCDET.NRLIB + @ echo 0 making ${OUT}/LEADCDET.o from ${MID}/LEADCDET.NRLIB +@@ -17558,13 +16387,6 @@ + + @ + \subsection{lie.spad \cite{1}} +-<>= +-${MID}/lie.spad: ${IN}/lie.spad.pamphlet +- @ echo 0 making ${MID}/lie.spad from ${IN}/lie.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/lie.spad.pamphlet >lie.spad ) +- +-@ + <>= + ${OUT}/JORDAN.o: ${MID}/JORDAN.NRLIB + @ echo 0 making ${OUT}/JORDAN.o from ${MID}/JORDAN.NRLIB +@@ -17637,13 +16459,6 @@ + + @ + \subsection{limitps.spad \cite{1}} +-<>= +-${MID}/limitps.spad: ${IN}/limitps.spad.pamphlet +- @ echo 0 making ${MID}/limitps.spad from ${IN}/limitps.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/limitps.spad.pamphlet >limitps.spad ) +- +-@ + <>= + ${OUT}/LIMITPS.o: ${MID}/LIMITPS.NRLIB + @ echo 0 making ${OUT}/LIMITPS.o from ${MID}/LIMITPS.NRLIB +@@ -17696,13 +16511,6 @@ + + @ + \subsection{lindep.spad \cite{1}} +-<>= +-${MID}/lindep.spad: ${IN}/lindep.spad.pamphlet +- @ echo 0 making ${MID}/lindep.spad from ${IN}/lindep.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/lindep.spad.pamphlet >lindep.spad ) +- +-@ + <>= + ${OUT}/LINDEP.o: ${MID}/LINDEP.NRLIB + @ echo 0 making ${OUT}/LINDEP.o from ${MID}/LINDEP.NRLIB +@@ -17755,13 +16563,6 @@ + + @ + \subsection{lingrob.spad \cite{1}} +-<>= +-${MID}/lingrob.spad: ${IN}/lingrob.spad.pamphlet +- @ echo 0 making ${MID}/lingrob.spad from ${IN}/lingrob.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/lingrob.spad.pamphlet >lingrob.spad ) +- +-@ + <>= + ${OUT}/LGROBP.o: ${MID}/LGROBP.NRLIB + @ echo 0 making ${OUT}/LGROBP.o from ${MID}/LGROBP.NRLIB +@@ -17794,13 +16595,6 @@ + + @ + \subsection{liouv.spad \cite{1}} +-<>= +-${MID}/liouv.spad: ${IN}/liouv.spad.pamphlet +- @ echo 0 making ${MID}/liouv.spad from ${IN}/liouv.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/liouv.spad.pamphlet >liouv.spad ) +- +-@ + <>= + ${OUT}/LF.o: ${MID}/LF.NRLIB + @ echo 0 making ${OUT}/LF.o from ${MID}/LF.NRLIB +@@ -17833,13 +16627,6 @@ + + @ + \subsection{listgcd.spad \cite{1}} +-<>= +-${MID}/listgcd.spad: ${IN}/listgcd.spad.pamphlet +- @ echo 0 making ${MID}/listgcd.spad from ${IN}/listgcd.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/listgcd.spad.pamphlet >listgcd.spad ) +- +-@ + <>= + ${OUT}/HEUGCD.o: ${MID}/HEUGCD.NRLIB + @ echo 0 making ${OUT}/HEUGCD.o from ${MID}/HEUGCD.NRLIB +@@ -17872,13 +16659,6 @@ + + @ + \subsection{list.spad \cite{1}} +-<>= +-${MID}/list.spad: ${IN}/list.spad.pamphlet +- @ echo 0 making ${MID}/list.spad from ${IN}/list.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/list.spad.pamphlet >list.spad ) +- +-@ + <>= + ${OUT}/ILIST.o: ${MID}/ILIST.NRLIB + @ echo 0 making ${OUT}/ILIST.o from ${MID}/ILIST.NRLIB +@@ -18045,13 +16825,6 @@ + + @ + \subsection{lmdict.spad \cite{1}} +-<>= +-${MID}/lmdict.spad: ${IN}/lmdict.spad.pamphlet +- @ echo 0 making ${MID}/lmdict.spad from ${IN}/lmdict.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/lmdict.spad.pamphlet >lmdict.spad ) +- +-@ + <>= + ${OUT}/LMDICT.o: ${MID}/LMDICT.NRLIB + @ echo 0 making ${OUT}/LMDICT.o from ${MID}/LMDICT.NRLIB +@@ -18084,13 +16857,6 @@ + + @ + \subsection{lodof.spad \cite{1}} +-<>= +-${MID}/lodof.spad: ${IN}/lodof.spad.pamphlet +- @ echo 0 making ${MID}/lodof.spad from ${IN}/lodof.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/lodof.spad.pamphlet >lodof.spad ) +- +-@ + <>= + ${OUT}/ASSOCEQ.o: ${MID}/ASSOCEQ.NRLIB + @ echo 0 making ${OUT}/ASSOCEQ.o from ${MID}/ASSOCEQ.NRLIB +@@ -18183,13 +16949,6 @@ + + @ + \subsection{lodop.spad \cite{1}} +-<>= +-${MID}/lodop.spad: ${IN}/lodop.spad.pamphlet +- @ echo 0 making ${MID}/lodop.spad from ${IN}/lodop.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/lodop.spad.pamphlet >lodop.spad ) +- +-@ + <>= + ${OUT}/DPMO.o: ${MID}/DPMO.NRLIB + @ echo 0 making ${OUT}/DPMO.o from ${MID}/DPMO.NRLIB +@@ -18322,13 +17081,6 @@ + + @ + \subsection{lodo.spad \cite{1}} +-<>= +-${MID}/lodo.spad: ${IN}/lodo.spad.pamphlet +- @ echo 0 making ${MID}/lodo.spad from ${IN}/lodo.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/lodo.spad.pamphlet >lodo.spad ) +- +-@ + <>= + ${OUT}/LODO.o: ${MID}/LODO.NRLIB + @ echo 0 making ${OUT}/LODO.o from ${MID}/LODO.NRLIB +@@ -18453,13 +17205,6 @@ + + @ + \subsection{manip.spad \cite{1}} +-<>= +-${MID}/manip.spad: ${IN}/manip.spad.pamphlet +- @ echo 0 making ${MID}/manip.spad from ${IN}/manip.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/manip.spad.pamphlet >manip.spad ) +- +-@ + <>= + ${OUT}/ALGMANIP.o: ${MID}/ALGMANIP.NRLIB + @ echo 0 making ${OUT}/ALGMANIP.o from ${MID}/ALGMANIP.NRLIB +@@ -18572,13 +17317,6 @@ + + @ + \subsection{mappkg.spad \cite{1}} +-<>= +-${MID}/mappkg.spad: ${IN}/mappkg.spad.pamphlet +- @ echo 0 making ${MID}/mappkg.spad from ${IN}/mappkg.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mappkg.spad.pamphlet >mappkg.spad ) +- +-@ + <>= + ${OUT}/MAPHACK1.o: ${MID}/MAPHACK1.NRLIB + @ echo 0 making ${OUT}/MAPHACK1.o from ${MID}/MAPHACK1.NRLIB +@@ -18711,13 +17449,6 @@ + + @ + \subsection{matcat.spad \cite{1}} +-<>= +-${MID}/matcat.spad: ${IN}/matcat.spad.pamphlet +- @ echo 0 making ${MID}/matcat.spad from ${IN}/matcat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/matcat.spad.pamphlet >matcat.spad ) +- +-@ + <>= + ${OUT}/MATCAT-.o: ${MID}/MATCAT.NRLIB + @ echo 0 making ${OUT}/MATCAT-.o from ${MID}/MATCAT-.NRLIB +@@ -18826,13 +17557,6 @@ + + @ + \subsection{matfuns.spad \cite{1}} +-<>= +-${MID}/matfuns.spad: ${IN}/matfuns.spad.pamphlet +- @ echo 0 making ${MID}/matfuns.spad from ${IN}/matfuns.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/matfuns.spad.pamphlet >matfuns.spad ) +- +-@ + <>= + ${OUT}/IMATLIN.o: ${MID}/IMATLIN.NRLIB + @ echo 0 making ${OUT}/IMATLIN.o from ${MID}/IMATLIN.NRLIB +@@ -18945,13 +17669,6 @@ + + @ + \subsection{matrix.spad \cite{1}} +-<>= +-${MID}/matrix.spad: ${IN}/matrix.spad.pamphlet +- @ echo 0 making ${MID}/matrix.spad from ${IN}/matrix.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/matrix.spad.pamphlet >matrix.spad ) +- +-@ + <>= + ${OUT}/IMATRIX.o: ${MID}/IMATRIX.NRLIB + @ echo 0 making ${OUT}/IMATRIX.o from ${MID}/IMATRIX.NRLIB +@@ -19044,13 +17761,6 @@ + + @ + \subsection{matstor.spad \cite{1}} +-<>= +-${MID}/matstor.spad: ${IN}/matstor.spad.pamphlet +- @ echo 0 making ${MID}/matstor.spad from ${IN}/matstor.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/matstor.spad.pamphlet >matstor.spad ) +- +-@ + <>= + ${OUT}/MATSTOR.o: ${MID}/MATSTOR.NRLIB + @ echo 0 making ${OUT}/MATSTOR.o from ${MID}/MATSTOR.NRLIB +@@ -19083,13 +17793,6 @@ + + @ + \subsection{mesh.spad \cite{1}} +-<>= +-${MID}/mesh.spad: ${IN}/mesh.spad.pamphlet +- @ echo 0 making ${MID}/mesh.spad from ${IN}/mesh.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mesh.spad.pamphlet >mesh.spad ) +- +-@ + <>= + ${OUT}/MESH.o: ${MID}/MESH.NRLIB + @ echo 0 making ${OUT}/MESH.o from ${MID}/MESH.NRLIB +@@ -19122,13 +17825,6 @@ + + @ + \subsection{mfinfact.spad \cite{1}} +-<>= +-${MID}/mfinfact.spad: ${IN}/mfinfact.spad.pamphlet +- @ echo 0 making ${MID}/mfinfact.spad from ${IN}/mfinfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mfinfact.spad.pamphlet >mfinfact.spad ) +- +-@ + <>= + ${OUT}/MFINFACT.o: ${MID}/MFINFACT.NRLIB + @ echo 0 making ${OUT}/MFINFACT.o from ${MID}/MFINFACT.NRLIB +@@ -19161,13 +17857,6 @@ + + @ + \subsection{misc.spad \cite{1}} +-<>= +-${MID}/misc.spad: ${IN}/misc.spad.pamphlet +- @ echo 0 making ${MID}/misc.spad from ${IN}/misc.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/misc.spad.pamphlet >misc.spad ) +- +-@ + <>= + ${OUT}/SAOS.o: ${MID}/SAOS.NRLIB + @ echo 0 making ${OUT}/SAOS.o from ${MID}/SAOS.NRLIB +@@ -19200,13 +17889,6 @@ + + @ + \subsection{mkfunc.spad \cite{1}} +-<>= +-${MID}/mkfunc.spad: ${IN}/mkfunc.spad.pamphlet +- @ echo 0 making ${MID}/mkfunc.spad from ${IN}/mkfunc.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mkfunc.spad.pamphlet >mkfunc.spad ) +- +-@ + <>= + ${OUT}/INFORM.o: ${MID}/INFORM.NRLIB + @ echo 0 making ${OUT}/INFORM.o from ${MID}/INFORM.NRLIB +@@ -19339,13 +18021,6 @@ + + @ + \subsection{mkrecord.spad \cite{1}} +-<>= +-${MID}/mkrecord.spad: ${IN}/mkrecord.spad.pamphlet +- @ echo 0 making ${MID}/mkrecord.spad from ${IN}/mkrecord.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mkrecord.spad.pamphlet >mkrecord.spad ) +- +-@ + <>= + ${OUT}/MKRECORD.o: ${MID}/MKRECORD.NRLIB + @ echo 0 making ${OUT}/MKRECORD.o from ${MID}/MKRECORD.NRLIB +@@ -19378,13 +18053,6 @@ + + @ + \subsection{mlift.spad.jhd \cite{1}} +-<>= +-${MID}/mlift.spad.jhd: ${IN}/mlift.spad.jhd.pamphlet +- @ echo 0 making ${MID}/mlift.spad.jhd from ${IN}/mlift.spad.jhd.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mlift.spad.jhd.pamphlet >mlift.spad.jhd ) +- +-@ + <>= + ${DOC}/mlift.spad.jhd.dvi: ${IN}/mlift.spad.jhd.pamphlet + @ echo 0 making ${DOC}/mlift.spad.jhd.dvi from ${IN}/mlift.spad.jhd.pamphlet +@@ -19397,13 +18065,6 @@ + + @ + \subsection{mlift.spad \cite{1}} +-<>= +-${MID}/mlift.spad: ${IN}/mlift.spad.pamphlet +- @ echo 0 making ${MID}/mlift.spad from ${IN}/mlift.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mlift.spad.pamphlet >mlift.spad ) +- +-@ + <>= + ${OUT}/MLIFT.o: ${MID}/MLIFT.NRLIB + @ echo 0 making ${OUT}/MLIFT.o from ${MID}/MLIFT.NRLIB +@@ -19436,13 +18097,6 @@ + + @ + \subsection{moddfact.spad \cite{1}} +-<>= +-${MID}/moddfact.spad: ${IN}/moddfact.spad.pamphlet +- @ echo 0 making ${MID}/moddfact.spad from ${IN}/moddfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/moddfact.spad.pamphlet >moddfact.spad ) +- +-@ + <>= + ${OUT}/MDDFACT.o: ${MID}/MDDFACT.NRLIB + @ echo 0 making ${OUT}/MDDFACT.o from ${MID}/MDDFACT.NRLIB +@@ -19475,13 +18129,6 @@ + + @ + \subsection{modgcd.spad \cite{1}} +-<>= +-${MID}/modgcd.spad: ${IN}/modgcd.spad.pamphlet +- @ echo 0 making ${MID}/modgcd.spad from ${IN}/modgcd.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/modgcd.spad.pamphlet >modgcd.spad ) +- +-@ + <>= + ${OUT}/INMODGCD.o: ${MID}/INMODGCD.NRLIB + @ echo 0 making ${OUT}/INMODGCD.o from ${MID}/INMODGCD.NRLIB +@@ -19514,13 +18161,6 @@ + + @ + \subsection{modmonom.spad \cite{1}} +-<>= +-${MID}/modmonom.spad: ${IN}/modmonom.spad.pamphlet +- @ echo 0 making ${MID}/modmonom.spad from ${IN}/modmonom.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/modmonom.spad.pamphlet >modmonom.spad ) +- +-@ + <>= + ${OUT}/GMODPOL.o: ${MID}/GMODPOL.NRLIB + @ echo 0 making ${OUT}/GMODPOL.o from ${MID}/GMODPOL.NRLIB +@@ -19573,13 +18213,6 @@ + + @ + \subsection{modmon.spad \cite{1}} +-<>= +-${MID}/modmon.spad: ${IN}/modmon.spad.pamphlet +- @ echo 0 making ${MID}/modmon.spad from ${IN}/modmon.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/modmon.spad.pamphlet >modmon.spad ) +- +-@ + <>= + ${OUT}/MODMON.o: ${MID}/MODMON.NRLIB + @ echo 0 making ${OUT}/MODMON.o from ${MID}/MODMON.NRLIB +@@ -19612,13 +18245,6 @@ + + @ + \subsection{modring.spad \cite{1}} +-<>= +-${MID}/modring.spad: ${IN}/modring.spad.pamphlet +- @ echo 0 making ${MID}/modring.spad from ${IN}/modring.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/modring.spad.pamphlet >modring.spad ) +- +-@ + <>= + ${OUT}/EMR.o: ${MID}/EMR.NRLIB + @ echo 0 making ${OUT}/EMR.o from ${MID}/EMR.NRLIB +@@ -19691,13 +18317,6 @@ + + @ + \subsection{moebius.spad \cite{1}} +-<>= +-${MID}/moebius.spad: ${IN}/moebius.spad.pamphlet +- @ echo 0 making ${MID}/moebius.spad from ${IN}/moebius.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/moebius.spad.pamphlet >moebius.spad ) +- +-@ + <>= + ${OUT}/MOEBIUS.o: ${MID}/MOEBIUS.NRLIB + @ echo 0 making ${OUT}/MOEBIUS.o from ${MID}/MOEBIUS.NRLIB +@@ -19730,13 +18349,6 @@ + + @ + \subsection{mring.spad \cite{1}} +-<>= +-${MID}/mring.spad: ${IN}/mring.spad.pamphlet +- @ echo 0 making ${MID}/mring.spad from ${IN}/mring.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mring.spad.pamphlet >mring.spad ) +- +-@ + <>= + ${OUT}/MRF2.o: ${MID}/MRF2.NRLIB + @ echo 0 making ${OUT}/MRF2.o from ${MID}/MRF2.NRLIB +@@ -19789,13 +18401,6 @@ + + @ + \subsection{mset.spad \cite{1}} +-<>= +-${MID}/mset.spad: ${IN}/mset.spad.pamphlet +- @ echo 0 making ${MID}/mset.spad from ${IN}/mset.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mset.spad.pamphlet >mset.spad ) +- +-@ + <>= + ${OUT}/MSET.o: ${MID}/MSET.NRLIB + @ echo 0 making ${OUT}/MSET.o from ${MID}/MSET.NRLIB +@@ -19828,13 +18433,6 @@ + + @ + \subsection{mts.spad \cite{1}} +-<>= +-${MID}/mts.spad: ${IN}/mts.spad.pamphlet +- @ echo 0 making ${MID}/mts.spad from ${IN}/mts.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/mts.spad.pamphlet >mts.spad ) +- +-@ + <>= + ${OUT}/SMTS.o: ${MID}/SMTS.NRLIB + @ echo 0 making ${OUT}/SMTS.o from ${MID}/SMTS.NRLIB +@@ -19887,13 +18485,6 @@ + + @ + \subsection{multfact.spad \cite{1}} +-<>= +-${MID}/multfact.spad: ${IN}/multfact.spad.pamphlet +- @ echo 0 making ${MID}/multfact.spad from ${IN}/multfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/multfact.spad.pamphlet >multfact.spad ) +- +-@ + <>= + ${OUT}/ALGMFACT.o: ${MID}/ALGMFACT.NRLIB + @ echo 0 making ${OUT}/ALGMFACT.o from ${MID}/ALGMFACT.NRLIB +@@ -19966,13 +18557,6 @@ + + @ + \subsection{multpoly.spad \cite{1}} +-<>= +-${MID}/multpoly.spad: ${IN}/multpoly.spad.pamphlet +- @ echo 0 making ${MID}/multpoly.spad from ${IN}/multpoly.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/multpoly.spad.pamphlet >multpoly.spad ) +- +-@ + <>= + ${OUT}/INDE.o: ${MID}/INDE.NRLIB + @ echo 0 making ${OUT}/INDE.o from ${MID}/INDE.NRLIB +@@ -20085,13 +18669,6 @@ + + @ + \subsection{multsqfr.spad \cite{1}} +-<>= +-${MID}/multsqfr.spad: ${IN}/multsqfr.spad.pamphlet +- @ echo 0 making ${MID}/multsqfr.spad from ${IN}/multsqfr.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/multsqfr.spad.pamphlet >multsqfr.spad ) +- +-@ + <>= + ${OUT}/MULTSQFR.o: ${MID}/MULTSQFR.NRLIB + @ echo 0 making ${OUT}/MULTSQFR.o from ${MID}/MULTSQFR.NRLIB +@@ -20124,13 +18701,6 @@ + + @ + \subsection{naalgc.spad \cite{1}} +-<>= +-${MID}/naalgc.spad: ${IN}/naalgc.spad.pamphlet +- @ echo 0 making ${MID}/naalgc.spad from ${IN}/naalgc.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/naalgc.spad.pamphlet >naalgc.spad ) +- +-@ + <>= + ${OUT}/FINAALG-.o: ${MID}/FINAALG.NRLIB + @ echo 0 making ${OUT}/FINAALG-.o from ${MID}/FINAALG-.NRLIB +@@ -20367,13 +18937,6 @@ + + @ + \subsection{naalg.spad \cite{1}} +-<>= +-${MID}/naalg.spad: ${IN}/naalg.spad.pamphlet +- @ echo 0 making ${MID}/naalg.spad from ${IN}/naalg.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/naalg.spad.pamphlet >naalg.spad ) +- +-@ + <>= + ${OUT}/ALGPKG.o: ${MID}/ALGPKG.NRLIB + @ echo 0 making ${OUT}/ALGPKG.o from ${MID}/ALGPKG.NRLIB +@@ -20471,7 +19034,7 @@ + @ echo 0 making ${MID}/ndftip.as from ${IN}/ndftip.as.pamphlet + @(cd ${MID} ; \ + ${SPADBIN}/notangle ${IN}/ndftip.as.pamphlet >ndftip.as ) +- ++ + @ + <>= + ${DOC}/ndftip.as.dvi: ${IN}/ndftip.as.pamphlet +@@ -20490,7 +19053,7 @@ + @ echo 0 making ${MID}/nepip.as from ${IN}/nepip.as.pamphlet + @(cd ${MID} ; \ + ${SPADBIN}/notangle ${IN}/nepip.as.pamphlet >nepip.as ) +- ++ + @ + <>= + ${DOC}/nepip.as.dvi: ${IN}/nepip.as.pamphlet +@@ -20504,13 +19067,6 @@ + + @ + \subsection{newdata.spad \cite{1}} +-<>= +-${MID}/newdata.spad: ${IN}/newdata.spad.pamphlet +- @ echo 0 making ${MID}/newdata.spad from ${IN}/newdata.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/newdata.spad.pamphlet >newdata.spad ) +- +-@ + <>= + ${OUT}/IPRNTPK.o: ${MID}/IPRNTPK.NRLIB + @ echo 0 making ${OUT}/IPRNTPK.o from ${MID}/IPRNTPK.NRLIB +@@ -20603,13 +19159,6 @@ + + @ + \subsection{newpoint.spad \cite{1}} +-<>= +-${MID}/newpoint.spad: ${IN}/newpoint.spad.pamphlet +- @ echo 0 making ${MID}/newpoint.spad from ${IN}/newpoint.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/newpoint.spad.pamphlet >newpoint.spad ) +- +-@ + <>= + ${OUT}/COMPPROP.o: ${MID}/COMPPROP.NRLIB + @ echo 0 making ${OUT}/COMPPROP.o from ${MID}/COMPPROP.NRLIB +@@ -20742,13 +19291,6 @@ + + @ + \subsection{newpoly.spad \cite{1}} +-<>= +-${MID}/newpoly.spad: ${IN}/newpoly.spad.pamphlet +- @ echo 0 making ${MID}/newpoly.spad from ${IN}/newpoly.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/newpoly.spad.pamphlet >newpoly.spad ) +- +-@ + <>= + ${OUT}/NSMP.o: ${MID}/NSMP.NRLIB + @ echo 0 making ${OUT}/NSMP.o from ${MID}/NSMP.NRLIB +@@ -20853,13 +19395,6 @@ + + @ + \subsection{nlinsol.spad \cite{1}} +-<>= +-${MID}/nlinsol.spad: ${IN}/nlinsol.spad.pamphlet +- @ echo 0 making ${MID}/nlinsol.spad from ${IN}/nlinsol.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/nlinsol.spad.pamphlet >nlinsol.spad ) +- +-@ + <>= + ${OUT}/NLINSOL.o: ${MID}/NLINSOL.NRLIB + @ echo 0 making ${OUT}/NLINSOL.o from ${MID}/NLINSOL.NRLIB +@@ -20912,13 +19447,6 @@ + + @ + \subsection{nlode.spad \cite{1}} +-<>= +-${MID}/nlode.spad: ${IN}/nlode.spad.pamphlet +- @ echo 0 making ${MID}/nlode.spad from ${IN}/nlode.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/nlode.spad.pamphlet >nlode.spad ) +- +-@ + <>= + ${OUT}/NODE1.o: ${MID}/NODE1.NRLIB + @ echo 0 making ${OUT}/NODE1.o from ${MID}/NODE1.NRLIB +@@ -20970,13 +19498,6 @@ + + @ + \subsection{npcoef.spad \cite{1}} +-<>= +-${MID}/npcoef.spad: ${IN}/npcoef.spad.pamphlet +- @ echo 0 making ${MID}/npcoef.spad from ${IN}/npcoef.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/npcoef.spad.pamphlet >npcoef.spad ) +- +-@ + <>= + ${OUT}/NPCOEF.o: ${MID}/NPCOEF.NRLIB + @ echo 0 making ${OUT}/NPCOEF.o from ${MID}/NPCOEF.NRLIB +@@ -21030,9 +19551,9 @@ + \subsection{nrc.as \cite{1}} + <>= + ${MID}/nrc.as: ${IN}/nrc.as.pamphlet +- @ echo 0 making ${MID}/nrc.as from ${IN}/nrc.as.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/nrc.as.pamphlet >nrc.as ) ++@ echo 0 making ${MID}/nrc.as from ${IN}/nrc.as.pamphlet ++@(cd ${MID} ; \ ++${SPADBIN}/notangle ${IN}/nrc.as.pamphlet >nrc.as ) + + @ + <>= +@@ -21047,13 +19568,6 @@ + + @ + \subsection{nregset.spad \cite{1}} +-<>= +-${MID}/nregset.spad: ${IN}/nregset.spad.pamphlet +- @ echo 0 making ${MID}/nregset.spad from ${IN}/nregset.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/nregset.spad.pamphlet >nregset.spad ) +- +-@ + <>= + ${OUT}/NORMPK.o: ${MID}/NORMPK.NRLIB + @ echo 0 making ${OUT}/NORMPK.o from ${MID}/NORMPK.NRLIB +@@ -21113,6 +19627,7 @@ + ${SPADBIN}/notangle ${IN}/nsfip.as.pamphlet >nsfip.as ) + + @ ++ + <>= + ${DOC}/nsfip.as.dvi: ${IN}/nsfip.as.pamphlet + @ echo 0 making ${DOC}/nsfip.as.dvi from ${IN}/nsfip.as.pamphlet +@@ -21125,13 +19640,6 @@ + + @ + \subsection{nsregset.spad \cite{1}} +-<>= +-${MID}/nsregset.spad: ${IN}/nsregset.spad.pamphlet +- @ echo 0 making ${MID}/nsregset.spad from ${IN}/nsregset.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/nsregset.spad.pamphlet >nsregset.spad ) +- +-@ + <>= + ${OUT}/LAZM3PK.o: ${MID}/LAZM3PK.NRLIB + @ echo 0 making ${OUT}/LAZM3PK.o from ${MID}/LAZM3PK.NRLIB +@@ -21184,13 +19692,6 @@ + + @ + \subsection{numeigen.spad \cite{1}} +-<>= +-${MID}/numeigen.spad: ${IN}/numeigen.spad.pamphlet +- @ echo 0 making ${MID}/numeigen.spad from ${IN}/numeigen.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/numeigen.spad.pamphlet >numeigen.spad ) +- +-@ + <>= + ${OUT}/INEP.o: ${MID}/INEP.NRLIB + @ echo 0 making ${OUT}/INEP.o from ${MID}/INEP.NRLIB +@@ -21263,13 +19764,6 @@ + + @ + \subsection{numeric.spad \cite{1}} +-<>= +-${MID}/numeric.spad: ${IN}/numeric.spad.pamphlet +- @ echo 0 making ${MID}/numeric.spad from ${IN}/numeric.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/numeric.spad.pamphlet >numeric.spad ) +- +-@ + <>= + ${OUT}/DRAWHACK.o: ${MID}/DRAWHACK.NRLIB + @ echo 0 making ${OUT}/DRAWHACK.o from ${MID}/DRAWHACK.NRLIB +@@ -21322,13 +19816,6 @@ + + @ + \subsection{numode.spad \cite{1}} +-<>= +-${MID}/numode.spad: ${IN}/numode.spad.pamphlet +- @ echo 0 making ${MID}/numode.spad from ${IN}/numode.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/numode.spad.pamphlet >numode.spad ) +- +-@ + <>= + ${OUT}/NUMODE.o: ${MID}/NUMODE.NRLIB + @ echo 0 making ${OUT}/NUMODE.o from ${MID}/NUMODE.NRLIB +@@ -21361,13 +19848,6 @@ + + @ + \subsection{numquad.spad \cite{1}} +-<>= +-${MID}/numquad.spad: ${IN}/numquad.spad.pamphlet +- @ echo 0 making ${MID}/numquad.spad from ${IN}/numquad.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/numquad.spad.pamphlet >numquad.spad ) +- +-@ + <>= + ${OUT}/NUMQUAD.o: ${MID}/NUMQUAD.NRLIB + @ echo 0 making ${OUT}/NUMQUAD.o from ${MID}/NUMQUAD.NRLIB +@@ -21400,13 +19880,6 @@ + + @ + \subsection{numsolve.spad \cite{1}} +-<>= +-${MID}/numsolve.spad: ${IN}/numsolve.spad.pamphlet +- @ echo 0 making ${MID}/numsolve.spad from ${IN}/numsolve.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/numsolve.spad.pamphlet >numsolve.spad ) +- +-@ + <>= + ${OUT}/FLOATCP.o: ${MID}/FLOATCP.NRLIB + @ echo 0 making ${OUT}/FLOATCP.o from ${MID}/FLOATCP.NRLIB +@@ -21479,13 +19952,6 @@ + + @ + \subsection{numtheor.spad \cite{1}} +-<>= +-${MID}/numtheor.spad: ${IN}/numtheor.spad.pamphlet +- @ echo 0 making ${MID}/numtheor.spad from ${IN}/numtheor.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/numtheor.spad.pamphlet >numtheor.spad ) +- +-@ + <>= + ${OUT}/INTHEORY.o: ${MID}/INTHEORY.NRLIB + @ echo 0 making ${OUT}/INTHEORY.o from ${MID}/INTHEORY.NRLIB +@@ -21538,13 +20004,6 @@ + + @ + \subsection{oct.spad \cite{1}} +-<>= +-${MID}/oct.spad: ${IN}/oct.spad.pamphlet +- @ echo 0 making ${MID}/oct.spad from ${IN}/oct.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/oct.spad.pamphlet >oct.spad ) +- +-@ + <>= + ${OUT}/OC-.o: ${MID}/OC.NRLIB + @ echo 0 making ${OUT}/OC-.o from ${MID}/OC-.NRLIB +@@ -21629,13 +20088,6 @@ + + @ + \subsection{odealg.spad \cite{1}} +-<>= +-${MID}/odealg.spad: ${IN}/odealg.spad.pamphlet +- @ echo 0 making ${MID}/odealg.spad from ${IN}/odealg.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/odealg.spad.pamphlet >odealg.spad ) +- +-@ + <>= + ${OUT}/ODEPAL.o: ${MID}/ODEPAL.NRLIB + @ echo 0 making ${OUT}/ODEPAL.o from ${MID}/ODEPAL.NRLIB +@@ -21708,13 +20160,6 @@ + + @ + \subsection{odeef.spad \cite{1}} +-<>= +-${MID}/odeef.spad: ${IN}/odeef.spad.pamphlet +- @ echo 0 making ${MID}/odeef.spad from ${IN}/odeef.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/odeef.spad.pamphlet >odeef.spad ) +- +-@ + <>= + ${OUT}/LODEEF.o: ${MID}/LODEEF.NRLIB + @ echo 0 making ${OUT}/LODEEF.o from ${MID}/LODEEF.NRLIB +@@ -21787,13 +20232,6 @@ + + @ + \subsection{oderf.spad \cite{1}} +-<>= +-${MID}/oderf.spad: ${IN}/oderf.spad.pamphlet +- @ echo 0 making ${MID}/oderf.spad from ${IN}/oderf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/oderf.spad.pamphlet >oderf.spad ) +- +-@ + <>= + ${OUT}/BALFACT.o: ${MID}/BALFACT.NRLIB + @ echo 0 making ${OUT}/BALFACT.o from ${MID}/BALFACT.NRLIB +@@ -21966,13 +20404,6 @@ + + @ + \subsection{omcat.spad \cite{1}} +-<>= +-${MID}/omcat.spad: ${IN}/omcat.spad.pamphlet +- @ echo 0 making ${MID}/omcat.spad from ${IN}/omcat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/omcat.spad.pamphlet >omcat.spad ) +- +-@ + <>= + ${OUT}/OM.o: ${MID}/OM.NRLIB + @ echo 0 making ${OUT}/OM.o from ${MID}/OM.NRLIB +@@ -22005,13 +20436,6 @@ + + @ + \subsection{omdev.spad \cite{1}} +-<>= +-${MID}/omdev.spad: ${IN}/omdev.spad.pamphlet +- @ echo 0 making ${MID}/omdev.spad from ${IN}/omdev.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/omdev.spad.pamphlet >omdev.spad ) +- +-@ + <>= + ${OUT}/OMENC.o: ${MID}/OMENC.NRLIB + @ echo 0 making ${OUT}/OMENC.o from ${MID}/OMENC.NRLIB +@@ -22104,13 +20528,6 @@ + + @ + \subsection{omerror.spad \cite{1}} +-<>= +-${MID}/omerror.spad: ${IN}/omerror.spad.pamphlet +- @ echo 0 making ${MID}/omerror.spad from ${IN}/omerror.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/omerror.spad.pamphlet >omerror.spad ) +- +-@ + <>= + ${OUT}/OMERR.o: ${MID}/OMERR.NRLIB + @ echo 0 making ${OUT}/OMERR.o from ${MID}/OMERR.NRLIB +@@ -22163,13 +20580,6 @@ + + @ + \subsection{omserver.spad \cite{1}} +-<>= +-${MID}/omserver.spad: ${IN}/omserver.spad.pamphlet +- @ echo 0 making ${MID}/omserver.spad from ${IN}/omserver.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/omserver.spad.pamphlet >omserver.spad ) +- +-@ + <>= + ${OUT}/OMSERVER.o: ${MID}/OMSERVER.NRLIB + @ echo 0 making ${OUT}/OMSERVER.o from ${MID}/OMSERVER.NRLIB +@@ -22202,13 +20612,6 @@ + + @ + \subsection{opalg.spad \cite{1}} +-<>= +-${MID}/opalg.spad: ${IN}/opalg.spad.pamphlet +- @ echo 0 making ${MID}/opalg.spad from ${IN}/opalg.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/opalg.spad.pamphlet >opalg.spad ) +- +-@ + <>= + ${OUT}/MODOP.o: ${MID}/MODOP.NRLIB + @ echo 0 making ${OUT}/MODOP.o from ${MID}/MODOP.NRLIB +@@ -22261,13 +20664,6 @@ + + @ + \subsection{openmath.spad \cite{1}} +-<>= +-${MID}/openmath.spad: ${IN}/openmath.spad.pamphlet +- @ echo 0 making ${MID}/openmath.spad from ${IN}/openmath.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/openmath.spad.pamphlet >openmath.spad ) +- +-@ + <>= + ${OUT}/OMEXPR.o: ${MID}/OMEXPR.NRLIB + @ echo 0 making ${OUT}/OMEXPR.o from ${MID}/OMEXPR.NRLIB +@@ -22300,13 +20696,6 @@ + + @ + \subsection{op.spad \cite{1}} +-<>= +-${MID}/op.spad: ${IN}/op.spad.pamphlet +- @ echo 0 making ${MID}/op.spad from ${IN}/op.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/op.spad.pamphlet >op.spad ) +- +-@ + <>= + ${OUT}/BOP.o: ${MID}/BOP.NRLIB + @ echo 0 making ${OUT}/BOP.o from ${MID}/BOP.NRLIB +@@ -22379,13 +20768,6 @@ + + @ + \subsection{ore.spad \cite{1}} +-<>= +-${MID}/ore.spad: ${IN}/ore.spad.pamphlet +- @ echo 0 making ${MID}/ore.spad from ${IN}/ore.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ore.spad.pamphlet >ore.spad ) +- +-@ + <>= + ${OUT}/APPLYORE.o: ${MID}/APPLYORE.NRLIB + @ echo 0 making ${OUT}/APPLYORE.o from ${MID}/APPLYORE.NRLIB +@@ -22530,13 +20912,6 @@ + + @ + \subsection{outform.spad \cite{1}} +-<>= +-${MID}/outform.spad: ${IN}/outform.spad.pamphlet +- @ echo 0 making ${MID}/outform.spad from ${IN}/outform.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/outform.spad.pamphlet >outform.spad ) +- +-@ + <>= + ${OUT}/NUMFMT.o: ${MID}/NUMFMT.NRLIB + @ echo 0 making ${OUT}/NUMFMT.o from ${MID}/NUMFMT.NRLIB +@@ -22606,13 +20981,6 @@ + + @ + \subsection{out.spad \cite{1}} +-<>= +-${MID}/out.spad: ${IN}/out.spad.pamphlet +- @ echo 0 making ${MID}/out.spad from ${IN}/out.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/out.spad.pamphlet >out.spad ) +- +-@ + <>= + ${OUT}/DISPLAY.o: ${MID}/DISPLAY.NRLIB + @ echo 0 making ${OUT}/DISPLAY.o from ${MID}/DISPLAY.NRLIB +@@ -22685,13 +21053,6 @@ + + @ + \subsection{pade.spad \cite{1}} +-<>= +-${MID}/pade.spad: ${IN}/pade.spad.pamphlet +- @ echo 0 making ${MID}/pade.spad from ${IN}/pade.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pade.spad.pamphlet >pade.spad ) +- +-@ + <>= + ${OUT}/PADE.o: ${MID}/PADE.NRLIB + @ echo 0 making ${OUT}/PADE.o from ${MID}/PADE.NRLIB +@@ -22744,13 +21105,6 @@ + + @ + \subsection{padiclib.spad \cite{1}} +-<>= +-${MID}/padiclib.spad: ${IN}/padiclib.spad.pamphlet +- @ echo 0 making ${MID}/padiclib.spad from ${IN}/padiclib.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/padiclib.spad.pamphlet >padiclib.spad ) +- +-@ + <>= + ${OUT}/IBACHIN.o: ${MID}/IBACHIN.NRLIB + @ echo 0 making ${OUT}/IBACHIN.o from ${MID}/IBACHIN.NRLIB +@@ -22823,13 +21177,6 @@ + + @ + \subsection{padic.spad \cite{1}} +-<>= +-${MID}/padic.spad: ${IN}/padic.spad.pamphlet +- @ echo 0 making ${MID}/padic.spad from ${IN}/padic.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/padic.spad.pamphlet >padic.spad ) +- +-@ + <>= + ${OUT}/BPADIC.o: ${MID}/BPADIC.NRLIB + @ echo 0 making ${OUT}/BPADIC.o from ${MID}/BPADIC.NRLIB +@@ -22982,13 +21329,6 @@ + + @ + \subsection{paramete.spad \cite{1}} +-<>= +-${MID}/paramete.spad: ${IN}/paramete.spad.pamphlet +- @ echo 0 making ${MID}/paramete.spad from ${IN}/paramete.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/paramete.spad.pamphlet >paramete.spad ) +- +-@ + <>= + ${OUT}/PARPCURV.o: ${MID}/PARPCURV.NRLIB + @ echo 0 making ${OUT}/PARPCURV.o from ${MID}/PARPCURV.NRLIB +@@ -23121,13 +21461,6 @@ + + @ + \subsection{partperm.spad \cite{1}} +-<>= +-${MID}/partperm.spad: ${IN}/partperm.spad.pamphlet +- @ echo 0 making ${MID}/partperm.spad from ${IN}/partperm.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/partperm.spad.pamphlet >partperm.spad ) +- +-@ + <>= + ${OUT}/PARTPERM.o: ${MID}/PARTPERM.NRLIB + @ echo 0 making ${OUT}/PARTPERM.o from ${MID}/PARTPERM.NRLIB +@@ -23160,13 +21493,6 @@ + + @ + \subsection{patmatch1.spad \cite{1}} +-<>= +-${MID}/patmatch1.spad: ${IN}/patmatch1.spad.pamphlet +- @ echo 0 making ${MID}/patmatch1.spad from ${IN}/patmatch1.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/patmatch1.spad.pamphlet >patmatch1.spad ) +- +-@ + <>= + ${OUT}/FPATMAB.o: ${MID}/FPATMAB.NRLIB + @ echo 0 making ${OUT}/FPATMAB.o from ${MID}/FPATMAB.NRLIB +@@ -23379,13 +21705,6 @@ + + @ + \subsection{patmatch2.spad \cite{1}} +-<>= +-${MID}/patmatch2.spad: ${IN}/patmatch2.spad.pamphlet +- @ echo 0 making ${MID}/patmatch2.spad from ${IN}/patmatch2.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/patmatch2.spad.pamphlet >patmatch2.spad ) +- +-@ + <>= + ${OUT}/PATMATCH.o: ${MID}/PATMATCH.NRLIB + @ echo 0 making ${OUT}/PATMATCH.o from ${MID}/PATMATCH.NRLIB +@@ -23498,13 +21817,6 @@ + + @ + \subsection{pattern.spad \cite{1}} +-<>= +-${MID}/pattern.spad: ${IN}/pattern.spad.pamphlet +- @ echo 0 making ${MID}/pattern.spad from ${IN}/pattern.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pattern.spad.pamphlet >pattern.spad ) +- +-@ + <>= + ${OUT}/PATAB.o: ${MID}/PATAB.NRLIB + @ echo 0 making ${OUT}/PATAB.o from ${MID}/PATAB.NRLIB +@@ -23597,13 +21909,6 @@ + + @ + \subsection{pcurve.spad \cite{1}} +-<>= +-${MID}/pcurve.spad: ${IN}/pcurve.spad.pamphlet +- @ echo 0 making ${MID}/pcurve.spad from ${IN}/pcurve.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pcurve.spad.pamphlet >pcurve.spad ) +- +-@ + <>= + ${OUT}/PPCURVE.o: ${MID}/PPCURVE.NRLIB + @ echo 0 making ${OUT}/PPCURVE.o from ${MID}/PPCURVE.NRLIB +@@ -23656,13 +21961,6 @@ + + @ + \subsection{pdecomp.spad \cite{1}} +-<>= +-${MID}/pdecomp.spad: ${IN}/pdecomp.spad.pamphlet +- @ echo 0 making ${MID}/pdecomp.spad from ${IN}/pdecomp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pdecomp.spad.pamphlet >pdecomp.spad ) +- +-@ + <>= + ${OUT}/PCOMP.o: ${MID}/PCOMP.NRLIB + @ echo 0 making ${OUT}/PCOMP.o from ${MID}/PCOMP.NRLIB +@@ -23715,13 +22013,6 @@ + + @ + \subsection{perman.spad \cite{1}} +-<>= +-${MID}/perman.spad: ${IN}/perman.spad.pamphlet +- @ echo 0 making ${MID}/perman.spad from ${IN}/perman.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/perman.spad.pamphlet >perman.spad ) +- +-@ + <>= + ${OUT}/GRAY.o: ${MID}/GRAY.NRLIB + @ echo 0 making ${OUT}/GRAY.o from ${MID}/GRAY.NRLIB +@@ -23774,13 +22065,6 @@ + + @ + \subsection{permgrps.spad \cite{1}} +-<>= +-${MID}/permgrps.spad: ${IN}/permgrps.spad.pamphlet +- @ echo 0 making ${MID}/permgrps.spad from ${IN}/permgrps.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/permgrps.spad.pamphlet >permgrps.spad ) +- +-@ + <>= + ${OUT}/PERMGRP.o: ${MID}/PERMGRP.NRLIB + @ echo 0 making ${OUT}/PERMGRP.o from ${MID}/PERMGRP.NRLIB +@@ -23833,13 +22117,6 @@ + + @ + \subsection{perm.spad \cite{1}} +-<>= +-${MID}/perm.spad: ${IN}/perm.spad.pamphlet +- @ echo 0 making ${MID}/perm.spad from ${IN}/perm.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/perm.spad.pamphlet >perm.spad ) +- +-@ + <>= + ${OUT}/PERM.o: ${MID}/PERM.NRLIB + @ echo 0 making ${OUT}/PERM.o from ${MID}/PERM.NRLIB +@@ -23892,13 +22169,6 @@ + + @ + \subsection{pfbr.spad \cite{1}} +-<>= +-${MID}/pfbr.spad: ${IN}/pfbr.spad.pamphlet +- @ echo 0 making ${MID}/pfbr.spad from ${IN}/pfbr.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pfbr.spad.pamphlet >pfbr.spad ) +- +-@ + <>= + ${OUT}/PFBR.o: ${MID}/PFBR.NRLIB + @ echo 0 making ${OUT}/PFBR.o from ${MID}/PFBR.NRLIB +@@ -23951,13 +22221,6 @@ + + @ + \subsection{pfo.spad \cite{1}} +-<>= +-${MID}/pfo.spad: ${IN}/pfo.spad.pamphlet +- @ echo 0 making ${MID}/pfo.spad from ${IN}/pfo.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pfo.spad.pamphlet >pfo.spad ) +- +-@ + <>= + ${OUT}/FORDER.o: ${MID}/FORDER.NRLIB + @ echo 0 making ${OUT}/FORDER.o from ${MID}/FORDER.NRLIB +@@ -24090,13 +22353,6 @@ + + @ + \subsection{pfr.spad \cite{1}} +-<>= +-${MID}/pfr.spad: ${IN}/pfr.spad.pamphlet +- @ echo 0 making ${MID}/pfr.spad from ${IN}/pfr.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pfr.spad.pamphlet >pfr.spad ) +- +-@ + <>= + ${OUT}/PFR.o: ${MID}/PFR.NRLIB + @ echo 0 making ${OUT}/PFR.o from ${MID}/PFR.NRLIB +@@ -24149,13 +22405,6 @@ + + @ + \subsection{pf.spad \cite{1}} +-<>= +-${MID}/pf.spad: ${IN}/pf.spad.pamphlet +- @ echo 0 making ${MID}/pf.spad from ${IN}/pf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pf.spad.pamphlet >pf.spad ) +- +-@ + <>= + ${OUT}/IPF.o: ${MID}/IPF.NRLIB + @ echo 0 making ${OUT}/IPF.o from ${MID}/IPF.NRLIB +@@ -24208,13 +22457,6 @@ + + @ + \subsection{pgcd.spad \cite{1}} +-<>= +-${MID}/pgcd.spad: ${IN}/pgcd.spad.pamphlet +- @ echo 0 making ${MID}/pgcd.spad from ${IN}/pgcd.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pgcd.spad.pamphlet >pgcd.spad ) +- +-@ + <>= + ${OUT}/PGCD.o: ${MID}/PGCD.NRLIB + @ echo 0 making ${OUT}/PGCD.o from ${MID}/PGCD.NRLIB +@@ -24247,13 +22489,6 @@ + + @ + \subsection{pgrobner.spad \cite{1}} +-<>= +-${MID}/pgrobner.spad: ${IN}/pgrobner.spad.pamphlet +- @ echo 0 making ${MID}/pgrobner.spad from ${IN}/pgrobner.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pgrobner.spad.pamphlet >pgrobner.spad ) +- +-@ + <>= + ${OUT}/PGROEB.o: ${MID}/PGROEB.NRLIB + @ echo 0 making ${OUT}/PGROEB.o from ${MID}/PGROEB.NRLIB +@@ -24286,13 +22521,6 @@ + + @ + \subsection{pinterp.spad \cite{1}} +-<>= +-${MID}/pinterp.spad: ${IN}/pinterp.spad.pamphlet +- @ echo 0 making ${MID}/pinterp.spad from ${IN}/pinterp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pinterp.spad.pamphlet >pinterp.spad ) +- +-@ + <>= + ${OUT}/PINTERP.o: ${MID}/PINTERP.NRLIB + @ echo 0 making ${OUT}/PINTERP.o from ${MID}/PINTERP.NRLIB +@@ -24345,13 +22573,6 @@ + + @ + \subsection{pleqn.spad \cite{1}} +-<>= +-${MID}/pleqn.spad: ${IN}/pleqn.spad.pamphlet +- @ echo 0 making ${MID}/pleqn.spad from ${IN}/pleqn.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pleqn.spad.pamphlet >pleqn.spad ) +- +-@ + <>= + ${OUT}/PLEQN.o: ${MID}/PLEQN.NRLIB + @ echo 0 making ${OUT}/PLEQN.o from ${MID}/PLEQN.NRLIB +@@ -24384,13 +22605,6 @@ + + @ + \subsection{plot3d.spad \cite{1}} +-<>= +-${MID}/plot3d.spad: ${IN}/plot3d.spad.pamphlet +- @ echo 0 making ${MID}/plot3d.spad from ${IN}/plot3d.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/plot3d.spad.pamphlet >plot3d.spad ) +- +-@ + <>= + ${OUT}/PLOT3D.o: ${MID}/PLOT3D.NRLIB + @ echo 0 making ${OUT}/PLOT3D.o from ${MID}/PLOT3D.NRLIB +@@ -24423,13 +22637,6 @@ + + @ + \subsection{plot.spad \cite{1}} +-<>= +-${MID}/plot.spad: ${IN}/plot.spad.pamphlet +- @ echo 0 making ${MID}/plot.spad from ${IN}/plot.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/plot.spad.pamphlet >plot.spad ) +- +-@ + <>= + ${OUT}/PLOT1.o: ${MID}/PLOT1.NRLIB + @ echo 0 making ${OUT}/PLOT1.o from ${MID}/PLOT1.NRLIB +@@ -24482,13 +22689,6 @@ + + @ + \subsection{plottool.spad \cite{1}} +-<>= +-${MID}/plottool.spad: ${IN}/plottool.spad.pamphlet +- @ echo 0 making ${MID}/plottool.spad from ${IN}/plottool.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/plottool.spad.pamphlet >plottool.spad ) +- +-@ + <>= + ${OUT}/PLOTTOOL.o: ${MID}/PLOTTOOL.NRLIB + @ echo 0 making ${OUT}/PLOTTOOL.o from ${MID}/PLOTTOOL.NRLIB +@@ -24521,13 +22721,6 @@ + + @ + \subsection{polset.spad \cite{1}} +-<>= +-${MID}/polset.spad: ${IN}/polset.spad.pamphlet +- @ echo 0 making ${MID}/polset.spad from ${IN}/polset.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/polset.spad.pamphlet >polset.spad ) +- +-@ + <>= + ${OUT}/GPOLSET.o: ${MID}/GPOLSET.NRLIB + @ echo 0 making ${OUT}/GPOLSET.o from ${MID}/GPOLSET.NRLIB +@@ -24626,13 +22819,6 @@ + + @ + \subsection{poltopol.spad \cite{1}} +-<>= +-${MID}/poltopol.spad: ${IN}/poltopol.spad.pamphlet +- @ echo 0 making ${MID}/poltopol.spad from ${IN}/poltopol.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/poltopol.spad.pamphlet >poltopol.spad ) +- +-@ + <>= + ${OUT}/MPC2.o: ${MID}/MPC2.NRLIB + @ echo 0 making ${OUT}/MPC2.o from ${MID}/MPC2.NRLIB +@@ -24705,13 +22891,6 @@ + + @ + \subsection{polycat.spad \cite{1}} +-<>= +-${MID}/polycat.spad: ${IN}/polycat.spad.pamphlet +- @ echo 0 making ${MID}/polycat.spad from ${IN}/polycat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/polycat.spad.pamphlet >polycat.spad ) +- +-@ + <>= + ${OUT}/AMR-.o: ${MID}/AMR.NRLIB + @ echo 0 making ${OUT}/AMR-.o from ${MID}/AMR-.NRLIB +@@ -24980,13 +23159,6 @@ + + @ + \subsection{poly.spad \cite{1}} +-<>= +-${MID}/poly.spad: ${IN}/poly.spad.pamphlet +- @ echo 0 making ${MID}/poly.spad from ${IN}/poly.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/poly.spad.pamphlet >poly.spad ) +- +-@ + <>= + ${OUT}/FM.o: ${MID}/FM.NRLIB + @ echo 0 making ${OUT}/FM.o from ${MID}/FM.NRLIB +@@ -25199,13 +23371,6 @@ + + @ + \subsection{primelt.spad \cite{1}} +-<>= +-${MID}/primelt.spad: ${IN}/primelt.spad.pamphlet +- @ echo 0 making ${MID}/primelt.spad from ${IN}/primelt.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/primelt.spad.pamphlet >primelt.spad ) +- +-@ + <>= + ${OUT}/FSPRMELT.o: ${MID}/FSPRMELT.NRLIB + @ echo 0 making ${OUT}/FSPRMELT.o from ${MID}/FSPRMELT.NRLIB +@@ -25258,13 +23423,6 @@ + + @ + \subsection{print.spad \cite{1}} +-<>= +-${MID}/print.spad: ${IN}/print.spad.pamphlet +- @ echo 0 making ${MID}/print.spad from ${IN}/print.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/print.spad.pamphlet >print.spad ) +- +-@ + <>= + ${OUT}/PRINT.o: ${MID}/PRINT.NRLIB + @ echo 0 making ${OUT}/PRINT.o from ${MID}/PRINT.NRLIB +@@ -25297,13 +23455,6 @@ + + @ + \subsection{product.spad \cite{1}} +-<>= +-${MID}/product.spad: ${IN}/product.spad.pamphlet +- @ echo 0 making ${MID}/product.spad from ${IN}/product.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/product.spad.pamphlet >product.spad ) +- +-@ + <>= + ${OUT}/PRODUCT.o: ${MID}/PRODUCT.NRLIB + @ echo 0 making ${OUT}/PRODUCT.o from ${MID}/PRODUCT.NRLIB +@@ -25336,13 +23487,6 @@ + + @ + \subsection{prs.spad \cite{1}} +-<>= +-${MID}/prs.spad: ${IN}/prs.spad.pamphlet +- @ echo 0 making ${MID}/prs.spad from ${IN}/prs.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/prs.spad.pamphlet >prs.spad ) +- +-@ + <>= + ${OUT}/PRS.o: ${MID}/PRS.NRLIB + @ echo 0 making ${OUT}/PRS.o from ${MID}/PRS.NRLIB +@@ -25375,13 +23519,6 @@ + + @ + \subsection{prtition.spad \cite{1}} +-<>= +-${MID}/prtition.spad: ${IN}/prtition.spad.pamphlet +- @ echo 0 making ${MID}/prtition.spad from ${IN}/prtition.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/prtition.spad.pamphlet >prtition.spad ) +- +-@ + <>= + ${OUT}/SYMPOLY.o: ${MID}/SYMPOLY.NRLIB + @ echo 0 making ${OUT}/SYMPOLY.o from ${MID}/SYMPOLY.NRLIB +@@ -25434,13 +23571,6 @@ + + @ + \subsection{pscat.spad \cite{1}} +-<>= +-${MID}/pscat.spad: ${IN}/pscat.spad.pamphlet +- @ echo 0 making ${MID}/pscat.spad from ${IN}/pscat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pscat.spad.pamphlet >pscat.spad ) +- +-@ + <>= + ${OUT}/MTSCAT.o: ${MID}/MTSCAT.NRLIB + @ echo 0 making ${OUT}/MTSCAT.o from ${MID}/MTSCAT.NRLIB +@@ -25643,13 +23773,6 @@ + + @ + \subsection{pseudolin.spad \cite{1}} +-<>= +-${MID}/pseudolin.spad: ${IN}/pseudolin.spad.pamphlet +- @ echo 0 making ${MID}/pseudolin.spad from ${IN}/pseudolin.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/pseudolin.spad.pamphlet >pseudolin.spad ) +- +-@ + <>= + ${OUT}/PSEUDLIN.o: ${MID}/PSEUDLIN.NRLIB + @ echo 0 making ${OUT}/PSEUDLIN.o from ${MID}/PSEUDLIN.NRLIB +@@ -25682,13 +23805,6 @@ + + @ + \subsection{ptranfn.spad \cite{1}} +-<>= +-${MID}/ptranfn.spad: ${IN}/ptranfn.spad.pamphlet +- @ echo 0 making ${MID}/ptranfn.spad from ${IN}/ptranfn.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ptranfn.spad.pamphlet >ptranfn.spad ) +- +-@ + <>= + ${OUT}/PTRANFN.o: ${MID}/PTRANFN.NRLIB + @ echo 0 making ${OUT}/PTRANFN.o from ${MID}/PTRANFN.NRLIB +@@ -25721,13 +23837,6 @@ + + @ + \subsection{puiseux.spad \cite{1}} +-<>= +-${MID}/puiseux.spad: ${IN}/puiseux.spad.pamphlet +- @ echo 0 making ${MID}/puiseux.spad from ${IN}/puiseux.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/puiseux.spad.pamphlet >puiseux.spad ) +- +-@ + <>= + ${OUT}/UPXS.o: ${MID}/UPXS.NRLIB + @ echo 0 making ${OUT}/UPXS.o from ${MID}/UPXS.NRLIB +@@ -25832,13 +23941,6 @@ + + @ + \subsection{qalgset.spad \cite{1}} +-<>= +-${MID}/qalgset.spad: ${IN}/qalgset.spad.pamphlet +- @ echo 0 making ${MID}/qalgset.spad from ${IN}/qalgset.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/qalgset.spad.pamphlet >qalgset.spad ) +- +-@ + <>= + ${OUT}/QALGSET.o: ${MID}/QALGSET.NRLIB + @ echo 0 making ${OUT}/QALGSET.o from ${MID}/QALGSET.NRLIB +@@ -25891,13 +23993,6 @@ + + @ + \subsection{quat.spad \cite{1}} +-<>= +-${MID}/quat.spad: ${IN}/quat.spad.pamphlet +- @ echo 0 making ${MID}/quat.spad from ${IN}/quat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/quat.spad.pamphlet >quat.spad ) +- +-@ + <>= + ${OUT}/QUAT.o: ${MID}/QUAT.NRLIB + @ echo 0 making ${OUT}/QUAT.o from ${MID}/QUAT.NRLIB +@@ -25982,13 +24077,6 @@ + + @ + \subsection{radeigen.spad \cite{1}} +-<>= +-${MID}/radeigen.spad: ${IN}/radeigen.spad.pamphlet +- @ echo 0 making ${MID}/radeigen.spad from ${IN}/radeigen.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/radeigen.spad.pamphlet >radeigen.spad ) +- +-@ + <>= + ${OUT}/REP.o: ${MID}/REP.NRLIB + @ echo 0 making ${OUT}/REP.o from ${MID}/REP.NRLIB +@@ -26021,13 +24109,6 @@ + + @ + \subsection{radix.spad \cite{1}} +-<>= +-${MID}/radix.spad: ${IN}/radix.spad.pamphlet +- @ echo 0 making ${MID}/radix.spad from ${IN}/radix.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/radix.spad.pamphlet >radix.spad ) +- +-@ + <>= + ${OUT}/BINARY.o: ${MID}/BINARY.NRLIB + @ echo 0 making ${OUT}/BINARY.o from ${MID}/BINARY.NRLIB +@@ -26140,13 +24221,6 @@ + + @ + \subsection{random.spad \cite{1}} +-<>= +-${MID}/random.spad: ${IN}/random.spad.pamphlet +- @ echo 0 making ${MID}/random.spad from ${IN}/random.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/random.spad.pamphlet >random.spad ) +- +-@ + <>= + ${OUT}/INTBIT.o: ${MID}/INTBIT.NRLIB + @ echo 0 making ${OUT}/INTBIT.o from ${MID}/INTBIT.NRLIB +@@ -26259,13 +24333,6 @@ + + @ + \subsection{ratfact.spad \cite{1}} +-<>= +-${MID}/ratfact.spad: ${IN}/ratfact.spad.pamphlet +- @ echo 0 making ${MID}/ratfact.spad from ${IN}/ratfact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ratfact.spad.pamphlet >ratfact.spad ) +- +-@ + <>= + ${OUT}/RATFACT.o: ${MID}/RATFACT.NRLIB + @ echo 0 making ${OUT}/RATFACT.o from ${MID}/RATFACT.NRLIB +@@ -26298,13 +24365,6 @@ + + @ + \subsection{rdeef.spad \cite{1}} +-<>= +-${MID}/rdeef.spad: ${IN}/rdeef.spad.pamphlet +- @ echo 0 making ${MID}/rdeef.spad from ${IN}/rdeef.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/rdeef.spad.pamphlet >rdeef.spad ) +- +-@ + <>= + ${OUT}/INTTOOLS.o: ${MID}/INTTOOLS.NRLIB + @ echo 0 making ${OUT}/INTTOOLS.o from ${MID}/INTTOOLS.NRLIB +@@ -26357,13 +24417,6 @@ + + @ + \subsection{rderf.spad \cite{1}} +-<>= +-${MID}/rderf.spad: ${IN}/rderf.spad.pamphlet +- @ echo 0 making ${MID}/rderf.spad from ${IN}/rderf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/rderf.spad.pamphlet >rderf.spad ) +- +-@ + <>= + ${OUT}/RDETR.o: ${MID}/RDETR.NRLIB + @ echo 0 making ${OUT}/RDETR.o from ${MID}/RDETR.NRLIB +@@ -26396,13 +24449,6 @@ + + @ + \subsection{rdesys.spad \cite{1}} +-<>= +-${MID}/rdesys.spad: ${IN}/rdesys.spad.pamphlet +- @ echo 0 making ${MID}/rdesys.spad from ${IN}/rdesys.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/rdesys.spad.pamphlet >rdesys.spad ) +- +-@ + <>= + ${OUT}/RDEEFS.o: ${MID}/RDEEFS.NRLIB + @ echo 0 making ${OUT}/RDEEFS.o from ${MID}/RDEEFS.NRLIB +@@ -26455,13 +24501,6 @@ + + @ + \subsection{real0q.spad \cite{1}} +-<>= +-${MID}/real0q.spad: ${IN}/real0q.spad.pamphlet +- @ echo 0 making ${MID}/real0q.spad from ${IN}/real0q.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/real0q.spad.pamphlet >real0q.spad ) +- +-@ + <>= + ${OUT}/REAL0Q.o: ${MID}/REAL0Q.NRLIB + @ echo 0 making ${OUT}/REAL0Q.o from ${MID}/REAL0Q.NRLIB +@@ -26494,13 +24533,6 @@ + + @ + \subsection{realzero.spad \cite{1}} +-<>= +-${MID}/realzero.spad: ${IN}/realzero.spad.pamphlet +- @ echo 0 making ${MID}/realzero.spad from ${IN}/realzero.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/realzero.spad.pamphlet >realzero.spad ) +- +-@ + <>= + ${OUT}/REAL0.o: ${MID}/REAL0.NRLIB + @ echo 0 making ${OUT}/REAL0.o from ${MID}/REAL0.NRLIB +@@ -26533,13 +24565,6 @@ + + @ + \subsection{reclos.spad \cite{1}} +-<>= +-${MID}/reclos.spad: ${IN}/reclos.spad.pamphlet +- @ echo 0 making ${MID}/reclos.spad from ${IN}/reclos.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/reclos.spad.pamphlet >reclos.spad ) +- +-@ + <>= + ${OUT}/POLUTIL.o: ${MID}/POLUTIL.NRLIB + @ echo 0 making ${OUT}/POLUTIL.o from ${MID}/POLUTIL.NRLIB +@@ -26676,13 +24701,6 @@ + + @ + \subsection{regset.spad \cite{1}} +-<>= +-${MID}/regset.spad: ${IN}/regset.spad.pamphlet +- @ echo 0 making ${MID}/regset.spad from ${IN}/regset.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/regset.spad.pamphlet >regset.spad ) +- +-@ + <>= + ${OUT}/QCMPACK.o: ${MID}/QCMPACK.NRLIB + @ echo 0 making ${OUT}/QCMPACK.o from ${MID}/QCMPACK.NRLIB +@@ -26807,13 +24825,6 @@ + + @ + \subsection{rep1.spad \cite{1}} +-<>= +-${MID}/rep1.spad: ${IN}/rep1.spad.pamphlet +- @ echo 0 making ${MID}/rep1.spad from ${IN}/rep1.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/rep1.spad.pamphlet >rep1.spad ) +- +-@ + <>= + ${OUT}/REP1.o: ${MID}/REP1.NRLIB + @ echo 0 making ${OUT}/REP1.o from ${MID}/REP1.NRLIB +@@ -26846,13 +24857,6 @@ + + @ + \subsection{rep2.spad \cite{1}} +-<>= +-${MID}/rep2.spad: ${IN}/rep2.spad.pamphlet +- @ echo 0 making ${MID}/rep2.spad from ${IN}/rep2.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/rep2.spad.pamphlet >rep2.spad ) +- +-@ + <>= + ${OUT}/REP2.o: ${MID}/REP2.NRLIB + @ echo 0 making ${OUT}/REP2.o from ${MID}/REP2.NRLIB +@@ -26885,13 +24889,6 @@ + + @ + \subsection{resring.spad \cite{1}} +-<>= +-${MID}/resring.spad: ${IN}/resring.spad.pamphlet +- @ echo 0 making ${MID}/resring.spad from ${IN}/resring.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/resring.spad.pamphlet >resring.spad ) +- +-@ + <>= + ${OUT}/RESRING.o: ${MID}/RESRING.NRLIB + @ echo 0 making ${OUT}/RESRING.o from ${MID}/RESRING.NRLIB +@@ -26924,13 +24921,6 @@ + + @ + \subsection{retract.spad \cite{1}} +-<>= +-${MID}/retract.spad: ${IN}/retract.spad.pamphlet +- @ echo 0 making ${MID}/retract.spad from ${IN}/retract.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/retract.spad.pamphlet >retract.spad ) +- +-@ + <>= + ${OUT}/FRETRCT-.o: ${MID}/FRETRCT.NRLIB + @ echo 0 making ${OUT}/FRETRCT-.o from ${MID}/FRETRCT-.NRLIB +@@ -27015,13 +25005,6 @@ + + @ + \subsection{rf.spad \cite{1}} +-<>= +-${MID}/rf.spad: ${IN}/rf.spad.pamphlet +- @ echo 0 making ${MID}/rf.spad from ${IN}/rf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/rf.spad.pamphlet >rf.spad ) +- +-@ + <>= + ${OUT}/POLYCATQ.o: ${MID}/POLYCATQ.NRLIB + @ echo 0 making ${OUT}/POLYCATQ.o from ${MID}/POLYCATQ.NRLIB +@@ -27074,13 +25057,6 @@ + + @ + \subsection{riccati.spad \cite{1}} +-<>= +-${MID}/riccati.spad: ${IN}/riccati.spad.pamphlet +- @ echo 0 making ${MID}/riccati.spad from ${IN}/riccati.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/riccati.spad.pamphlet >riccati.spad ) +- +-@ + <>= + ${OUT}/ODEPRRIC.o: ${MID}/ODEPRRIC.NRLIB + @ echo 0 making ${OUT}/ODEPRRIC.o from ${MID}/ODEPRRIC.NRLIB +@@ -27133,13 +25109,6 @@ + + @ + \subsection{routines.spad \cite{1}} +-<>= +-${MID}/routines.spad: ${IN}/routines.spad.pamphlet +- @ echo 0 making ${MID}/routines.spad from ${IN}/routines.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/routines.spad.pamphlet >routines.spad ) +- +-@ + <>= + ${OUT}/ATTRBUT.o: ${MID}/ATTRBUT.NRLIB + @ echo 0 making ${OUT}/ATTRBUT.o from ${MID}/ATTRBUT.NRLIB +@@ -27192,13 +25161,6 @@ + + @ + \subsection{rule.spad \cite{1}} +-<>= +-${MID}/rule.spad: ${IN}/rule.spad.pamphlet +- @ echo 0 making ${MID}/rule.spad from ${IN}/rule.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/rule.spad.pamphlet >rule.spad ) +- +-@ + <>= + ${OUT}/APPRULE.o: ${MID}/APPRULE.NRLIB + @ echo 0 making ${OUT}/APPRULE.o from ${MID}/APPRULE.NRLIB +@@ -27271,13 +25233,6 @@ + + @ + \subsection{seg.spad \cite{1}} +-<>= +-${MID}/seg.spad: ${IN}/seg.spad.pamphlet +- @ echo 0 making ${MID}/seg.spad from ${IN}/seg.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/seg.spad.pamphlet >seg.spad ) +- +-@ + <>= + ${OUT}/INCRMAPS.o: ${MID}/INCRMAPS.NRLIB + @ echo 0 making ${OUT}/INCRMAPS.o from ${MID}/INCRMAPS.NRLIB +@@ -27470,13 +25425,6 @@ + + @ + \subsection{setorder.spad \cite{1}} +-<>= +-${MID}/setorder.spad: ${IN}/setorder.spad.pamphlet +- @ echo 0 making ${MID}/setorder.spad from ${IN}/setorder.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/setorder.spad.pamphlet >setorder.spad ) +- +-@ + <>= + ${OUT}/UDPO.o: ${MID}/UDPO.NRLIB + @ echo 0 making ${OUT}/UDPO.o from ${MID}/UDPO.NRLIB +@@ -27529,13 +25477,6 @@ + + @ + \subsection{sets.spad \cite{1}} +-<>= +-${MID}/sets.spad: ${IN}/sets.spad.pamphlet +- @ echo 0 making ${MID}/sets.spad from ${IN}/sets.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sets.spad.pamphlet >sets.spad ) +- +-@ + <>= + ${OUT}/SET.o: ${MID}/SET.NRLIB + @ echo 0 making ${OUT}/SET.o from ${MID}/SET.NRLIB +@@ -27568,13 +25509,6 @@ + + @ + \subsection{sex.spad \cite{1}} +-<>= +-${MID}/sex.spad: ${IN}/sex.spad.pamphlet +- @ echo 0 making ${MID}/sex.spad from ${IN}/sex.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sex.spad.pamphlet >sex.spad ) +- +-@ + <>= + ${OUT}/SEX.o: ${MID}/SEX.NRLIB + @ echo 0 making ${OUT}/SEX.o from ${MID}/SEX.NRLIB +@@ -27647,13 +25581,6 @@ + + @ + \subsection{sf.spad \cite{1}} +-<>= +-${MID}/sf.spad: ${IN}/sf.spad.pamphlet +- @ echo 0 making ${MID}/sf.spad from ${IN}/sf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sf.spad.pamphlet >sf.spad ) +- +-@ + <>= + ${OUT}/DFLOAT.o: ${MID}/DFLOAT.NRLIB + @ echo 0 making ${OUT}/DFLOAT.o from ${MID}/DFLOAT.NRLIB +@@ -27887,13 +25814,6 @@ + + @ + \subsection{sgcf.spad \cite{1}} +-<>= +-${MID}/sgcf.spad: ${IN}/sgcf.spad.pamphlet +- @ echo 0 making ${MID}/sgcf.spad from ${IN}/sgcf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sgcf.spad.pamphlet >sgcf.spad ) +- +-@ + <>= + ${OUT}/SGCF.o: ${MID}/SGCF.NRLIB + @ echo 0 making ${OUT}/SGCF.o from ${MID}/SGCF.NRLIB +@@ -27926,13 +25846,6 @@ + + @ + \subsection{sign.spad \cite{1}} +-<>= +-${MID}/sign.spad: ${IN}/sign.spad.pamphlet +- @ echo 0 making ${MID}/sign.spad from ${IN}/sign.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sign.spad.pamphlet >sign.spad ) +- +-@ + <>= + ${OUT}/INPSIGN.o: ${MID}/INPSIGN.NRLIB + @ echo 0 making ${OUT}/INPSIGN.o from ${MID}/INPSIGN.NRLIB +@@ -28025,13 +25938,6 @@ + + @ + \subsection{si.spad \cite{1}} +-<>= +-${MID}/si.spad: ${IN}/si.spad.pamphlet +- @ echo 0 making ${MID}/si.spad from ${IN}/si.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/si.spad.pamphlet >si.spad ) +- +-@ + <>= + ${OUT}/SINT.o: ${MID}/SINT.NRLIB + @ echo 0 making ${OUT}/SINT.o from ${MID}/SINT.NRLIB +@@ -28147,13 +26053,6 @@ + + @ + \subsection{smith.spad \cite{1}} +-<>= +-${MID}/smith.spad: ${IN}/smith.spad.pamphlet +- @ echo 0 making ${MID}/smith.spad from ${IN}/smith.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/smith.spad.pamphlet >smith.spad ) +- +-@ + <>= + ${OUT}/SMITH.o: ${MID}/SMITH.NRLIB + @ echo 0 making ${OUT}/SMITH.o from ${MID}/SMITH.NRLIB +@@ -28186,13 +26085,6 @@ + + @ + \subsection{solvedio.spad \cite{1}} +-<>= +-${MID}/solvedio.spad: ${IN}/solvedio.spad.pamphlet +- @ echo 0 making ${MID}/solvedio.spad from ${IN}/solvedio.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/solvedio.spad.pamphlet >solvedio.spad ) +- +-@ + <>= + ${OUT}/DIOSP.o: ${MID}/DIOSP.NRLIB + @ echo 0 making ${OUT}/DIOSP.o from ${MID}/DIOSP.NRLIB +@@ -28225,13 +26117,6 @@ + + @ + \subsection{solvefor.spad \cite{1}} +-<>= +-${MID}/solvefor.spad: ${IN}/solvefor.spad.pamphlet +- @ echo 0 making ${MID}/solvefor.spad from ${IN}/solvefor.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/solvefor.spad.pamphlet >solvefor.spad ) +- +-@ + <>= + ${OUT}/SOLVEFOR.o: ${MID}/SOLVEFOR.NRLIB + @ echo 0 making ${OUT}/SOLVEFOR.o from ${MID}/SOLVEFOR.NRLIB +@@ -28264,13 +26149,6 @@ + + @ + \subsection{solvelin.spad \cite{1}} +-<>= +-${MID}/solvelin.spad: ${IN}/solvelin.spad.pamphlet +- @ echo 0 making ${MID}/solvelin.spad from ${IN}/solvelin.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/solvelin.spad.pamphlet >solvelin.spad ) +- +-@ + <>= + ${OUT}/LSMP.o: ${MID}/LSMP.NRLIB + @ echo 0 making ${OUT}/LSMP.o from ${MID}/LSMP.NRLIB +@@ -28343,13 +26221,6 @@ + + @ + \subsection{solverad.spad \cite{1}} +-<>= +-${MID}/solverad.spad: ${IN}/solverad.spad.pamphlet +- @ echo 0 making ${MID}/solverad.spad from ${IN}/solverad.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/solverad.spad.pamphlet >solverad.spad ) +- +-@ + <>= + ${OUT}/SOLVERAD.o: ${MID}/SOLVERAD.NRLIB + @ echo 0 making ${OUT}/SOLVERAD.o from ${MID}/SOLVERAD.NRLIB +@@ -28382,13 +26253,6 @@ + + @ + \subsection{sortpak.spad \cite{1}} +-<>= +-${MID}/sortpak.spad: ${IN}/sortpak.spad.pamphlet +- @ echo 0 making ${MID}/sortpak.spad from ${IN}/sortpak.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sortpak.spad.pamphlet >sortpak.spad ) +- +-@ + <>= + ${OUT}/SORTPAK.o: ${MID}/SORTPAK.NRLIB + @ echo 0 making ${OUT}/SORTPAK.o from ${MID}/SORTPAK.NRLIB +@@ -28421,13 +26285,6 @@ + + @ + \subsection{space.spad \cite{1}} +-<>= +-${MID}/space.spad: ${IN}/space.spad.pamphlet +- @ echo 0 making ${MID}/space.spad from ${IN}/space.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/space.spad.pamphlet >space.spad ) +- +-@ + <>= + ${OUT}/SPACEC.o: ${MID}/SPACEC.NRLIB + @ echo 0 making ${OUT}/SPACEC.o from ${MID}/SPACEC.NRLIB +@@ -28500,13 +26357,6 @@ + + @ + \subsection{special.spad \cite{1}} +-<>= +-${MID}/special.spad: ${IN}/special.spad.pamphlet +- @ echo 0 making ${MID}/special.spad from ${IN}/special.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/special.spad.pamphlet >special.spad ) +- +-@ + <>= + ${OUT}/DFSFUN.o: ${MID}/DFSFUN.NRLIB + @ echo 0 making ${OUT}/DFSFUN.o from ${MID}/DFSFUN.NRLIB +@@ -28579,13 +26429,6 @@ + + @ + \subsection{sregset.spad \cite{1}} +-<>= +-${MID}/sregset.spad: ${IN}/sregset.spad.pamphlet +- @ echo 0 making ${MID}/sregset.spad from ${IN}/sregset.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sregset.spad.pamphlet >sregset.spad ) +- +-@ + <>= + ${OUT}/SFQCMPK.o: ${MID}/SFQCMPK.NRLIB + @ echo 0 making ${OUT}/SFQCMPK.o from ${MID}/SFQCMPK.NRLIB +@@ -28698,13 +26541,6 @@ + + @ + \subsection{s.spad \cite{1}} +-<>= +-${MID}/s.spad: ${IN}/s.spad.pamphlet +- @ echo 0 making ${MID}/s.spad from ${IN}/s.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/s.spad.pamphlet >s.spad ) +- +-@ + <>= + ${OUT}/NAGS.o: ${MID}/NAGS.NRLIB + @ echo 0 making ${OUT}/NAGS.o from ${MID}/NAGS.NRLIB +@@ -28737,13 +26573,6 @@ + + @ + \subsection{stream.spad \cite{1}} +-<>= +-${MID}/stream.spad: ${IN}/stream.spad.pamphlet +- @ echo 0 making ${MID}/stream.spad from ${IN}/stream.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/stream.spad.pamphlet >stream.spad ) +- +-@ + <>= + ${OUT}/CSTTOOLS.o: ${MID}/CSTTOOLS.NRLIB + @ echo 0 making ${OUT}/CSTTOOLS.o from ${MID}/CSTTOOLS.NRLIB +@@ -28888,13 +26717,6 @@ + + @ + \subsection{string.spad \cite{1}} +-<>= +-${MID}/string.spad: ${IN}/string.spad.pamphlet +- @ echo 0 making ${MID}/string.spad from ${IN}/string.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/string.spad.pamphlet >string.spad ) +- +-@ + <>= + ${OUT}/CCLASS.o: ${MID}/CCLASS.NRLIB + @ echo 0 making ${OUT}/CCLASS.o from ${MID}/CCLASS.NRLIB +@@ -29041,13 +26863,6 @@ + + @ + \subsection{sttaylor.spad \cite{1}} +-<>= +-${MID}/sttaylor.spad: ${IN}/sttaylor.spad.pamphlet +- @ echo 0 making ${MID}/sttaylor.spad from ${IN}/sttaylor.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sttaylor.spad.pamphlet >sttaylor.spad ) +- +-@ + <>= + ${OUT}/STTAYLOR.o: ${MID}/STTAYLOR.NRLIB + @ echo 0 making ${OUT}/STTAYLOR.o from ${MID}/STTAYLOR.NRLIB +@@ -29080,13 +26895,6 @@ + + @ + \subsection{sttf.spad \cite{1}} +-<>= +-${MID}/sttf.spad: ${IN}/sttf.spad.pamphlet +- @ echo 0 making ${MID}/sttf.spad from ${IN}/sttf.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sttf.spad.pamphlet >sttf.spad ) +- +-@ + <>= + ${OUT}/STTF.o: ${MID}/STTF.NRLIB + @ echo 0 making ${OUT}/STTF.o from ${MID}/STTF.NRLIB +@@ -29139,13 +26947,6 @@ + + @ + \subsection{sturm.spad \cite{1}} +-<>= +-${MID}/sturm.spad: ${IN}/sturm.spad.pamphlet +- @ echo 0 making ${MID}/sturm.spad from ${IN}/sturm.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sturm.spad.pamphlet >sturm.spad ) +- +-@ + <>= + ${OUT}/SHP.o: ${MID}/SHP.NRLIB + @ echo 0 making ${OUT}/SHP.o from ${MID}/SHP.NRLIB +@@ -29178,13 +26979,6 @@ + + @ + \subsection{suchthat.spad \cite{1}} +-<>= +-${MID}/suchthat.spad: ${IN}/suchthat.spad.pamphlet +- @ echo 0 making ${MID}/suchthat.spad from ${IN}/suchthat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/suchthat.spad.pamphlet >suchthat.spad ) +- +-@ + <>= + ${OUT}/SUCH.o: ${MID}/SUCH.NRLIB + @ echo 0 making ${OUT}/SUCH.o from ${MID}/SUCH.NRLIB +@@ -29217,13 +27011,6 @@ + + @ + \subsection{suls.spad \cite{1}} +-<>= +-${MID}/suls.spad: ${IN}/suls.spad.pamphlet +- @ echo 0 making ${MID}/suls.spad from ${IN}/suls.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/suls.spad.pamphlet >suls.spad ) +- +-@ + <>= + ${OUT}/SULS.o: ${MID}/SULS.NRLIB + @ echo 0 making ${OUT}/SULS.o from ${MID}/SULS.NRLIB +@@ -29256,13 +27043,6 @@ + + @ + \subsection{sum.spad \cite{1}} +-<>= +-${MID}/sum.spad: ${IN}/sum.spad.pamphlet +- @ echo 0 making ${MID}/sum.spad from ${IN}/sum.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sum.spad.pamphlet >sum.spad ) +- +-@ + <>= + ${OUT}/GOSPER.o: ${MID}/GOSPER.NRLIB + @ echo 0 making ${OUT}/GOSPER.o from ${MID}/GOSPER.NRLIB +@@ -29335,13 +27115,6 @@ + + @ + \subsection{sups.spad \cite{1}} +-<>= +-${MID}/sups.spad: ${IN}/sups.spad.pamphlet +- @ echo 0 making ${MID}/sups.spad from ${IN}/sups.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/sups.spad.pamphlet >sups.spad ) +- +-@ + <>= + ${OUT}/ISUPS.o: ${MID}/ISUPS.NRLIB + @ echo 0 making ${OUT}/ISUPS.o from ${MID}/ISUPS.NRLIB +@@ -29374,13 +27147,6 @@ + + @ + \subsection{supxs.spad \cite{1}} +-<>= +-${MID}/supxs.spad: ${IN}/supxs.spad.pamphlet +- @ echo 0 making ${MID}/supxs.spad from ${IN}/supxs.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/supxs.spad.pamphlet >supxs.spad ) +- +-@ + <>= + ${OUT}/SUPXS.o: ${MID}/SUPXS.NRLIB + @ echo 0 making ${OUT}/SUPXS.o from ${MID}/SUPXS.NRLIB +@@ -29413,13 +27179,6 @@ + + @ + \subsection{suts.spad \cite{1}} +-<>= +-${MID}/suts.spad: ${IN}/suts.spad.pamphlet +- @ echo 0 making ${MID}/suts.spad from ${IN}/suts.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/suts.spad.pamphlet >suts.spad ) +- +-@ + <>= + ${OUT}/SUTS.o: ${MID}/SUTS.NRLIB + @ echo 0 making ${OUT}/SUTS.o from ${MID}/SUTS.NRLIB +@@ -29452,13 +27211,6 @@ + + @ + \subsection{symbol.spad \cite{1}} +-<>= +-${MID}/symbol.spad: ${IN}/symbol.spad.pamphlet +- @ echo 0 making ${MID}/symbol.spad from ${IN}/symbol.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/symbol.spad.pamphlet >symbol.spad ) +- +-@ + <>= + ${OUT}/SYMBOL.o: ${MID}/SYMBOL.NRLIB + @ echo 0 making ${OUT}/SYMBOL.o from ${MID}/SYMBOL.NRLIB +@@ -29508,13 +27260,6 @@ + + @ + \subsection{syssolp.spad \cite{1}} +-<>= +-${MID}/syssolp.spad: ${IN}/syssolp.spad.pamphlet +- @ echo 0 making ${MID}/syssolp.spad from ${IN}/syssolp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/syssolp.spad.pamphlet >syssolp.spad ) +- +-@ + <>= + ${OUT}/SYSSOLP.o: ${MID}/SYSSOLP.NRLIB + @ echo 0 making ${OUT}/SYSSOLP.o from ${MID}/SYSSOLP.NRLIB +@@ -29547,13 +27292,6 @@ + + @ + \subsection{system.spad \cite{1}} +-<>= +-${MID}/system.spad: ${IN}/system.spad.pamphlet +- @ echo 0 making ${MID}/system.spad from ${IN}/system.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/system.spad.pamphlet >system.spad ) +- +-@ + <>= + ${OUT}/MSYSCMD.o: ${MID}/MSYSCMD.NRLIB + @ echo 0 making ${OUT}/MSYSCMD.o from ${MID}/MSYSCMD.NRLIB +@@ -29586,13 +27324,6 @@ + + @ + \subsection{tableau.spad \cite{1}} +-<>= +-${MID}/tableau.spad: ${IN}/tableau.spad.pamphlet +- @ echo 0 making ${MID}/tableau.spad from ${IN}/tableau.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/tableau.spad.pamphlet >tableau.spad ) +- +-@ + <>= + ${OUT}/TABLBUMP.o: ${MID}/TABLBUMP.NRLIB + @ echo 0 making ${OUT}/TABLBUMP.o from ${MID}/TABLBUMP.NRLIB +@@ -29645,13 +27376,6 @@ + + @ + \subsection{table.spad \cite{1}} +-<>= +-${MID}/table.spad: ${IN}/table.spad.pamphlet +- @ echo 0 making ${MID}/table.spad from ${IN}/table.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/table.spad.pamphlet >table.spad ) +- +-@ + <>= + ${OUT}/EQTBL.o: ${MID}/EQTBL.NRLIB + @ echo 0 making ${OUT}/EQTBL.o from ${MID}/EQTBL.NRLIB +@@ -29804,13 +27528,6 @@ + + @ + \subsection{taylor.spad \cite{1}} +-<>= +-${MID}/taylor.spad: ${IN}/taylor.spad.pamphlet +- @ echo 0 making ${MID}/taylor.spad from ${IN}/taylor.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/taylor.spad.pamphlet >taylor.spad ) +- +-@ + <>= + ${OUT}/ITAYLOR.o: ${MID}/ITAYLOR.NRLIB + @ echo 0 making ${OUT}/ITAYLOR.o from ${MID}/ITAYLOR.NRLIB +@@ -29883,13 +27600,6 @@ + + @ + \subsection{tex.spad \cite{1}} +-<>= +-${MID}/tex.spad: ${IN}/tex.spad.pamphlet +- @ echo 0 making ${MID}/tex.spad from ${IN}/tex.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/tex.spad.pamphlet >tex.spad ) +- +-@ + <>= + ${OUT}/TEX.o: ${MID}/TEX.NRLIB + @ echo 0 making ${OUT}/TEX.o from ${MID}/TEX.NRLIB +@@ -29942,13 +27652,6 @@ + + @ + \subsection{tools.spad \cite{1}} +-<>= +-${MID}/tools.spad: ${IN}/tools.spad.pamphlet +- @ echo 0 making ${MID}/tools.spad from ${IN}/tools.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/tools.spad.pamphlet >tools.spad ) +- +-@ + <>= + ${OUT}/ESTOOLS.o: ${MID}/ESTOOLS.NRLIB + @ echo 0 making ${OUT}/ESTOOLS.o from ${MID}/ESTOOLS.NRLIB +@@ -30021,13 +27724,6 @@ + + @ + \subsection{transsolve.spad \cite{1}} +-<>= +-${MID}/transsolve.spad: ${IN}/transsolve.spad.pamphlet +- @ echo 0 making ${MID}/transsolve.spad from ${IN}/transsolve.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/transsolve.spad.pamphlet >transsolve.spad ) +- +-@ + <>= + ${OUT}/SOLVESER.o: ${MID}/SOLVESER.NRLIB + @ echo 0 making ${OUT}/SOLVESER.o from ${MID}/SOLVESER.NRLIB +@@ -30080,13 +27776,6 @@ + + @ + \subsection{tree.spad \cite{1}} +-<>= +-${MID}/tree.spad: ${IN}/tree.spad.pamphlet +- @ echo 0 making ${MID}/tree.spad from ${IN}/tree.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/tree.spad.pamphlet >tree.spad ) +- +-@ + <>= + ${OUT}/BBTREE.o: ${MID}/BBTREE.NRLIB + @ echo 0 making ${OUT}/BBTREE.o from ${MID}/BBTREE.NRLIB +@@ -30251,13 +27940,6 @@ + + @ + \subsection{trigcat.spad \cite{1}} +-<>= +-${MID}/trigcat.spad: ${IN}/trigcat.spad.pamphlet +- @ echo 0 making ${MID}/trigcat.spad from ${IN}/trigcat.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/trigcat.spad.pamphlet >trigcat.spad ) +- +-@ + <>= + ${OUT}/AHYP.o: ${MID}/AHYP.NRLIB + @ echo 0 making ${OUT}/AHYP.o from ${MID}/AHYP.NRLIB +@@ -30530,13 +28212,6 @@ + + @ + \subsection{triset.spad \cite{1}} +-<>= +-${MID}/triset.spad: ${IN}/triset.spad.pamphlet +- @ echo 0 making ${MID}/triset.spad from ${IN}/triset.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/triset.spad.pamphlet >triset.spad ) +- +-@ + <>= + ${OUT}/GTSET.o: ${MID}/GTSET.NRLIB + @ echo 0 making ${OUT}/GTSET.o from ${MID}/GTSET.NRLIB +@@ -30674,13 +28349,6 @@ + + @ + \subsection{tube.spad \cite{1}} +-<>= +-${MID}/tube.spad: ${IN}/tube.spad.pamphlet +- @ echo 0 making ${MID}/tube.spad from ${IN}/tube.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/tube.spad.pamphlet >tube.spad ) +- +-@ + <>= + ${OUT}/EXPRTUBE.o: ${MID}/EXPRTUBE.NRLIB + @ echo 0 making ${OUT}/EXPRTUBE.o from ${MID}/EXPRTUBE.NRLIB +@@ -30773,13 +28441,6 @@ + + @ + \subsection{twofact.spad \cite{1}} +-<>= +-${MID}/twofact.spad: ${IN}/twofact.spad.pamphlet +- @ echo 0 making ${MID}/twofact.spad from ${IN}/twofact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/twofact.spad.pamphlet >twofact.spad ) +- +-@ + <>= + ${OUT}/NORMRETR.o: ${MID}/NORMRETR.NRLIB + @ echo 0 making ${OUT}/NORMRETR.o from ${MID}/NORMRETR.NRLIB +@@ -30832,13 +28493,6 @@ + + @ + \subsection{unifact.spad \cite{1}} +-<>= +-${MID}/unifact.spad: ${IN}/unifact.spad.pamphlet +- @ echo 0 making ${MID}/unifact.spad from ${IN}/unifact.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/unifact.spad.pamphlet >unifact.spad ) +- +-@ + <>= + ${OUT}/UNIFACT.o: ${MID}/UNIFACT.NRLIB + @ echo 0 making ${OUT}/UNIFACT.o from ${MID}/UNIFACT.NRLIB +@@ -30871,13 +28525,6 @@ + + @ + \subsection{updecomp.spad \cite{1}} +-<>= +-${MID}/updecomp.spad: ${IN}/updecomp.spad.pamphlet +- @ echo 0 making ${MID}/updecomp.spad from ${IN}/updecomp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/updecomp.spad.pamphlet >updecomp.spad ) +- +-@ + <>= + ${OUT}/UPDECOMP.o: ${MID}/UPDECOMP.NRLIB + @ echo 0 making ${OUT}/UPDECOMP.o from ${MID}/UPDECOMP.NRLIB +@@ -30910,13 +28557,6 @@ + + @ + \subsection{updivp.spad \cite{1}} +-<>= +-${MID}/updivp.spad: ${IN}/updivp.spad.pamphlet +- @ echo 0 making ${MID}/updivp.spad from ${IN}/updivp.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/updivp.spad.pamphlet >updivp.spad ) +- +-@ + <>= + ${OUT}/UPDIVP.o: ${MID}/UPDIVP.NRLIB + @ echo 0 making ${OUT}/UPDIVP.o from ${MID}/UPDIVP.NRLIB +@@ -30949,13 +28589,6 @@ + + @ + \subsection{utsode.spad \cite{1}} +-<>= +-${MID}/utsode.spad: ${IN}/utsode.spad.pamphlet +- @ echo 0 making ${MID}/utsode.spad from ${IN}/utsode.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/utsode.spad.pamphlet >utsode.spad ) +- +-@ + <>= + ${OUT}/UTSODE.o: ${MID}/UTSODE.NRLIB + @ echo 0 making ${OUT}/UTSODE.o from ${MID}/UTSODE.NRLIB +@@ -30988,13 +28621,6 @@ + + @ + \subsection{variable.spad \cite{1}} +-<>= +-${MID}/variable.spad: ${IN}/variable.spad.pamphlet +- @ echo 0 making ${MID}/variable.spad from ${IN}/variable.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/variable.spad.pamphlet >variable.spad ) +- +-@ + <>= + ${OUT}/ANON.o: ${MID}/ANON.NRLIB + @ echo 0 making ${OUT}/ANON.o from ${MID}/ANON.NRLIB +@@ -31107,13 +28733,6 @@ + + @ + \subsection{vector.spad \cite{1}} +-<>= +-${MID}/vector.spad: ${IN}/vector.spad.pamphlet +- @ echo 0 making ${MID}/vector.spad from ${IN}/vector.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/vector.spad.pamphlet >vector.spad ) +- +-@ + <>= + ${OUT}/DIRPCAT-.o: ${MID}/DIRPCAT.NRLIB + @ echo 0 making ${OUT}/DIRPCAT-.o from ${MID}/DIRPCAT-.NRLIB +@@ -31307,13 +28926,6 @@ + + @ + \subsection{view2D.spad \cite{1}} +-<>= +-${MID}/view2D.spad: ${IN}/view2D.spad.pamphlet +- @ echo 0 making ${MID}/view2D.spad from ${IN}/view2D.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/view2D.spad.pamphlet >view2D.spad ) +- +-@ + <>= + ${OUT}/GRIMAGE.o: ${MID}/GRIMAGE.NRLIB + @ echo 0 making ${OUT}/GRIMAGE.o from ${MID}/GRIMAGE.NRLIB +@@ -31366,13 +28978,6 @@ + + @ + \subsection{view3D.spad \cite{1}} +-<>= +-${MID}/view3D.spad: ${IN}/view3D.spad.pamphlet +- @ echo 0 making ${MID}/view3D.spad from ${IN}/view3D.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/view3D.spad.pamphlet >view3D.spad ) +- +-@ + <>= + ${OUT}/VIEW3D.o: ${MID}/VIEW3D.NRLIB + @ echo 0 making ${OUT}/VIEW3D.o from ${MID}/VIEW3D.NRLIB +@@ -31405,13 +29010,6 @@ + + @ + \subsection{viewDef.spad \cite{1}} +-<>= +-${MID}/viewDef.spad: ${IN}/viewDef.spad.pamphlet +- @ echo 0 making ${MID}/viewDef.spad from ${IN}/viewDef.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/viewDef.spad.pamphlet >viewDef.spad ) +- +-@ + <>= + ${OUT}/VIEWDEF.o: ${MID}/VIEWDEF.NRLIB + @ echo 0 making ${OUT}/VIEWDEF.o from ${MID}/VIEWDEF.NRLIB +@@ -31444,13 +29042,6 @@ + + @ + \subsection{viewpack.spad \cite{1}} +-<>= +-${MID}/viewpack.spad: ${IN}/viewpack.spad.pamphlet +- @ echo 0 making ${MID}/viewpack.spad from ${IN}/viewpack.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/viewpack.spad.pamphlet >viewpack.spad ) +- +-@ + <>= + ${OUT}/VIEW.o: ${MID}/VIEW.NRLIB + @ echo 0 making ${OUT}/VIEW.o from ${MID}/VIEW.NRLIB +@@ -31483,13 +29074,6 @@ + + @ + \subsection{void.spad \cite{1}} +-<>= +-${MID}/void.spad: ${IN}/void.spad.pamphlet +- @ echo 0 making ${MID}/void.spad from ${IN}/void.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/void.spad.pamphlet >void.spad ) +- +-@ + <>= + ${OUT}/EXIT.o: ${MID}/EXIT.NRLIB + @ echo 0 making ${OUT}/EXIT.o from ${MID}/EXIT.NRLIB +@@ -31562,13 +29146,6 @@ + + @ + \subsection{weier.spad \cite{1}} +-<>= +-${MID}/weier.spad: ${IN}/weier.spad.pamphlet +- @ echo 0 making ${MID}/weier.spad from ${IN}/weier.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/weier.spad.pamphlet >weier.spad ) +- +-@ + <>= + ${OUT}/WEIER.o: ${MID}/WEIER.NRLIB + @ echo 0 making ${OUT}/WEIER.o from ${MID}/WEIER.NRLIB +@@ -31601,13 +29178,6 @@ + + @ + \subsection{wtpol.spad \cite{1}} +-<>= +-${MID}/wtpol.spad: ${IN}/wtpol.spad.pamphlet +- @ echo 0 making ${MID}/wtpol.spad from ${IN}/wtpol.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/wtpol.spad.pamphlet >wtpol.spad ) +- +-@ + <>= + ${OUT}/OWP.o: ${MID}/OWP.NRLIB + @ echo 0 making ${OUT}/OWP.o from ${MID}/OWP.NRLIB +@@ -31660,13 +29230,6 @@ + + @ + \subsection{xlpoly.spad \cite{1}} +-<>= +-${MID}/xlpoly.spad: ${IN}/xlpoly.spad.pamphlet +- @ echo 0 making ${MID}/xlpoly.spad from ${IN}/xlpoly.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/xlpoly.spad.pamphlet >xlpoly.spad ) +- +-@ + <>= + ${OUT}/FLALG.o: ${MID}/FLALG.NRLIB + @ echo 0 making ${OUT}/FLALG.o from ${MID}/FLALG.NRLIB +@@ -31871,13 +29434,6 @@ + + @ + \subsection{xpoly.spad \cite{1}} +-<>= +-${MID}/xpoly.spad: ${IN}/xpoly.spad.pamphlet +- @ echo 0 making ${MID}/xpoly.spad from ${IN}/xpoly.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/xpoly.spad.pamphlet >xpoly.spad ) +- +-@ + <>= + ${OUT}/FMCAT.o: ${MID}/FMCAT.NRLIB + @ echo 0 making ${OUT}/FMCAT.o from ${MID}/FMCAT.NRLIB +@@ -32090,13 +29646,6 @@ + + @ + \subsection{ystream.spad \cite{1}} +-<>= +-${MID}/ystream.spad: ${IN}/ystream.spad.pamphlet +- @ echo 0 making ${MID}/ystream.spad from ${IN}/ystream.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/ystream.spad.pamphlet >ystream.spad ) +- +-@ + <>= + ${OUT}/YSTREAM.o: ${MID}/YSTREAM.NRLIB + @ echo 0 making ${OUT}/YSTREAM.o from ${MID}/YSTREAM.NRLIB +@@ -32129,13 +29678,6 @@ + + @ + \subsection{zerodim.spad \cite{1}} +-<>= +-${MID}/zerodim.spad: ${IN}/zerodim.spad.pamphlet +- @ echo 0 making ${MID}/zerodim.spad from ${IN}/zerodim.spad.pamphlet +- @(cd ${MID} ; \ +- ${SPADBIN}/notangle ${IN}/zerodim.spad.pamphlet >zerodim.spad ) +- +-@ + <>= + ${OUT}/FGLMICPK.o: ${MID}/FGLMICPK.NRLIB + @ echo 0 making ${OUT}/FGLMICPK.o from ${MID}/FGLMICPK.NRLIB +@@ -32512,7 +30054,7 @@ + @ echo OBJ= ${OBJ} MNT= ${MNT} O=${O} LISP=${LISP} BYE=${BYE} + + #src: ${AS} +-src: ${SPADFILES} ${ORDER} ++src: ${MID}/INTERP.EXPOSED ${ORDER} + @ echo Building NRLIBS from spad sources + + # @ (cd ${MID} ; \ +@@ -32544,7 +30086,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32555,7 +30096,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32770,7 +30310,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32799,14 +30338,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -32829,7 +30366,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32848,7 +30384,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32875,7 +30410,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32902,7 +30436,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32937,7 +30470,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32956,7 +30488,6 @@ + <> + <> + +-<> + <> + + <> +@@ -32993,7 +30524,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33014,7 +30544,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33133,14 +30662,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33166,14 +30693,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33202,42 +30727,36 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33260,7 +30779,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33560,7 +31078,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33579,7 +31096,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33590,21 +31106,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33625,7 +31138,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33636,7 +31148,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33655,14 +31166,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33685,7 +31194,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33696,7 +31204,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33707,7 +31214,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33718,28 +31224,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33774,7 +31276,6 @@ + <> + <> + +-<> + <> + + <> +@@ -33785,14 +31286,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33803,14 +31302,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33853,28 +31350,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33885,14 +31378,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33911,28 +31402,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33943,21 +31430,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33972,14 +31456,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -33990,14 +31472,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34018,14 +31498,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34062,7 +31540,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34097,7 +31574,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34112,14 +31588,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34138,35 +31612,30 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34197,14 +31666,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34231,21 +31698,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34256,21 +31720,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34285,7 +31746,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34302,14 +31762,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34324,7 +31782,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34333,14 +31790,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34379,35 +31834,30 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34418,7 +31868,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34451,7 +31900,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34466,21 +31914,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34499,21 +31944,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34532,7 +31974,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34542,7 +31983,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34569,21 +32009,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34594,7 +32031,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34613,7 +32049,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34624,7 +32059,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34655,7 +32089,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34670,7 +32103,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34697,7 +32129,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34732,7 +32163,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34751,7 +32181,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34762,14 +32191,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34806,7 +32233,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34837,7 +32263,6 @@ + <> + <> + +-<> + <> + + <> +@@ -34852,21 +32277,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34897,56 +32319,48 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -34979,28 +32393,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35019,7 +32429,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35034,14 +32443,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35052,70 +32459,60 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35125,14 +32522,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35159,7 +32554,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35178,7 +32572,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35193,7 +32586,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35208,7 +32600,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35219,7 +32610,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35242,14 +32632,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35278,7 +32666,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35289,7 +32676,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35306,7 +32692,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35321,14 +32706,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35355,7 +32738,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35378,14 +32760,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35400,7 +32780,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35426,14 +32805,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35444,7 +32821,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35465,14 +32841,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35487,7 +32861,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35498,7 +32871,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35509,28 +32881,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35561,14 +32929,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35587,7 +32953,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35614,7 +32979,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35639,7 +33003,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35662,7 +33025,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35689,7 +33051,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35710,7 +33071,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35733,7 +33093,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35752,35 +33111,30 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35807,14 +33161,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35823,21 +33175,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35848,14 +33197,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35870,14 +33217,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35888,14 +33233,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35906,7 +33249,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35921,7 +33263,6 @@ + <> + <> + +-<> + <> + + <> +@@ -35944,14 +33285,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -35996,7 +33335,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36015,7 +33353,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36040,7 +33377,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36067,7 +33403,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36088,7 +33423,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36099,14 +33433,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36116,7 +33448,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36133,7 +33464,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36147,7 +33477,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36162,7 +33491,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36173,21 +33501,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36202,9 +33527,6 @@ + <> + <> + +-<> +-<> +- + <> + <> + <> +@@ -36213,7 +33535,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36230,7 +33551,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36245,7 +33565,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36260,7 +33579,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36295,14 +33613,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36321,7 +33637,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36332,14 +33647,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36350,14 +33663,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36372,7 +33683,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36401,7 +33711,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36414,7 +33723,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36429,7 +33737,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36440,7 +33747,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36455,7 +33761,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36486,7 +33791,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36513,14 +33817,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36563,7 +33865,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36586,7 +33887,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36605,7 +33905,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36616,7 +33915,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36627,7 +33925,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36638,7 +33935,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36649,7 +33945,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36660,7 +33955,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36671,7 +33965,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36698,7 +33991,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36709,7 +34001,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36720,21 +34011,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36745,21 +34033,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36770,14 +34055,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36794,7 +34077,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36809,7 +34091,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36852,7 +34133,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36899,7 +34179,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36910,28 +34189,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -36942,7 +34217,6 @@ + <> + <> + +-<> + <> + + <> +@@ -36979,21 +34253,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37014,7 +34285,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37025,7 +34295,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37042,14 +34311,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37072,7 +34339,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37095,14 +34361,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37113,14 +34377,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37131,21 +34393,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37172,7 +34431,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37197,28 +34455,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37235,7 +34489,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37246,7 +34499,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37257,7 +34509,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37268,7 +34519,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37283,7 +34533,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37322,7 +34571,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37333,14 +34581,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37355,7 +34601,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37394,14 +34639,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37420,7 +34663,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37439,28 +34681,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37475,21 +34713,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37504,7 +34739,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37519,7 +34753,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37542,14 +34775,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37578,7 +34809,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37605,14 +34835,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37623,28 +34851,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37659,28 +34883,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37689,21 +34909,18 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37714,7 +34931,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37745,7 +34961,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37760,7 +34975,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37771,7 +34985,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37786,7 +34999,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37797,7 +35009,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37830,7 +35041,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37883,7 +35093,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37908,7 +35117,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37927,7 +35135,6 @@ + <> + <> + +-<> + <> + + <> +@@ -37938,35 +35145,30 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -37989,7 +35191,6 @@ + <> + <> + +-<> + <> + + <> +@@ -38026,7 +35227,6 @@ + <> + <> + +-<> + <> + + <> +@@ -38037,28 +35237,24 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -38073,14 +35269,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -38091,7 +35285,6 @@ + <> + <> + +-<> + <> + + <> +@@ -38132,7 +35325,6 @@ + <> + <> + +-<> + <> + + <> +@@ -38175,14 +35367,12 @@ + <> + <> + +-<> + <> + + <> + <> + <> + +-<> + <> + + <> +@@ -38209,7 +35399,6 @@ + <> + <> + +-<> + <> + + + +--=-60OPaxFfLcp8qTKvunBC-- + + + + diff --git a/changelog b/changelog index 6df2664..34ccd6e 100644 --- a/changelog +++ b/changelog @@ -1,3 +1,5 @@ +20140418 tpd src/axiom-website/patches.html 20140418.04.tpd.patch +20140418 tpd book/2003-08.txt regularize 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